As we continue to work on the code that will eventually become stackoverflow, we belatedly realized that we’d be contributing to the glut of username and passwords on the web. I have fifty online logins, and I can’t remember any of them! Adding that fifty-first set of stackoverflow.com credentials is unlikely to help matters. Visit for more information
Best Username
With some urging from my friend Jon Galloway, I decided to take a look at OpenID. OpenID aims to solve the login explosion problem:
Let’s say you’re visiting a new website for the first time. As you browse around, eventually you’ll do something that requires more than anonymous guest access. So you’ll get shunted to the “create a new account” page, in whatever form that takes. I’m sure everyone reading this knows the drill. But if the website is OpenID enabled, you don’t have to go through all the typical rigamarole necessary to create a new account. Instead, you can enter your OpenID login:
I’m going to indulge in a bit of hand waving here and assume that you already have an OpenID login. It’s not such a terrible stretch, honestly; every AOL and Yahoo user already has an OpenID login even if they don’t know it yet.
OpenIDs are technically URLs. Here are a few examples:
That’s one usability problem with OpenID: you have to remember a relatively complete personal URL that no two OpenID providers define the same way. Which compares unfavorably to, say, remembering your email address. There are shortcuts around this that I’ll describe later, but for now, there’s ID selector, which provides a reasonably friendly UI for building an OpenID login URL.
If you enter the right URL, you’ll get redirected back to your OpenID provider, where you’ll enter your single set of login credentials.
You’ll be prompted to add this site to your provider’s list of “trusted sites” for your account. Once you do this, you can bypass all of these steps the next time you’re on the site.
And, finally, you’re logged in for the first time!
If that seems like extra work – and remember, I’m not counting the time it took to set up the initial account at ClaimID, either – well, I won’t lie to you. It is more work. But it’s worth noting that:
It’s not exactly frictionless, but it’s a heck of an improvement over having to remember 50 different usernames and passwords for 50 different websites, wouldn’t you say? I think it compares quite favorably with the current champion of frictionless communication: anonymous comment boxes. They typically have three fields to fill out: username, URL, and email. OpenID requires only one. Your provider can proxy your URL and email back to the blog automatically from your provider profile, if you choose a smart provider with attribute exchange support.
Which brings me to the other problem with OpenID. The quality of your OpenID experience is heavily influenced by the provider you choose. For example, Yahoo! is smart enough to work even if you enter nothing but “yahoo.com” as your OpenID URL. That is, assuming you’ve enabled OpenID support for your Yahoo! login. Providers can also offer unique functionality that sets them apart, too. For example, SignOn.com allows the use of Information Cards in Windows, so you can log into a website without ever typing in a password! It’s a bit of work, as you have to associate the Information Card with your provider account first, but I tried it, and it works as advertised.
My experiments with OpenID were quite positive, but all is not wine and roses in the land of OpenID. Stefan Brands identifies some potentially large problems with OpenID, backed by exhaustive references:
As I mentioned above, I feel most of these criticisms can be mitigated by picking a quality, trustworthy OpenID Provider. Particularly one that uses SSL. Since it’s an open ecosystem, I’d hope the more reputable and reliable OpenID providers would rise to the top. And consider the advantages: as an application developer, you no longer have to store passwords! That’s a huge advantage, because storing passwords is the last business you want to be in. Trust me on this one.
I also found Jan Miksovsky’s criticisms of the user experience of OpenID – as of 6 months ago – fairly damning:
Perhaps the most compelling point Jan makes is this one: it is a bit odd to ask users to associate themselves with an arbitrary URL instead of an email address. I definitely saw some rough edges in today’s experimentation, but I’d say the user experience has improved since Jan looked at OpenID. That’s encouraging.
I realize that OpenID is far from an ideal solution. But right now, the one-login-per-website problem is so bad that I am willing to accept these tradeoffs for a partial worse is better solution. There’s absolutely no way I’d put my banking credentials behind an OpenID. But there are also dozens of sites that I don’t need anything remotely approaching banking-grade security for, and I use these sites far more often than my bank. The collective pain of remembering all these logins – and the way my email inbox becomes a de-facto collecting point and security gateway for all of them – is substantial.
If you’re a software developer building an application that requires user accounts, please consider using OpenID rather than polluting the world with yet another login and password. I also encourage you to experiment with OpenID as a user. Create one. Try logging in somewhere with one. If you don’t like the experience, or if you agree with one (or more) of the criticisms I listed above, how can we collectively fix it? We desperately need a solution to the login explosion, and right now the only thing I’ve seen on the horizon that has any kind of critical mass whatsoever is OpenID.
If we can’t make OpenID work, at least for run of the mill, low-value credentials that litter the web in increasing numbers – what hope do we have of ever fixing the login explosion problem?
