The long identity tail

I had a really great time at the Open Source CMS Summit this past week, where I took part in a panel on “identity and why we care, as well as discussion around implementation, single sign on, security, distributed authentication, user profiles”. I finally got to meet Identity Woman, who is a very thoughtful and passionate person (her youthful appearance did make me wonder how long I can keep up my “grrl” shtick!). And Boris Mann and Roland Tanglao were very gracious hosts indeed. (I’ll add a quick “thanks” to Lauren for arranging this gig in the first place!)

In preparation for the panel, I did some reading on the lightweight identity phenomenon that would be the focus of many of the attendees. Here was my cheat sheet covering quite a lot of the space, both “heavy” and “light”, along with elevator pitches — which might reflect my idiosyncratic interests but are meant to be objective and accurate as far as they go (I welcome corrections and augmentations, of course [UPDATE: Please see some in the comments. Thanks, Johannes!]):

OpenID: A system for supporting URL-based identifiers, allowing for a confirmation to prove that it’s your URL (a la email confirmation loops)
LID: A system for supporting URL-based identifiers, now coordinating closely with OpenID so as not to compete unnecessarily
YADIS: A policy protocol to let a relying party discover whether an authority uses OpenID or LID and adjust its behavior accordingly
SXIP: A company that has built identity solutions and protocols with an intended focus on easy integration with existing web apps
DIX: A proposal for IETF identity protocol work driven by SXIP; a BOF is scheduled soon to consider WG creation
Pubcookie: A classic cookie-based system for non-federated single sign-on within a single domain
XRI: An effort within OASIS to build a new URI scheme for use in creating identifiers and resolving information about identities
i-names: Simple XRI-compatible identifiers, which for people take the form of =name
Identity Commons: An organization developing stock sets of policies for identity information usage, a la Creative Commons
SAML: An OASIS standard for representation and federated exchange of identity information, with a focus on human-facing interactions
Liberty: A set of technology standards and business guidelines for privacy-enabled identity interactions, both human-facing and machine-to-machine
WS-Federation: A privately produced protocol for identity federation, with current product support focusing on human-facing interactions
Infocard: Microsoft’s new UI component for a client that can mediate identity interactions, similarly to LECPs/ECPs (see below)

The “explicitly lightweight” identity world is a bit new to me; having gotten the lay of the land, I prepared and presented some slides (.pdf) that I hoped would serve as a brief introduction to SAML and Liberty and a spur to further discussion that might put all the systems out there in context. Following are a few thoughts that may be helpful as a companion to the slides:

• Slide 2: It’s generally acknowledged that we need to reach across multiple DNS domains to let identity information pass through where appropriate. But if lightweight identity technology confines itself to low-security “personal” uses, then identity will still be stuck in that silo because enterprise and public sector uses require much better safeguards than that. Thus, at some point we need to solve for the general case and allow for the stepping up of security and privacy safeguards. If the lightweight solutions are what’s comfortable for the long tail (ah yes, Wikipedia has the long-tail graphic I was looking for), and SAML and Liberty are most comfortably done by only the first section of the tail, then — as Boris Mann put it — we need to figure out interoperability where they meet. BTW, I asked other attendees where they stood on WS-Federation and got a lot of eye-rolling! It’s not even on the table for them. (Having learned more about what this community considers to be a reasonable software integration task, I hope to post some more on the topic later.)
• Slide 3: It seems these two use cases, which I agonized over, really do have the highest demand (another common one is the set of multiple-principal situations that underlie something like the Liberty People Service); during the first day of the summit, which I couldn’t attend, apparently a discussion took place around identity use cases that identified these same two. When it comes to authority vs. relying websites in the SSO Guy use case, a lot of the current technologies use different terminology, but it’s possible to sync them up. So, for example, a SAML/Liberty/general-use identity provider corresponds roughly to a SXIP homesite, and a SAML/Liberty/general-use service provider corresponds roughly to a SXIP membersite. When it comes to authority vs. relying services in the Personal Profile Gal use case, the realization that she (through her client devices) can function as her own service is key — essentially you need an identity-friendly client. A Microsoft Infocard-supporting device corresponds roughly to a Liberty-Enabled Client or Proxy (LECP, pronounced “leck-pee”, unfortunately) or a SAML V2.0 Enhanced Client or Proxy (ECP, pronounced “eck-pee”, even more unfortunately). A couple of links that may be handy for understanding LECP concepts are here and here, though these are a couple of years old.
• Slides 5-7: My goal was to show real examples of SAML assertion structures (which I believe to be a target on which the entire XML-accepting community is converging), and highlight places where it’s extensible. In fact, were someone to be interested in this, URL-based identifiers could be accommodated just as easily as the email-based one shown on slide 5, just by supplying a NameFormat that means “the identifier is a URL”.(SAML doesn’t have a “this is a URL” identifier NameFormat standardized; should it? Should others write their own a profile? Who might be interested in this?) And looking at slide 7, SXIP properties could perhaps have their own attribute NameFormat.
• Slide 8: Here I wanted to make the point that SAML covers a lot of common flows for SSO, including starting out at the service (relying/membersite) provider rather than the identity (authority/homesite) provider, and using bindings that stick to HTTP redirects along with ones that involve SOAP back-and-forthing but have other efficiencies.
• Slide 14: I forgot to mention that Pat Patterson has posted some nice flash demos (of identity web services and of our Federation Manager product for easy service provider deployment) and a video of the Sun-Microsoft web single sign-on interop demo (high/low res).

Yikes, this post is longer than I intended (“the long identity post”?), so I’ll stop now. But I’m sure I’ll have more to say on the OSCMS experience. I struck up some new relationships with lots of smart people and I hope to stay in touch, and brainstorm, with many of them in the coming days.