Charter submission for Account Chooser Working Group

Anthony Nadalin tonynad at microsoft.com
Tue Aug 30 07:34:43 UTC 2011


So still confused, I assume that "user interface" refers to UI and semantics? Is there a wire format to be done at all? How does this fit into OpenID Connect? Is the "account chooser" just use to select account and not user consent?

From: openid-specs-bounces at lists.openid.net [mailto:openid-specs-bounces at lists.openid.net] On Behalf Of Eric Sachs
Sent: Monday, August 29, 2011 7:53 PM
To: Dick Hardt
Cc: Christopher Messina; John Bradley; OpenID Specs Mailing List; Chuck Sievert; Basheer Tome; Kevin Long; Andrew Dahley; Don Thibeau; Wei Tu
Subject: Re: Charter submission for Account Chooser Working Group

Agreed.  I updated the charter posted at https://sites.google.com/site/oauthgoog/workinggroupcharter?pli=1
On Mon, Aug 29, 2011 at 6:34 PM, Dick Hardt <dick.hardt at gmail.com<mailto:dick.hardt at gmail.com>> wrote:
I'd suggest replacing/removing the word "guidelines" in the Statement of Purpose and Scope -- here is a suggested change

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.

Scope

Produce a specification for the account chooser user interface.


On 2011-08-29, at 6:29 PM, Eric Sachs wrote:


>> Is your proposal to create "guidelines" or "requirements"?
The current goal is "requirements" for a website <or vendor product> that wants to say it has implemented an "OpenID account chooser v1."  As an example, the very rough draft spec has some elements that are described as a MUST.  For example, this section:
https://docs.google.com/document/d/1ES9vo1euh3ArzKRaAmCfZWWwTm5bluNuH49hFec5a_I/edit?hl=en_US#heading=h.5y8muzxvbm92
Even the sections with SHOULDs allow a website/product to say things like they "implemented an OpenID account chooser v1 with the optional navigation bar support."

Obviously websites may still choose not to implement all the MUSTs, in which case they are using the spec more as a guideline.  However some of the frequent feedback from website owners about the account chooser is the desire to know that they could switch between vendor products, or their own implementation, or even mix/match components, and still provide their users with a consistent experience.  For example, a website might get a JavaScript library from one vendor that implements a lot of the UI elements, but hook it up to a product from another vendor that supports the key functional logic.  Or a website might get an end-to-end solution from one vendor, and later they want to replace it with a different vendor without loosing major functionality in the the user experience.

There is also another perspective on "interoperable."  The community has talked a lot about the idea of people being able to expect a consistent/interoperable user experience across websites that are RPs, similar to how the Bluetooth mark might cause them to expect a similar pairing experience across a mix of phones & headsets.  That type of interoperable has value as well, but likely involves more components then just a spec.  Separately we did ask Scott David to investigate the idea of marks and talk about them to the OIDF board in the future.

On Mon, Aug 29, 2011 at 5:49 PM, Dick Hardt <dick.hardt at gmail.com<mailto:dick.hardt at gmail.com>> wrote:
Hi Eric

I'm getting hung up on some semantics in your proposal. An important objective of a specification is to standardize a practise to enable interoperability. In your proposal, you describe the specification to consist of guidelines. Guidelines sound like "nice to have" attributes rather than requirements. If this is a best practises document, I don't think it needs to go through the specs committee. If it will be branded OpenID and there are compliance requirements, then it does.

Is your proposal to create "guidelines" or "requirements"?

-- Dick

On 2011-08-29, at 4:59 PM, Eric Sachs wrote:

>> Can you give us a idea as to what the content and format of the design spec might look like?

There is a bit of intro to answers those questions at the top of https://sites.google.com/site/oauthgoog/workinggroupcharter

The goal is to look something like the section of the existing OpenID user interface extension that has guidelines outside protocol specs.  However the UI guidelines would be much more detailed then the few sentences in that spec.  We posted an initial rough spec<https://docs.google.com/document/d/1ES9vo1euh3ArzKRaAmCfZWWwTm5bluNuH49hFec5a_I/edit?hl=en_US> using that approach.  Some people have suggested adding one bit of protocol to the spec which is a way for the RP to tell the IDP that it is implementing an account chooser so that the IDP could do something different, just as it does for the popup spec.  However we have not been able to determine what the "different" behavior would be.

There may be related output from the work in this area like open source JS code.  There will hopefully also be easier to read implementation guides that are not in the spec format, but include things like mocks and flowcharts.  There are some examples of something like that at http://accountchooser.com/ux.html.  However that type of output seemed to be outside the bounds of what a WG charter should cover.



On Mon, Aug 29, 2011 at 4:46 PM, Allen Tom <allentomdude at gmail.com<mailto:allentomdude at gmail.com>> wrote:
Hi Eric,

Thanks for submitting the Account Chooser  WG proposal. As far as I know, this is the first time a non protocol spec WG has been proposed.

Can you give us a idea as to what the content and format of the design spec might look like? Will it be a set of wireframes? Mockups? Flowcharts? Will it cover only the login form? Will it also cover account linking and account recovery?

Thanks,
Allen


On Mon, Aug 29, 2011 at 10:46 AM, Eric Sachs <esachs at google.com<mailto:esachs at google.com>> wrote:
This is a formal submission to the OpenID Specs Council to approve the Account Chooser Working Group.  The draft charter is posted at https://sites.google.com/site/oauthgoog/workinggroupcharter and the current version has been copied below.  If possible, we would like to get a response from the Specifications Council before the September OpenID Summit so we can use that event for more discussions on this topic.



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<http://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 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 guidelines for how a relying party can implement an account chooser for both adding accounts, and selecting an account that was previously added.

Scope

Produce a specification for the account chooser user interface guidelines.

Out of Scope

The working group is not expected to define a protocol specification.

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 at basheertome.com<mailto:basheer at basheertome.com>, independent
John Bradley, jbradley at me.com<mailto:jbradley at me.com>, independent
Nat Sakimura, sakimura at gmail.com<mailto:sakimura at gmail.com>, NRI
Kevin Long, kevin at janrain.com<mailto:kevin at janrain.com>, Janrain
Pam Dingle, pdingle at pingidentity.com<mailto:pdingle at pingidentity.com>, Ping
Eric Sachs, Esachs at google.com<mailto:Esachs at google.com>, Google
Chuck Sievert, csievert at google.com<mailto:csievert at google.com>, Google
Wei Tu, weitu at google.com<mailto:weitu at google.com> Google
Andrew Dahley, andyd at google.com<mailto:andyd at google.com>, Google
Chris Messina, messina at google.com<mailto:messina at google.com>, Google

Initial Editors

Eric Sachs, Esachs at google.com<mailto:Esachs at google.com>>, Google




--
Eric Sachs | Senior Product Manager | esachs at google.com<mailto:esachs at google.com>

_______________________________________________
specs mailing list
specs at lists.openid.net<mailto:specs at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs




--
Eric Sachs | Senior Product Manager | esachs at google.com<mailto:esachs at google.com>





--
Eric Sachs | Senior Product Manager | esachs at google.com<mailto:esachs at google.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20110830/89f7b7ec/attachment.html>


More information about the specs mailing list