Charter submission for Account Chooser Working Group

Tue Aug 30 02:53:09 UTC 2011

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> 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> 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>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> 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.
>>>>
>>>> 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, independent
>>>> John Bradley, jbradley at me.com, independent
>>>> Nat Sakimura, sakimura at gmail.com, NRI
>>>> Kevin Long, kevin at janrain.com, Janrain
>>>> Pam Dingle, pdingle at pingidentity.com, Ping
>>>> Eric Sachs, Esachs at google.com, Google
>>>> Chuck Sievert, csievert at google.com, Google
>>>> Wei Tu, weitu at google.com Google
>>>> Andrew Dahley, andyd at google.com, Google
>>>> Chris Messina, messina at google.com, Google
>>>>
>>>> *Initial Editors*
>>>>
>>>> Eric Sachs, Esachs at google.com>, Google
>>>>
>>>
>>>
>>
>>
>> --
>> Eric Sachs | Senior Product Manager | esachs at google.com
>>
>>  _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>>
>
>
> --
> Eric Sachs | Senior Product Manager | esachs at google.com
>
>
>

-- 
Eric Sachs | Senior Product Manager | esachs at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20110829/6ddd506c/attachment.html>