Since tomorrow is the Data Sharing Summit, I was familiarizing myself with the OpenID specification because I was wondering how it dealt with people making false claims about their identity.

Scenario: I go to http://socialnetwork.example.com which supports OpenID and claim that my URL is http://brad.livejournal.com (i.e. I am Brad Fitzpatrick). The site redirects me to https://www.livejournal.com/login.bml along with a query string that has certain parameters specified (e.g. “?openid.mode=checkid_immediate&openid.identity=brad&openid.return_to=http://socialnetwork.example.com/home.html”) which is a long winded way of saying “LiveJournal can you please confirm that this user is brad then redirect them back to our site when you’re done?” At this point, I could make an HTTP request to http://socialnetwork.example.com/home.html, specify the Referrer header value as https://www.livejournal.com/login.bml and claim that I’ve been validated by LiveJournal as brad.  

This is a pretty rookie example but it gets the idea across. OpenID handles this spoofing problem by requiring an OpenID consumer (e.g. http://socialnetwork.example.com) to first make an association request to the target OpenID provider (e.g. LiveJournal) before making performing any identity validation. The purpose of the request is to get back an association handle which is in actuality a shared secret between both services which should be specified by the Consumer as part of each checkid_immediate request made to the Identity Provider.  

There is also a notion of a dumb mode where instead of making the aforementioned association request, the consumer asks the Identity Provider whether the assoc_handle returned by the redirected user is a valid one via a check_authentication request. This is a somewhat chattier way to handle the problem but it leads to the same results.

So far, I think I like OpenID. Good stuff.

Now playing: Gangsta Boo - Who We Be


 

Friday, September 7, 2007 4:33:40 AM (GMT Daylight Time, UTC+01:00)
We just implemented OpenID, LiveID, CardSpace and updated AD provider for the next release of DotNetNuke which is due out in a week. Of all the authentication methods, I like OpenID the best since it seems to be the most intuitive and flexible. LiveID is good, but it doesn't handle custom profile data and there is only one provider. With OpenID users have a lot more freedom about how to share profile data and are free to use whichever provider they wish in order to validate their claims. It will be interesting to see how Cardspace fits into the mix long-term and whether OpenID can truly thrive or if it will continue to be relegated to the fringe websites.
Friday, September 7, 2007 8:30:08 AM (GMT Daylight Time, UTC+01:00)
Your verbal statement is indeed one character longer than the query string, plus the query string conveys more information, so what do you mean by "long winded"? ;)
Saturday, September 8, 2007 1:20:54 PM (GMT Daylight Time, UTC+01:00)
A key problem I see with OpenID is not in identity spoofing but identity provider spoofing to harvest passwords.
Monday, September 10, 2007 10:08:50 PM (GMT Daylight Time, UTC+01:00)
you need good music
http://www.amazon.com/s/002-3274932-4158466?ie=UTF8&tag=mozilla-20&index=blended&link%5Fcode=qs&field-keywords=handsome%20boy%20modeling%20school
John William Minton
Tuesday, September 11, 2007 4:21:26 PM (GMT Daylight Time, UTC+01:00)
This relies on the the OpenID Identity Provider (http://www.livejournal.com in your example) to not only be trustworthy, but also trusted by http://socialnetwork.example.com.

The big shortcoming of this is since not all OpenID identity providers can, and should, be trusted, it puts the burden on the relying party to figure out who to trust. Invariably, the # of OpenID providers will dwindle to a much smaller subset that can actually make trustworthy claims about a user.
Tuesday, September 11, 2007 4:30:15 PM (GMT Daylight Time, UTC+01:00)
Trevin,
I consider that to be a feature not a bug. I don't want to be able to consume IDs from any random Web site that can throw together a Perl script. However when I do decide to partner with particular Web sites, I should be able to use a standard technology that everyone is familiar with to do so instead of proprietary one-off solutions.
Tuesday, September 11, 2007 6:56:20 PM (GMT Daylight Time, UTC+01:00)
Agree that it's a good thing to only have a network of trusted Identity Providers. I definitely wasn't suggesting otherwise. Just pointing out a seemingly obvious point, since much of the OpenID "benefits" surround it being completely de-centralized with theoritically an unlimited # of identity providers. As the # of identity providers go down, the de-centralization argument loses traction.
Comments are closed.