Uncategorised

One of the issues that the OpenID 1.1 specification did not cover is the fact that an identity URL may not remain the property of a user over time. For large OpenID providers there are two cases they may run into:

1. A user with a popular user name stops using the service, and they want to make that name available to new users.
2. A user changes their user name. This may be followed by someone taking over the old name.

In both cases, RPs would like some way to tell the difference between two different users who present the same ID at different points in time.

The traditional method of solving this problem is to assign two identifiers to a user: a human friendly identifier and a persistent identifier (e.g. a UNIX user ID, a database row ID, etc). At any point in time, the human friendly identifier will point to a particular persistent identifier, but over time the relationship may not hold. Whenever a human-friendly identifier is presented, it is transformed to its persistent counterpart before storage.

With OpenID 1.1, Relying Parties are expected to use the canonicalised form of what the user enters to identify them. It is possible to redirect the human friendly identifier to a persistent one, but that is not particularly nice if you are trying to co-locate the user’s home page and OpenID.

OpenID 2.0: XRIs

The only solution to this problem in earlier drafts of OpenID 2.0 was to use XRIs. When resolving an XRI, the resulting XRDS document includes a persistent identifier in the element.

For example, resolving “=foo” gives us a canonical ID of “=!4EFC.841C.8012.E2F8”. If a user logs in to an RP with the former, the RP will record the latter. This means the following:

1. If the user stops paying their $12/year and someone else registers “=foo”, that new user will have a different persistent ID so won’t be able to assume the identity.
2. If the user registers another XRI pointing at the same persistent identifier, it will be considered equivalent.

OpenID 2.0: URL identifiers

But if you want to use URLs as identifiers, how do you solve the problem?

One solution that was shot down was to allow the <CanonicalID> element in the XRDS document for a URL OpenID. Apparently this was rejected because it would result in another round trip during the discovery process to find the endpoint for the persistent ID.

Instead, a feature was added to help detect the case where an identifier was recycled. As part of the positive authentication response, an OP is allowed to modify the claimed ID to include a fragment URI component. If the identifier gets reassigned, the OP is expected to return a different fragment.

This solves problem (1) but not problem (2). As it stands, the OpenID 2.0 specification doesn’t provide much guidance in letting a user change their human friendly URL identifier while maintaining the same identity.

A Solution

One solution to this problem is to make use of the directed identity feature of OpenID 2.0. Rather than making the user’s homepage their identifier, make it an OP identifier URL. This lets the OP decide on the final claimed identifier.

This allows the user to enter their home page (e.g. http://example.com/james), and have the RP record a persistent identifier (e.g. http://example.com/id/42). If the user changes their human friendly identifier, they’ll still be able to use existing services.

This solution does have a few downsides though:

• Users can log in with any other user’s homepage URL since they all point at the same OP.
• Supporting both OpenID 1.1 and 2.0 on the same URL will likely cause confusion, since 1.1 requests would record the human friendly identifier and 2.0 requests record the persistent identifier. If an RP upgraded to the 2.0 protocol, the user would appear to be a different person (which is one of the problems we are trying to avoid).

So it seems that there isn’t a good solution if you need to support OpenID 1.1. If anyone else has ideas, I’d be glad to hear them.

Most people have probably seen or used OpenID. If you have used it, then it has most likely that it was with the 1.x protocol. Now that OpenID 2.0 is close to release (apparently they really mean it this time …), it is worth looking at the new features it enables. A few that have stood out to me include:

• proper extension support
• support for larger requests/responses
• directed identity
• attribute exchange extension
• support for a new naming monopoly

I’ll now discuss each of these in a bit more detail

Extension Support

OpenID 1.1 had one well known extension: the Simple Registration Extension. An OpenID relying party (RP) would send a request with an openid.sreg.required field, and get back user information in openid.sreg.* fields from the OpenID Provider (OP). The RP and OP would just need to know that “openid.sreg” fields means that the simple registration extension is being used.

But what if I want to define my own extension? If my RP sends openid.foo.* fields, how does the OP know that it refers to my extension and not some other extension that happened to pick the same prefix?

OpenID 2.0 solves this problem by borrowing the idea of name space URIs from XML. If I am sending some openid.foo.* fields in an OpenID message, then I also need to send an openid.ns.foo field set to a URI that identifies the extension. This means that a message that sends the same data as openid.bar.* fields should be treated the same provided that openid.ns.bar is set to the extension’s name space URI.

As with XML name spaces, this allows us to piggy back on top of DNS as a way of avoiding conflicts.

Large Requests and Responses

OpenID 1.1 uses HTTP redirects as a way of transferring control between the RP and OP (and vice versa). This means that the upper limit on a message is effectively the same as the smallest upper limit on length of URLs in common web browsers and servers. Internet Explorer seems to have the lowest limit—2,083 characters—so it sets the effective limit on message size.

For simple authentication checks (what OpenID was originally designed for), this is not generally a problem. But once you start to introduce a few extensions, this limit can easily be reached.

OpenID 2.0 allows messages to be sent as an HTTP POST body which effectively removes the upper limit. The recommended way of achieving this is by sending a page to the user’s browser that contains a form that posts to the appropriate endpoint and contains the data as hidden form fields. The form would then get submitted by a JavaScript onload handler.

Directed Identity

For OpenID 1.1, the authentication process goes something like this:

1. the user enters their identity URL into a form on the RP
2. the RP performs discovery on that URL to find the user’s OP.
3. the RP initiates an OpenID authentication request with that OP.

With OpenID 2.0, the discovery process may tell the RP that the URL identifies the OP rather than the user. If this happens, the RP proceeds with the authentication request using the special “http://specs.openid.net/auth/2.0/identifier_select” value as the identity URL. The OP will then fill in the user’s actual identity URL in the subsequent authentication response. As an additional step, the RP is then required to perform discovery on this URL to ensure that the OP is entitled to authenticate it.

There are a number of cases where this feature can be useful:

1. An OpenID provider can give their users a single URL that will work for everyone. For instance, if AOL sets things up correctly, you’d be able to type “aol.com” into any OpenID 2.0 enabled site to log in with an AIM screen name.
2. A privacy concious user could configure their own OpenID provider that will hand out different identity URLs to different RPs, similar to how some people use single-purpose email addresses today.
3. If an RP requires that users use a particular OP, they could use directed identity to begin the authentication request without requiring the user to enter an identity URL.

Attribute Exchange Extension

The OpenID Attribute Exchange extension is like the simple registration extension on steroids. The major differences are:

• Unlike the simple registration extension, the attribute exchange extension does not have a fixed set of attributes that can be transmitted. Instead it uses URIs to identify the attribute types, making it easy to define new attributes without causing conflicts. Of course an attribute is not particularly useful if no one else supports it, so there is a process set up to standardise common attribute types.
• As well as receiving attribute values as part of an authentication response, an RP can request that an OP store certain attribute values. This is done as part of an authentication request, so the OP can verify that the user really wants to store the values.
• The RP can request ongoing updates for the attributes it is interested in. As an example, if you stored your hackergotchi with your OP, changes to the image could be automatically pushed out to all sites you use that want to display that image.

Prop Up A New Naming Monopoly

With OpenID 2.0, a user is supposed to be able to enter an i-name in place of an identity URL in an RP, and be authenticated against the i-broker managing that name. So rather than entering an ugly URL, users can enter an ugly string starting with “=” or “@”.

All it costs to take advantage of this is US$12 per year (or US$55 for an organisation name). They claim that it will be possible to use an i-name in many contexts in the future, but for now it appears to be limited to (1) a subset of OpenID RPs, (2) a web form that people can use to send you emails and (3) an HTTP redirection to your website.

At this point, it seems that i-name support in OpenID is more important to the i-name crowd than the OpenID crowd. That said, the complexity is hidden by most of the existing OpenID libraries, so it’ll most likely get implemented by default on most RPs moving forward.

Conclusion

Overall OpenID 2.0 looks like a worthwhile upgrade, even if some parts like i-names are questionable.

Assuming the attribute exchange extension takes off, it should provide a much richer user experience. Imagine being able to update your shipping address in one place when you move house and having all the online retailers you use receive the updated address immediately. Or changing your email address and having all the bugzilla instances you use pick up the new address instantly (perhaps requiring you to verify the new address first, of course).

The improved extension support should also make it easier for people to experiment with new extensions without accidentally conflicting with each other, which should accelerate development of new features.