« Don't bury the lede: What's the real story behind a UI interaction? | Main | Bill Buxton's "Sketching User Experiences" »

August 16, 2007


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.


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?


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.


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. :)


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?


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.


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.


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.


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]


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.

Mixed In Key


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?


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


Hi, everybodyu


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


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

wejfx iesjyxuo

bahcz idckr rimovzapt meoul ykmvi aehrqg lpskixw

The comments to this entry are closed.