The OpenID 2.0 specification was finalized at IIW this week. OpenID 2.0 comprises two separate specifications: OpenID Authentication 2.0 and OpenID Attribute Exchange 1.0. Getting 2.0 out the door has been a long process, but the additions will be a real boost to OpenID's usefulness.
OpenID 1.0 is largely about authentication. OpenID 2.0 adds several important new capabilities:
- directed identities
- attribute exchange
- support or large requests and responses
- robust support or extensions
- support for XRIs
Directed identities allow the identity provider (IdP) to return the actual identifier to the relying party (RP) rather than requiring the user to enter the identifier up front. There are two primary use cases. The first is to allow a Web site to direct users to a particular IdP (e.g. AOL) and let AOL sort out who the user is before authenticating. The user's AOL OpenID would be returned in the "authenticated" message. The second use case is to allow users to create aliases to avoid identifier correlation among RPs or simply for convenience. This is a real boon to privacy.
Attribute exchange, of course, has been one of the areas where OpenID 1.0 was roundly criticized. Simple authentication, as provided by 1.0, is limited in what you can accomplish. Most applications also want to exchange user attributes so that users can avoid re-entering it at site after site. Using attribute exchange, your OpenID 2.0 provider, knowing your name and address, could send those to the e-commerce site your just authenticated to, for example.
Exchanging attributes means that data payloads may exceed the limits that some browsers place on URL lengths. OpenID 2.0 allows HTTP POST, as well as GET, messages to support larger requests.
People wrote extensions for OpenID 1.0 but there was no standard for naming. Consenquently there was an opportunity for extension name collisions. OpenID 2.0 fixes that by piggy-backing on the DNS system, in the same way XML namespaces do, to allow users to create names that are guaranteed to be unique.
Last, but not least, OpenID 2.0 has built in support for XRI-based identifiers. While some decry the addition of "yet another namespace" XRI's provide important, standardized ways of creating identifier extension with semantic meaning for sophisticated discovery via XRDS.
As part of the announcement, non-assertion agreements were collected from contributors to this and prior specifications. The non-assertion agreements declare that these companies will not assert any patent rights against OpenID implementations. Getting these assertions collected--and getting them right--was one of the things that has kept the OpenID 2.0 specification unfinalized for these past months.
The good news is that because of the delay, there are many libraries already available that support the new specification. What's more, multiple OpenID Providers including MyOpenID, Sxipper, and VeriSign's PIP already have support for both of these specifications.
Other significant announcements at IIW surrounding OpenID include Blogger's imminent support for OpenID-based commenting. That means any of the 160 million already existing OpenIDs can be used to leave a comment without signing up for Blogger or Google accounts. This is important because it's the first big relying party for OpenID. It's relatively easy to become an OpenID IdP. Being a relying party is an expression of trust.
For example, as far as I know, you can use your Wordpress.com blog as an OpenID (they're acting as the IdP), but you can't yet use OpenID to leave comments on Wordpress.com hosted blogs. Wordpress.com is an IdP, but not an RP. The same is true for AOL.
As I spoke to Steve Gillmor at the workshop, he explained that even something as simple as blog commenting is significant. Support for OpenID-authenticated commenting by the major blog hosters would create a single namespace for blog comments--allowing them to be correlated and rolled up into a searchable, referencable place. Imagine if all the comments you left around the 'Net could easily be placed on your blog? OpenID enables that without a lot of centralized infrastructure or a new company--that's the beauty of identifiers that cross silos.