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 URI1 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.2

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 five3 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.


  1. The predefined URI is <http://specs.openid.net/auth/2.0/identifier_select>.

  2. It did take a bit more work in the consumers, but that is because ruby-openid does not support directed identity authentication yet. It does not like the fact that the identity in the id_res response does not match the identity of the initial authentication request. However, a bit of consulting the source lead me to a way of tricking it into accepting the responses even though they appear, on the surface, to be unrelated to the initial authentication requests.

  3. That is five so far. All new functionality is implemented as a new supplementary application so this number is on an ever increasing trajectory.

4 comments on “OpenID 2.0’s Killer Feature

  1. -

    This new feature is definitely killer. I’ve spent so much time already trying to figure out if I can accomplish complete transparency between several apps with the current status of OpenId and OAuth.

    It’s nice to be able to do direct identity, but that doesn’t seem to be all that efficient with OAuth. Wouldn’t it be sufficient for an OAuth consumer to pass an openid_url and a kind of permission-to-act-as token, and then the OAuth provider go and authenticate that token with the user’s openid_server? In effect, the OAuth consumer has been granted permission to “act as” the user; and the OAuth provider just verifies that fact. What do you think? It’d be less hassle between apps, and zero user interaction.

  2. -

    above, the reference to “direct identity” really meant “identity discovery”…

  3. -

    Nilez Parker,

    Unfortunately, I have not really spent a lot of time looking at what OAuth is capable of, so I cannot really say.

Comments are closed.