OpenID

It looks like the OpenID Authentication 2.0 specification has finally been released, along with OpenID Attribute Exchange 1.0. While there are some questionable features in the new specification (namely XRIs), it seems like a worthwhile improvement over the previous specification. It will be interesting to see how quickly the new specification gains adoption. While this is certainly an important milestone, there are still areas for improvement. Best Practices For Managing Trust Relationships With OPs The proposed Provider Authentication Policy Extension allows a Relying Party to specify what level of checking it wants the OpenID Provider to perform on the user (e.g. phishing resistant, multi factor, etc). The OP can then tell the RP what level of checking was actually performed. What the specification doesn't cover is why the RP should believe the OP. I can easily set up an OP that performs no checking on the user but claims that it performed "Physical Multi-Factor Authentication" in its responses. Any RP that acted on that assertion would be buggy. This isn't to say that the extension is useless. If the entity running the RP also runs the OP, then they might have good reason to believe the responses and act on them. Similarly, they might decide that JanRain are quite trustworthy so believe responses from myOpenID. What is common in between these situations is that there is a trust relationship between the OP and RP that is outside of the protocol. As the specification gives no guidance on how to set up these relationships, they are likely to be ad-hoc and result in some OpenIDs being more useful than others. At a minimum, it'd be good to see some best practices document on how to handle this. Trusted Attribute Exchange As mentioned in my previous article on OpenID Attribute Exchange, I mentioned that attribute values provided by the OP should be treated as being self asserted. So if the RP receives an email address or Jabber ID via attribute exchange, there is no guarantee that the user actually owns them. This is a problem if the RP wants to start emailing or instant messaging the user (e.g. OpenID enabled mailing list management software). Assuming the RP doesn't want to get users to revalidate their email address, what can it do? One of the simplest solutions is to use a trust relationship with the OP. If the RP knows that the OP will only transfer email addresses if the user has previously verified them, then they need not perform a second verification. This leaves us in the same situation as described in the previous situation. Another solution that has been proposed by Sxip is to make the attribute values self-asserting. This entails making the attribute value contain both the desired information plus a digital signature. Using the email example, if the email address has a valid digital signature and the RP trusts the signer to perform email address verification, then it can accept the email address without further verification. This means that…

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: A user with a popular user name stops using the service, and they want to make that name available to new users. 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: 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. 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…

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: the user enters their identity URL into a form on the RP the RP performs discovery on that URL to find the user's OP. the RP initiates an OpenID authentication request with that OP. With OpenID 2.0, the discovery process may tell the RP that the…