Identity in the Browser
http://ihack.us/2009/11/10/active-identity-clients-aics-for-openid/
Active Identity Clients (AICs) for OpenID
Note Taker: Dr. Ernie @ 5:18 pm
Tags: identity, javascript, openid
“Enough is enough! I have had it with these #@%!*$ AICs and their #@%!*$ panes” — Samuel H.S. “Hammer Stack” Jackson (with apologies to Neville Flynn)
Introduction
The OpenID community is still wrestling with how to deliver a first-time login experience that is acceptable to mainstream users. Research indicates we need something less open-ended than typing into a blank URL field, but neither is it desirable to push users to choose from a few (or worse, many) pre-selected identity provider logos.
One approach for solving this problem is called (for lack of a better term) the Active Identity Client, or AIC (similar to what I previously called a Chamberlain). An AIC boostraps the identity selection process at a new website (aka Relying Party, or RP) by storing some amount of identity information on the user’s home computer. The AIC uses that identity to access a persistent record of the user’s interaction with multiple sites and identity providers (IdPs) to negotiate and streamline future such interactions. This (in theory) allows the user, rather than the RP, to prioritize which providers to use.
A number of such AICs were demonstrated at last week’s Internet Identity Workshop. Rather than attempting to standardize on a single AIC, a group of us discussed developing a common infrastructure that might enable a broad spectrum of AICs to innovate and compete. Specifically, we attempted to identity conventions, best practices, and extensions to existing standards that would support both “native” and “in-browser” AICs.
This article is my idiosyncratic attempt to synthesize what we discussed into a coherent vision for Active Identity Clients. It may not fully reflect the opinions of any given participant, and certainly does not represent the views of our respective employers. Rather, it is a subjective snapshot of a still-evolving problem space, and is intended to provide a concrete starting point for further discussion, critique, and clarification.
Usage
The one problem OpenID can’t solve is knowing what to tell a first-time user, since by definition the website doesn’t yet know who the user is. An Active Identity Client is able to streamline the process of establishing trust because it always knows who the user is, and can thus negotiate with the website on the user’s behalf to ensure only relevant choices are presented. For example, it can:
- Track and manage the user’s preferred identities
- Automatically sign on to known and trusted sites with the appropriate ID
- Suggest which existing ID to use when visiting a new OpenID site
- Safely enable user to acquire a new ID for a given site, when necessary
- Ensure a user’s custom ID is as readily usable as a ‘well-known’ ID
- Record where and when a user used various IDs
Scope
In order to make forward progress during IIW, we explicitly agreed to focus on a very narrow set of requirements:
- OpenID, versus all other protocols (e.g., InfoCard and SAML)
- Required infrastructure, versus the overall AIC user experience
Those other issues are far from unimportant, but we wanted to first come up with a concrete solution that addressed this specific problem, after which we can and should see whether it could be easily generalized for broader use.
However, we did expand the definition of AIC to include both native (e.g., via plug-in, toolbar, external manager, or direct browser support) and JavaScript (e.g, cloud-based) implementations. There was heated discussion about which of those models is more secure and/or viable, which is why we want to enable both and let the market decide. Note however that ensuring this flexibility may require some creativity in how this gets implemented and rolled out.
Markup
This first piece of infrastructure needed to support AICs is some simple markup a web designer can add to their website to indicate support for OpenID and AICs. We consider — and rejected — a proposal to simply include the information as a META tag in the header, as that would potentially require the AIC to scan every page to determine whether to active/be activated. Instead, we agreed to develop a custom tag that could either be interpreted directly by the browser, accessed by JavaScript, or converted to an <object> to launch a plugin when activated.
The rationale for a custom tag (as opposed to, say, a microformat) is to allow the website (i.e., Relying Party) to explicitly and unambiguously provide important metadata, such as:
- Canonical name/template for the Relying Party (“realm”)
- Lists of suggested and/or required Identity Providers
- URL to return to after authentication
- Link to privacy policy
- Tags describing type of website (to facilitate user policies)
- Plus perhaps “protocol” and “tokenType” to allow use of tag by other protocols
I believe it is important to provide appropriate defaults (either global or AIC-specific) for all of these, so that it is as simple as possible for web developers to ‘tag’ their websites as supporting OpenID AICs. For example, one possible implementation is to have a “login” tag that wraps the various URLs used for manual login, which would not need any attributes if the developer was happy with the default values. In theory it might even be possible for browsers to “sniff” OpenID support even in the absence of an explicit tag, but that may or may not be advisable.
Status
The ultimate goal would be to have this tag become part of HTML 5 or a similar standard. Chris Messina of the OpenID Foundation has agreed to take this action item, to propose an implementation and shepherd it through the appropriate approval process.
Provider Branding The second extension required is a way for OpenID Identity Providers (IdPs) to provide human-oriented descriptions of themselves to facilitate user decisions. Currently, various websites and client software hard-code their own list of names and logos for different providers. Instead, we recommend that as part of its XRDS file each IdP also specify their:
- logo, in, e.g. 16×16, 48×48, 128×128, 256×256 sizes
- human-readable name
Note that were appropriate there should be a localized version of this content based on the language specified in the HTTP headers.
Status
Mike Jones of Microsoft has already been discussing this extension with the OpenID User Experience working group, and formal proposal is in the process of being approved.
Security and Spoofing One of the main reasons for Provider Branding is to enable a friendly listing of Providers specified by the RP in the login tag. Unfortunately, this means that Branding could be used to redirect users to a phishing site. While in one sense this is no different than the website presenting that directly, the fact that a putatively trustworthy AIC is displaying what may be misleading information is a cause for concern.
The best that can be done is for the AIC to explicitly mark Providers as untrusted (vs. trusted) until they have been explicitly verified by the user. But to avoid bombarding the user with false negatives, AIC’s should pre-populate with a list of well-known Providers (“whitelist”), or perhaps well-known Phishers (“blacklist”).
There was considerable interest in having such lists be published and/or managed by a neutral party, such as the OpenID Foundation. However, there was no clear consensus on what the policy should be for inclusion in that list, given that different regions may have different “well-known” providers and some providers (e.g., Google) may want to authorize millions of subdomains.
Status
Under the circumstances, I believe it is premature (and may well be unnecessary) to standardize this aspect of the user experience. Instead, it is incumbent upon each AIC developer to:
- Choose a reasonable set of pre-approved Providers
- Require SSL certificates for any trusted Providers
- Allow the user to easily specify their own trusted Provider
- Automatically honor Extended Validation Certificates
- That should provide a reasonable balance of convenience and security for the short term, and provide useful experience to inform future standardization efforts.
JavaScript Support One area we only touched on briefly at IIW but may prove crucial to adoption is the development of a standard JavaScript library to act as a meta-selector. Since it will take a long time (if ever) before browsers fully support a login tag, participating sites will probably need to include a JavaScript library that:
- Detects which AICs are installed/available
- Determine which AIC the user prefers/has configured
- Can rewrite the login tag to launch a plug-in
- Can delegate to an in-browser AIC
- The logical home for this would be an OpenID popup library, which would also act as “fallback” if no AIC was available. In fact, the additional metadata specified here should enhance the user experience of the popup, by allowing it to dynamically customize the list of buttons based on the Providers recommended by the website.
Status
This is the most important but least well-defined of the areas under investigation. Ariel Gordon of Microsoft agreed to work with Allen Tom and Paul Trevithick on how best to integrate it with the frameworks they work on.
Conclusion
OpenID has enormous potential for making browsing the web both safer and more convenient, but that potential will not be realized under “ordinary” users feel comfortable using it. I believe that if we can successfully tackle these few remaining issues then JavaScript, browser, and platform developers will be able to experiment with and deliver vastly improved user experiences. This in turn should encourage even more websites to act as Relying Parties, and finally make single sign-on a reality on the public Internet.
Appendix: Related Technologies
