To everything, at least.
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.