Burton Group reports on user-centric interop

The Burton Group has posted its evaluation of the user-centric interopathon held at this year's Catalyst. The analyst is Bob Blakley, now with Burton and previously chief scientist for Security and Privacy at IBM Tivoli Software. 

Bob writes, “Prior to the event, there were some specifications, one commercial product, and a number of open-source projects.  After the event, it can accurately be said that there is a running identity metasystem.”

The Burton Group hosted a User-Centric Identity Interop at the Catalyst Conference in San Francisco during the week of 23 – 29 June 2007; a public demo session was held on the evening of Wednesday 27 June to showcase the accomplishments of the participants in this event.

The interop event was a milestone in the maturation of user-centric identity technology.  Prior to the event, there were some specifications, one commercial product, and a number of open-source projects.  After the event, it can accurately be said that there is a running identity metasystem.  This identity metasystem is not grown up yet, and it still suffers from a number of issues.  But a lot of issues which used to exist have been fixed as a result of the efforts of the interop participants leading up to the event, and many more issues which were previously unknown have been identified and are being worked.  Many gaps in the user-centric identity and information card documentation have been identified and some have already been filled.  Microsoft's Open Specification Promise documentation set has been augmented with new material essential for smooth multi-vendor (or multi-project) interoperability.

The interop participants accomplished in two months of concentrated effort what it would probably have taken them a year to do working independently without the looming deadline provided by the Catalyst demo.  While it is still fair to say that user-centric identity technology is in its infancy, if progress continues at this rate the technology should be ready for enterprise adoption within a year.  The interop participants, recognizing the accelerant effect the Catalyst event has had on development of their technologies and products, are planning a series of future public interop events, some at Burton Group events and some elsewhere, to maintain the momentum they have built by participating in the Catalyst event.

PARTICIPANTS

24 organizations and individuals participated in the interop event; in alphabetical order they were: the Bandit project, BMC Software, Ian Brown, CA, FuGen Solutions, the Higgins project, IBM, Internet2, Microsoft, NetMesh, the Pamela Project, Oracle, Ping Identity, Sxip Identity, Verisign, WSO2, and XMLDAP.org.  This list includes for-profit corporations, open-source projects, and individuals.

The user-centric identity architecture includes three types of components: Identity Selectors (which allow users to select information cards and thus control which  claims are distributed to other parties), Relying Parties or RPs (which consume and rely upon claims to grant access and authority to users), and Identity Providers or IDPs (which manage user identity information and distribute it to RPs).

The participants brought 7 Identity Selectors to the interop event:

• 3 Higgins selectors

• Ian Brown's Safari plugin selector

• the Microsoft Windows Cardspace selector

• an early version of an upcoming version of the Microsoft Windows CardSpace selector

• the XMLDAP.org selector.

12 Identity Providers were tested during the interop event; again in alphabetical order, these were:

• Bandit Wag IDP

• FuGen's Test IDP

• the Higgins IDP

• IBM IDP

• the Internet2 Shibboleth IDP

• Kim Cameron's Identityblog HumanPresent IDP

• Microsoft Age STS IDP

• Microsoft's Windows Live Labs IDP

• the Ping Identity SignOn.com IDP

• the Verisign IDP

• the WSO2 IDP

• the XMLDAP IDP

25 Relying Parties were tested during the interop event; these were:

• 2 Bandit RPs

• the BMC RP

• the CA RP

• the FuGen Social Photos RP

• the Higgins RP

• the IBM RP

• the Internet2/University of Washington RP

• 2 Kim Cameron Identityblog RPs

• 2 Windows Live Labs RPs

• the Microsoft Age STS RP

• the Microsoft Fabrikam Friends RP

• the NetMesh RP

• 2 Pamela project RPs (one for Joomla, one for WordPress)

• the Oracle RP

• the Ping Identity RP

• the Sxip Access RP

• the Verisign RP

• 2 WSO2 RPs

• the XMLDAP RP

• the CardSpaceDemos.com FriendsWithCards RP

RESULTS

The interop clearly showed that Microsoft's decision to open the information card specifications, combined with the identity community's enthusiasm for user-centric identity technologies, has resulted in a truly open environment with lots of innovation and a variety of commercial and open-source providers.

Two scenarios were tested:

1. Identity Selector imports managed information card from Identity Provider

2. Identity Selector logs user in to Relying Party using information card

    2a. using a self-issued information card
    2b. using a managed information card obtained from an IDP via scenario 1

Some Relying Party sites implemented customized content or behavior which was triggered based on claims generated by IDPs and consumed by RPs.

Many combinations of Identity Selector, Identity Provider, and Relying Party were tested – exact statistics can't be compiled because record-keeping during the event was not completely systematic.  Most tested combinations worked successfully in both scenarios.

Many issues were identified during the two months leading up to the Catalyst interop event, and most of them were fixed.  Vendors and open-source projects worked hard and they worked well together. 

Most of the issues identified arose from the usual sources: underspecification of namespaces, schemas, required and optional protocol elements, algorithms, and encodings; the next section (“ISSUES”) enumerates the most important of these issues. Given the relative youth of the specifications and the explicit WS-* philosophy of trading off in favor of extensibility and flexibility and against completeness of specification, the existence of these issues is not surprising.  However it's also important to note that most of these issues will be easy to fix via profiles and additional specification detail. 

A few more serious issues arose also.  It became clear during the preparation for the interop that the trust semantics of IDP assertions are not yet firmly established; RPs need to be able to know what to expect when they consume an assertion from a new IDP, and this will not be possible until rules of trust are written down.  Interactions between users and RPs is also not yet sufficiently standardized.  Users who visit multiple RPs will need to be able to understand the icons they see on RP screens, and to understand in advance what behaviors to expect when they select those icons.  Some RPs require the use of encryption technology which is encumbered by international deployment restrictions.  Finally, it is not clear how the namespace of claims communicated from IDPs to RPs should be organized and governed.

ISSUES

Claim validation

• It became clear during the run-up to the interop that no standard set of token and claim validation procedures had been defined for RPs.

• Matching rule issues caused some failures (for example, is a URL with an appended “/” the same as or different from the same URL without the “/”?)

Claims and claim namespaces

• Some RPs rejected claims because they did not recognize the claim namespace generated by the IDP.

• Some RPs rejected claims because of case-sensitivity issues.

• The handling of claims with multivalued attributes appears not to be fully specified

• The semantics of an IDP issuing a claim are not clear; in particular it is not clear whether creation of a signed token containing a claim constitutes a statement by the IDP that it believes the claim is accurate.

Required and supported claims

• Some RPs required an exact match of required claims and presented claims; other RPs matched if required claims were a subset of presented claims.

• Some IDPs generated tokens with claims not requested by the RP; the consensus was that IDPs should not generate claims which do not appear in the RP's list of required or optional claims, because of privacy concerns.

Card Acquisition

• Card creation varies from IDP to IDP, and is in many cases primitive from a human-factors point of view.

• Procedures for importing cards are also not standard and are in some cases complicated or confusing.

Encoding

• SAML token version requirements are underspecified; IDPs and RPs need to be able to agree on the supported token versions.

• Base-64 encoding issues caused some failures due to incompatible assumptions about where line breaks may legally occur.

• Some RPs rejected claims because of ambiguities in what token information was to be included in the scope of hashes in signed tokens.

• Some RPs encountered issues with XML canonicalization of tokens.  Use of a standard canonicalization library may be desirable.

• Some issues were encountered with how plaintext data was padded prior to encryption.

• SOAP versioning (1.1 vs. 1.2) caused compatibility issues.

Certificates and Keys

• Some RPs required installation of a certificate on the selector machine.

• Certificate path validation is handled in a variety of ways by RPs; some RPs experience serious performance problems due to path validation.

• Introduction behavior is not well-specified; when an RP encounters a token from a previously unseen IDP which is not in an administered trust list, no standard behavior is defined.  Most RP failure modes provide little information to an administrator who might want to add the IDP to a trust list.

• Using EV Certificates requires complicated configuration.

Encryption algorithm support (and export restrictions)

• Some RPs could not decrypt tokens because they lacked support for the encryption algorithm used; furthermore, since the failure resulted from inability to  use 256-bit AES encryption, which is subject to US export controls and other international deployment and use restrictions, this problem may not be straightforward to fix.

Time

• Some RPs rejected assertions because of issues with synchronizing clocks between IDPs and RPs.

• When self-issued cards are used, time synchronization between the client machine running the Identity Selector and the RP server can cause failures.  Since client machines are less carefully administered than IDP and RP servers, this may prove to be a difficult issue.

Presentation

• Neither selector behavior nor RP behavior is standardized; it is not straightforward for users to know what to expect when using information cards with different selectors, or with the same selector but a variety of RPs.

• It was observed that some RPs are using different approaches to detecting and triggering identity selectors; this caused some failures.

• Some RPs exhibited different behavior on first visit (required registration of some sort) versus subsequent visits.

MOVING FORWARD

OSIS, a working group of Identity Commons, is already working on future interop events; the Burton Group and many of the interop participants working to host another interop event at the European Catalyst conference in October in Barcelona.

OSIS is also considering a number of other initiatives which should improve interoperability and usability of user-centric identity technology.  These include claim schema standardization, documentation of user-centric identity, OpenID, and information card best practices for Identity Selectors, Identity Providers, and Relying Parties, test suites for user-centric identity components, and interoperability profiles for user-centric identity components.

Active discussion of interoperability issues continues on the OSIS mailing list.

THANKS

Finally, a number of organizations and individuals deserve special thanks for their part in the Interop event.  Oracle contributed the monitors which were used to demo the technology to Catalyst attendees.

Johannes Ernst and NetMesh contributed the Wiki which was used to plan and administer the interop event.

Mike Jones of Microsoft not only devoted significant amounts of his time to the interop event but also moved heaven and earth at Microsoft to ensure that all the intellectual property needed to make the interop possible was included in the Open Specification Promise document set.  Microsoft also sponsored both the network and the catering for the interop event.

Pamela Dingle of Nulli Secundus and the Pamela Project devoted a significant amount of time to defining the interop scenarios and also helped organize the IIW interop which paved the way for the Catalyst event.

Dale Olds of the Bandit project sponsored the interop event; he also designed the illustrated brochure  which advertised it to Catalyst participants (a lot of work) and paid for the printing of the brochure.  Finally, Dale collaborated with Pamela on the organization of the IIW interop event.

Ping Identity sponsored a much-needed after-party for interop participants.  IBM, courtesy of Tony Nadalin, co-sponsored this party, as did we.