In response to a Kim Cameron item about Blogger’s support for OpenID — and, when the OpenID provider is myopenid.com, for identity selectors — Vittorio Bertocci pointed out something I had not realized:
MyOpenID does exactly what I was asking for: it allows me to create a new openid without having to establish any password. Let me repeat/rephrase it: I can create an account that can be accessed exclusively by using a personal card.
That got my attention. Coincidentally I had just been reading the rough cut of Vittorio’s forthcoming book, Understanding CardSpace, and was at the same time reviewing how OpenID providers like MyOpenID work with OpenID relying parties like ClaimID.com. The ability to create a passwordless, card-only account on MyOpenID is a great step forward, for the reasons Vittorio explains on his blog.
I went over to MyOpenID, created a new, passwordless account, associated that OpenID URL with my ClaimID account, and away I went. Nice!
Now I’m trying to imagine how I would explain all this to a civilian. Honestly, I don’t think I could, yet. It’s a stretch even for me to hold in my head all the moving parts. Which identity selector works with which browser on which platform? What does the card represent? What does the OpenID URL represent?
But we are tantalizingly close to real use cases that will begin to walk people through these scenarios. It’s difficult to describe the abstractions, but as people begin to actually have the experiences, it’ll all start to come clear. Similarly, as people start to have the managed-card experiences that Dick Hardt discusses in our ITConversations podcast, those will start to come clear as well.
To all those attending the Internet Identity Workshop today: Thanks, and keep up the great work!
When discussing OpenID it is important to note that there are pretty serious security issues with it, both at the technical level, and at the social-engineering level. While looking at implementing it for Moodle on the OLPC school server, I’ve had some discussions with Ben Laurie (author of the Apache SSL module, and well versed in PKI and similar arcana).
See the discussion here
http://lists.laptop.org/pipermail/server-devel/2007-July/000083.html and Ben Laurie’s notes at http://www.links.org/?p=187 and his later blogposts.
“there are pretty serious security issues with it, both at the technical level, and at the social-engineering level.”
Which is why marrying OpenID with a passwordless identity selector is helpful.
How well will OpenID retrofit? Those of us who have been using the internet for a couple of years or more must have accumulated a hundred of more sites that require User ID/Password. Will OpenID retrofit these?
Rhapsody, Yahoo, email servers, medical insurance site, Youtube, Digg, FlightAware, Slacker, Netflix, Myspace, Hotwire, eBay, university site, MetaFilter, MarketScreen.com, Raging Bull, Sirius Radio, etc., etc.
There are strategies for handling all these passwords — mostly to use one ID as often as possible and to record all IDs to a word document the name of which is well camouflaged, so as to be of minimal interest to any possible hacker.
If OpenID can not adapt to dozens/hundreds of existing IDs, then I’m afraid it just gets added to the list of one more site’s passwords. One other concern is how well OpenID’s server is protected from intruders. My computer is just one of many millions. Chances are pretty low that I’ll be randomly hit by a hacker. OpenID is out there labeled as a site containing LOTS of passwords. That’s so much more attractive to hackers than my one measly computer. Do I want to open myself to that magnitude of a risk of computer-identity theft?
“How well will OpenID retrofit?”
My hope is that for OpenID, and also CardSpace, we’ll find that over time sites offer us the option to migrate from name/password to these other mechanisms.
Right now, you’d be the oddball service if you offered an alternative, so there’s no peer pressure to do it. But when things tip, you’ll be the oddball for not offering alternatives. Then you’ll feel that pressure, and will want to do something about it.
The team I work with has created a password-less provider service that binds a users account to an strong authentication devices, such as a smart card, fingerprint reader, or USB token:
https://openid.trustbearer.com