Make OpenID More Useful

Making OpenID more useful: let’s detect logged-in state

One of the biggest issues with OpenID is its usability. Many relying parties are currently faced with a difficult choice: how do you let the user know the provider they should be using? Users may be familiar with the brands of Facebook, Google, Yahoo, etc, but if your site doesn’t show it, then it may as well not exist. For the time being, at least, the OpenID brand is invisible (and in fact, sometimes is considered a negative).

As I see it, the fundamental problem we would like to solve is to figure out what are the most likely OpenID providers that the user would like to use? There are a few approaches to this:

• Show logos for the most popular providers. This is currently a common option, popularized by Janrain’s RPX and numerous other sites. This scales up to maybe 4-8 providers - beyond that, we get into what Chris Messina dubs the “OpenID Nascar”

Janrain RPX displays icons of various top identity providers

• Show a dropdown of popular providers. This scales to maybe a few more, but starts to suffer from the value problem. What’s the first element of the dropdown? Do users understand what the “openid” moniker means that sits in front of it? (the answer: nope)

Ma.gnolia used a dropdown of common providers

• Let the user type in a url. You can provide a simple textbox, or better yet, a typeahead, in which the user can enter the service provider. The problem is that without prompting, users don’t really understand the value or what to write - in fact, they will type just about anything in there. You can see what this looks like here.

Blank box offers infinite choice and confusion

The core problem is that we are relying entirely on the user to tell us what their provider is, but we can’t really ask them an intelligent question without explaining the value first. And the catch-22 is that the value provided relies sometimes on the provider! For instance, I may not know what OpenID is or internet identity or whatever, but I just want to log in okay?

To a user of Google products, this is how the interface should look

A solution: detect the user’s provider

Okay, so let’s not just ask the user. Let’s ask the user’s browser, and let it tell us who their provider is. There are a few brainstormed techniques for doing this, none of which is particularly widespread at the moment:

• One idea that’s commonly suggested but not implemented is to use some strange browser history hacks to determine what sites the user has visited recently. If an OpenID provider appears in the list, then target the message to them. Fantastic!

  While this would work with today’s technology, I think most sites have shied away from it because the information comes via an exploited bug rather than intentional, informed consent.

• We could build support into the OpenID spec for detecting the user’s current logged-in state. Relying parties could iterate through a whole bunch of possible providers, and if the user is currently logged in, they can show them a login screen. The performance would hardly be as bad as people think - requests can go in the background, in parallel, and you could theoretically query dozens or hundreds of providers within a few seconds (although I admit I haven’t tested it). See more discussion below.
• We could create a centralized authority or authorities for managing user OpenID provider preferences. People could set a single cookie with their preferred provider, and then every relying party can check that cookie via a cross-domain call. Some Google engineers have initiated some discussion of this based on a similar model used for advertising, but it suffers from a severe chicken-and-the-egg problem. I think that we first need to feel some pain from these other approaches first before everyone gets fed up and moves to a centralized model

OpenID needs a middle state

I think #2 is the best option of the three. OpenID already supports two types of requests- first, modal calls, with a mode of “checkid_setup”, tell the provider to ask the user to login. This is the standard mode that most people are familiar with, and much of the user experience discussion (including my previous post about the popup UI) has focused on it.

The second type of call is triggered with a mode of “checkid_immediate”, and it, well, always returns immediately. This mode is used by a relying party to re-authorize a user that has previously visited the site. When a provider receives an immediate request, it can send only one of two replies:

1. Yes: Yes, the user is currently logged in, and they have previously authorized your website, so here’s their identifier. (mode is “id_res”)
2. No: Nope, don’t know anything about them, you have to send them over to find out. (mode is “setup_needed”).

By contrast, Facebook Connect offers more functionality. If an application (relying party) queries the Facebook servers for a given user, it can return three states: returns three states:

1. Yes, the user is logged into Facebook and they previously authorized your website.
2. The user is logged into Facebook, but they haven’t authorized your site.
3. No, we don’t know anything about this user.

That middle state ends up being pretty important. When a site sees it, they can place a Facebook login more prominently than they otherwise would. Also, because the relying party knows the user is already logged in (and so won’t be entering any user credentials), it can issue a nice neat iframe dialog instead of the heavyweight popup window. Because the popup can’t get blocked or hide behind the window, it is a nicer and less confusing user experience, and it looks better too. (It’s not really a security problem - if the OP wants to collect a password, it can always pop out of the iframe with Javascript).

There’s currently no way to communicate that middle state via the OpenID protocol. What I would like to see is an additional parameter that’s part of the “setup_needed” mode, which says in effect “the user is logged in, so if you present them with a dialog, it will be an easier experience than with other providers”.

Objection: what if a provider doesn’t want to?

Releasing logged-in state can be an optional feature. There should be a way to return logged-in state within the context of an OpenID transaction. Right now, there’s no standard way to do this, so providers that want to need to invent their own way to release that state.

Of course, the OpenID community has been fighting an uphill battle to even get the basic checkid_immediate call to work. Google, MyOpenID, and many others behave correctly, but even top providers like Myspace, Yahoo, and Microsoft always return a negative response to immediate requests - even when the user is logged in and authorized! We clearly still have a lot of work to do to make checkid_immediate a standard across all top providers.

Nonetheless, the spec should make it possible for providers who WANT to offer this additional state to do so. Just as some providers choose to offer checkid_immediate and others don’t, likewise we should allow those who want to the ability to return a more nuanced reply.

Objection: what if the user is logged into more than one provider?

So let’s say this becomes widespread. A user shows up to a relying party, and the background ping reveals that the user is logged into Facebook, Google, and Yahoo. Now what?

I think this would be a great problem to have. The relying party could present the user with choices if it wanted to, except confident in the fact that the user is familiar with all the choices. Or, a relying party could choose the provider that it has found gives it consistently better data and user experience. Or it could choose based on security preferences. The point is, the interface is still in the control of the relying party, but now the RP has strictly more information to make a better experience for its users.

Comments

• Niall Kennedy Says:
  April 15th, 2009 at 10:11 am

  I have been thinking about this detection issue a lot. I’ll show some working code this weekend at Social Foo to better negotiate the current viewer and his identity and social provider of choice.

  Regarding your 3 options, I don’t see how pinging a remote provider (#2) is better than pinging a local provider (#1). At least with the local model I am not delivering tracking breadcrumbs back to home base, and the implementing site gets the same information either way.

  Centralized solution (#3) might just be the e-wallet solution, adding an identity provider to the current data stored by the OS or browser (basically a vCard) for form fill-in yet extended to social utilities. Google and Yahoo! already essentially do this via browser toolbars, which have huge adoption and extendability.

• David Recordon Says:
  April 15th, 2009 at 11:33 am

  Niall, I think one of the differences between #1 and #2 is that while #2 means pinging providers to see if the user is logged in there, if implemented correctly it can actually provide the user with additional privacy assuming that they trust their provider. With the #1 case, the site I’m logging into is looking into by browsing history via CSS/JS which is not something I have control over. With #2, I could configure my provider to never return login state information, only return it for “trusted” sites, etc.

• Chris Messina Says:
  April 15th, 2009 at 7:18 pm

  I’m glad that you included the objection. That was the one thing that I was thinking reading through your proposal that I think is going to be really hairy.

  All you need is for someone to use Yahoo! mail and Google Docs and to be logged in to both to see the conflict emerge, and then we’re back to the user having to pick which ID to use. I think we can get around this with effective UI design and language, but it’s not something to gloss over, especially where we already see Google “making it easier for the user” in Friend Connect — presuming that if you’re signed in to your Google account that you want to use THAT OpenID for the current transaction.

  I don’t want to merely take the side of crazy libertarian — but point out that people will want to have ready access to different OpenIDs used for different purposes. Making it easier to hint to the RP which options to show is a great idea — as long as it’s consistent from RP to RP (as the Facebook Connect experience is!).

• Luke Shepard Says:
  April 15th, 2009 at 8:22 pm

  Niall, I think I agree with David - while clearly tempting, reading browser history is too broad and doesn’t allow user control. With the browser history hack, the user has really only two choices: either she allows all or none.

  At least if the provider chooses to release that information, then it is under the control of the provider. As David points out, the provider can act on behalf of its users, and allow for some to opt out. And as we’ve seen, some providers will leak this info, and others will refuse - so we can let the marketplace decide the right balance between openness of data and privacy.

  Chris- totally agree (which is why I included the objection). But I think this is an incremental step. Once/if this becomes widespread, I think it could be one step along the way to a better, but more complicated solution (like the central discovery service).

• Chris Messina Says:
  April 15th, 2009 at 9:50 pm

  Also, in opposition to Niall’s hacked approach, there’s no saying when (or if) browser makers will fix this bug (few sites seem to use defaults anyway — maybe :visited will go away?) and furthermore (or worse) it complicates things by creating inconsistent user experiences across devices with different browsing histories.

  In other words, on your personal laptop, perhaps you can test that someone’s been to Yahoo, Google and so on… but on the office system that’s locked down, perhaps history is cleared on a regular basis and you’re unable to get the same results on the other machine. That means that you’re delivering varying user experiences with no rhyme or reason, because the mechanism is opaque to the user.

  Allowing the OP to advertise whether the user’s signed in or not is a nice compromise, where you can opt in for added convenience or choose not to in favor of preserving privacy.

• Jon Menzies-Smith Says:
  April 16th, 2009 at 1:50 am

  Something you have neglected to mention is the case for users who have not yet visited the provider site, what happens if the browser history is cleared and how should you behave for shared pcs. You end up getting yourself back into the same predicament.

  I certainly wouldnt want to have to visit openid or log into facebook in order to be presented with the options to log in.

• Allen Tom Says:
  April 16th, 2009 at 6:06 pm

  In our experience, we’ve seen that many users have several accounts, each with a different purpose, and they deliberately do not want to link the accounts together. For instance, someone might have a professional persona using one account, and a party persona using another.

  We have to be careful to protect the user’s privacy if the user has multiple personas on the RP, each tied to a different OP. If the user happens to be signed into both OPs (for instance, if the user using both Google Docs and Yahoo Mail) knows which account is being used when visiting the RP. This is one of the reasons why Yahoo does not (currently) support checkid_immediate — we want the user to be aware of which account or persona is being used when signing into an RP.

  In the Facebook case, where everyone uses their Real Identity, juggling multiple personas isn’t really an option, however that might be the case for other OPs.

• Your stuff is here, here and here. Rely on it | Coded Style Says:
  April 17th, 2009 at 10:45 am

  […] stuff is here, here and here. Rely on it Luke Shepard posted about avoiding Open ID Nascar and detecting the user’s […]

• Bertil Hatt Says:
  April 17th, 2009 at 2:08 pm

  You might want to have a default list of providers (based on the site’s previous users, or more general statistic) and a button “I don’t understand” or “Pick one for me” that choses one at random; even better, a button “Tell me which account I already have” triggers the History script.

• Bill Shupp Says:
  April 19th, 2009 at 10:58 pm

  Allen,

  Agreed. This is not such an issue for OPs where there is only one “persona”. But I like the idea of OPs allowing users to pre-select whether or not to communicate their logged state to RPs. Maybe even include a list of personas that the user could select in the resulting dialog on the RP side, with a follow up request for any AX/SREG information (so it is not sent before a persona is authorized).

  Regards,

  Bill