I agree with you. Open ID is meant to solve an important problem. But until it's as easy to sign up for and use as typing in a user name and password is now, it's not really good enough.

Well... surprise, surprise, surprise! It comes down to the same basic issue that's been leveled at X.509 certificates, and Notes IDs before that. Secure authentication is inherently difficult and/or inconvenient.

Over the summer, I spoke at the Internet Child Safety Task Force (or some other impressive and forgettable name) in Boston. Microsoft did a presentation on their OpenID toolkit and I got a chance to talk to their PM. It sorta sounds like hosted client-side SSL certs (and probably is under the hood).

Since the venue was for child safety, it got a decent reception. MS will probably find a way to sink it into their SSL impl in a future OS.

Ned, I felt much as you do up until recently. However I think the fundamental technology is sound, and I believe we'll see a lot of the useability problems get resolved in time. (As you've discovered, delegation is a critical part of making OpenID's usable - I was frickin' ecstatic when I discovered I could use "broofa.com" as my OpenID, and not be tied to a specific provider at the same time. :-) ).

If nothing else, I'm convinced OpenID will we'll see more and more companies becoming OpenID providers, if for no other reason than to simplify integration with 3rd party products and services. Our company, zenbe.com [shameless plug] is a perfect example of why. Our webmail service requires users to login, and like a good, little, Web2.0 company, we offer our users forums and a blog to communicate with us and other users. But our forums are kind of primitive and hard to manage, so we're looking at GetSatisfaction.com as an alternative. The problem is that all of these are 3rd party products that require users to create yet more accounts. We're potentially asking users to create up to 4 accounts to participate in our service... silly, right?

The solution (we hope) is for us to become an OpenID publisher. because WordPress, BBPress, and GetSatisfaction all support OpenID login. Our users can then login at any of our related sites using "zenbe.com/username" as their username.

Note that we wouldn't expect users to have us be their canonical OpenID provider - we would merely offer this as a way for them to login into these other sites that they may not have used before, without having to go through any annoying registration process.

Anyhow, so far this has been the most compelling use-case I've found for why OpenID is important. I'm pretty excited about it, and look forward to when we have the resources to implement OpenID support on our service.

Ted Dziuba: the guy who ranted about cloud computing on The Register because his Web 2.0 site, running on the Amazon cloud, had given up the ghost. "So, what's the solution, Ted?" [sound of dialtone]

Maybe there's an opportunity to make OpenID more accessible, although I doubt Ted's onto it.

The real issue with OpenID is not necessarily that you have to get a provider, but rather, the masses are not able to use a their online profiles as addresses. For example, if MySpace was an OpenID provider someone could simply enter their MySpace URL for their identity, which would be much closer to the whole idea of OpenID allowing a person to use their URL as an identity.

You do make a good point though regarding Yahoo as a provider. If a major company is going to be an OpenID provider, then they should make it as easy as something like MyOpenID.com. Providing a URL like the one you mentioned above makes no sense and says more about the provider (IMHO) than the OpenID system at large.

Try digging around a bit, and you'll find Yahoo's OpenID server. I found it in the source of the funky link you posted above.

<link rel="openid2.provider" href="https://open.login.yahooapis.com/openid/op/auth">;
<link rel="openid.server" href="https://open.login.yahooapis.com/openid/op/1.1/auth">;

Sorry for multiple posts, but I just thought of something else to add. To see the true benefits of OpenID, you need to see a good implementation example. Ma.gnolia uses it in a way that almost hides it from the user.

Visit their signin page:
http://ma.gnolia.com/signin/

Then click on "AOL". Notice the slight mention of OpenID, but all the user needs to enter is his AOL username. They use this same OpenID technique for several of the other options. This can be done for any site where the OpenID URLs are known and based on the username.

@Richard: But OpenID is not terribly secure. It relies on DNS for example so any DNS poisening attack will let someone run their own OpenID server that authenticates as your URL. OpenID was created only for making blog comments and forum posts, nothing more 'secure' than that is supposed to be behind OpenID. This is the message I got continually when I kept asking about security features on the OpenID Mail list.

Ned, you are right on. There was a session at OSCON by Simon Willison and some others on "Critiques of OpenID" where they tried to explain some criticisms and how they were addressing them. I think they failed, as the questions showed that:

A) OpenID's goal as SSO (SINGLE Sign-On) has failed. Simon and others admitted they all have multiple OpenID's at multiple sites, which means multiple usernames and passwords, and the chance to forget which OpenID URL was used to sign-in. This is one of the key problems OpenID was supposed to solve in the first place and now people have a half dozen or more OpenID tokens from various providers. (I personally have already had this problem, as I forget which OpenID token I used at a site)

B) OpenID is a huge failure from the user experience. Not only do you have a username/password for sites, you also have an OpenID URL you might use to sign-in, and you might even have multiple OpenID URL's. Add to that all the bouncing around you do, and its pretty dang confusing from an average user perspective.

C) OpenID is a huge failure from a developer standpoint. Not only do you as a developer have to support usernames/password as usual, you also have to support OpenID sign-in, adding OpenID identifiers to existing users, new user sign-in with OpenID SimpleReg Extension, and of course the mess of a sign-up flow you get as a result of all these various ways someone signs up.

D) OpenID is less secure than a user/pass. It's just as vulnerable as user/passwords to phishing attacks, and there's no way for a site to re-authenticate a user.

At the end of the OSCON session, Leah Culver (developer of pownce) stood up and gave a rather good rant about these issues and how the only ones who seem to care to begin with are a fairly small group of geeks. And those small group of geeks who rant so loudly about how "OpenID is the future, we need single sign-on!" all have multiple OpenID accounts anyways.

From a security perspective, OpenID can't do a fairly basic thing most sites that want to be secure require. You want to re-authenticate the user, that is, you want to make the user sign-in again so that you can be sure its still the user at the controls and someone else hasn't drifted over.

There's no way to do this right now and actually know for sure whether the users OpenID provider actually asked them for their password again. A OpenID extension draft that supports this is out, however, just because an OpenID provider claims to support it doesn't mean it really does. So you end up having to verify OpenID providers to ensure they really do what they claim, then add them to a white-list. Apparently when Yahoo lets you sign-in to your Yahoo account with OpenID, it will only be from a whitelisted set of OpenID providers that they have checked these things out with.

The most interesting thing from the OSCON OpenID Critique session, is that it sounded like the presenters ran out of reasons for this mess pretty dang quick. OpenID may eventually address some of this in the future, but in the meantime I really consider it more hassle than its worth.

There is however, one great use for OpenID that I should mention, using it as a SSO system for a single companies websites. The user never sees or knows its OpenID, merely that when they visit the companies various websites, they bounce over to the companies central login for a single user/pass that they get to use across any of the companies websites. This works rather well since you know and trust the OpenID Provider (under your control), and the users never need to know or care that OpenID is allowing them to use that single username/password across all the companies sites.

FYI, you can also use i-names instead of URLs for your OpenId.

=Gustavo

I'm so glad I'm not the only one who feels this way about OpenID.

I set up an account at myopenid.com and what I liked a lot there was that they gave me a certificate for my browser. So now I have to remember http://myuserid.myopenid.com/ I'll get redirected there, (have to click on SSL-authentication, grmpf), and if I'm using my normal browser, it'll take care of the sign in, and I don't type a password. Having the authentication on a different channel (an IM message saying 'is it ok?') than http prevents the masquerading, as they don't know what IM system I use (or that I use a certificate).

But the gain is admittedly not that big. And all the sites I've used with it, still set up a useraccount (pick a login name, what's your email, although I already told them through myopenid I didn't want them to have my email address), so that part is less great.

@Chris: Say someone uses a nifty Javascript exploit to steal your cookie, you know, the one that has you logged in on your OpenID Provider. How can a website ask you to login again? All it can do is redirect you to your OpenID Provider, which sees your cookie, says you're logged in, then bounces back.

This is the re-auth problem I noted, which is critical for sites that want to do more than let you post blog comments (ie, financial transactions). A website has no way of knowing whether the OpenID provider really asked you for your password again.... which leads to a situation where only certain OpenID Providers get on a 'white-list' of ones that websites have verified actually do honor the re-auth OpenID Extension.

Do you as a OpenID user know which OpenID Providers are getting on these white-lists? Do we really want to explain to the average user not only OpenID, but the whole thing of how not all OpenID Providers are quite the same.... ugh!

OpenID has been around for quite awhile, 2.0 only recently made it to an actual spec. The OpenID extensions that add some semblance of security are in early draft stage with no way to actually guarantee they're implemented properly (thus the white-listing), the user experience is still terrible, and the developer experience is horrid as well. OpenID is definitely something that we should be waiting on (for it to address all these issues), not something we should be rushing to implement as the advocates keep claiming.

@Ben: Thanks for the great commentary on OpenID. It's humbling to see my original "basically sound" opinion quickly poked full of holes. :) (In my defense, it does seem like my use case for where it offers the most value isn't too far off the mark - i.e. as a single sign on solution for companies that want to offer more than one service to their users.)

After reading your comments, I find myself thinking, "Okay, I get that there are issues with OpenID. But what other option do we have? If not OpenID, then what?"

We've already seen that a proprietary system like MSFT's Passport won't achieve widespread acceptance (thank god!) Nor will something like the slightly more open "Liberty Alliance" that Sun Microsystems spearheaded back in 2001. OpenID seems to be the only movement with a chance at getting embraced by more than a small cabal of Fortune500 players.

I guess I can't help but think that even if OpenID is, "only good for blogs and forums", that might actually be a much bigger success than the phrase implies. If blog and forum-quality authentication is all that's needed 98% of the time, than one could argue that OpenID - even in it's current, imperfect, incarnation - is radically more succesful than any of it's predecessors and not, as you say, a "huge failure". Mind you, I totally agree about it being nigh-unusable for most users right now, but I, like other commenters here, see that as more of an implementation detail than a fundamental flaw in the technology.

Is this a case of "perfection is the enemy of good enough".

@Robert: I think your use-case is perfect for OpenID. No one wants to implement their own custom company SSO, so OpenID works perfect for letting people login across a single companies website properties.

I think I mispoke about the "only good for blogs and forums", to be more specific, the relative security of OpenID is only good for blogs and forums, I'm really holding out hope that there is a better way to deal with the blog comments and forum bit beyond OpenID.

The original goal of OpenID with blog comments for the most part, was so that you could stop worrying about remembering what username/password you used. However, this seems to not quite be the case with people increasingly having multiple OpenID URL's..... which one did you use on that blog again?

Or lets say MyOpenID does great, so great in fact that in a year, Microsoft buys it.... does everyone jump ship?

At it's heart, OpenID may be better off for something Simon Willison mentioned before.... proving basic data to a new site. I can prove my AOL IM messenger by logging in to a site with AOL's OpenID, though in the face of OAuth I'm not even sure thats so great.

So lets go back to the basic 'problem'. It's a pain to have to remember what User/Password (or what OpenID token) you used to login to a site cause you wanted to make a blog comment, or forum post.

First, is the whole blog comment thing a problem? Are we not all commenting here on Ned's blog with no account creation problems? ;)

Second, assuming its a forum, we want people to be able to login, and remember their login. Is everyone so sure that the 'average' user is really having a horrible time doing this? Was there general public inclusion and testing to see that OpenID is even addressing a real need that the general public has? Or, as Leah said, is it just to make some geeks happy?

I think in addition to the problems OpenID has, we should be questioning its purpose and reason for existence. So far, no one I know (non-geek that is) complains about too many usernames/passwords. Most websites now seem to use email address as login, leaving the average person to just remember a password. And sure, lots of people use the same password all over the place, which isn't very secure, though as we mentioned, OpenID is only a little better...

Part of it is that browsers now remember usernames/passwords for people, and there's lots of integrated password utilities that help out. Browsers also will auto-fill many registration fields, making that task fairly fast. Is it ideal? No, not really, nor is OpenID. Given the massive companies Microsoft partnered with for Passport, it's even possible that more average users used Passport than have used OpenID, so I'd still call OpenID a "huge failure". :)

I'll be happy to have a single-sign on someday, and OpenID only started off simpler than the Liberty Alliance because it was significantly simpler to begin with (and thus less secure). As they add security, it gets larger and larger and larger.... and lets see if anyone wants to support OpenID 2.0 + Auth Extensions + Verified Identity + whatever else has to be added for it to really work right. I'm guessing.... prolly not. And why should they when users (not programmers, but average users) seem content to use a username (or email) and password?

I believe you can delegate your OpenID to Yahoo via http://idproxy.net/

Thanks for all the interesting discussion! To those trying to help me make OpenID work better: your suggestions just make it more complicated. "i-names"? I don't know what those are. I can find Yahoo's server URL by digging around by chance in some guy's HTML page? No thanks. I can delegate to a Yahoo OpenID by using some other site I'm not familiar with? I chose Yahoo originally because of its stature, so why would I want to involve a site I've never heard of?

It does seem that OpenID is better than the alternatives, at the very least in that I don't have to place all of my faith permanently in a large corporation whose motives may not be pure. But as a technology to reach the breadth of the web, OpenID just isn't there yet.

You actually only have to put in "yahoo.com" to log in with Yahoo's OpenID, not your whole identity url. They even say that on the page with the big ugly URL. Admittedly OpenID is still really more for nerds right now but I think you're omitting some details and making it sound worse than it is.

@Ben: Unfortunately (or fortunately?) I'm going to have to cut my participation in this thread short. I've have to get packed and ready for Cycle Oregon. Oh, the sacrifices we make. ;)

One of the gists in what you're saying that I would take issue with is that OpenID is intended primarily to avoid having to remember what your login was. Granted, that's a nice side effect of a single sign on, but I think an equally important, if not more important, benefit is in allowing users to circumvent the registration process that a sites require.

Registration is often a big barrier to entry for users, one that I know every company I've worked for has struggled with. ("How do we make it as easy as possible for users to come to our site???") If OpenID can eliminate this step, I suspect both users and companies alike would find this tremendously valuable.

Unfortunately profile sharing is defined in one of those extensions you refer to (Attribute Exchange) and so far I have yet to find an OpenID site that succesfully takes advantage of it. It's distressing when I log into a site with my OpenID and find myself presented (again!) with the same registration and email validation bullsh*t as usual. :P

Anyhow, great thread - thanks to Ned and everyone else for some real insights into this intriguing technology.

@Norman: I honestly didn't understand the Yahoo page, and did not know that I could just put "yahoo.com" into the OpenID field. That's not me making it sound worse than it is: that's Yahoo not being able to explain it to me, and I was really trying to understand. Look again at that page: what information is highlighted? The big ugly URL.

And while "yahoo.com" is a nice simple thing to put into an OpenID field, it's a big cultural shift for regular users. "I used to put my name in these kinds of fields, but now I say I'm yahoo.com? That's not me!"

@Ned,

Yeah, it's not really ready to be the only option for logging into most sites yet, unless you have a largely technical audience. It may get there eventually though, or foster a competitor which fixes the flaws. Hopefully. I'm tired of having to remember so many usernames and passwords!

You might be interested in the ID Selector widget, it helps make the OpenID login on sites a little more intuitive for users.

https://www.idselector.com/

BTW, this is what it says on the Yahoo OpenID page:

To make things easy, we have generated this identifier for you:

https://me.yahoo.com/a/eAfB.kAk3Oz6IuoE0iXc4hLLNjuGmZblahblahblah

You don't need to save this identifier. While logging in to websites, you can simply look for a Yahoo! button or type yahoo.com in the OpenID text field. You can also choose additional custom identifiers for your Yahoo! account below.

This step is completely optional. After you choose an identifier, you cannot edit or delete it.

I'm guessing maybe this wasn't there when you wrote your post. But when I read your post and saw that you mentioned the URL and the "this step is optional" part, while excluding the paragraph in the middle, it looked to me like you were making it sound harder than it actually is. If you just missed it, then I'm not sure that's entirely Yahoo's or OpenID's fault.

That text was on the page. I didn't read it properly, because I was expecting to see a URL on the page, and that I would have to use that URL as my OpenID. I saw a URL (the big ugly thing), in fact, Yahoo highlighted it for me. Does anyone use that ugly URL? If I can simply use "yahoo.com", why are they showing (and highlighting) a horrible thing that no one would want to use? Just put a big picture of an OpenID login box with "yahoo.com" in it, and a bold chunk of text that says, "No complicated URLs to remember! Use "yahoo.com" to login to thousands of web sites!". This is exactly the sort of stuff that has to be ultra-polished and friction-free for this technology to take off.

So for my confusion, Yahoo deserves blame.

And yes, this comment is about Yahoo's implementation, not about OpenID itself, but the geeky implementations are dragging OpenID down, and need to be rooted out.

> That text was on the page. I didn't read it properly, because I was expecting to see a URL on the page

I don't think that would be the case with normal users though. You approached it with the expectation of it being difficult, and grabbed at the first thing you saw that looked complicated. Non-techies wouldn't have that assumption. If you had known nothing about OpenID, you might have seen something on the page besides the URI. I think Yahoo's page could be better, but they aren't to blame for you outright ignoring what they say.

3 problems with OpenID:

1) Phishing - the attacker just needs to scrape the OpenID login that you would be redirected to and generate a form just like it to capture your the username/password you use on all your other OpenID sites (putting all your eggs in one basket anyone?)

2) DNS issues - sure you can delegate to an official OpenID provider for your blog, but what if an attacker hacks your blog and swaps his own provider in place of yours?

3) Potential bot issue - the moment OpenID becomes popular is the moment you have to start typing captchas along with your OpenID url.

I guess the experience with OpenID differs from person to person depending on what they are expecting from the service. To me, it has been a life-saver.

I get to forgo the stupid registration step on every new forum and blogs where membership is compulsory to make comments.

I don't understand why people would create multiple openids. I have only one and because it is guaranteed to be unique, I have no need to create another. Even if I want to change the provider in future, I think openid providers allow such delegation possible without chaning my openid. (You can also create multiple 'profiles' if you want to. Seriously, why would you maintain multiple OpenIDs at the same time?)

OpenId reduced my password list to just one, so I can afford to make it stronger or weaker based on my requirements. This saved me from having to come up with passwords of different formats to satisfy the code on different websites: password must include a digit, must include a special character, must have combination of upper and lower case, blah blah blah. Now I deal with only one password validation code: my openid provider's.

As examples, I am happily using OpenID on Magnolia, Identica, booksiamreading, laterthis, toluu, twitterfeed, stackoverflow,com, blogger, ustream, gitorious, sourceforge, lighthouse...too many to list. I can't imagine having had to remember different usernames and different passwords for so many services. Still OpenID is not universally supported, especially by the forum installations.

I don't use OpenID for security reasons but only for convenient authentication. I have ssh keys/certificates for important services. Providers like MyOpenID do provide the complete history of how your OpenID is being used.

> So for my confusion, Yahoo deserves blame.

One of the "advantages" of OpenID is provider choice -- except when the provider sucks. And Yahoo's implementation.. kinda sucks. Pick a better OpenID Provider! :)

We really, really like myopenid for example. They do it right.

As an early OpenID enthusiast I must admit that I agree with all current criticisms of this technology.

Joe user will never make sense of OpenID (and I'm not sure I do, in fact), full stop.

So what about simpler approaches ? Simpler as in more understandable as well as more robust.

Some suggestions :

1) Low-tech : Evangelise using highly secure login/password (long and cryptic) and stick to it for ALL one's registrations.

2) Higher-tech : design and promote referrer-based, chain-of-trust technology between websites.
I just thought of it by reading this post, let me explain :
a) I login to site A (A is a recognized trustful website)
b) From A I navigate to site B
c) Site B looks up referrer site and asks about me (some token involved ?)
d) Site A confirms my identity
e) I'm automatically logged in on B
Of course this leaves out lots of important details but it shouldn't be any more convoluted than OpenID.
Chain-of-trust, or web-of-trust more exactly is even more decentralized that OpenID with its supposedly trusty servers.

If you use Yahoo! as your OpenID provider, I think you can't move to another provider in the future, though I am not totally sure about it.

Even Voodoo makes it a complicated process(but we can opt for it to be simpler, right?). I too like MyOpenID the most and that's the one I personally use and recommend to the others.

Despite the niceties and the popularity of openid amongst us geeks, I've found that quite a lot of people get scared away by the OpenID login dialog.

On one of the sites I'd built, I was displaying the openid signin form by default, instead of the password based login dialog. Switching it to the password based dialog increased the signup rate considerably.

@Norman: thanks for posting the complete text of the Yahoo message. It actually sounds even worse than Ned made it out to be. This should be a textbook case in how not to write messages to end-users; it makes no sense at all.

E.g. "To make things easy" -- to make WHAT easy? How does this gibberish URL make anything easy? "You don't need to save this identifier." -- then why show it at all? "This step is completely optional" -- what step? "After you choose an identifier, you cannot edit or delete it." -- what constitutes choosing an identifier, and if it's both optional and irreversible, why would I do it?

OpenID wasn't originally meant as login protocol. It was designed for homepage / URL verification only. And that shows. Adding complexity to the protocol and removing any initial information sparsity hasn't exactly helped.

Picking Yahoo! was your first mistake. Have a look at myOpenID. It provides an OpenID like http://username.myopenid.com.

I've been using OpenID for quite a while now have found it to be easy to use and understand. Of course, I might have been thrown off initially if I went the Yahoo! route too.

Very informative and well written article and lots of insightful comments. Its cool to see this kind of dialog going on around the topic of OpenID. I work for a company called Vidoop and we have been working to address alot of these concerns with our OpenID provider myVidoop: http://myvidoop.com

Specifically we want people to feel comfortable using OpenID for more high value transactions and so we have implemented a two factor authentication system. Without requiring any additional hardware or software we have a image based login system that generates a random passcode for every login.

We also offer a password manager for storing/organizing your traditional logins and passwords, support OpenID delegation (very useful), have custom activity reports, and more. You can create an OpenID and check it out for free. The feedback we have been receiving, especially about the integrated, cross platform password mangers has been very positive.

If you run a site and want to make it easy to refer people to get an OpenID from myVidoop we have an affiliate program at http://affiliates.vidoop.com

Joining an affiliate program is a way for the site operator to keep the user from having to wade through all the providers and possibly getting stuck with an unreliable provider.

It is also worthwhile to note that OpenID is only a component in the identity stack, there is an excellent description of everything that goes into someone’s identity beyond OpenID here: http://blogs.oracle.com/talkingidentity/2008/05/05

Cheers,
Kevin

@Kevin: Does Vidoop support the re-auth draft extension? If not, its utterly un-safe for high-value, or even mid-value transactions. It's only acceptable for blog comments/forums without re-auth.

I don't consider Vidoop significantly more secure, though I do like its image based system. But since you only need to type 3 letters, out of a set of 9, and they can be in any order... that's a pretty small combination sequence. Random guessing gives you a pretty high percentage chance to get it the first time. If you load it up a few times, and watch for the categories that don't change, you can prolly get even closer. Sure you need to steal the users cookie first to prevent Vidoop from requiring the computer to auth, but there's lots of ways to steal cookies nowadays.

And of course, there's the basic problem that even if Vidoop and myOpenID do things securely, it means those of us creating 'high-value transaction' websites have to white-list a very narrow set of OpenID Providers that we know we can trust to do security properly. Oh wait, anyone remember that the 'beauty' of OpenID was that it was supposed to be distributed? That you can run your own OpenID service if you don't like the others?

Well, not with white-lists.... with white-listed OpenID Providers, we have Microsoft Passport, except with some other people.... until Microsoft buys myOpenID and Vidoop. :)

White-listing OpenID Providers destroys a core concept of distributed auth, and removes a ton of choice from people.

Those that were saying that Ned just picked the wrong OpenID provider, think of the new burden you're placing on people. Not only do average users have to learn OpenID, but they have to learn how to determine which ones are good, which ones are likely to be on others white-lists, etc.?

It definitely has a long long ways to go.

Couple things... we do support that extension and re: guessing you can have up to 5 image categories, specify a 4x4 image shield, and require the code to be entered in a specific order. Also we put a flash object and cookie on the local machine, so copying a session would not be trivial. We also have account alerts setup so you can be notified anytime there is a failed login, etc.

There still needs to be some things worked out re: whitelists, I agree they are bad things. It is better to have a blacklist and build that up. PAPE and other extensions are working to allow the RP to dynamically check providers. Passpack recently had this dilemma and ended up having a group of suggested providers, and everything else was use at your own risk.

I dont think OpenID is any different than email was years ago, and average people were able to sort that out :)

-K