Terminology

• A website that relies on assertions from the user agent is referred to as a service provider (SP).
• A web service that issues cards to the user, authenticates the user agent to the card, and provides a set of signed claims on request by the user agent is referred to as a identity provider (IdP).
• An attribute about the user is sometimes referred to as a claim.
• The software integrated with the browser (either entirely within a browser extension, or invoked by the extension) is referred to as an active client or sometimes as a selector.

Lessons Learned

This section summarizes what worked and what didn’t across all known Infocard projects.

User Experience

• Card metaphor. Expressing a facet of a person’s composite digital identity as a card, seemed to work well. There are two broad classes of cards. A managed card represents a set of claims from an external IdP. A managed card holds no claim values, but rather the endpoint of an IdP web service (often called a Security Token Service (STS)). A personal card represents (and physically holds) a set of self-asserted claims from the active client’s internal IdP.
• Usability. First generation Infocard implementations provided complete transparency, notice and consent to the user related to every disclosure of claims to an SP. While providing the best possible security and privacy, the experience was considered overly intrusive and annoying. The balance needed to be readjusted. To improve usability, and admittedly at the expense of some privacy and security, more recent active clients implemented the following usability improvements:
  • Instead of popping up the card selector window each time, the selector would remember what card had been used on the previous visit to this same SP. Microsoft’s CardSpace 2 beta (never released) selector experimented with an option wherein the SP rendered the image of the previously used card “inline” within their web page. Clicking on this card would cause the login (claims transmission) without popping up the card selector window at all.
  • Instead of showing all of the details of the claims required and/or desired by the SP in the initial card selector window, these details were hidden and accessed by drilling in on a link. Examination of the UI of OAuth-based systems in the wild shows that the OAuth (e.g. Facebook Connect, etc.) community has come to an even more extreme simplification of the UI in this area. The UI is often reduced to a checkbox saying that the user is consenting to the disclosure to the OAuth consumer of “some”, [unspecified and not discoverable list of] attributes and other kinds of disclosures.
• Automatic card matching worked well and was critical to simplifying the user experience. Card matching refers to the active client only displaying the set of cards whose characteristics (e.g. the set of claims it supports, the card issuer, etc.) satisfy the requirements described in the SP’s policy (e.g. the set of claims desired and/or required, the set of IdPs that are trusted by this SP, etc.)
• Performance. All common user interactions must happen in less than a second. Early selectors took several seconds to load and display the “card picker” window (especially the first time). This sluggishness was annoying.
• Roaming. The active client must roam the person’s digital identity (i.e. their set of cards) across all of that user’s devices and browsers.
• Unmodified browser support. A major drawback to Infocard is the inability for it to work work even in a simplified and/or degraded manner with an unmodified browser. We learned that future solutions should instead follow a “better with” philosophy. That is, they should work in some fashion with an unmodified browser and then work “better” if a browser-integrated active client is available.
• Card bootstrapping. Infocard failed to provide a UI that would guide the user who didn’t have any cards that satisfied the SP’s policy, to find and get a suitable card. In this situation future solutions must guide the user to a list of possible card issuing sites (IdPs) where a suitable card can be obtained.
• Active client bootstrapping. Infocard failed to provide a UI that would guide the user who didn’t have an active client (or cloud selector) into becoming provisioned with one. Future solutions must guide the user from the SP side to a list of possible (and likely competing) cloud selectors. And, following the “better with” philosophy to a list of identity-capable browsers and/or browser extensions.
• Cross-platform. The solution must be available on all of the user’s computing platforms including mobile devices.
• Cross-browser. Users often use multiple browsers, the solution must work across all popular browsers.
• Cross-protocol. Users simply want things to work. They don’t care about underlying protocols. The solution should present a consistent UX for identity-related interactions irrespective of underlying protocol. Infocard introduced a new, incompatible protocol with that had the effect splintering the identity ecosystem further and introducing yet-another competing UX to learn and use.
• Dynamic claims. Infocards failed to support the dynamic claims. In some cases the SP needs to be able to not just indicate the types of claims required (e.g. givenname, employer, etc.) but also to be able to indicate (dynamic) parameters to the claims. In payment use cases (e.g. using a card to pay for an item at checkout) the SP must be be able to pass the price as a parameter along with its other “policy” information back to the active client so that the client can in turn pass this price parameter back to the IdP (e.g. a bank). The Infocard community never achieved consensus on how to implement this. Axel Nennker suggested an approach that both his own research project and the French FC2 consortium implemented in their respective selectors.
• Claims aggregation. In more complex use cases SPs need to aggregate claims from multiple IdPs (e.g. physical address information from your mobile provider and payment information from your bank). With most Infocard solutions this causes the selector “card picker” UI to appear multiple times in succession (once for each IdP). This is annoying for the user. David Chadwick worked on and the FC2 consortium implemented multi-card selection in their research selector however the Infocard community never reached consensus on an SP policy format that would support a single request for claims from multiple IdPs. See also my opinions in my Attributes First post.
• Brokered authentication (and claims providers vs. identity providers). Current Infocard solutions require the user to authenticate to each (managed) card issuer (IdP) in order to use the card. While the number of passwords (and other challenges) was greatly reduced from the usual one-password-per-SP model, it wasn’t reduced to a single master password (or other kind/set of “master” challenges). To achieve this, a distinction should be made between an identity provider and a claim provider. Ideally the user would have a very small number of identity providers (ideally perhaps just one) to which they would authenticate themselves using a specific, consistent method for a given level of assurance (and other specific, consistent methods for progressively higher levels of assurance). Claims providers would then rely on assertions from identity providers. The active client would “broker” the identity assertions from the IdP and pass them along with their requests to claims providers. The FC2 consortium in their research active client implemented the ability to have multiple claims providers leverage the results of a single authentication to an identity provider (e.g.  a government issued smart card).

Capabilities

• Decentralized architecture. Infocard architecture allows IdPs, active clients, and SPs to be developed independently of one another.
• Extensible schema. For managed cards, the issuer of the card (i.e. the IdP) may independently define the set of claims it chooses support. The browser’s active client dynamically supported any set of claims on a managed card. This loosely coupled, extensible approach worked well. It relied on market forces to “socialize” a set of claim types that one or more IdPs might issue and one or more SPs might rely on. The personal cards as implemented by Microsoft supported a fixed 14 claim-type schema. There was some discussion in open source projects of allowing personal (self-asserted) cards to also support an extensible schema but this was never implemented.
• Claims as URIs. URIs worked well as claim types since they provide a well-understood global namespace management approach. But we could have gone further. The URIs were treated within the Infocard active clients as opaque strings. There have been discussions initially with Dick Hardt and later with Mark Wahl, Drummond Reed, Markus Sabadello, John Bradley, Axel Nennker and others about the benefits of actually having these claim/attribute URIs be dereferenceable to a metadata description of themselves. There were some early proposals on the semantics of this metadata. Each advocate for a given set of semantics preferred a different serialization format: Dick’s was in XML, Mark’s in RDFa, Higgins used RDF, etc. No consensus was ever reached on either the semantics or the serialization. See Identity Schemas WG for some related work on claim URIs.
• Claim catalog. The ecosystem of Infocard proponents created a central, common Claim Catalog to promote interoperability. The thought was that we should have a common repository of well-known claims in order to prevent unnecessary minting of claims with the same semantics as existing claims. The catalog was maintained using a lightweight process based on an email list managed by the Schemas WG of the Information Card Foundation. This process worked well. We noticed that despite the fact that minting claim URIs rooted in one’s own domain offers no advantage over using the standard “http://schemas.informationcard.net/@ics” organizations acting as IdPs often preferred to use their own domains.
• Browser-initiated invocation. Unlike SAML and similar redirect-based approaches wherein the SP initiates the flow, with Infocard the browser actively looks for “trigger” markup in the SP web page and if it is found invokes and displays the selector app. This approach worked well and provided a level of phishing protection. The Microsoft-proposed, (later, OASIS IMI) trigger mechanism was an embedded <object> tag in the HTML. An alternative mechanism was implemented by Axel and Higgins that used a URI link to trigger invocation. This URI used a  scheme (e.g. “icard:”) that was detected as a trigger by browser plugins. This approach has a second key advantage, namely, that it works with mobile smartphones. Smartphone borwsers (e.g. iPhone and Android) while not supporting plugins to associate apps with URI schemes. This allowed an active client (aka selector) app to be associated with the scheme.
• Passive advertisement of SP policy. Markup in the SP passively declares the SP’s policy–things like what identity providers (IdPs) are trusted by the SP (or if self-asserted claims are acceptable, the set of “required” claims, the set of “optional” claims. The Microsoft-proposed, (later, OASIS IMI), approach included the policy as embedded markup within the <object> tag. Axel, Kantara ULX, Higgins and others felt that instead the trigger mechanism (see above) should be separated from the SP policy description. By using a URI scheme for the trigger mechanism, the URI acts as a reference to the policy. Some work was done on defining a JSON format for this policy.
• Minimal disclosure. When the user selects a card to “send” to the SP, the active client provides minimal set of claims necessary, not all of the claims “supported” by the card.
• Non-correlatable identifiers (PPIDs). The active client generated pair-wise unique Private Personal Identifiers (PPIDs) to allow persistent SP-specific pseudonyms. This capability increased privacy while ensuring that the SP can reliably recognize the same visitor over time.
• Audit logs. Active clients implemented audit logs (sometimes called ledgers) that kept track of what claims the user had disclosed to which SP.

Implementation trade-offs

• Performance vs. security. The original Infocard implementation with its secure desktop while more secure was considered unacceptably sluggish.
• Cost of cloud services. Cloud-based selectors have many advantages, however their reliance on centralized processing increases the cost to deploy them.
• Pure browser extension vs. browser extension + app. Whereas a pure browser extension has deployment advantages (easy download/install and in some cases some cross platform support), five years ago the thinking was that such an approach had three disadvantages: (i) the lack of isolation in browsers (at that time) meant that the selector would be too vulnerable to attack (ii) a pure browser extension wouldn’t be useable by local (non-browser-based) apps and would thus not be as “universal” a solution (iii) it would take more development effort since more of the code would be browser-dependent and less of it common, browser-independent code. Note: the latest thinking in Higgins 2.0 is to go back to the original approach. On these three points the thinking is now, respectively: (i) the security characteristics of browsers are now good enough, (ii) non-browser-based apps are less important to worry about, and it may even be possible to have a local app leverage the browser (iii) the benefits of i) and ii) outweigh the cost of a lot of per-browser development.
• Identity in the browser vs. Identity in the platform. CardSpace and most (though not all) other active clients were separate applications that were invoked by browser extensions. In the case of CardSpace the application was bundled with the operating system (e.g. Vista and Windows 7) and was more correctly “identity in the platform.” The benefit of this approach is that the active client can be invoked by applications other than the browser. In this way the user has a consistent “identity” experience across both the Web and local apps. The Higgins project implemented a “selector switch” abstraction layer that decoupled the user’s choice of browser from the user’s choice of active client application. It allowed, for example, IE to invoke CardSpace or a Higgins-based active client. Until an “identity” layer is integrated into either the platform or the browser, users will have to download and install something. Experience has shown that making this installation experience extremely light and fast is very important for user adoption. As a consequence the Higgins 2.0 project has backed off from the “in the platform” goal and has (for now) abandoned the selector switch idea because the simplest and fastest user experience (for conventional PCs) is the installation of a browser extension using the browser’s native installation mechanisms.

Driving Adoption

• Focus on SPs. Infocard proponents were too slow to realize that the hardest part of driving adoption is getting the SPs to adopt the technology (not recruiting IdPs nor even building active client support into browsers). Resources must be invested in creating libraries and services to make it as easy as possible for SPs to adopt a new technology, especially since SPs are so numerous compared to the population of IdPs.
• Create a non-competitive, layered, protocol stack. As mentioned above, users simply want identity-related interactions to work with a consistent experience irrespective of the underlying protocols. Layering a consistent experience over protocols that were never designed to work together appears to be difficult and creates a fragmented, competitive landscape. A more promising approach would be to collaboratively create a layered model of protocols and user experiences. This could unify the ecosystem instead of creating multiple competing solutions with differing strengths and weaknesses.
• Microsoft vs. an ecosystem. Microsoft, having gotten a black eye years before with Passport and Hailstorm, was determined to learn from these mistakes with Infocard. And they did. The changes were profound: the Infocard architecture was decentralized, the network protocols were  contributed to a standards organization (OASIS), the IP was covered by an Open Specification Promise (basically an agreement not to sue developers) and Microsoft was uncharacteristically open and collaborative with open source projects (e.g. Higgins). They genuinely wanted to see the emergence of active clients integrated with other browsers and other (especially non-Windows!) platforms. The reality was quite good. The problem was one of market perception. Despite the collaboration, openness, standardization, IP stances taken etc. the perception in the market was that Infocard was a “Microsoft” technology. Industry analysts by lauding Kim and his team for their seminal contributions and by never quite realizing that solving the Internet identity problem would “take a village” (an ecosystem with multiple tech providers). The unintended consequence of promoting Microsoft’s early role was to limit greatly the appeal of Infocard. Many at Microsoft could never quite understand that the more they promoted Infocard (and thereby made it seem like a Microsoft-controlled technology), the less successful it would be in the marketplace.

History

We begin by describing Microsoft CardSpace and then discuss other projects and how they differed and innovated.

2006: Microsoft Windows CardSpace 1.X

In 2006 Kim Cameron and his team at Microsoft released Windows CardSpace.

The following section describes the salient points about CardSpace.

Cards & Selectors

• Uses the card UX metaphor (and introduced a browser-integrated “identity selector” client app to hold and manage them). A card is a metaphor for a digital identity–a set of claims (attributes) by some issuer (the user or an IdP)
• Supports personal cards (that contain attributes (aka claims) & values as asserted by the user)
• Supports managed cards (that contains a pointer to an IdP (the IdP that issued the card to the user))

Sending a Card to a Site User Experience

• User goes to a website and sees a purple icon.
• The icon indicates that the site either wants the user to login or it wants the user to provide a set of claims.
• User clicks on the icon and the selector application’s “card selector” UI window is displayed
• A set of zero, one or more cards that match the SP’s policy (requirements) is shown within this window
• The user clicks on a card to “send” it to the site

Get Card User Experience

• User goes to a card-issuing website
• User logs in and may have to provide other attributes
• User clicks on the icon of a card
• User downloads an info card (a 3kb-ish signed XML file) that is automatically imported into the user’s selector

Architectural Highlights

• Overview: browser plugin that communicates with a desktop selector app. Selector was almost entirely written in managed (C#) code and leveraged .NET.
• Browser-initiated invocation. Unlike SAML and similar redirect-based approaches wherein the SP initiates the flow, with Infocard the browser actively looks for “trigger” markup in the SP web page and if it is found invokes and displays the selector app.
• Passive advertisement of SP policy. Markup in the SP passively declares the SP’s policy–things like what identity providers (IdPs) are trusted by the SP (or if self-asserted claims are acceptable, the set of “required” claims, the set of “optional” claims.
• Selector-to-IdP protocols: based on a suite of SOAP protocols centered on WS-Trust.
• Selector/browser-to-SP protocols: HTTP(S) POST of a security (e.g. SAML 1.1, etc.) token.
• Security: selector supported only a single “getToken()” API.
• Security: the selector runs in its own protected operating system process called a secure desktop.

Implementation

• Commercially released application.
• Compatible with IE.
• Installable on Windows XP; bundled with Vista & Windows 7.

Capabilities

• Federated login. User can login to a SP without an SP-specific password.
• Verified claims. User can convey a signed set of claims from an IdP to the SP.
• Multiple identities. Each card represents a different digital identity of the user. Each card supports a different set of claims. For example, a card might support only the single claim that a person is over the age of 21.
• Card matching. When the card selector window appears only the set of cards whose characteristics (e.g. IdP domain, set of supported claims, etc.) match what the SP has declared in their policy are displayed.
• Minimal disclosure. Only the intersection of (a) the set of claims supported by the card/IdP and (b) the set of claims required by the SP, are disclosed to the SP.
• Non-correlatable identifiers (PPIDs). An identifier (e.g. an email address or userid, etc) is a kind of claim. For privacy reasons where possible cross-SP correlatable identifiers should be avoided and less identifying claims used instead. CardSpace used a pair-wise key generated between the selector and the SP to generate the value of a PPID claim (if the SP policy asked for it). In this way the SP can reliably know that this was the same user as an earlier visit without being able to collude with other SPs to aggregate information about the user.
• Audit logs. The selector automatically maintained a log of what cards & claims had been used at what SPs
• SP authentication. The selector provided visual cues to help the user recognize the identity of the SP

2006-2010: Eclipse Higgins 1.0 and 1.x

Cross-browser and Cross Platform support

The Higgins project initially wanted to see if a selector could be implemented entirely as a pure browser extension. This would have the advantage of making it more easily deployed, and for cross-platform browsers (e.g. Firefox) would provide a cross platform solution. The initial browser targeted was Firefox 2.x as shown below.

Higgins also experimented with another approach to achieving cross platform support, namely by developing a native application written in a cross-platform toolkit. Contributors to Higgins from Novell created a GWT-based selector to run on several flavors of Linux as well as Windows. Theoretically a GWT-based app could also run on OSX, but in practice the UI wasn’t acceptable, so a native Cocoa-based app was also developed by the Novell team.

Roaming

One of the most serious drawbacks of the selectors mentioned above is that they suffer from the “card roaming” issue. Since cards are stored within the selector clients, if the user wishes to use more than one machine, or borrow someone’s computer, or use a kiosk, etc. their cards are not available. Two approaches to address this limitation were pursued at Higgins.

One approach was to develop the heart of the selector as web service. Then, the active client portion that is integrated with the browser is merely a presentation layer with the cardstore being resident in the web service. The Higgins I-Card Service is such a service, and provides web services to a “UI-only” Adobe AIR rich client selector as well as the iPhone selector shown below.

Mobile Browsers

A number of mobile Infocard solutions have been developed. As mentioned in the Lessons Learned section, since mobile browsers don’t support plugins it was necessary to replace the IMI-defined <object> tag trigger with a URI-based trigger in the SP’s web pages.

As an example of a mobile solution, the Higgins iPhone Selector relies on a hosted I-Card web service:

A second approach to providing card roaming was also explored and partially implemented. In this architecture the selectors would be full clients having their own local cardstores but have the ability to optionally take advantage of a cloud-based cardstore and synchronization service.

Browser-Only Support (Cloud Selectors)

One of the most serious drawbacks of the active client approach is quite simply that they require an active client (even if in some cases this active client is merely a browser extension) in order to work. Within Higgins a Cloud Selector was developed that worked with an unmodified browser. The cloud selector relied on OpenID to allow the SP to initiate redirect to the cloud selector. The “back end” of the cloud selector remained unchanged with the required security token being returned in the second redirect back to the SP. Note that without an active client more care must be taken (e.g. a second factor of authentication added) to strengthen the authentication between the user and selector.

David Siegel calls it a Personal Data Locker, others Personal Data Space or Personal Data Vault. W3C folks are working on Personal Data Wiki. I was just on a VRM call today. At Drummond’s suggestion a bunch of us are going to try to create wikipedia entries, and hopefully a diagram (as Iain Henderson suggested) that define some common terms. It would be helpful at this early “market development” stage to have a common set of terms that developers and techies can understand. Here are my contributions:

Terms:

• Personal Data Service (PDS) – A service that enables the user to participate as a peer within a distributed personal data ecosystem. A PDS provides one or more of the following services: (a) a web portal that provides a dashboard view of the user’s data, the ability update self-asserted data, and a way to manage authorizations (e.g. using something like an UMA Authorization Manager) and set policies under which 3rd parties gain access to portion of the user’s information, (b) supports a Discovery API that allows you to be discoverable by other people, organizations, apps and exchanges whose inquiries that meet criteria you specify, and (c) provides an identity provider (IdP) endpoint (e.g. OpenID OP)
• Attribute Data Service – Service that (A) locally stores your self-asserted data attributes, makes them available via APIs, and supports active clients. Ideally these self-asserted data are stored in encrypted form using a key that the PDS operator does not know. It also (B) maps data from both external data services (e.g. Facebook, etc.) as well as from external Personal Data Services (e.g. your friend’s PDS or a PDS managed by your favorite telco), makes it all available via APIs (e.g. XDI, SPARQL, oStatus, etc.), and supports active clients.
• 3rd Party App – A web app that consumes data from the PDS. These include information refineries –a kind of app that reads datasets from the PDS, refines them, and writes them back to the PDS user. The refinery process includes analytics, inferencing, segmentation, etc. Refineries generally to create higher value, more refined data from the more raw forms of data, while often also making the data sets less personally identifying. These also include information exchanges–a kind of PDS App that is involved in creating personal data exchanges analogous to a stock exchange. An exchange itself is a platform that supports yet another layer of apps above it [this is not shown above].

Couldn’t resist drawing a picture:

I’ve annotated the diagram above with little “H” and “A” markers so you can see specifically the areas that Higgins and Azigo are working on respectively. Lots of other folks are also working on other parts of the picture too, of course.

Apps

Apps are of course the most important kind of component since they are what the end user sees and appreciates. Apps gain access to the user’s data by making calls (e.g. getAttribute) to an API exposed by the PDS Client. Architecturally, we’ve seen the need to support both conventional kinds of apps: web, mobile (iPhone, Android, etc.), and desktop, as well as a more unusual kind of app, I’ll call a Javascript app.  In this latter case Javascript is fetched from a web service (e.g. from Kynetx KNS) injected locally into your browser by a browser extension. This same browser extension exposes the same PDS Client API to this Javascript program.

Dashboard

The dashboard is an admin GUI app for your personal data. It is an occasional-use tool that provides: (a) a control panel to manage the permissioning policies that control which of your attributes are shared with whom (including so-called “selector” functionality to approve the release of your info)  (b) a dashboard GUI to see and manage all of your identity data attributes (including profile data, credentials, friends lists, etc.) whether stored in your own PDS or managed by others (c) a place to directly enter self-asserted attributes (d) an embedded app marketplace (e) a canvas area where apps can extend the UI to add their own admin interfaces (f) a place to import & manage your i-cards and OpenID OP relationships.

ASIDE: Dashboard is a new word I’m trying out. The reality is that this piece of software is a bit of a swiss army knife where each blade/tool is called something different. A few examples: Microsoft calls the aspect that pops up to give notice and consent to release a set of attributes an identity selector. Inside Google they call identity-related client add-ons to a browser an active client. The “show me all of my stuff” aspect does sound like a dashboard. On the other hand, the permissioning aspect is something Eve would call a relationship manager (or I think she would). And I think Bob Blakley would too.

The dashboard combines aspects of earlier client efforts. In 2006-2007 we saw Information Card Selectors like Windows CardSpace as well as the Higgins selectors provide an interface to view and manage multiple digital identities displayed as visual cards, as well as provide notice and consent to the release of your selected digital identity. In 2009 Azigo augmented the selector concept support for Kynetx apps in Azigo (along with cross-platform and card roaming support). Prototypes shown by Microsoft (e.g. OpenID Active Client) and Higgins at IIW in 2009 added OpenID support thus demonstrating multi-protocol support. Mozilla Lab’s Account Manager is doing some great work in this area. The Higgins project is working on a next-generation client as part of the Higgins 2.0 Active Client expected in 2011.

Personal Data Store

A PDS is a web service that works on your behalf, giving you more control over your own personal data whether it is stored in the PDS or managed elsewhere. PDS stores local attributes in blinded form so that only the user has the decryption key–not the PDS service provider. The PDS is an idea that has been underdevelopment for years. For some background see Joe Andrieu, Joe again, and Iain Henderson. As part of Higgins 2.0 the PDS is being developed. Another interesting PDS development project is Mine!

PDS Client

The PDS Client has no UI, but provides an API for apps that wish to read/write attributes from the PDS. Here are some of its functions:

• Maintains (and syncs to the PDS and other clients) the user’s ”permissions”–the decisions that the user has make as to who (what app or relying party) has access to what attributes. For example, the first time a new app/RP asks for a certain set of attributes, the PDS Client will trigger the PDS Dashboard to present the policy decision to the user. The next time this same request happens, the PDS Client remembers the grant and usually doesn’t have to bother the user about it this time.
• Maintains a local copy of some or all of the person’s personal data stored in the remote PDS
• Maintains an OAuth WRAP access token that it gets by authenticating itself to an external authentication service. It passes this token along in XDI messages to the remote PDS service.
• Can be configured to encrypt attribute values before they are sent over the wire (e.g. in XDI messages) to the remote PDS
• Contains a local Security Token Service (STS) that allows it to create and sign SAML (for example) tokens for self-asserted attributes.
• Contains an STS client to support remote IdP/STSes managed by external parties (e.g. to support managed i-cards).
• Performs cross-context schema mapping.

The Higgins 2.0 PDS Client is packaged as either a C++ or Java code library or as a separate operating system process (e.g. on Windows it is a Windows Service).

Network Protocol

Drummond Reed with his OASIS XDI and OASIS XRI work was first to my knowledge to define an open data web. A few years later Tim published his Linked Data paper. We’re starting to see implementations of Linked Data so now the Semweb folks also have a data web. Both of these approaches are important.

An open community is starting to form around the XDI that is focused on PDS-related use cases and create might be called a profile of XDI in this area. The community is leveraging XDI’s existing strengths in the areas of identity management integration, security, access control, data sharing and versioning, as well as extending them where needed in order to meet the PDS-related requirements.

This focus probably provides a critical time-to-adoption advantage over the Linked Data effort in this PDS area. Since the objective is interoperability (i.e. an interoperable ecosystem of PDSes and apps over a common protocol) assembling a community focused on this area would seem to be the fasted way to get there. Linked Data (like “vanilla” XDI) has a much broader link-all-the-worlds-data-together mission and lacks direct support for many of the PDS-related requirements. As a consequence RDF developers (including Higgins) define ad-hoc extensions to RDF to make it support the PDS use cases that are only interoperable within their own developer community.

PDS Schema

The Higgins PDS uses its own internal schema called the Persona data model. This is not to say that the PDS architecture imposes a single ontology on its clients. Quite the opposite. Every attribute call (e.g. getAttribute) may request attributes in any vocabulary. As I’ve mentioned in my schema mapping post, we follow the philosophy of mapping into and out from the internal schema.

Authorization Manager (AM)

The AM provides the “back end” authorization manager for access control of attributes managed by data services other than your own PDS. The Higgins project has been tracking the promising UMA Authorization Manager effort that Eve Maler and others have been developing.

Kynetx KNS

KNS is a web service that serves up compiled Javascript apps for injection into browsers. The app developer uses the Kynetx AppBuilder tool to create apps. Each app is packaged as an information card. The developer puts this app on their website for folks to download and install. If you click on it and already have a PDS Dashboard the new app gets installed in about one second. If you click on it an you don’t already have a PDS Dashboard, then you download an installation package that includes a Dashboard (with the app pre-installed inside it).

And while we’re being lazy, we just sit back and watch as these schema-creators evangelize their particular schema as far and as wide as they wish to. Today the only way an IdP can talk to an RP is if both know how to speak a common schema. This is true regardless of protocol or transport. It is as true of SAML tokens as OpenID attributes.

Its all a form of tight coupling. And tight coupling requires a lot of effort. You know what they say “consensus is harder than code.” Experience shows that the richer the schema the higher the costs to get everyone on board, the longer the process takes, and the narrower the diffusion/adoption. These economic realities drive the creation of more and newer schemas in each sub-ecosystem, even when common schemas could theoretically be agreed to.

But if we can’t all agree to the “one schema to rule them all” aren’t we doomed to a Tower of Babel?

Not entirely. There is another possible route to interoperability. Mapping. Instead of creating N*N mappings between each schema we create 2N mappings into and out from a common, rich, granualr, and horribly complicated schema (that nobody would use directly).

We use a mechanical process (think web service, library, etc.) that maps an input schema into a rich, intermediate schema, and from there to an output schema. This schema mapping process, being both algorithmic and data driven, can live at the RP, in the cloud, or at the IdP, depending on the need.

I will now describe one way to do this schema mapping. I have a personal bias towards declarative approaches that involve rich data and simple algorithms. The mapping rules that I’m about to describe can themselves be described as data with embedded names of a few simple functions. So that’s the design approach. Here are the details.

Every input attribute must come from some known namespace (schema name). A set of mapping rules must have already been created; one for each attribute in the input schema. The rule for the specific input attribute is then looked up and applied to transform this input attribute into its equivalent attribute(s) in the internal, intermediate data model (schema). To create the output attribute(s) the process is reversed. The target namespace (schema name) must be known, and a set of mapping rules must have been created for it. The output process takes the attribute in the internal data model, looks up the mapping rule for it and uses this rule to generate the output attribute.

This approach was discussed a lot on the second day of the recent Tao of Attributes workshop, and a some similar thinking was discussed a couple years ago regarding a Common Dictionary Service (CDS) on the IdentitySchemas.org list at Identity Commons

The Higgins project is starting work on an open source Persona Data Model that could serve as a common internal schema. A schema that nobody would actually use per se, but useful to map into and out from. We’re also experimenting with declarative mapping rules.

A quick aside:

The straw that broke the camel’s back for me happened recently. In the ICF’s Schema Working Group, we created a super-lightweight, email-based process to simply list whatever attribute/claim URIs that any party reasonably suggested they wanted. Here’s the catalog we created. When Equifax wanted an “I’m over 18″ URI we swung into action and minted http://schemas.informationcard.net/@ics/age-18-or-over/2008-11. Cool.

Then the ICF and OpenID foundations start working together with the GSA and other parts of the Federal government. There’s a need for a “Level of Assurance” 1 claim. No problem. We created http://schemas.informationcard.net/@ics/icam-assurance-level-1/2009-06. Trouble is, when the GSA’s profile for IMI Infocards was published the URI started with http://idmanagement.gov.

Why? Who knows. That’s what they wanted. And since (sadly) in SAML there are no sub-namespaces allowed with the URI namespace, one URI is as good as another since all must be treated as an opaque string. So it’s hard to push back on the “customer” and tell them that the attribute should really start off http://schemas.informationcard.net…  They think that the LOA 1 URI is theirs. To make a separate URI and thus define another schema over such a trifling matter, was all the convincing that I needed to rethink things.

One of the long term goals of the Higgins project is to provide universal login. This is the ability to log you in to almost any website or app (aka Relying Party (RP)) using a variety of methods including I-Card (as defined in ISIP 1.5 and soon here-ish), OpenID and username/password.

As a step towards universal login, I’ve written up this summary of password cards based on input from many folks. The basic idea is to enhance the Higgins browser extension with “password manager” capabilities, and to enhance the selector such that it can store your usernames and passwords as claim values on personal cards, and to do so with special care to prevent phishing attacks.

As I mentioned here, I see this work as a step towards convergence on single browser extension that “just works” (universal login). Beyond un/pw and I-Card we’d like to integrate support for what the IDIB folks, Axel Nennker, and others are doing with OpenID. And then there’s SAML.

Odd as it may seem, by embracing passwords, we’ll help eliminate them. Or at least I hope so.

We start by defining identity as a group of “personas” (see “Defining identity, persona, role”). Any persona can be made up of a group of personas or roles. Each of those personas can be linked, or separated, as the entity identified by them wishes. One of those personas is (or, rather, could be) an “enterprise persona.” That one brings together “…all the activities and attributes of a single entity” performed for or related to that enterprise “into a readily accessible (and reportable and auditable) form.”

So there is no “user-centric” or “enterprise-centric” identity. There is just an entity with AN identity made up of various personas some of which may be controlled or limited in some way by an outside organization – not only by the enterprise but also by governments, social organizations, etc. The ability to keep these personas separate, where legally able to do so, must be a given. Each persona will have different identity needs and requirements, of course, but that’s what will drive the “identity economy” as vendors seek to satisfy those needs and requirements in accordance with the laws. The government’s laws, the enterprise’s “laws”, the fraternal and social organization’s “laws” and the Laws of Identity as laid down by Cameron.

I really didn’t understand this when I started the Higgins project back in 2003. I was trying to scratch a personal itch. I wanted a personal dashboard that would pull together all of my profiles and social relationships. I felt like my various personas and buddy lists were scattered all over the web in hundreds of silos/sites.

Later when my colleague Mary Ruddy described the Higgins project to Jamie Lewis, Jamie suggested that we talk to Tony Nadalin (IBM) and Kim Cameron. My initial reaction was “no,” and “no way” [respectively]. I figured that I was working on a user-centric solution that would work for me, as an individual. So why would we talk to IBM, they sell to enterprises [so surely what we're working on can't be of interest]. And as for talking to Microsoft (I didn’t know Kim at the time)…why would I talk to the folks that brought us Hailstorm and Passport?

As history has shown, I was wrong on both counts. Luckily, Jamie was persuasive and Mary was insistent. We have since joined forces with Tony and Kim. Tony explained to us that the problems facing the enterprise were extremely relevant to Higgins and that there was no conflict. And Kim (and later Mike Jones and others) won us over by showing that Microsoft could be a good actor in this space. [So much so that the Higgins project decided to invest a ton of resources on making sure that its "card-based" metaphor and file formats were a pure super-set conceptually, functionally, and architecturally WRT CardSpace.]