See my previous post on Web 2.1: How OpenID will rescue Web 2.0 where I wax lyrical on how great it will be when I can have a single ID and use it everywhere. Well, I still think it is a good idea, and I still think it is the right approach, but I am considerably more disappointed about the level of support.
The asymmetry of the support bugs me. It seems that there are many providers who say “yes, our ID’s are open IDs” but then they don’t accept anyone else’s open ID. WordPress is one of those. My wordpress ID is an open ID, but I can not use any other. Obviously with this kind of support, I can’t just have one OpenID, which is the whole point.
I recently hit a Web 2.0 service I use occasionally — I will keep them anonymous for now — and noticed a new “Log in with OpenId” button. Great! This is what I am looking for. I have a log-in ID there, but this would be my chance to ditch it, and use my open id instead. I click the button, and what happens is not what I expected.
I use MyOpenID.com, which asks for a confirmation, so did so, and then got another screen saying that the application was asking for some additional information. Seems fair enough to share a little information about myself, but I was more curious about what kind of information it was using. I clicked OK, and then I was presented with a standard “register” screen with a few of my details filled in. Not sure why I needed to do this, but I will go along with it. I do expect the application to keep a couple of details about me, so no problem.
Then it told me “that user ID already taken”. Apparently, the service was not really using my openId as an ID at their site. Instead, they use the openID provider just as an aid to set up a local account. They should realize, that only the full OpenID is guaranteed to be unique. Using a value from my provider as a local ID is not guaranteed to be unique, and therefor is not a good ID.
Conclusion: To let people access a site with an OpenID, you have to actually use the OpenID as an ID. There is no short cut, and ironically, there is nothing easier either.
By the way, after I wrote the Web 2.1 article, I saw a great talk by a speaker at SOA World on the subject. I asked for the slides, but have not gotten them yet. He pointed out some potential problems, and I hope to cover them here .. when I get those slides 🙂
Thinking Matters 
Um… no.
> Conclusion: To let people access a site with an OpenID, you have to actually use the OpenID as an ID.
This would be great if the site only allowed OpenID users, which wouldn’t work since there isn’t enough OpenID penetration on the web.
Now, I’m not defending the particular Web 2.0 service you are referring to, they are still wrong, but using OpenID as your ID on a site is probably a bad idea. Instead what you want is to link your OpenID to your existing user account. If you don’t have a user account, you’d still need to create that account on the service, so the above usage would be correct.
Now I’d argue that the correct behavior is that if you try to login with an OpenID and don’t have an account, that you should have an account automagically created and populated with whatever info your OpenID provider gives them (or that you allow). But that isn’t always possible, and certainly wouldn’t have helped in the situation of an already existing user account that isn’t linked to the OpenID in question.
Look, an OpenId is globally unique. If you want give out your own local ID, you simply scope those names by your own domain name. Now all of your local IDs are globally unique and can’t possibly conflict with an externally generated ID.
If by “local account” you mean that there is some information maintained locally for each user, then sure, someone logging in with an ID from someplace else will still have a local account. But the ID of that account is the OpenID globally unique string.
Sites that have existed before knowing about OpenID have to either migrate existing IDs or make the code handle two kinds of ID: long fully qualified ones, and short ones that need to be qualified by their domain name. This allows an existing application to migrate to the OpenID world.
That is my only point here: I was prevented from creating an account because of a name clash that should not have happened.
You also make a good point, that what I would like to do is to change my ID to my OpenID (link it as you say). It did not expect this level of sophistication, because in most systems an ID is the key to all the stuff done or managed by that user, and usually there is no capability to migrate all those artifacts to a new ID. So I was willing to take the hit of having to create a new ID, and move the relevant artifacts manually.
I’m sure they had some problem with the legacy design of their non-OpenID aware user system and bridging OpenIDs to their existing account structure was just the lowest barrier way to let OpenID in the door.
They should offer a way to connect an existing account with your OpenID, if they don’t already. I think this should be standard, as we already have accounts on sites all over the internet, and moving to OpenID is less attractive for users, if we loose the value of our existing accounts.
Hi, I am intrigued by your making a mistake I have never seen made before: it’s not “wax lyrically” but “wax lyrical”. The reason is that “wax” basically means “become” (more precisely, it means “grow” with the implication “become”) and so it’s followed by a complement.
I agree completely. Had blogged earlier on a rather similar issue which seemed to show itself up at a id creation time here : http://blog.dhananjaynene.com/2008/02/implications-of-openid-on-software-design/
I disagree. An OpenID acts as a replacement (or alternative) to a username and password combination for authentication. There’s nothing inherently wrong with asking a user to pick a unique username for that specific site if the site has already settled on usernames for things like profile URLs – obviously it’s nicer if the OpenID can be used for this username, but it isn’t the end of the world if the site still asks for a username to be picked.
My problem with OpenID is not the same as yours. Rather it’s about the kind of OpenID service a certain site allows. One site allows the use of myopenid.com OpenIDs while another uses only OpenIDs from other services.
I have used a few openID services before I used myvidoop which is a username and password storage service and an OpenID provider. I just hope websites which are migrating to OpenID would provide users from different OpenID providers access to their websites. It’s a hassle signing up to different OpenID services.
Thanks for the corrections. Honestly, when I wrote the piece, I was not sure, and I actually did a search to try and discover whether this was the correct form, and I found enough hits to convince me that it was in common use that way. I will correct the post.
Pingback: Who’s Ready for OpenID « Travaganza - Design and Development Trends
Pingback: Identity Update: Browsers with OpenID? « Go Flow
Pingback: SSO: What is it « Agile Software Craftsmanship