Note: This is the final proposal that became accepted in early September 2011

There is interest in starting a new OpenID working group to create a spec for an account chooser.  There is a formal process to start such a working group.  This AC WG (account chooser working group) would be similar to the OpenID User Interface Work Group Proposal that created the OpenID User Interface Extension 1.0 spec.  That spec had UI guidelines such as

The RP SHOULD create the popup to be 450 pixels wide and 500 pixels tall. The popup MUST have the address bar displayed, and MUST be in a standalone browser window. The contents of the popup MUST NOT be framed by the RP.

The RP SHOULD open the popup centered above the main browser window, and SHOULD dim the contents of the parent window while the popup is active. The RP SHOULD ensure that the user is not surprised by the appearance of the popup, and understands how to interact with it.

The initial input for a similar set of UI guidelines for the AC WG UI are posted at accountchooser.com/ux.html and an initial rough spec is also available.  Below is an initial draft of a charter for the AC WG.  Potentially the existing User Interface work group could generalize its charter to also cover this purpose, but that would probably be more complex to get formally approved.

Name

OpenID Account Chooser Working Group

Background Information

The term "NASCAR UI" is used to refer to one of the most common user experiences on Relying Parties to enable users to login with an identity provider.  There are a number of known usability problems with that UI, especially in terms of supporting a large number of identity providers, and for offering users the ability to log in with either an identity provider or a traditional email/password.  The identity community has had discussions about building a “cloud based” identity selector to deal with some of those problems.  The idea has been to mix the user experience advantages of Information Cards, the popularity of consumer identity providers, and still support large numbers of identity providers as InCommon has done.  The end result is a user experience that is being called an Account Chooser.  For background, see accountchooser.com.

The account chooser model can in some cases improve usability on a website even if it does not support identity providers, or a website that only supports identity providers, or a website that only supports a single identity provider.   The model should be protocol agnostic where possible to support both multiple protocols or multiple versions of the same major protocol. The account chooser model can also allow a relying party to customize the set of buttons it shows during the "add account" flow based on IP geolocation of the user to help promote a larger number of identity providers around the world instead of just a small number of providers as is generally shown on a NASCAR UI.  The working group will discuss all of these use cases.

Statement of Purpose

This workgroup intends to produce user interface specifications for how a relying party can implement an account chooser for both adding accounts, and selecting an account that was previously added.  The specification would include a definition for the API interaction between a JavaScript widget and RP server that are being used in combination to implement an account chooser.

Scope

Produce a specification for the account chooser user interface.

Out of Scope 

The working group is not expected to define non-backwards compatible changes to server-server protocols such as OpenID v2.

Specifications 

OpenID Account Chooser User Interface 1.0.

Anticipated audience

All those interested in improving the usability of relying parties.

Language of business

English. 

Method of work

Mailing list discussion. Posting of intermediate drafts in the OpenID Wiki. Virtual conferencing on an ad-hoc basis. 

Basis for completion of the activity

The OpenID Account Chooser User Interface 1.0 final specification is completed. 

Proposers

Basheer Tome, basheer@basheertome.com, independent

John Bradley, jbradley@me.com, independent

Nat Sakimura, sakimura@gmail.com, NRI

Kevin Long, kevin@janrain.com, Janrain

Pam Dingle, pdingle@pingidentity.com, Ping

Axel Nennker, Axel.Nennker@telekom.de, Deutsche Telekom AG, T-Labs (Research & Development)

Andrew Csinger, Andrew@mobio.net, Mobio

Eric Sachs, Esachs@google.com, Google

Chuck Sievert, csievert@google.com, Google

Wei Tu, weitu@google.com Google

Andrew Dahley, andyd@google.com, Google

Chris Messina, messina@google.com, Google

Enterprise RP - waiting for confirmation

IDPs - need to reach out

Allen Tom, independent - if needed

Initial Editors

Eric Sachs, Esachs@google.com>, Google