A bunch of us who are involved in OpenID, SAML, XRI, and Liberty identity web services took advantage of our relative proximity this past week and got together just prior to the Portland OpenID Mashpit to discuss the proposition:
Where and how can we move from incompatibility to convergence?
(We thought of this as a “northwest nexus” gathering, and I rather like the definitions of “nexus” that I’m getting out of Answers.com: a means of connection, a link or tie, a connected series or group, or the core or center. If you like, you can take the “swirling” part in the title to refer to the frozen precipitation that caused us so much grief this week!)
Besides myself, on hand were gracious JanRain host Scott Kveton, his colleague Jason McKerr (who ably talked me and my car down from a precarious position on a steep icy street), RL “Bob” Morgan of Shibboleth fame, OpenID maven David Recordon, XRI guru Drummond Reed, his colleague (and my fellow songwriter) Laurie Rae, and SAMLista Jeff Hodges of Neustar. I hope these folks will speak up to correct any details I’ve gotten wrong here. I’ve supplemented with a ton of links that weren’t in my original notes so as to make this post as directly useful as possible.
There are lots of reasons to be striving for better compatibility and more convergence. SAML and Liberty technologies have deliberately stayed the heck away from questions of user experience, which OpenID is exploring in rapid, consensus-driven fashion as an essential part of its innovations around web-friendly identifiers. OpenID has deliberately stayed the heck away from being a trust system, a challenge that Liberty has met head-on with technology, public policy, and business needs in mind. The growth curve of OpenID has been truly staggering, but in the realm of lightly protected data and lightweight applications so far. SAML and Liberty have an adoption pattern that is both deep and wide, but is typically enterprise-heavy and not intended for “promiscuous” open-Internet use (though there are notable exceptions, such as ProtectNetwork and OpenIdP). OpenID has already been through a convergence trend, incorporating XRI and Yadis and being influenced by several other systems. SAML has done the same, with Shibboleth profiles and Liberty’s federation work ultimately coming to rest in SAML2. A lot of complementarity here, yes? There are some jobs they both tackle to varying degrees today — namely identity provider discovery, service metadata, and authentication services — though their knobs and dials for security and ease of deployment are tuned to different settings.
So how did we begin? With some fine pirate cookin’ for dinner.
The next morning, refreshed, we continued the “convergence touchpoints” exploration that began back in October and saw progress in December.
We spent a fair bit of time on what we in Sun call TOIs, or transfers of information. Yes, I know, attack of the TLAs… JeffH presented a document he’s been working on called Comparison: OpenID and SAML and collected a few clarification points from David. We also compared notes on the various approaches being used and explored for attribute representation and exchange and for message transfer in OpenID; the SAML-based Shibboleth approach to attribute exchange that has been deployed in the Internet2 community; and the Liberty Alliance ID-WSF framework for attribute services. (I’ll blog my new presentation on this last subject in the next couple of days.)
JeffH also presented a draft OpenID-SAML profile that leverages the work he and Scott Cantor have already done on Lightweight SSO. As I have previously noted, there’s already a set of specs that combines the use of i-names with SAML-based single sign-on; the XRI Authentication Service Profiles — written by Drummond and Peter Davis last year — got pretty far towards imagining how OpenID and SAML could use the same discovery and metadata methods. And of course Pat Patterson showed the world how easy it is to implement something very OpenID-SAMLish in his “Lightbulb” pure-PHP implementation of a relying party.
So after all this palaver (sorry, I’m reading The Dark Tower and it’s affecting my vocabulary), what did we conclude by the end of the day? My notes from our “next steps” discussion (conducted as the Mashpit participants straggled in) are sprinkled with question marks, but here were the items I captured as being interesting to do next:
Work on the OpenID-SAML profile already begun, both to illuminate the semantic relationship between “OpenID-native” and “OpenID-SAML” ways of doing things but also to inform us about potential convergence futures.
Define a canonical mapping between SAML assertions and the OpenID equivalents (likely as part of the comparison document already begun), partly again for the pedagogical value but also to assist anyone who might require a formal STS-like token exchange function to do this (since you can’t just convert a signed token willy-nilly and expect it to remain valid).
Consider ways in which the SAML and/or Liberty communities might want to profile or pick up the UX work being done for OpenID.
Take a look at how native SAML profiles and ID-WSF — for which there are extensive testing procedures, various open-source implementations (OpenSAML, SourceID, OpenSSO, Entrouvert, ZXID, Conor’s), and many vendor products — can provide guidance in the OpenID attribute exchange exploration.
Sketch out how an OpenID-enabled People Service (or other such identity service, but everyone seems pretty hot on this one — and with good reason!) might work.
Relatedly, get moving on ways to mix ID-WSF support and OpenID support in a single open-source home so they can be played with together (David mentioned PIP, into which ZXID or Conor’s code — suitably wrapped — could be incorporated, and OpenSSO seems like a good target from the other side).
I hope others will find these items interesting as well, and if so, maybe even help out on some of them. Let me know what you think! I would also love to discuss these swirling thoughts with folks at the Liberty 2.0 workshop being held on Monday. Hope to see you there.
[…] But it does it pretty well: it lets your users use their own ids to login to your site. And that’s it. That way you don’t need to manage their usernames and passwords. But any further questions you might have about your user, like “who the heck are they“, “how old are they”, and “can they pay me” are left quietly unsaid. For now. […]