Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Interlinked claims providers (20070627)
The Concordia Project workshop in San Francisco (preceding the Burton Group Catalyst Conference) reviewed use cases from organizations deploying services that would encourage interoperability between multiple identity protocols on the Internet.
One of the common themes of many of the use cases is the potential of a plurality of attribute (or claim, or identity) providers. Historically, multiple providers could be thought of as independent, either as pure-play identity providers such as competing public OpenID providers, or those serving specific communities of users, such as providers operated on behalf of their employees.
However, there are other factors which indicate a need for linking providers to meet user's and administrator's expectations, including:
- No one provider will cover all of an individual's identities, as providers are oriented to particular social roles of an individual (e.g., as an employee, as a citizen, as a subscriber to a service).
- As stated by Phil Hunt of Oracle and Eric Norman, attribute providers should only maintain information for which they are authoritative.
- Within a federated community, each organization participating in the federation may have a specific role and relationship with the user. One organizations may wish to leverage the results of another organization's relationship.
- Within an enterprise, approaches using a metadirectory to assemble all the attributes of each user into a single massive data store also aggregates risk.
- A single store may be inefficient, especially for rapidly changing attributes (e.g., presence or location).
There are several architectural approaches for this:
- a claims transformation approach, in which a security token service, potentially operated by a third party, maps the claims returned by the identity provider into those expected by a relying party.
- a virtual directory approach, which has been very successful for LDAP directories within enterprises. A virtual directory provides clients with a single view of a directory entry through its standard access protocol, but behind the scenes the virtual directory server might be assembling the attributes of that entry from data elements from multiple data sources, obtained through both directory and non-directory protocols. In an identity metasystem model, an identity provider could "chain" to one or more attribute authorities to assemble a set of claims to return to a relying party
- a map approach, in which the identity provider describes to the relying party the sources for attributes for a user that the identity provider has authenticated. The relying party is given directions, such as "to obtain the dateOfBirth attribute or isOver18 claim, go to server attrs.example.com with transaction token Y". An advantage of this approach is that the identity provider need never see the value of the attribute or claim, or know whether the relying party obtained it or not.
-
a "two-step" approach, in which one relying party (or identity provider) needs an
attribute or claim that is issued by one of a potentially large set of identity providers for authorization. For example, during a disaster scenario a hospital might allow "any doctor" to access a particular relying party application. In order to prepare for this, the "first step" would be to define the trust relationships that identify the set of organizations that issue credentials to doctors (e.g., medical boards), and the "second step", in which the doctor takes a credential obtained from their state board and provides it to the hospital.
First step 
Second step 
One difficulty is that many of the identity protocols and implementations do not yet have support for multiple sources.
- LDAP: no protocol support for assembling values into an entry, although chaining and virtual directories are widely available
- SAML and Liberty: some protocol support, although not yet widely deployed
- CardSpace: no support for caching authentication information and claims
- WS-Federation: some protocol support, but as discussed in "multiple endpoint references", additional capabilities are needed
- OpenID: not yet addressed