Charter submission for Account Chooser Working Group

Eric Sachs esachs at google.com
Wed Sep 7 00:51:43 UTC 2011


JohnnyB sent the feedback below, but I think it only got to me, so I've
added back the rest of the people on the thread.

And +1 to your/Allen/Dick's comments.  Once we start the actual mailing list
to refine the spec, we'll reiterate that guidance.

On Tue, Sep 6, 2011 at 5:40 PM, Johnny Bufu <johnny.bufu at gmail.com> wrote:

> Hi Eric,
>
> My thoughts are along the same lines expressed by Allen and Dick earlier in
> the thread. While offering useful alternatives to RPs, I would suggest to
> favor MUSTs over SHOULDs as much as possible as the spec is refined and
> details filled-in.
>
> Johnny
>
>
> On Tue, Sep 6, 2011 at 9:33 AM, Eric Sachs <esachs at google.com> wrote:
>
>> Adding Axel Nannker who also asked to be listed as a proposer for this new
>> working group.
>>
>> Does anyone on the specs council have additional questions or suggestions
>> on how we could improve the charter?  I believe the present membership of
>> the specifications council is:
>>
>>    - Johnny Bufu
>>    - Mike Jones
>>    - Breno de Medeiros
>>    - Dick Hardt
>>    - David Recordon
>>    - Nat Sakimura
>>    - Allen Tom
>>
>> I have talked or exchanged email on this thread with everyone except Johnny
>> Bufu and Mike Jones.  Johnny, if you are still monitoring this list could
>> you let us know if you have questions/suggestions?  That just leaves Mike,
>> but he just got back from vacation about a week ago and pinged me that he is
>> reviewing it.  I am hoping we can get his ideas for improving the charter
>> this week, and then have a formal specs council vote.
>>
>>
>> On Tue, Aug 30, 2011 at 10:02 AM, Eric Sachs <esachs at google.com> wrote:
>>
>>> >> Is the “account chooser” just use to select account and not user
>>> consent?
>>> That is generally correct.  One of the specific goals was a UX that would
>>> work with multiple redirect based protocols (which is already true of a
>>> NASCAR style UI) so the past work in this area has explicitly stayed away
>>> from specifying changes that IDPs need to make, or changes in protocols.
>>>
>>> At the same time, the spec does say that RPs should send the user to an
>>> IDP to "get user consent" to access their photo/name/identifier, and the
>>> spec then describes specific ways to use that information.  The methods for
>>> doing that vary across OpenIDv2+AX, OpenIDv2+SREG, and OpenIDConnect, as
>>> well as existing OAuth2 IDPs like Facebook/WindowsLive/Salesforce.  I do
>>> think it would help to describe in more detail how to use specific protocols
>>> to get that information.  However I hoped the working group could decide
>>> whether it is better to do that in the spec itself, or in related
>>> documentation that is outside the actual spec.
>>>
>>> >> How does this fit into OpenID Connect?
>>> The current specs of OpenIDConnect suggest a set of attributes in the
>>> default response from an IDP that happen to contain the minimal information
>>> that an RP would need to deploy an account chooser based on the initial
>>> draft spec.  So the attribute exchange part will require less work then
>>> integrating with an OpenID v2 IDP.
>>>
>>> >> Is there a wire format to be done at all?
>>> The minimum "wire formats" already exist in the protocols, but as noted
>>> it is not clear how much this AccountChooser spec should reference them in
>>> detail.  There is also the suggestion that the spec should define a standard
>>> way (for at least one protocol) that the RP could use to tell an IDP that it
>>> is using an account chooser in case the IDP wants to behave differently.
>>>  That could certainly be done within this spec if the specs council suggests
>>> it is worth including.
>>>
>>> >> So still confused, I assume that “user interface” refers to UI and
>>> semantics?
>>> It definitely includes those 2 components, but it only works if the RP
>>> website has a protocol, (or protocols) it can then use to talk to identity
>>> providers.  This spec needs to at minimum talk about that protocol
>>> integration at a generic level, but it could give examples/details for
>>> integration with particular protocols.  There is also the edge case of
>>> websites that are interested in deploying an Account Chooser without
>>> supporting identity providers.  A few sites have asked about that, though in
>>> all those cases they wanted to do it as a stepping stone to becoming an RP.
>>>  The current proposed charter says the spec would describe how a site could
>>> implement that mode, and that would not require any protocol integration.
>>>
>>>
>>> Another more generic thing to keep in mind is that Google has been asked
>>> to "do the right thing" to make sure there are no IPR concerns (at least
>>> with Google's IP) about vendors or individual websites implementing their
>>> own account chooser.  We have received a number of requests along those
>>> lines, and we hope that a side effect of this working group is that its
>>> scope would help address any such existing IPR concerns.  It won't be
>>> sufficient by itself because there are other things like code people want us
>>> to open source, and icons people want us to transfer to the OIDF.  However
>>> that "do the right thing" goal was definitely part of the input to the
>>> earliest drafts of the working group charter.
>>>
>>>
>>>
>>> On Tue, Aug 30, 2011 at 12:34 AM, Anthony Nadalin <tonynad at microsoft.com
>>> > wrote:
>>>
>>>>  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>
>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Eric Sachs | Senior Product Manager | esachs at google.com
>>>
>>>
>>
>>
>> --
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20110906/9501a316/attachment-0001.html>


More information about the specs mailing list