Ask YC: Who uses OpenID?
With all the talk of open APIs and data portability going on in the news, who here either currently uses or plans to implement OpenID, OAuth, etc; and, for those that don't, why not?
I have finally found one clear use case for OpenID: sending out login passwords to newly hired consultants without using cleartext email. Of course, this isn't the kind of killer app that will make OpenID a household word.
Among other things, OpenID is: confusing even to geeks, not especially secure, not solving a particularly important problem, an open-ended set of external dependencies on provider code that you do not control, very poorly branded (because, you know, everyone loves having their ID checked), poorly marketed, and often assumed to be something it isn't.
From a site developer's standpoint, OpenID solves the wrong problem. Nobody is avoiding your site because they have to remember a password. That requirement hasn't killed eBay, Gmail, Amazon, PayPal, Facebook, Plentyoffish, HotOrNot, news.yc, or any other site in history. Frankly, if people are avoiding your site, it's probably because it sucks. Spend your time making your site suck less.
A good way to make your site suck less is to eliminate the need for signups at all, to delay that need as long as possible, or to get the user so excited about the site that they barely notice the signup process. OpenID doesn't do these things. The problem with signups is not the typing, remembering the passwords, or even securing the passwords -- it's the mental overhead associated with deciding whether or not you want another relationship in your life. Can you trust this new site? Will it waste your time? Will it spam you? Will it hit you up for money, forcing you to feel embarassed as you say no over and over? Will your friends find out that you signed up on the site? Will the site plaster your Amazon purchase history all over the open Internet?
Signing up for a site is exactly like making a new friend, and if you think it would be great to automatically be friends with everybody in the world, find a recent multimillion-dollar lottery winner and ask them what that's like. Managing your relationships takes thought, attention, and judgement. Nobody's automated that yet.
So what are you saying -- that because there are successful sites that require passwords, that passwords aren't a problem for users?
And this problem hasn't killed any sites that were really good? How do you know? Perhaps clever entrepreneurs can steer around the problem, but the point is that there could be a whole other class of apps enabled by a universal identity system.
I happen to work on a site where the user can derive a lot of value from getting recommendations, based on their social network. We do well, but our biggest problem is that a new user doesn't know how good it can be once they've done the work of creating their own network. All over again. For every site that they use.
The short-term answers are strategies such as you mention. Your points about delaying the need for signup are good advice for today.
The long-term answer to this problem is not Facebook, or for everyone to get acquired by Yahoo or Google or whatever. The answer is to create an open or otherwise portable social network -- manage in one place, use everywhere. OpenID, or something like it, will be required for this.
There are some big flaws in OpenID (the phishing problem for one) but at least some people are trying to address them.
It confuses some geeky/internet-savvy people too, just because of the horrifically bad implementation and design of the OpenID system.
I think that users do need to be educated to not enter their passwords until they're redirected to their identity provider (and to confirm their "SiteKey" if the provider supports it). But it hardly "teaches users to fall prey to identity theft".
The fact is that most users end up using the same passwords over and over again. Most websites (ecommerce and banks excluded) don't bother using any sort of encryption for logging in at all.
OpenID goes a long way to lessen those risks. Additionally, integration into browsers could eliminate the risk of phishing.
I'm not sure, but it may be better to take the chance that the user has only one password, than to give that user an OpenID account and remove all doubt.
With OpenID, your password is only ever entered in one place: the OpenID provider's login page. When another site wishes to authenticate you it redirects you to your provider where you enter your password then get redirected back to the original site along with a token proving you have authenticated and granted authorization to the site.
The most important thing is that you use a provider that you trust.
A good OpenID provider can actually help prevent phishing and identity theft. For example, myopenid.com (and probably others) lets you select a personalized image that is displayed whenever you're prompted for your password (much like Bank of America and other banks' "SiteKey") and you're supposed to train yourself to never enter your password unless you see the correct image, to prevent phishing (though most of us are smart enough to look at the URL too). They also provide a comprehensive log of every site which has authenticated using your account, so if your password has been compromised it is very easy to find out.
By the way, OpenID doesn't require you authenticate to your provider with a password. It could be done via a SecurID token, or even biometrics. Passwords just happen to be the simplest and most common method.
Is OpenID more secure than my solution? I mean, it's obviously less convenient and harder to understand, but perhaps it would be more secure.
I guess you could argue that my passwords are sometimes sent in the clear, when the site I'm logging into doesn't have HTTPS. Fair enough, but I wouldn't think that the marginal additional security of OpenID would matter too much in that scenario. Sites which don't support HTTPS can hardly be relied upon to be careful with my data, anyway.
Plus, once you're logged into your OpenID provider, you don't have to enter your password for any sites which you already trust, until you log out. That's part of the advantage of a single sign-on system.
"Sites which don't support HTTPS can hardly be relied upon to be careful with my data, anyway." -- so, the vast majority of sites? People are going to use these sites either way. Most users don't even know what HTTPS is.
While it's unlikely an OpenID provider would sell out to DoubleClick, etc, if you're paranoid it's also very easy to use your personal website URL as a portable OpenID (it's literally two extra HTML tags in your homepage's header). You can either run your own provider using a simple prepackaged solution, or do what I do and just delegate to another provider, which you can easily change in the future with a quick edit of you homepage's header. Here's mine:
<link rel="openid.server" href="http://www.myopenid.com/server" />
<link rel="openid.delegate" href="http://tlrobinson.myopenid.com/" />
I agree OpenID is a little difficult to understand (as evidenced by some of the comments here) but it's actually very easy to set up a simple OpenID (many people already have one and don't know it... all AOL, Technorati, LiveJournal, WordPress, and some other accounts are OpenIDs) and not too much harder to set up a delegated OpenID or run your own provider.
Here's a great little article by Sam Ruby: http://www.intertwingly.net/blog/2007/01/03/OpenID-for-non-S...
I suggest everyone look into OpenID a little more before completely dismissing it.
I don't understand some of these people who are hyper-security-conscious to the point of insanity. It affects their enjoyment of the internet.