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 think it's important not to confuse OAuth with OpenID. I think OAuth might be very useful indeed, and I'd like to see it succeed. Tying it to the Titanic will not help.
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.
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.
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.
Point taken. I did not mean to suggest that they are one and the same, just that they are both examples of measures that web services are taking to open their systems up. I agree that OAuth definitely seems to be inherently much more valuable.
As open social will gain more popularity these kind of solutions will be necessary. OpenID is for your users, OAuth is for other sites and services you wish to communicate with, and DataPortability is for the whole thing being portable from one service to another. I don't believe the world will remain in the chaos it is at this moment and a unified open-standardized platform will be a must. Don't look who don't, be a pioneer and implement it. The major players will follow.
From what my friends have experienced with their sites, I'd say you're better off with putting your time in doing something else. OpenID is LONG way off from becoming mainstream. On consumer sites, it's RARELY used, unfortunately.
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.
The fact is that most users end up using the same passwords over and over again.
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.
That's the point. It's inevitable because we're human, we can't remember hundreds of different passwords. Why not allow the user the connivence of logging in once using a single password, and at the same time improve the overall security?
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.
I agree with all of what you say. That's why I paid $35 for 1Password. It stores all my passwords locally. It supports 95% of the sites in the world, today. It doesn't sit outside a firewall or accept requests from the open internet. It doesn't run on Windows. It is unphishable. It doesn't provide hackers, datacenter thieves, and rogue employees with a big tempting centralized target. It doesn't require me to figure out OpenID. When my laptop gets stolen, I will know immediately that it's time to change all my passwords, and hopefully the encryption will buy me the time to do so. The company will probably not be bought by DoubleClick and used to data-mine my login history (which, at the moment, it doesn't track anyway), and if that does happen it is easy and intuitive for me to just switch to something else -- or just switch to a notepad -- because I have all the passwords under my local control.
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.
Less convenient? So, what happens when you're at a friend's house or public computer where you don't have your 1Passwd/Keychain database?
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:
There's even WordPress (and I'm sure others) plugins to make this trivial for non-technical users.
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.
I use OpenID and it's frustrating that websites don't accept it. On this website, for example, I was forced to use BugMeNot. Why? I don't like being forced into this position.
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.