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 the Liberty 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.
1 comment:
We went to San Francisco on a vacation on Spring Break. We were having dinner at a restaurant in the downtown area where minoo’s purse got stolen. She had $600/- in cash, a diamond bracelet, few credit cards, her driver license, her check book, etc. We found about the purse being stolen after a couple of hours (when we asked for the check) and by then the thief had already spent about $1000/- on Minoo's credit card. We had call the cops, wait for them to show up and file a report. After we went to our hotel, we had to make a dozen (if not more) phone calls to cancel our cards, call our bank, etc. The next day we had to go to the bank to close out account and open a new one. Now I have to set up the auto-pay again. What a pain.
That got me thinking…..there has to be a better way. And this is what I thought.
I would not carry a single thing on me. All I would have is a PIN# that I have memorized. It’s not on me so nobody would be able to steal it. Just the way the restaurants, stores, hotels, etc. display a sticker that they accept AmEx, Visa, Master, etc., they would have one more sticker that would say that they accept…say….”e-Wallet”. I then would go in and order what I wanted. When it was time to call for the check, I would inform the waiter that I would pay thru’ e-Wallet. The waiter would bring a device that would have a small key pad and a screen. I would punch in my PIN. The screen would show me the cards that I have linked to this PIN. I then could choose the card and press OK. The transaction would wirelessly (and thru’ a secure channel) transmit to the base station which would be located somewhere in the back of the restaurant. How would I know that it is a secured channel? The device would show a green light. The base station would authorize the charge and retransmit the confirmation. The confirmation code would flash on the screen in front of me. At this stage, I have completed my transaction.
This is not a mandatory, federal database where my PIN is stored. There is not a “big brother watching over me" type of an uneasy feeling. I can choose what I want to link. If DMV and Social Security get on board, I can also link those. The key to this being successful is not to have a single thing on person that would compromise the security. All I have to do is to memorize a number. Just one number.
Post a Comment