Beyond Single Sign On
I'm just coming off three days at the Internet Identity Workshop (IIW), a workshop I, Kaliya Hamlin, and Doc Searls organize every six months. IIW focuses on what's called "user-centric identity," a set of technologies for building an identity layer for the Internet. (You can read my reports on day one, day two, and day three or just look at the pictures.)
When people think about Internet identity, the first thoughts are usually about single-sign on, or SSO. Let's face it, we've all got too many passwords and most of us would love something that helps manage that mess. But the fact is that tools like Sxipper do a good job at solving that problem. If all an identity layer did was provide SSO, it wouldn't be worth all the effort.
Beyond SSO, an identity layer for the Internet reduces friction and increases security. Consider the kids in their garage building the next hot mash-up or the corporate IT department building a new customer facing application. They have a great idea and want to focus on that, but the first thing they have to do is figure out how to manage identity information. An identity layer, solves that problem in a universal way so that programmers can focus on building their application. That reduces friction.
To be sure, some applications want to manage the identity because that's part of the value, but many don't need to. Moreover, if my application doesn't have to store your private information or ever see your passwords and credit card data, I've reduce my liability. That increases security.
There isn't just one way to do build this identity layer. In fact, there's been a number of proposals. One of the goals of IIW is to provide a venue where those proposals can be aired, sorted out, and be fitted into the larger whole. To that end, one of the things we did this time was devote an afternoon to interoperability.
The goal wasn't to simply demonstrate interoperability, but provide a laboratory where different systems could be tested and the kinks worked out. The testing involved five information card selectors, eleven relying party code sets, seven identity provider code sets, four token types, and two authentication mechanisms. Not every combination of these made sense, but a lot of the edge cases were tested. The bottom line was that for the most part, these systems all worked well together. There were a few problems and they were documented for more work.
We'll be doing this same thing again in December. With Microsoft releasing it's CardSpace system and vendors like AOL and Sun supporting OpenID, there's significant momentum building in this space.