Home

News: OpenID: Great idea, bewildering consumer experience

  1. "OpenID: Great idea, bewildering consumer experience" is a thorough document saying that OpenID ... might have some problems. Some of the issues are: the site for OpenID is geared to developers, not users; finding an OpenID provider is troublesome; users won't understand that an OpenID is a location, not an actual identification. OpenID basically centralizes login processes by requiring that users provide a URL to a site that provides their identity. When the user needs to "log in" to a site that participates in OpenID, the site redirects to the URL the user provided, where the user logs in; the OpenID provider then redirects back to the original site, providing the user's identity. The advantage here is that users can log in on one server - the OpenID provider - for all sites participating, instead of potentially having passwords for each site on which the user has a login ID. There are OpenID providers available; one is http://openid.org/, for example. There are also programmatic providers, as specified on OpenID.net. What do you think of the idea of OpenID? TSS is considering OpenID for its login authentication; good idea or bad? Resources:

    Threaded Messages (7)

  2. The problem sites like this have is that most visitors are not signed in and therefore have limited functionality, reduced incentive to come back, and less overall time on this site. You are competing with dozens of other sites and inevitably there's going to be users who don't bother to sign in. Yet some functionality like e.g. posting or storing preferences requires being signed in. OpenID solves this problem by making it really easy for users to sign in. Upcoming browsers such as Firefox 3 are going to make it even easier. You can implement openid on top of existing user system so it doesn't replace or conflict with your existing security solution. Sounds like a good idea for any site with this problem. A no-brainer really. The problem right now is decent support in popular CMS software. For example, openid enabling your blog currently requires quite a bit of hacking with half or non supported extensions/plugins to stuff like drupal or wordpress. I gave up on it for my own blog. If you have your own CMS like this site probably has, that is much less of an issue of course.
  3. The Key to OpenID...[ Go to top ]

    The key to OpenID success will be whether many large sites start to use it. The reason the OpenID site is for developers is that they want web site developers to incorporate OpenID hooks. At Hyperic, we're considering this, because it's a win for users if they can just use their openid name. Dev tools have progressed to the point where implementation is easier now. I wonder how many other sites are considering it? I've heard whispers of many evaluations, but I've yet to see major sites move to it. -John Mark Community Manager Hyperic, Inc. http://www.hyperic.com/
  4. Single point of failure[ Go to top ]

    I like the concept of OpenID, but from a technical point of view I think it's a single point of failure. When your OpenID Provider is having trouble and the services you want to access don't provide any alternative login, you are in trouble too. So for me it's only a solution if the provider is really reliable or services have a backup/alternative login service.
  5. nonsense[ Go to top ]

    As a consumer you can pick your openid provider like your email provider. On top of that (unlike email) there is notion of openid delegation which allows you to actually switch provider and keep the same openid. So basically you have quite a bit of flexibility in case your preferred provider proves to be so incompetent that you run into this hypothetical non-issue. Of course the issue is not unique to openid and you have exactly the same problem with any identity solution: if the IDP goes down you can't authenticate. Of course the delegation feature is rather unique to openid so you actually gain flexibility here. Compare this with e.g. facebook where the whole ecosystem depends on facebook's php based system not failing. Skype which had a nice authentication issue the other day might have been better off with a decentralized authentication system like openid. Trust and security are of course important. Whitelisting of providers solves this and is perfectly legal under the openid spec. This is what for example AOL is planning to do when they openid all their services in the next few months (they are already a provider for 60 million users). If you want to access their service, you will have to use or delegate to an openid they trust.
  6. Re: nonsense[ Go to top ]

    As a consumer you can pick your openid provider like your email provider. On top of that (unlike email) there is notion of openid delegation which allows you to actually switch provider and keep the same openid.
    But to be fair, your OpenID name is simply a URL, and the delegation is based upon data provided within the document FROM that URL. So, even though you might be using something ultra reliable (like, hypothetically, openid.google.com) as your provider, if your OpenID URL, say jiles.vangurps.com, is hosted at "$2/year! Free Bandwidth! CheapassHosting.com!", then that's your point of failure. It suffers from the weakest link syndrome. Mind, I believe the system can be reliable. I think it would be nice if some large provider (google, amazon, yahoo) would let folks host OpenID subdomain URLs across their farm of servers (round robin DNS load balanced etc.). You own the domain, they host it. And then you can pick whatever combination of OpenID certificate host and OpenID credential provider you like. That's my minor nit about the system. That it's a URL. That means unless I own my own domain, my global ID is at the mercy of some other company. Yet, maintaining a domain, paying for it, renewing it, bla bla bla, maybe something that we do ok, but not something Ma and Pa Kettle may well be wont to do. But the AOL initiative is a good one -- all of their subscribers get an OpenID.
  7. Re: nonsense[ Go to top ]

    Maybe, or more likely you'll get 'sign in with Google/Yahoo' services built on openid from places like amazon, ebay, etc. This will be used to facilitate simple, more reliable transactions. People are already using those online email providers and have no intention of moving away from them. Business can easily exchange user data in a reliable, widely adopted commercial format. When integrating openid servers with ldap, you can shutdown the account once and all external partner authentications will be dead too. Justen Stepka
  8. Re: nonsense[ Go to top ]

    Maybe, or more likely you'll get 'sign in with Google/Yahoo' services built on openid from places like amazon, ebay, etc.
    Well, if we can get any of these guys to port their account bases over to something like OpenID, I think that would be a great shift and that would "fix" the problem. The clever part of OpenID is that the ID is simply a URL. And the URL provides the start of the credential chain. I also like how is does delegation, in two ways. One, it delegates the actual ID server, but it also delegates the actual ID. So, in theory, I make my own ID at (say) theserverside.com/users/will. I can then (assuming access) change that document to validate against the openid.google.com servers using my google.com/mail/will.hartung ID. That means I can now identify myself to any OpenID site as theserverside.com/users/will, but using my google password. Now, it's not a "secret" by any means. Anyone can follow that chain, but it does give you the ability to consolidate and alias as time goes on. So, that means that as long as an OpenID provider gives you the ability to change the servers and the delegates, and is willing to serve up the the minimal URL document, you don't have to make a commitment to any actual provider. Not quite cell phone number portability, but it's close. We should also have the ability to somehow migrate IDs on destination sites. For example, whatever my account is here at TSS, I should be able to assign one (or several) OpenID accounts to the "Entity That Be Me Here". This kind of flexibility will speed adoption. It means I can run over to OpenID.org and sign up there without worrying that it'll be some kind of horrible mistake in the future. Migrate to Google or Yahoo later, or even TSS. I mean, why shouldn't TSS be an OpenID server rather than just a consumer? Once the meme explodes, and everyone is serving and consuming the OpenID, then things can settle down. But for now, since we can have some sense of portability, yet still maintain federated ID, I think implementation should be wide and liberal. So, in summary, IMHO, TSS should: a) implement OpenID for authentication b) offer OpenID services to its users for authentication for other sites c) make available the proxy and delegate abilities within OpenID so that we can more easily transfer and move our identity around the bustling intraweb as OpenID settles out. d) enable us to change or assign other OpenID URLs to our accounts here. e) "default" our current logins to an OpenID login. For example, we currently use our email addresses. TSS can easily port all of the emails to an OpenID URL: theserverside.com/useremailid/willh at example dot com. Then when "normal" TSS readers log in, the system says "That looks like an email, I'll silently convert it to an OpenID URL and toss them in to the TSS OpenID system". This gives TSS a single authentication system, but works for legacy users. And TSS basically shadows the "email" style, with a newer system that allows users to pick their ID (so their OpenID in the large isn't their email). And, ta da, OpenID enabled TSS working both as a consumer and as a server. Someone (that ever present Someone -- you know who you are!) should build a Java WAR (and a PHP module, etc) combining OpenID services with the user management facilities and a sample schema that any site can easily incorporate, and set the baseline for patterns and Best Practice. Accepting OpenID, providing OpenID, exposing delegate information, user preferences for exposure of personal information (on a site by site basis), accepting and registering multiple OpenIDs for a single account for login. The whole kit. Make a standard, easily integrated piece that's TESTED AND SECURE so that legacy, standalone sites can migrate in a day of integration and a week of testing. Anyone who is maintaining users today may as well consume and provide OpenID services. Then this thing spreads like wildfire and Amazon, Ebay, Yahoo, Google et al basically have no choice but to follow suit.