This (v3) document describes Information Card related R&D that has been undertaken over the past five years by Microsoft, the Eclipse Higgins open source project (especially contributions from IBM, Novell and Azigo), from Axel Nennker, and from the FC2 consortium. In this revision we start with the lessons learned and then follow with a summary of some relevant experiences and development efforts. The opinions expressed here are my own.

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 “https://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.

Some thoughts on active clients and Personal Data Services with a heavy bias towards those under development within Higgins. Uses the old “Personal Data STORE” term…

If you just look at authentication, and you ignore hardware-based solutions and look at cost (where cost means the hard dollar cost per user that an organziation will have to pay including help desk, user education, systems integration, operating costs, fees, etc.) plotted against the level of security required, my intuition is that the tradeoffs look roughly like this:

I created these slides in response to a request 48 hours ago from Harry Halpin of the W3C’s social web experts group for a briefing on my views of the identity ecosystem.

If I’d had a bit more notice I should have added a discussion of the oStatus stack, XDI, RDF syndication and other things related to the pubsub of attributes. And VRM.

The open identity landscape today is semi-organized chaos. At an organizational level is perceived of as Kantara vs. ICF vs. OIDF vs. OIX vs. Identity Commons vs. …. At a tech level it is perceived of as OpenID vs. I-Cards vs. SAML vs. passwords vs. OpenID vNext vs. Oauth vs. UMA vs….  Some have buzz. Some have security. Some have maturity. There’s been lots of great work, and lots of progress. But all the same, we’re at an inflection point.

What our experience with open tech has taught us is that no single approach can address all of the use cases, security levels, levels of convenience, etc.  The fact both OpenID and I-Cards are underway with next generation efforts that will introduce at least some breaking changes speaks for itself. And username/password isn’t going away either. Heterogeneity is here to stay.

Let me illustrate. If you just look at authentication, and you ignore hardware-based solutions and look at cost (where cost means the hard dollar cost per user that an organziation will have to pay including help desk, user education, systems integration, operating costs, fees, etc.) plotted against the level of security required, my intuition is that the tradeoffs look roughly like this:

Or here’s another way to frame the issue. Different tech is suitable for different “volume” vs. long tail use cases:

If you need a third perspective, consider certification and the need for trust frameworks. The OIDF and ICF both jointly created the OIX organization to meet this (clearly cross-protocol) need. Yet there is still confusion about how this relates to Kantara’s IAF. Clearly certification and trust frameworks cut across the existing lines. Every technology needs a certification listing service. Every technology needs interoperability testing.

Based on just these examples of cross-cutting realities, I contend that most of the non-profits as we know them have outlived their usefulness in their current form:

• High overhead. Each spends money duplicating the resources, executive directors, infrastructure, etc. The result is that less work gets done promoting, say, OpenID, than it could otherwise.
• Lack of coherent messaging. In the enterprise market, for example, the louder each non-profit shouts the more the buyers sit on the fence and say “let’s wait and see which cat emerges from the bag.”
• Poor and inconsistent UX. The user experiences of each isn’t great. Try putting two or three together and the result is nonsensical.
• Not enough focus on relying parties. Relying parties are who adopt this stuff. We need clear messaging and we need great enabling libraries and services. After all, Janrain can only do so much!

The next step is consolidation

Creating a new consolidated non-profit for open identity that would combine existing groups and thereby create something quite different and new is an obvious and unoriginal idea. The question, as ever, is one of timing. Is now the moment? Kantara tried to pull this off a couple years ago, but that was too early. As my fellow board members on the ICF can attest, my sense of timing on this topic is too hurried. But all the same I can’t shake the feeling that now is the time to try to make some kind of progress. So I continue to have private conversations with friends and colleagues.

To protect the innocent I won’t name names, but I get generally supportive reactions. A recent plum was, “Good idea Paul, we’ll sit on the sidelines and watch you run around getting arrows in your back; we might even pull one out for you.”  For the moment and the record, I’m doing this without being duly authorized by Identity Commons, ICF, Kantara, or any other board I sit on.

Beyond reducing duplication and waste the most compelling argument for NewCo (what Bob Blakley might call IDTBD 2.0) is that we have no place to work on critical projects including:

• Cross protocol analytic framework (and common messaging). We need an analytic framework that helps RPs decide what open technology is right for what use case, cost target, LOA, etc. For example, I think we need a project team put together that takes my sketch of cost vs. security and calibrates it to actual “all in” costs and security levels by studying real world deployments. Let’s move away from the religious wars over whose tech is better.
• A consistent UX across technologies. The Kantara ULX group is doing good work but lives in a silo beside the OIDF’s efforts.
• A set of cross-protocol RP libraries and enabling technologies.
• R&D on active clients. A consensus has emerged. An active client has to build on, and work with OpenID (and other protocols) and not compete with it(them). I think an active client must also be a password manager. An active client must be optional; things should work without it and work “better with” it. The ICF is supposed to support active clients, yet work on OpenID v.Next goes on at the OIDF. This makes no sense to either organization.

Lastly, from a marketing point of view a startling amount of energy would be created by consolidating several websites into one. Of course true alignment will take years, but the perception of alignment even if we just start at the top would be powerful.

This post presents an architecture comprised of apps, a dashboard, and a personal data store (PDS) that can be implemented by multiple developers, hosted by multiple operators over an open, personal data network and whose goal is to give users more control over their own identity (personal data, profiles, preferences, affiliations, and relationships). It is in support of aspirations that have been widely reported by others and called variously VRM, data portability, user-centric identity, the Data Web, Augmented Social Network (2003), and so on.

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).

At RSA Ely Kahn (Director of Cybersecurity Policy at National Security Staff) and some of his contractors/staff met with members of the ICF board as well as with members of the OIDF and OIX boards. During the meeting the foundations were asked to respond to a questionnaire that was designed inform the “National Strategy for Secure Online Transactions” (NS-SOT) –a name chosen to sidestep the big brother alarm raised whenever words like identity management are used by the feds. He mentioned that Obama would be announcing this strategy in June.

Instead of answering the questionnaire the ICF board decided to write and send this NS-SOT ICF Response to Ely. Ely is one of the good guys, so I’m glad to spend time on this sort of thing. The jist of the paper is that relatively small, short term (not FY12 !) investment in turning a few Federal agencies into buyers of federated/externalized identities would jump-start an entire ecosystem. It would be particularly good for i-cards and OpenID.

This post is an attempt to summarize in one place some interoperability issues related to IMI PPID computation that we’ve run into as we get ready for RSA next week.

Specifications

There are two specifications of how to compute the PPID:

1. ISIP 1.0
2. IMI 1.0 (same as ISIP 1.5 submission). A clarification was added as described here: (see  Changes Made in ISIP V1.5 on page 72). It says: “To provide a migration path from non-EV to EV certs, the RP PPID Seed for a non-EV cert containing the same OLSC values is the same as for an EV cert, resulting in the same PPID”

In addition, here’s a very detailed article about this calculation, with example values. Mike suggests that anyone wanting to debug their implementation might want to check its calculations against these known-good values.

CardSpace Versions

1. .Net 3.0 version: implements ISIP 1.0 according to Mike
2. .Net 3.5 version: implements IMI 1.0 according to Mike
3. .Net 3.5 SP1 version: (i) implements IMI 1.0a for token of p-card (ii) implements both ISIP 1.0, and IMI 1.0 to find a p-card that matches the PPID credentials of a “backed” m-card.
4. .Net 3.5 SP2 version: same as #3 above
5. CardSpace 2.0 beta version: same as #3 above

Azigo Versions

• 2.0.0.35 –> 2.0.0.40 versions: implement IMI 1.0

Higgins STS

• Higgins 1.1 STS implements IMI 1.0

Avoco Versions

• It appears to use different PPID-related logic than CardSpace WRT to finding a matching p-card against the PPID of a backed m-card.

Known Incompatibilities (bugs):

1. Pam reported: You can’t export a p-card backed m-card from Azigo 2.0.0.35 and import into .Net 3.5 SP1 version of CardSpace.
2. Paul Battersby of Avoco reported: 1) An Azigo Managed card backed by a CardSpace Personal card using a crds imported from CardSpace. 2) An Azigo Managed card backed by an Azigo Personal card using a crds imported from Azigo Desktop selector. In the first case the PPID matches (i.e. the PPID calculated by the selector matches the PPID stored in the managed card). The algorithm uses a Relying Party Id generated from |O=”*.azigo.net”|L=””|S=””|C=””|. The second scenario fails. However, if I force the code to use a Relying Party Id generated from the public key of the certificate then the PPID matches. This is rather strange as the certificates in the Managed cards from both scenarios are exactly the same and the public key should only be used if the certificate is not valid or the Organizational units are empty.
3. JohnB recently pointed out that Azigo 2.0.0.40 and CardSpace .Net 3.5 SP2 generate different (and thus incompatible) PPID values on p-cards for the PayPal site (site with an EV cert)

The first two above are caused by the same set of inter-related issues. The root cause is an inability to validate the certificate of cardpres.azigo.net and as a result Azigo computes the wrong PPID for this site. We thought that we could fix this by including then entire certificate chain in the .crd. We did this today, but there are other related issues and we need another 2 days to deploy a new version of our hosted i-card service (service.azigo.com)

• Kantara ULX WG – a quick intro to what we’re trying to do
• Relationship cards – newbie intro

Open Trust Frameworks for Open Government. Jointly created by the OpenID Foundation and the Information Card Foundation.

I’m just back from DC at the GSA’s IdManagement Privacy Workshop where this paper was presented by Don and Drummond (the two E.D.s) on a panel moderated by Mary Ruddy.

Don’s related post.

Axel contributed this: