OpenID 2.0’s Killer Feature

The OpenID 2.0 spec has been finalized. On the surface, it does not seem to be very different from the 1.1 spec but it does include at least one sweet new feature. It provides protocol support for directed identity.

Directed identity is the concept of having a single identity that appears to be a different identity for every relying party (ie, an application that wants to verify your identity). The identity provider would, of course, understand that all these single use identities are really all part of the same identity. This would, theoretically, prevent unscrupulous people from building a profile about all the things you do online, because each website you visited would know you by a different identity. However, you could still log into all those websites using the same credentials since the identity provider would know that all those single use identities belong to you.

The change that was made to the OpenID protocol to support directed identity is brilliantly simple. It amounts just defining that if a provider receives a normal authentication request with a predefined URI¹ as the identity that the request is a directed identity request. The provider would then verify the user’s credentials and respond with the appropriate identity for the relying party. The OpenID provider responses always include the identity being verified so it turned out to be a very minor change to support that in our provider.²

Now, just to be clear, I don’t actually have any use for directed identity in the applications on which I work. However, the protocol mechanism that supports directed identity can also be used to implement multi-application single sign-on. And that is a killer feature for the stuff on which I work.

For maintainability, we have divided our application into five³ separate components. This works great as a way to keep the code simple, the architecture comprehensible and the system distributable. However, in the past, it left a bit to be desired with regards to the user experience because a user was forced to login five different times just to use the different sections of the application. Well, actually, we have been using OpenID for a while so the user did not actually have to login five time, but the did have to type in their user name five times. And that is not any better.

The directed identities support in OpenID 2.0 provides a solution to this repeated challenge problem. Each supplementary application discovers the trusted OpenID provider for the system and the performs a direct identity authentication request against that provider. The provider figures out who the user is and conveys that information to the supplementary application in the id_res response.

This means that once you have logged into any component of our system you will never the asked for your identity info again. We may make half a dozen requests to determine and verify your identity when you navigate to a component for the first time but all that work it is completely seamless from the users point of view. To the user it seems like just another page in the application.