By Jake Edge
October 31, 2007
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:
There is nothing stopping people from releasing 2.0 libraries written
to Draft 12 (as is already happening) nor from people implementing,
using, and shipping 2.0 code and services. From a technical
perspective, no issues have been raised so it is fair to assume that
there will not be changes between Draft 12 and Final.
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.
(
Log in to post comments)