I realize I’ve had a lot of anti-technology posts recently, but really they’re more like anti-hype posts. A lot of technologies are hyped like crazy and when you start working with them you realize that it’s a lot of crap. Today’s story is about OpenID, which I recently implemented (but we haven’t published yet) for wishlisting.

If you’ve never used it, the gist of it is that it’s going to give you the ability to log in to any site that supports it, and all you need is a single username and password. Makes sense and sounds compelling, although there was this thing called Passport which tried to do that too. It was never widely supported by websites, even though everyone with a Hotmail account had one. The big reason people point to with regard to Passport’s lack of adoption was that it was totally controlled by Microsoft, and people/companies had trust issues with them watching what sites you join and controlling all of your data.

So, the OpenID standard was created, and the big hype is around how it’s “decentralized” and no single entity controls all of your data, solving Passport’s biggest problem. Except, for most people, it doesn’t. And it introduces some problems Passport didn’t have. And no one seems to be doing anything about them.

Problem #1: It’s centralized (for most users). The way their “decentralization” works is that you pick a domain that you own (I chose “lianza.org”) and add some markup to the page that says, basically “My open ID is at http://someopenidprovider.com/tlianza”. That way, your username and password are stored at someopenidprovider.com, and if you don’t like them, you can just change your pointer to some other provider. Oh wait, you don’t own a domain? That’s no problem, you can still get an open id. There are lots of providers – like myopenid.com. Of course, that’s centralized. So, if you don’t own your own domain, you’re back in centralized-land again. No problem right – after all, doesn’t everyone own their own domain? (Hint: no).

Problem #2: It’s not easy to use (for most users) If you check out OpenID early adopters like ma.gnolia, you’ll see that the common implementation of the OpenID login box is a single text box with an OpenID logo in/near it. Wow – one box, even better than username/password right? Not really. Into that box you put a URL. That’s the URL of your own domain (for those of us who own them) or the URL of your provider, which is undoubtedly some string with either a subdomain or a subdirectory and a site name that you may or may not remember. Explain to Joe websurfer that he can’t login with his familiar ‘joesurfer43’ username and instead he has to log in with ‘http://myopenid.com/joesurfer43’ and I’m not so sure he’ll be to thrilled about that. Assuming he bothered to create one in the first place.

Problem #3: You already have one, you just don’t know what it is! To get around the “assuming he bothered to create one in the first place” problem, services like AOL started saying they’ll support being used as an open id provider. So, my mom can now use OpenID because she has an AOL account. Does she know what it is or how to use it? Does she know that instead of her username she’ll have to type in ‘http://openid.aol.com/username’ to log in? I bet she doesn’t. If this thing continues to spread, she’ll probably have multiple OpenIDs that she doesn’t even know about. Which one does she use (if she even knows any of them)?

Don’t get me wrong, I use it personally and think it’s great for me. But I’m tech-savvy, own my own domain, and create a lot of logins at a lot of places. The value proposition for most people is pretty slim. With wishlisting, we’ve basically decided we’re going to stick with the UI convention that other sites are using because at least that way the people who use OpenID will be greeted with a familiar screen and know what to do. However, if the Open ID community really wanted to drive adoption they should have a UI that does not require the username to be a URL. There are a lot of ways you can do this. You can provide a box for a username and a dropdown for the service (@aol.com, @gmail.com, etc). That box might start to get unweildy, and it doesn’t solve the problem of people with multiple OpenIDs who forget which one they use, but it’s a start. Launching straight in with requiring people to remember a URL sounds like an approach that will keep adoption very low outside geeky circles.