OK... I know that USA Today, even in its InternetLife pages, is not exactly Scientific American, but this bubbly upbeat article about the emergence of OpenID does seem to me to miss some of the key points.
I have huge sympathy, incidentally, for Brad Fitzpatrick of Six Apart, who probably spent a while on the phone to Jon Swartz - the article's author. The reward for Brad's investment of time was the following illuminating soundbite about the take-up of OpenID: "It's a little surprising".
Time well spent, then ;^)
Clearly, it was hard for USA Today to ignore the OpenID phenomenon, as it recently got a level of endorsement from Microsoft. Apparently OpenID is a feature similar to Cardpsace. That probably made Kim Cameron's day, too.
But what are USA Today's readers supposed to make of the idea that OpenID "could be the answer to a major headache: It lets consumers use the same
user name and password for hundreds of websites that require a sign-in." Hold on... isn't that just what we've all been telling people not do to for the last few years? And in any case, if I want to use the same user ID and password for every website I subscribe to, I don't need OpenID to tell me how to do that... I just type them in and hope for the best.
The problem is that, in simplfying the OpenID concept to this extent, Mr Swartz has omitted both a key point about how OpenID actually works, and a key decision factor about when it's a good idea and when it might not be the best alternative.
In case you haven't tried it yet, the simple idea behind OpenID is this: you 'register' yourself at an OpenID provider, which basically means that you associate a user ID/password with a given URL: so, for instance, I associate the ID and password "robin" and "trivial" with the URL "http://myopenid.tla/robin".
When I subsequently want to get to a Service Provider website which needs me to identify myself, the OpenID protocol allows the Service Provider to re-route me to me URL, where I confirm that I know my userID and password (to the server at that domain... not to the service provider).
The OpenID server sends me back to the Service Provider with a message which says "yes, he knew the ID and password", and the Service Provicer lets me in.
So the first relevant point is - this is not a matter of setting the same ID and password at every subscription site I use... it's a matter of rerouting Service Providers to a single (or if I have lots, my choice of) OpenID provider.
Second relevant point: why would the Service Provider trust the assertion it gets back from the OpenID URL? How does the Service Provider know that I haven't set up a malicious OpenID provider which always answers "Yes"? The answer is that the Service Provider has no de facto reason to trust the OpenID Provider's word for it, unless there is some other factor in operation which increases the trust level - such as a trust agreement between the Service Provider and the OpenID Provider (and possibly the user too).
That's more heavyweight than the default OpenID scheme is intended to be, because its primary aim is (as the article correctly points out) to increase user convenience. If you do add those additional trust factors, you end up with a distributed authentication service which looks unsurprisingly similar to a subset of Liberty's ID-FF functionality (the browser redirect functions, but not the single login-logout or the link/unlink functions...).
And it's fine to have the objective of increasing user convenience. Which takes me back about 12 years to the 'Cynic's Law of Security Systems':
"You can have secure, manageable or convenient... pick any two".
Posted by racingsnake
@ 03:38 PM GMT+00:00