OpenID: Great idea, bewildering consumer experience

A while back I tried signing up for an OpenID, an "open, decentralized, free framework for user-centric digital identity." The basic idea is that, instead of needing to choose a user name and password for every site you visit, you can identify yourself with an ID that many sites will accept. It sounds great, but in practice I found the whole process bewildering. In my opinion, it’s not ready for consumer use. 

 

Beyond security criticisms of the scheme that can be found elsewhere, I think OpenID has some significant user experience issues. Some of the problems can be fixed, others are integral to the way the system works. 

• It's way, way too hard to get started. All the sites supporting OpenID point curious users to the home page for the OpenID Foundation. From this site, it’s actually stunningly difficult to find a link to a place where you can actually get an OpenID. A link to a site called I want my OpenID! sounds promising, but the destination page doesn't actually deliver on the promise of getting a user an OpenID either. 
• The content and tone of the OpenID Foundation site is oriented at developers, not end users. The second sentence of the home page boasts, "OpenID starts with the concept that anyone can identify themselves on the Internet the same way websites do—with a URI." You know what? To most people, that doesn't sound like an advantage; it sounds geeky, dehumanizing, and more than a little bit frightening. 
• While there are very cool benefits that come from identifying oneself with a URL (URI), pity the poor consumer. They have dutifully learned that a user name is an identity and a URL is a place to go. Now they must wrap their weary brains around the concept that, when asked to identify themselves, they should provide a location. "Why can't I just use my email address?" they'll wonder.
• The process of selecting an OpenID provider will stump the average consumer. They’re being asked to pick an ID that they will, in theory, use everywhere and forevermore to gain access to everything they own. They’re supposed to obtain this ID by making an effectively random selection from a group of providers they have never heard of.
• Various OpenID sites also promote the notion that users should set up their own OpenID provider. This is fine for a teeny tiny portion of web users, and scary and out of the question for everyone else.
• The lists of OpenID providers are presented in a static order. In some cases this will be alphabetical. The most commonly referenced list of OpenID providers is presented in chronological order of when the service went live, an order that is effectively random. It's not immediately clear in most of these lists why a user would pick one provider over another. None of the lists I've seen are organized around attributes which are relatively easy for a user to base a decision upon, like: Do you have a blog already? Or, Which language do you prefer to speak?
• As an aside, when you ask a normal person to choose a provider from a list for a service they don't understand, most people are just going to pick the first or last entry. (If a default value is provided, they'll pick that. The default value will almost always be the first entry.) So, a static list of providers turns out to be a really good way to screw the bulk of providers whose entries sit in the middle of the list. Microsoft learned this lesson the hard way in various places in Windows, addressing such problems by dynamically shuffling provider names so that all providers spend equal time at the top of the list. More usefully, the lists could reflect community-based provider ratings.
• The ostensible universality and permanence of an OpenID actually makes the task of picking a provider harder. Even if I happen to currently have a SixApart blog with a TypeKey, am I really prepared to use that ID everywhere? Exactly how long can a consumer expect a given OpenID provider to remain in existence? In my playing around on one site, when I remapped a URI from one provider to another, I lost my ID-related preferences. This gives me pause in depending upon any provider that could potentially die before the web service I'm using the ID with. Frankly, many of the OpenID providers seemed like tiny organizations that could disappear overnight. Nowhere could I find anything that would tell me what should theoretically happen to my ID-bound accounts if that were to happen.
• Suppose that, at some point, a visitor to an OpenID-enabled site is really intrigued by this OpenID thing they keep coming across, and decides on the spot that they want to get one for themselves. The OpenID community, and the sites that use it, appear to have given little thought to addressing this scenario. Go to the LiveJournal home page and try figuring out how you’d get an OpenID and come back to use it. I’ll bet analytics on the site will show that, of the tiny percentage of visitors to LiveJournal who go off from there to get an OpenID, only the most determined will make it back. Why would a site operator let anyone leave their site to perform a task from which they will never return? 
• An OpenID is an identity (like a user name), not an account. A consumer still needs an account to use the site. However, this isn't at all obvious to a consumer. When I tried to sign in to Plaxo with my OpenID, I got an otherwise blank page displaying the error, “Unable to verify the specified OpenID.” Some sites do a reasonable job of letting a user who has never logged on before create an account on the spot. When I tried to sign in to LiveJournal with my OpenID, they let me create an account and then start using it. This inconsistency among implementations will confuse a lot of people.
• When I actually tried to use my OpenID on a site, I got a confusing message from the OpenID provider requiring me to confirm that I really wanted to let the site access personal information I had associated with my OpenID. The clarity of such messages varies from OpenID provider to provider, ranging from puzzling to incomprehensible. In the case of Verisign, I was instructed to select which “Trust Profile” I wanted to associate with the site—or did I want to create a new Trust Profile? Wha?

Since most users have never encountered the concept of sharing information across sites, a ton of education would be necessary to make these messages meaningful to the average user.

• Currently, even those sites that do implement OpenID generally treat OpenIDs as a second-class form of identification. They put their own proprietary means of signing in (generally with a user name and password) on their home page, and bury the OpenID sign in facility behind a link. This means that the hip OpenID-using visitor has to make more clicks than the proprietary ID-using masses... which doesn't exactly sound like a reward.

And all this is for—what, exactly? To save me from having to pick a user name and password? As annoying as that can be, it's just not that hard! Remembering an arbitrary user name does cause real trouble, but simply allowing email addresses to be used as IDs can solve almost all of that problem. As more and more sites allow email addresses as IDs, the need for OpenID becomes less compelling to a consumer.

For the time being, I can’t imagine a sane business operator forcing their precious visitors through this gauntlet of user experience issues just for the marginal benefits that accrue to a shared form of ID. I've read numerous claims that all it will take is for someone big like Google to support OpenID to crack this problem open. Unfortunately, there's no business of any size that can afford to direct their traffic down a dead end.

Most service operators will, at best, offer users a choice between using a proprietary ID or an OpenID, creating a terrible economic proposition for a consumer. Faced with the proposition of: 1) struggling once for thirty minutes to struggle through a process they can barely understand, or 2) spending two minutes on every new site breezing through a familiar process they've done countless times before, normal busy people will choose the familiar route time and time again. I’ll bet anything that most people will keep going for proprietary IDs, further deferring the network effects possible from OpenID adoption.

This isn't to say that OpenID isn't worth attempts to fix it. At least some of the above problems can, and should, be addressed head on by the OpenID community. My recommendations:

1. Redesign the OpenID home page for consumers. The page's main content should contain a brief explanation of OpenID in consumer-friendly terms, along with a giant Get an Open ID button. Move all the developer material behind a Developers button.
2. Design an end-to-end process for getting an OpenID from a service operator's site. Since most services won't care which provider the user uses, let these services send the user into a real flow for picking a provider, getting an ID, and most importantly coming back to the original service to use the new ID. When they get back to the service, the new OpenID should be prefilled.
3. Give the above flow a sidebar titled "Do you have a blog?" that explains that, if they have a blog on LiveJournal, TypePad, etc., they can use that for their OpenID. A link in the sidebar should shunt the user into a page that has them pick their blog provider, then tells them what the (blog service dependent) form of their OpenID is. The flow should then return the user to the service they started on (again, with their OpenID prefilled).
4. Organize the list of providers around factors that can actually influence a user's decision. Consider offering provider ratings based on ease of use, uptime, etc.
5. Refine reference designs for the complex range of cases that come up in using OpenID with a service. E.g., define the expected behavior and terminology that should be used when a user tries to log in with an OpenID but does not already have an account with that ID.
6. Define guarantees that services should offer to users in the event their OpenID provider goes out of business.
7. Build an organization that can do real usability testing on this service with real consumers.

UPDATE (October 7, 2007): This week OpenID.net overhauled their site, and the new site addresses a number of the criticisms listed above.

Comments

[Andrew Green]

100% agreed on all counts here. As a developer at the geekier end of the spectrum, I considered adding support for OpenID to Buy Our Honeymoon, a service resolutely aimed at a non-geeky market. But we didn't, largely because doing so would have meant having to provide our own, detailed explanation of the service, and then supporting it. I'll bet that most sites that treat OpenID as a second class citizen have a similar motivation -- that by hiding it, only people who already know what it is (and consequently won't need support for it) will be inclined to use it.

[Asbjørn Ulsberg]

I agree to most points. Thankfully, most of them will be irrelevant when OpenID gets implemented in browsers. Then, the identity will be a part of the user's desktop somehow; either as an integrated part of their operating system (like Windows CardSpace) or as a part of the identity a user builds in his or her browser.

My OpenID can, in the case a browser has control of it, be automatically submitted to sites (it can be announced as a part of the HTTP request as a header for example) and approval of sites requesting the OpenID will be done directly in the browser through a button, information bar or similar. It can be a challenge/response system like ordinary HTTP authentication and it will in most cases mean pressing a "confirm" button in the browser.

This of course introduces other problems, like using several computers to authenticate with the same OpenID on the same sites, but that problem is being worked on already by the browser vendors relative to centralized storage of favorites and such. I think most of these problems will be gone in a year or two, at least if Internet Explorer 8 embraces OpenID.

[Gary Krall]

I am the technical director for the PiP here at VeriSign and we completely agree with you regarding how confusing the Trust Profile selection **was**. The functionality you describe is about 2 months old as we relaunched our service last month and we removed that entire flow metaphor.

I'd appreciate it if you could take a look at the new service and give me some of your comments. We have spent a fair bit of time attempting from a UI perspective to address some of the legitimate concerns you raise as an OP while at the same time adding in additional functionality.

With that said, I think you make some really excellent points in your post especially as it relates to Relying Parties. And I think your point #4 in your recommendations would also be very meaningful in choosing providers and we'd welcome such an approach.

Excellent post and commentary.

[Observer]

Hi, Gary. Just signed up for your service. Looked really good. A couple of nits/notes:

You might want to make the standard "My Information" table an ordinary form, instead of having all those [edit] links there. Filling in more than one or two fields will drive people crazy.

Also make it clear on that screen that the user should only fill in the information that they might want to share with others, and that they will be given full control over what to share when they use the OpenID to sign in on other sites.

The "Sign In" form is really slick, but it wasn't obvious to me what "associated field" meant. I somehow assumed that if I clicked on the button for the email, it would put my email in the email field, but it ended up in the field that had focus instead. Either make this smarter, or replace "associated" with something more obvious.

The expiration radiobuttons are flexible, but a "Allow just this request" button would probably be a nice shortcut.

[Joseph Smarr]

We had some technical issues when we first rolled out OpenID at Plaxo, but I think everything's fixed now, so if you get a chance, try it again and let me know if it doesn't work. We go through the account creation flow if it's a new OpenID as you mention above. Thanks! js

[Gary Krall]

Excellent suggestions and the My Information one we discussed alot internally for as you point out this metaphor differs from the way we handle My OpenIDs in which a user can elect to either pull values from their My Information or enter new values which in this case is a form edit.

In terms of the associated fields that's a good catch. You'll be pleased to know that the metaphor you suggested was exactly what our internal usability group proposed (we actually have the mockups from them to do this). In this case we had to balance the need to ship something versus the functionality but know that it is in our queue in a subsequent update.

Thanks again.

[David Recordon]

As others have said, these are all great points. I've started updating some text on http://openid.net and would definitely appreciate any other feedback as well!

[Eric Norman]

Here's a short, albeit cynical, but accurate, summary. OpenID was designed by geeks for geeks. Please note that this is a very common phenomenon; it's not just OpenID.

Anyway, I do think you missed what could be w very useful suggestion.

Involve people that actually know something about usability, human engineering, and so forth in the design process. Suggestion 7 is that they be involved after design and coding. That's too late. They need to be involved and make contributions from the very beginning.

Let me try to be clear who I'm talking about here. I'm talking about people who can actually speak the language and have their brains wrapped around the concepts of human engineering. I'm talking about non-geeks. They're out there. FInd them and form an alliance with them.

[Joseph Holsten]

Well, one improvement might be to get the community's opinion on the open openid provider. Care to share your opinion?
http://jyte.com/site/search?q=best+openid+provider

[Jonas]

Well, openid is a pretty lousy idea. We already have https which could facilitate a much simpler to operate single sign on system than openid ever can, given just a little bit of usability work from the web browser developers.

In those few cases I actually WOULD like an identity shared between different services, that is. Also, there is absolutely nothing "proprietary" with username/password authentication. I don't know what word you may be looking for but that can't be it.

[Jack S.]

I admit to not knowing much about this idea - because I dismissed it the first time I read about it. The main problem, as stated above, is that there is no motivation to participate in yet another flaky, undertested beta web annoyance/signup/service, to avoid entering in a username at each site. Then add on the obvious security problems and the additional unnecessary points of failure.

It's a solution without a problem, from the POV of the user.

A better explanation may be that the whole thing is corporate marketing-motivated, in the relentless effort to consolidate and sell customer data, and to track individual activity across independent sites and retailers. At least that makes sense.

[Forsooth]

Agreed on all points. However as a consumer I would streamline further. Instead of having a openid-less user pick a provider I would simply send them to a pre-selected, high quality, possibly co-branded provider.

I would also never have two types of logins if I was authoring a new site. Either use openid for all accounts or not at all. With the streamlining you can get away with this. For an old site you probably would not want to go through the trouble of migrating existing accounts and retraining users.

As a provider not only should I send new openid users back to the site they came from but send them back logged in. (This may require an extension to the standard.)

To ease the fears of the provider going out of business I would allow the user to choose their own domain, ideally with a standard extension like .oid or somesuch. The extension should then be optional on sign-in to save keystrokes (e.g. johnsmith instead of johnsmith.oid) and make it look more like a username than a url. Of course this costs bucks so allow the user to later migrate (e.g. from johnsmith.provider.com to johnsmith.oid).

[Eric RIce]

It always seems to me like 'open' is a conceptual word important to the developers and techs, not to the consumer.

Would a consumer want something like their ID be "open" instead of 'secure' 'locked' 'protected' etc? Those words mean different things to both camps.

Who owns it? Who is accountable? Microsoft? Apple? Or uh, you know, some people. <-- those are customer questions, not mine. :)

[Bryan]

Agree with the comments.

OpenID providers: you need to provide some info up front, available *before* someone signs up to use your OpenID services. Here are just a few of the things I need at least some reassurance about before signing blindly up for service:

* Is if free? Will it always be?
* What's your privacy policy?
* How do I know you'll still be in business a year from now? or 10 years from now? What will happen to my OpenID if you are not?
* Will I be able to create multiple OpenID identities? And manage them easily?

[Jordan]

I couldn't agree more on all accounts. As a moderately geeky person, I have to say that I am continually frustrated by the absolutely impenetrable explanations on OpenID provider sites. Nonetheless, I remain a steadfast fan of the system and always recommend to websites that I sign up with that they implement the OpenID system. I sign up sometimes 1-2 new sites a day, and I can't underestimate how much easier this would make my life.

I think that as more people are willing to take a few minutes and understand it, you're going to see it begin to move to a lowest common denominator situation. Wikipedia was the same way when it launched - people called it flaky, unsecured, untested. When I was hired at a new company a few months ago, where there aren't a lot of people I would consider technologically oriented in any way (but who do sit in front of a computer all day), they reference Wikipedia almost on a daily basis.

There does need to be a concerted effort by the OpenID community to completely divorce "consumer"/"corporate"/"developer" documentation, though. I see that the OpenID.net site has been updated a little, but for it to be effective at all for consumers or corporations, their information should be completely delineated. Either separated by clear formatting or different pages -- not just different paragraphs.

Moreover, I think as more and more people get into the idea of having an "identity" on the internet (like MySpace or Facebook pages), we're going to see ideas like catch on quicker.

[jason]

There is a simple way to make this easy for users: all major providers should enable openId (as aol has done) and then make it clear that they can login to many new sites with that one ID (something aol has not done) From here, the technology should be smart enough to recognize the @gmail.com for example portion and create the correct uri. Almost everyone has an ID from a major service like Yahoo or Google, and those who don't are usually the geekier ones who have the ability to understand OpenID as it is now, or will refuse such a service all together over security concerns.

The other simple, though less desirable solution, is to use a per provider api like Yahoo!'s BBauth.

[Ben]

Stop whinging. OpenID is great - it's not ready for the myspace generation and you just wasted 20 minutes writing a whingy post when you could have written to the maintainers and asked if you could update help make their website more end-user friendly.

(But then I just wasted 3 minutes writing this - woah - so meta)

[Dennis Martinez]

I think like with all newer technology, there are going to be some bumps in the road. Your experience has differed greatly from my own, although it seems you've used this system way more than I have. In my experience, I haven't had most of those problems you mentioned, like confusing messages when trying to create an account at a site or actually getting an OpenID. But maybe for the regular, non-tech-oriented person, this may seem a little bit daunting at first.

However, there are strides being made every day with OpenID support. I've been seeing more and more sites and applications adding OpenID funcionality to their sites. Some apps, like Beast (http://beast.caboo.se - a forum app running on Rails), are adding it in their main login screens instead of relegating it to obscurity.

You're right in that it seems OpenID is developer-centric, but that's because it's still in an adoption phase. Once OpenID usage is more widespread, the end user should see more improvements. I think OpenID has a chance while these shortcomings - all valid, in my opinion - become fixed. It probably won't end the Username / Password logins we're all used to, but it should gain increased popularity down the road.

[TRS-80]

http://intertwingly.net/blog/2007/01/03/OpenID-for-non-SuperUsers says most of what should be on the OpenID front page. In particular, delegation allows you to use any provider while keeping your own URI.

[Yakov [Mixed In Key]]

Hi,

I read your blog through RSS, so I never post here. But I agree with this post 100% -- we avoided OpenID on our custom Community website precisely because of these reasons. OpenID is an idea not ready for primetime. The damage to the user experience is way too high at the moment.

-Yakov
Mixed In Key

[Jon]

I'm a web programmer/designer and have been using the web for years. Yet for the life of me, I could not figure out how to sign up for an account, and REALLY wanted to try it out. I can only imagine what joe sixpack is going through

[Doctor Memory]

I have a better idea: Don't use OpenID, and for the love of god don't encourage naive users to use it. Problem solved.

(Hm, apparently this blog filters out html links? Very well, click here for context: http://www.emergentchaos.com/archives/2007/08/welcome_iouhgijudgviujs_p.html )

[Will Hartung]

There's no reason that OpenID can not be implemented transparently.

Take your generic, everyday, Login/Password page. Add an OpenID logo. Implement OpenID.

When the user logs in, did they provide a password? If they did, authenticate like normal.

Is the pasword blank? Does it look like the login id might be a URL? (i.e. if Frank accidently types in 'frakn', no obvious domain, no slashes, probably not a URL then) Then throw it down Open IDs rabbit hole and see what happens. Does it work? They're in. You're done.

All you need to do is allow empty passwords (on top of implementing OpenID of course).

So, now, when Joe User shows up, they enter "joe" and "password". Boom, they're in.

When Joe Geek shows up, they enter "joe.geek.openid.org" (or whatever). Login fails, fall back tries OpenID, boom, they're in.

Silent, transparent, no trauma on the user interface. Most catastrophic issue being that Joe Geek doesn't get "free fill in" from their browser for their Open ID because the fieldname isn't the suggested Open ID form field. Boo Hoo.

[Paul Tanner]

I agree with all your points but I want to focus a comment on:

>> Organize the list of providers around factors that can actually influence a user's decision. Consider offering provider ratings based on ease of use, uptime, etc.

This is fundamental because the OpenID concept depends on trusting a OP. How can an average user do that? So the (essential) resource that describes OpenID to users needs to provide material to allow judgements to be made about OPs.

I note that the Foundation has indicated that it does not want to get involved in this. This seems strange because this is key to OpenID as a potentially viable brand. So another player is needed to provide independent assessments.

In the absense of such assessments an RP that is not also an OP would be obliged to partner with one or more OPs and put contractual obligations in place. If not which OP would they advise users to choose?

[judy]

I have always wanted a compendium of novena prayers. Thank you for sharing all these prayers with us. It brings joy and happiness to everyone. I know, I do feel that way.i

[Dan]

Hi, everybodyu

[naella]

I found this from the link at http://newfileengine.com/

[Ron]

I like it and the background and colors make it easy to readi

[wejfx iesjyxuo]

bahcz idckr rimovzapt meoul ykmvi aehrqg lpskixw