OpenID allows the user to choose any identity provider, even one that the relying party has never heard of. This freedom of choice is, in my opinion, the most valuable feature of OpenID. Unfortunately, this feature comes with a difficult challenge: how to provide the relying party with the information it needs to interact with the identity provider.
OAuth does not have this problem because the relying party has to preregister with the identity provider, typically a social site, and therefore must know of the identity provider. An OAuth relying party displays one or a few buttons labeled with the logos of the social sites it supports, e.g. Facebook and Twitter, and the user chooses a site by clicking on a button. But of course freedom of choice is lost: the user can only use as identity provider a social site supported by the relying party.
The traditional OpenID user interface consists of an input box where the user types in an OpenID identifier, which serves as the starting point of an identity provider discovery process. To compete with the simplicity of picking a social site by clicking on a button, some OpenID relying parties present the user with many buttons labeled by logos of popular OpenID identity providers, in addition to the traditional input box; but this user interface has been deemed ugly and confusing to the user. The many logos have been compared to the many ads on a race car, hence the term NASCAR problem that is used to refer to the OpenID user interface challenge.
To solve the challenge we propose to let the browser keep track of the identity provider(s) that the user has signed up with. The list of identity providers will be maintained by the browser as a user preference.
An identity provider will be added to the list by explicit declaration. As the user is visiting the identity provider’s site, the provider will offer its identity service to the user. The user will accept the offer by clicking on a button or link. In the HTTP response to the browser that follows the HTTP request triggered by this action the identity provider will include an ad-hoc HTTP header containing identity provider data including the OP Endpoint URL. The browser will ask the user for permission to add the identity provider to the list and store the identity provider data.
A relying party will use a login form containing a single button, with a label such as Login with OpenID. There need not be any input box for entering an OpenID identifier, nor any buttons with logos of particular identity providers. The form will contain a new ad-hoc non-visual element <idp>. When the form is submitted, the browser will choose one identity provider from the list and send its data to the relying party as the value of the <idp> element.
Which identity provider is chosen is up to the browser. It could be the default, or an identity provider that has previously been used for the relying party, as recorded by the browser, or an identity provider explicitly chosen by the user from a menu presented by the browser. The browser could choose to permanently display a menu showing the user’s list of identity providers as part of the browser chrome.
We arrived at this solution while thinking about the NSTIC pilot that we plan to propose. In the planned proposal the identity provider issues a certificate to the browser, which the browser imports automatically. A natural extension is to let the identity provider download to the browser other data besides the certificate, such as the OP Endpoint URL. Also, a browser user interface for selecting an identity provider is akin to the user interface for selecting a client certificate that browsers already have. We realize that existing user interfaces for certificate selection are less than optimal, but we believe that this is due to lack of attention by browser manufacturers to a rarely used feature, and that better interfaces can be designed.
“OpenID. Unfortunately, this feature comes with a difficult challenge: how to provide the relying party with the information it needs to interact with the identity provider. OAuth does not have this problem because the relying party has to preregister with the identity provider, …” Wait what? I think you’ve got it backwards. OpenID doesn’t have the problems that OAuth has, because OpenID has discovery of Providers built-in, whereas OAuth has no such discovery built in.
If you read the whole paragraph you’ll see we are in agreement. In OAuth the relying party has to preregister with the identity provider. That’s a BAD thing, because the user cannot freely choose any identity provider. Since the user cannot choose freely, the problem of how to communicate a free choice doesn’t come up. So an OAuth relying party just shows one or two buttons with the logos of the identity providers (social sites) that it supports. And the user is redirected to the identity provider with a single click. What I’m proposing provides the same one-click simplicity in OpenID, without sacrificing the freedom of choice proviced by OpenID.
To summarize: I do like OpenID better than OAuth 🙂
This blog post was also discussed in the OpenID General Discussion Mailing List and the Identity Commons Mailing List.
I think you are trying to re-invent Mozilla Persona.
In Mozilla Persona, the identity is the email address of the user, whereas the solution proposed in the post does not rely on an email address. There are cases where the user does not want to reveal his or her email address to the relying party, for the sake of privacy, security, and protection against spam.
I do like the proposed solution but some issues come to mind
1) What about a user who’s browser’s known ID providers list is still new/empty?
2) What about a shared computer such as the one in the living room?
3) How does one sign in when you have some regular used IDPs in your own device but you find yourself using a shared computer such as one at an “Internet Cafe” or other public kios?
Good questions!
1. The browser may not have recorded any identity providers because the user does not have any, or because the user has not used any on that particular browser. When the user presses the “Login with OpenID” button provided by the relying party and the browser knows of no identity providers, the browser prompts the user to enter an OpenID identifier that the user may have already been using on some other browser, and provides instructions on how to register with an identity provider if the user does not have one already, perhaps providing a choice of identity providers that the browser vendor likes.
The relying party could also query the browser through a JavaScript API to find out if it knows of any identity providers for the user, and display a different form if it doesn’t. That form could fall back on prompting the user for an OpenID identifier.
In the post I said that the browser should record an identity provider when the user registers with the provider, but it must also be able to record an identity provider upon first use on that browser, since the user may have registered with the provider on some other browser.
2. The living room computer should have multiple user accounts, or the browser on the computer should have multiple user profiles.
3. The browser at the Internet cafe should be in a clean state with no recorded identity providers. The browser and/or the relying party can handle the lack of recorded identity providers as explained above in the response to question 1. Alternatively, the browser may allow the user to download a user profile from a server provided by the browser vendor, upon authentication of the user to the browser itself.