Last week, I attended the Internet Identity Workshop. As an attendee with less exposure to the user centric identity, an early session provided an great overview of how the pieces fit together. This is a regular topic at the IIW and I’m sure the community will continue collaborating online at the Identity Commons wiki page. However, the image below captures the map as discussed during our session.
Flickr Photo Credit: Thermistor (click link to see full view of map)
In this post I will walk through the information covered, because it has served as a useful framework as I’ve thought about the issues – and I believe will also be useful to the R/WW community.
3 Major Systems
Working from left to right on the diagram and to establish the basics, fundamentally decentralized identity systems involve three major systems / components for a user to establish their online identity:
- Identity Provider: the site / service that issues and authorizes a user is who they say they are
- Relying Party: the site / service that accepts an identity provider’s credentials to authorize a user
- User / Client: the individual (typically via browser or other client) trying to authenticate with a relying party
Suites / Frameworks
There are four suites that have been established to communicate authenticated attributes across the different 3 systems (ID provider, Relying Party and User/Client) using appropriate protocols. These include:
- Open ID
- SAML
- Microsoft Windows CardSpace
- Liberty Alliance Specifications
Open ID
The OpenID framework has established itself as the leading framework for providing online decentralized authentication. Currently, more than 90 million Open ID accounts have been created, using various identity providers. This includes AOL announcing they had setup an Identity Provider server internally, enabling every AOL account (screen name) to be used as a user’s OpenID account. This resulted in 63 million new Open ID accounts. (However, I’m sure many AOL users still need to learn what that means for them.) In addition to the progress getting companies to setup servers operating as identity providers, there are now over 2500 sites on the web that operate as relying parties to accept Open ID authorization. The growth of relying parties that accept OpenID has been tremendous over the last six months, as shown in the graph below from the OpenID foundation’s presentation at IIW.
Microsoft Windows Card Space
Microsoft has been a involved in the online identity space for some time, starting with Microsoft Passport. And they have learned from that early experience. Their new framework is called Microsoft Windows Card Space (formerly ‘InfoCard’). The idea is that users are able to select one of any number of digital identities (cards), which the end-user can choose from when asked for their identity from a relying party. In a paper introducing CardSpace and describing the Identity Metasystem Landscape, it was interesting to read the conclusion:
“Microsoft is doing its part by providing software for Windows, but it can’t unilaterally make the identity metasystem vision successful. Others must also understand the benefits they will derive from more effective use of digital identities, and they must choose to participate.”
After digesting this vision, I was interested in reading the following recent announcement that the CardSpace framework now works easily within the OpenID framework.
Other Frameworks
The OASIS (Organization for the Advancement of Structured Information Standards) has developed SAML (Security Assertion Markup Language) and theLiberty Alliance has developed sets of specifications.
Protocols and Attributes / Tokens
There are a number protocols which have been established for delivering attributes or tokens between each of the three systems (ID Provider, Relying Party and Client). Typically, the different frameworks try to establish a common interface to the variety of protocols and attributes a system would need to work with. While this certainly provides a flexible system, the vocabulary can get confusing – because the name of a suite is often shared by a specific protocol and attribute spec. However, that same suite can often work across additional protocols and attributes beyond the one they share a name with.
The best example of this seems to be Open ID. On the specifications page, there are both specs on the overall suite (or framework) as well as specs for attributes that can be exchanged. However,the OpenID framework works effectively to exchange attributes beyond the specified OpenID attributes. While this serves to be a very flexible architecture, as already mentioned it does sometimes make the conversation confusing.
Conclusion
While the user centric identity space is evolving, the landscape appears to be coming into focus. It seems like the major challenge in the next year will be working on simple explanations for end users to better understand how these components fit together. Hopefully as this happens, the conversation can shift away from protocols and standards and towards applications that are built on these frameworks. If this happens, I would imagine at some point we’ll be interacting with the suites and frameworks on a regular basis. However, we’ll be as likely to refer to them by their specific names, as we are today to talk about SMTP/POP3 when discussing our email. With that caution, I hope this was a valuable overview of the fundamentals.
