Identity In The Browser at 5. Lessons Learned.

This document describes information card 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. We begin by describing Microsoft CardSpace and then discuss other projects and how they differed and innovated. To inform future work, we conclude with list of areas where Inforcard implementations succeeded and others where they failed.

Terminology

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

Sending a Card to a Site User Experience

Get Card User Experience

Architectural Highlights

Implementation

Capabilities

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.

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.

Lessons Learned

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

User experience

The following capabilities as defined and described above are key requirements for a successful solution:

Implementation trade-offs

Driving Adoption