6 June 2008 - 11:38Make OpenID go away.
There seems to be broad consensus among both OpenID supporters and detractors: OpenID is confusing to use and that for it to have any hope of success OpenID needs to find ways to fade to the background.
Agreed. Here’s how I would do it: put it in the browser.
Click ‘Allow’ and an OpenID login session occurs in the background. The browser would presumably ask the user to log in to their OpenID Provider at the beginning of their browsing session.
I’ve come up with a small list of things that would need to change in order for this to be technically viable. There are probably more. Whether or not this is a good solution is open for debate and my intention is to provoke some discussion.
Here are a few things a hypothetical implementor would need to do:
1) The browser would need to know your OpenID url and who your identity provider is. Extensions like Verisign’s OpenID SeatBelt do this very well already.
2) Relying Parties need to broadcast the fact that they are Relying Parties, probably through an XRDS document. Likewise, the browser would need to auto-discover OpenID Relying Parties’ XRDS documents.
3) OpenID Providers need to provide a programmatic way for the browser to add domains to their users’ trust pools, though not necessarily. Not doing so means additional steps when a user logs in to a domain for the first time and the whole point is to get rid of those steps.
I have an additional theory: the infrastructure required to make it technically feasible to put OpenID in the browser is the same infrastructure that would make it feasible for single sign on to be easily used on a mobile device.
Thoughts?
16 Comments | Tags: Open Web
07 Jun 2008 - 0:01
[...] Make OpenID go away Nathan Bell writes “There seems to be broad consensus among both OpenID supporters and detractors: OpenID is confusing to use and that for it to have any hope of success OpenID needs to find ways to fade to the background.” [...]
07 Jun 2008 - 0:19
Amen. The technical challenges of OpenID are trivial when compared with the usability/adoption challenges.
From a technical standpoint, your suggestions could happen. Why do I have to find an OpenID field and type in my URI? Why can’t my browser find it for me?
I’m curious about your third point… are you suggesting that browsers would ship with a “preapproved” list of domains for which OpenID authentication would happen automagically?
I wasn’t able to be at the OpenID sessions at BarCamp (due to work conflicts) but these are great discussions that need to happen.
07 Jun 2008 - 13:00
Aaron: regarding my third point, actually what I meant was that OpenID providers require that I trust a domain name before it will proceed with a login. For instance, if I am already logged in to my OpenID provider but I had never logged in to ma.gnolia before, currently:
1) I provide ma.gnolia with my OpenID url
2) Relying party forwards me to my OpenID Provider who asks me if I want to trust http://ma.gnolia.com (either just now, or forever)
3) Provider redirects me back to ma.gnolia.
It would be convenient if this step could be integrated into the browser so that it really is just a one step with no ‘foreground’ redirects necessary. Currently, asking for trust is necessary because otherwise any website could simply redirect you to your provider and grab your identity.
Asking for trust can be delegated to the browser, however, since it already has your provider session information. All that’s needed is a standard, programmatic way to send the command. The fact that you trust the domain is implicit in you clicking ‘allow’.
After rereading your comment it’s obvious you already understand this. The reason that nefarious relying parties won’t be able to abuse this hypothetical API call (which actually already exists, it’s just not standardized) is because they don’t have your user session. But the browser does, and in fact nothing in the way that the OpenID protocol executes changes, the same HTTP request is made whether your click it yourself or your browser does it automatically. But what that request looks like is currently different for each provider.
09 Jun 2008 - 21:08
[...] I wanted to throw in my two cents on requirement #3 that he laid out in his post. I and some other Vidoopsters (Michael, Chris, Will) were working on one of our OpenID usability [...]
10 Jun 2008 - 8:50
I’m one of those OpenID supporters who agrees with you on the usability aspect of OpenID.
In fact what you’re asking for can already be done using a XRDS type. In fact, Yahoo sort of requires specifying that the “openid.realm” match the “openid.return_to” value:
http://openid.net/specs/openid-authentication-2_0-12.html#realms
Browsers can absolutely detect this and provide the experience as you’ve described.
10 Jun 2008 - 10:20
Couldn’t agree more that OpenID needs to be more intuitive for users and that having it embedded in the browser would be a great step. Until that happens, there are ways to make login at an RP more consistent and intuitive. ID Selector (www.idselector.com) was designed for just that purpose. Users don’t need to remember their OpenID URL syntax, just their user/account name. Upon repeat visits, the ID Selector remembers your preferences and provides “single click” login without having to enter any text.
10 Jun 2008 - 11:09
@Brian: the major problem with ID Selector is helping people choose WHICH of the many account options provided they should actually use.
For example, if I have ClaimID, AOL and Yahoo or MyOpenID accounts, which one should I use? It shouldn’t necessarily matter, but I would effectively be creating new accounts if I later choose to signin with one of my other accounts… So I’m actually skeptical of the ID Selector UI.
10 Jun 2008 - 11:24
@Chris Thanks for the comment. I hadn’t noticed before that there’s a spec for RP endpoint discovery already, that’s great!
The missing piece for this particular flow (besides the browser stuff) seems to be automating the trust handshake between the user and their OP. I now read that at Vidoop you and Scott have been talking about removing the trust screen completely when there is no sReg data changing hands. That would be a huge gain if it can be done, and may even obviate the need to put the trust screen in the browser. I’m not sure though. I’m thinking about putting together a little Firefox extension to test this login flow. I think the shortcomings of my idea will become a lot more obvious when I actually have to use it. But hey, maybe it will work great!
We’ll see what happens.
10 Jun 2008 - 11:52
Have you seen the OpenID Seatbelt FF extension from VeriSign? It certainly isn’t the entire solution, but was a fun extension to play around with OpenID in the browser and I find it to be pretty useful (though am biased since I worked on it a bit).
https://pip.verisignlabs.com/seatbelt.do
10 Jun 2008 - 12:07
@David I have seen it, in fact I use it and love it! I even linked to it in this blog post
I think something like Seatbelt is a key part of the solution. Things I love about seatbelt:
- it gives me in-browser status of whether or not I’m logged in to my provider.
- it makes it easy to setup my provider, assuming I already know who my provider is.
It seems that everyone agrees that there are opportunities to build on top of that. I have a really ambiguous (ambitious?) goal in my head: can a novice user, upon installing firefox, setup their OpenID Provider and complete an OpenID login into a RP with out ever knowing they’ve used OpenID. What would that flow look like?
If there is no answer to that, if it’s just not possible, then I’m not sure how OpenID will get broad adoption. It seems everyone agrees with that and I hope that anyone who doesn’t will contest it and explain, there’s merit in that discussion, too! But assuming it’s possible, what’s next and who (OPs, RP, browser) can contribute what to simplifying the flow? Above is just one idea
11 Jun 2008 - 11:31
[...] Make OpenID go away - add it to the browser [nathanpbell.com] “There seems to be broad consensus among both OpenID supporters and detractors: OpenID is confusing to use and that for it to have any hope of success OpenID needs to find ways to fade to the background.” (tags: openid) « links for 2008-06-10 [...]
24 Jun 2008 - 17:21
[...] I hear about OpenID revolve around usability, including our own Nathan Bell’s thoughts on putting OpenID in the browser. However, I myself am not a tech guy, and see a bigger issue with adoption that needs to be [...]
02 Jul 2008 - 14:20
“Do you want http://*.intrigo.com to know your identity? Allow / Cancel”
As a technical user, I ‘m not even sure I know what that means. What is my identity? What can intrigo.com do when it has my identity? Why does it want my identity? And if I don’t want to allow this, what do I need to do to still get access to the site?
As a non-technical user, I just want to use intrigo.com and get my work done (or have fun). I’m going to learn pretty quickly that clicking “Allow” takes me to the site, so I’m just always going to click it.
OpenID is a great technology, and integrating with browsers is a good step forward, but it still feels like we’re building a solution for people who understand the technology. Either we need to make safe decisions on behalf of the non-technical users, or figure out a good way to explain what we are asking them to decide about.
17 Aug 2008 - 10:45
[...] - bookmarked by 4 members originally found by ivan7881 on 2008-07-24 Make OpenID go away. http://nathanpbell.com/blog/make-openid-go-away/ - bookmarked by 4 members originally found by [...]
25 Aug 2008 - 6:22
I’m quite curious to hear how your implementation of the Firefox add-on is going. I’m always up for beta-testing (assuming I get to dig about it the source, and it’s FF3 compatible).
I agree that the language you show above could some tweaking, but the core idea seems sound. Another note is that you should examine how the new save password bar at the top is designed and match that look and feel—that will emphasize the “stored/saved authentication system” parallel.
10 Sep 2009 - 15:30
Hi! I was surfing and found your blog post… nice! I love your blog.
Cheers! Sandra. R.