OpenID is a fantastic little protocol that lets a user log in with their username from another service. It means you can log into Explode with your AIM screen name; you can also log into Livejournal with your Explode profile URL. The OpenID client site shoots the user's web browser over to the OpenID server site, authentication is performed, a token is passed back to the client, and bob's your uncle.
As far as this goes, it's simple, powerful, and very clever. If you're building a new web application, I highly recommend including OpenID functionality - even if you don't switch it on for everybody. But what happens if you want to do something behind the scenes?
The larger web applications are typically built around a number of server architectures, which each perform a different task. One might process some data on the back end; another might be reserved for displaying thumbnail images. If all the servers are owned by one body, they can each be passed a token (maybe even a cookie if they're all subdomains of the same parent domain), and poll the authentication server for the current user's details.
Now imagine you want to build a decentralised version of that using web services which are all owned by different organisations - but web services that need to know about who you are. One might provide storage, another might provide a profile, a third might be a messaging application. How do you provide a generalised way of passing authentication across, if there's no central authentication authority (as there isn't in OpenID, or in a decentralised system), and you don't want to go through the user's web browser each time?
Don't say Shibboleth.
None of the standards out there match the simplicity of OpenID, and therefore stand a chance of being as widely adopted. SAML, nominally the standard, requires SOAP, which brings its own problems. Even OpenID, when you examine the number of supported services, is very far away from becoming a mainstream standard. Federated identity is tough, but I think part of that may be to do with the way these standards are created; often they're the products of committee development, either in an institutional or corporate field. In both cases, the demands placed on the spec by the various stakeholders are inevitably going to cause bloat and inefficiency; the two surefire things that will prevent standard adoption. OpenID, meanwhile, has a very small spec, does what it's supposed to and nothing more, and even has pre-written code classes available via JanRain.
This is one of the issues we'll be bringing up at the Data Sharing Summit next month; I'd be interested to hear your ideas. Project Higgins looks to have a very healthy (user-centric, protocol-agnostic) attitude towards identity federation, and they may be one to watch.
Keywords: data sharing, identity federation, openid
Comments
"How do you provide a generalised way of passing authentication across, if there's no central authentication authority (as there isn't in OpenID, or in a decentralised system), and you don't want to go through the user's web browser each time?"
I don' t understand. I thought OpenID provided exactly that, cross-domain single sign on (via a cookie to the IdP domain)? All of the services would have to support OpenID, off course. There is a centralized authentication authority: the identity provider associated with the OpenID URL. It' s decentralized, because the IdP can be anyone, it's user controlled, because the IdP can be changed at will by the user. Did I misunderstand?
Well, I just tried my OpenID, ewout.org at two sites, http://pccepa21.if.usp.br:8004/moodle/ and http://ex.plode.us/login.php and I never had to authorize manually: both these sites talked to myopenid.com behind my back (as they should), since I was already logged in there. (By the way, ex.plode.us does not handle delegation: it would handle ewout.myopenid.com but not http://ewout.org . That is a problem if I want to change my IdP from myopenid to something else.)
But now I understand what you saying: even while the user can be logged in automatically to various services, your third-party web-service cannot impersonate the user and log in on her behalf, to have access to her data. For that to happen your web-service would have to have permission from the user. (Leading to elaborate page flows like flickr does when it gives permission to other aplication to access your fotos)
This is certainly not something that openid was designed for, but does it have anything to do with it being distributed or not? A centralized authentication service would not solve the problem of your web-service.
Granted, we haven't seen many services distributed this way .. but I think we will further down the line.
But when I log in to for example ex.plode.us, I see it talking to myopenid.com in the status bar. What is that all about then? The cookie on my computer only is send to the myopenid.com domain, right? I thought that ex.plode.us, when it receives the openid url, must dereference the url, check what is the IdP, ask the IdP whether it can get authentication, the *IdP* then checks the cookie and if I am logged in, sends a token to ex.plode.com.
Also, why does it require my involvement? I only had to give it my identity, a url. Any service could do that for me so that I would not have to manually enter a string in a text box.
Anyway, all this only authenticates me and my browser to all of my services. It does not authenticate your web-service off course. I do understand your point that openid based access to third party data would be something interesting to start thinking about how to standardize. There is this article explaining how Google, Yahoo etc. give access to third paries to their users data: http://www.xml.com/lpt/a/1705 Could something like this be build upon OpenID?
It dawned on me that we are talking past each other. You are thinking like a developer and when you say "require your involvement" you mean the the users browser is involved, whereas for me, as a user, it all happens automagically (as if by technology).
So I looked into it a bit further, and found some other people thinking about the same thing: This peace makes your point very succinctly: "[OpenID] doesn't help when you need to get some explicit token to pass around to services to prove that the user authorized you to do something on their behalf." This post has a nice summary of the issues. It mentions oauth, apparently an effort to leverage OpenID to do the kinds of things you mention, but nothing is released yet.
It is a common misconception that SAML requires SOAP. In fact, that is not true. A variation of the primary SAML use case is outlined in wikipedia:
http://en.wikipedia.org/wiki/SAML
This simple flow does not require SOAP.