Charter submission for Account Chooser Working Group
Eric Sachs
esachs at google.com
Thu Sep 8 21:02:03 UTC 2011
I have some concern as well, and I am going to try to use IIW to recruit
more people to collaborate in that area.
On the positive side within Google we have built 3 AccountChooser
implementations (JS, mobile JS, non-JS) using different backends, and the
user experience across them is very consistent. I have also seen progress
by 2 other vendors and 1 other website so far building their own
implementations, and they also seem to be achieving the same.
On Thu, Sep 8, 2011 at 1:48 PM, Anthony Nadalin <tonynad at microsoft.com>wrote:
> OK, I’m a little worried that this could not result in a consistent
> account chooser experience since the server side would be the important
> piece here to make all the clients behave proper****
>
> ** **
>
> *From:* Eric Sachs [mailto:esachs at google.com]
> *Sent:* Thursday, September 08, 2011 1:45 PM
> *To:* Anthony Nadalin
> *Cc:* Mike Jones; 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****
>
> ** **
>
> >> One thing that is not clear is the scope, is this WG also going to deal
> with the server side, that is dealing with the delivery of various JS
> bundles to the client?****
>
> ** **
>
> Short answer is no.****
>
> ** **
>
> There is interest from a subset of proposers in the future to build an
> open-source JS widget that implements a subsection of the account-chooser
> functionality that could be contained in JS. The IPR for that would be
> handled under an open source policy instead of a specs working group IPR
> policy. If there is progress in that area, then some of those people might
> create a working group to define a spec for the connections between a JS
> AccountChooser widget and a server. Google is going to try to help
> bootstrap such an effort by splitting the JS widget in the
> GoogleIdentityToolkit into two pieces. The higher level UI piece could be a
> starting point for such a project (see initial article<https://sites.google.com/site/gitooldocs/customidps>),
> whereas the lower layer piece would be specific to GITKit.****
>
> ** **
>
> However multiple websites and vendors want to build an AccountChooser
> without having to agree on the connection between their JS widget and
> server. Based on feedback from potential websites customers of vendor
> products, the website customers generally don't feel the need to standardize
> that connection, but do want to be confident they could switch from vendor A
> to vendor B (or build their own) and still get the same customer facing
> functionality.****
>
> ** **
>
> In the near term though I wasn't able to get enough interest from people
> outside Google to work on either a spec for this connection, or the open
> source implementation, so I didn't put that in the charter. However if
> anyone is interested in working in this area in the near term....hint hint
> :-)****
>
> ** **
>
> ** **
>
> ** **
>
> On Thu, Sep 8, 2011 at 1:25 PM, Anthony Nadalin <tonynad at microsoft.com>
> wrote:****
>
> One thing that is not clear is the scope, is this WG also going to deal
> with the server side, that is dealing with the delivery of various JS
> bundles to the client? ****
>
> ****
>
> *From:* Eric Sachs [mailto:esachs at google.com]
> *Sent:* Wednesday, September 07, 2011 11:35 AM
> *To:* Mike Jones
> *Cc:* Anthony Nadalin; 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****
>
> ****
>
> >> Can we combine or close the old WG and make sure we have 1 effort?****
>
> ****
>
> That idea was discussed by a few of the proposers, but we could not come up
> with a good logistical way to do that. One idea was to have a really
> broadly defined WG on user-experience, but then there were concerns from
> multiple proposers that from a corporate/legal/IPR perspective they wanted a
> more constrained charter for the WG. So the current charter was an effort
> to find a middle ground.****
>
> ****
>
> Maybe in hindsight we should have used a more specific name like Popup UX
> working group as opposed to its current very generic "User Interface WG"
> name.****
>
> ****
>
> One suggestion that might be worth considering in the future is to
> categorize workgroups on the formal page that lists them<http://wiki.openid.net/w/page/12995249/Working%20Groups>,
> and to list both the Popup and AccountChooser WG as items in the UX
> category. But that might still require "formally" changing the name of the
> older WG from "UserInterface" to "Popup" and I don't know how to do that.
> Or as Mike suggests, maybe we can just close the older "UserInterface" WG
> in the future to avoid the confusion.****
>
> ****
>
> ****
>
> On Wed, Sep 7, 2011 at 11:33 AM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:****
>
> We should close all the inactive working groups when we have the next
> membership vote. (It takes a membership vote to close a working group.)**
> **
>
> ****
>
> We should do this when we send the Connect specs out for the Implementer’s
> Draft vote.****
>
> ****
>
> -- Mike****
>
> ****
>
> *From:* openid-specs-bounces at lists.openid.net [mailto:
> openid-specs-bounces at lists.openid.net] *On Behalf Of *Anthony Nadalin
> *Sent:* Wednesday, September 07, 2011 10:59 AM
> *To:* Eric Sachs****
>
>
> *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****
>
> ****
>
> OK, that captures what I was after.****
>
> ****
>
> We have an active “User Interface Workgroup” already so this charter seems
> to be addressing that WG but this is a request to start a new WG. Can we
> combine or close the old WG and make sure we have 1 effort?****
>
> ****
>
> *From:* Eric Sachs [mailto:esachs at google.com]
> *Sent:* Tuesday, September 06, 2011 4:29 PM
> *To:* Anthony Nadalin
> *Cc:* Dick Hardt; Christopher Messina; John Bradley; OpenID Specs Mailing
> List; Chuck Sievert; Basheer Tome; Kevin Long; Andrew Dahley; Don Thibeau;
> Wei Tu; Axel.Nennker at telekom.de
> *Subject:* Re: Charter submission for Account Chooser Working Group****
>
> ****
>
> >> So this brings up the issue of backwards compatibility****
>
> Yes. Fortunately in our past group/industry discussions we have found that
> a side effect of being protocol agnostic is that it also seems to provide
> some forwards/backwards compatibility. However achieving that goal took a
> lot of evolution of the design to find the right abstraction points. We
> seem to have found an abstraction that works for generally any federation
> protocol that relies on URL redirects. But only time will tell.****
>
> ****
>
> For example, when MSFT moved from WRAP to OAuth2 Google's AccountChooser
> implementations did not need to change. Similarly we are experimenting with
> Google's IDP moving from OpenID v2 to OpenIDConnect and similarly found no
> change was needed. Our AccountChooser implementations are built on top of a
> lower layer outside the AccountChooser that handles protocol details. That
> part changed, but not the logic on top.****
>
> ****
>
> >> it looks like you want to keep compatibility with V2 and the extensions
> that were done for V2 an d not limit the scope to OpenID Connect, is this
> right?****
>
> Correct****
>
> ****
>
> >> You want the compatibility to be covered in the charter and
> specifications?****
>
> After reading your email I went back and looked at the charter description
> and it does not say anything specific about this goal of being somewhat
> protocol agnostic and forward/backward compatible. Below is a suggestion of
> a modification to the charter that adds one clarifying sentence in red. I
> will go ahead and make that change unless anyone has different suggested
> wording.****
>
> ****
>
> 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.****
>
> ****
>
> ****
>
> ****
>
> On Tue, Sep 6, 2011 at 3:55 PM, Anthony Nadalin <tonynad at microsoft.com>
> wrote:****
>
> So this brings up the issue of backwards compatibility, as it looks like
> you want to keep compatibility with V2 and the extensions that were done for
> V2 an d not limit the scope to OpenID Connect, is this right? You want the
> compatibility to be covered in the charter and specifications?****
>
> ****
>
> *From:* Eric Sachs [mailto:esachs at google.com]
> *Sent:* Tuesday, September 06, 2011 9:33 AM
> *To:* Anthony Nadalin
> *Cc:* Dick Hardt; Christopher Messina; John Bradley; OpenID Specs Mailing
> List; Chuck Sievert; Basheer Tome; Kevin Long; Andrew Dahley; Don Thibeau;
> Wei Tu; Axel.Nennker at telekom.de****
>
>
> *Subject:* Re: Charter submission for Account Chooser Working Group****
>
> ****
>
> 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 ****
>
> ****
>
>
>
> ****
>
> ****
>
> -- ****
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20110908/4d3576c1/attachment.html>
More information about the specs
mailing list