Security

OpenID 2.0 closing in on acceptance

A very common complaint about using the web today is the proliferation of user IDs and associated passwords, people would much rather see a "single sign-on" (SSO) system. There are many proposed solutions for SSO, but OpenID is one of the simpler and most widespread; it also has the advantage of not being tied to a specific vendor, with open specifications and freely available libraries. Currently the OpenID 2.0 specification is closing in on acceptance with just the "intellectual property" rights (IPR) policy standing in its way.

One of the nicest features of OpenID is its user-centric nature – users can have as much control as they want over their identity. Unlike other solutions, there is no central authority required to store identities or process authentication requests. Users can run their own server or pick one of the available providers to get a free ID. An overview of OpenID appeared on this page last year.

OpenID 2.0 adds a number of features that will be quite useful for both users and websites that implement OpenID ("relying parties" or RPs in OpenID terminology). The Attribute Exchange extension is one that could solve a common problem by allowing users to associate additional information with their identity, sharing and, more importantly, updating that information at multiple sites more or less transparently. If a user moves or changes email addresses, that information could be updated at multiple sites.

OpenID 2.0 also provides support for additional extensions to the protocol, allowing functionality beyond what is currently envisioned, while adding namespaces to avoid name collisions between those extensions. Directed identities takes the delegation idea from OpenID 1.1 one step further, allowing users to specify the URL of the OpenID provider (OP), rather than their user-specific URL, as their ID. The OP can then resolve the user's URL through some means (such as a login screen) and provide that back to the RP. As James Henstridge points out in his weblog, this would allow an OP like AOL to allow "aol.com" as the OpenID for millions of users. Perhaps not the OpenID of choice for everyone, but it does offer a pretty simple ID to remember.

There are other improvements included in OpenID 2.0, including interfacing with other identity solutions, security improvements, and allowing for arbitrary length of protocol messages, rather than being limited by the URL-length limits of browsers. There are freely available implementations of OpenID 2.0 for PHP, Python, and Java (at least), all of which interoperate.

A recent discussion on the specs mailing list would appear to pave the way for the most recent draft (Draft 12) to gain acceptance. According to David Recordon, there are no technical barriers to acceptance:

The only barrier is a legal one, the IPR policy needs to be agreed upon, then each contributor needs to sign a "non-assertion statement" that promises not to sue any implementer of the standard for patent infringement. This allows anyone to implement the standard without fear of lawsuits or having to pay royalties, at least to the companies that have signed. Other companies or, worse yet, patent trolls are, of course, free to sue.

OpenID still suffers from a lack of sites that accept it, though many big players are flirting with it: AOL and Microsoft for example. AOL is an OpenID provider, all AOL screen names have an OpenID if they wish to use it, but you cannot log in to AOL using it. Also, there is rampant speculation that Google's recently announced OpenSocial API will provide OpenID support eventually. So far, though, other than the LiveJournal blogging sites (where OpenID originated) and Digg, there just aren't that many sites where OpenID can be used. Perhaps finalizing and accepting the 2.0 specification will turn the tide.

Comments (8 posted)

cups: buffer overflow

Comments (none posted)

mldonkey: privilege escalation

Comments (none posted)

python: integer overflows

Comments (none posted)

subversion: possible information leak

Comments (none posted)

xen-utils: insecure temp files

Comments (none posted)