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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected] >>> > 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:* [email protected] [mailto: >>>> [email protected]] *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 <[email protected]> >>>> 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 <[email protected]> >>>> 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 <[email protected]> >>>> 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 <[email protected]> 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, [email protected], independent >>>> >>>> John Bradley, [email protected], independent >>>> >>>> Nat Sakimura, [email protected], NRI >>>> >>>> Kevin Long, [email protected], Janrain >>>> >>>> Pam Dingle, [email protected], Ping >>>> >>>> Eric Sachs, [email protected], Google >>>> >>>> Chuck Sievert, [email protected], Google >>>> >>>> Wei Tu, [email protected] Google >>>> >>>> Andrew Dahley, [email protected], Google >>>> >>>> Chris Messina, [email protected], Google >>>> >>>> >>>> >>>> *Initial Editors* >>>> >>>> >>>> >>>> Eric Sachs, [email protected]>, Google >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Eric Sachs | Senior Product Manager | [email protected] >>>> >>>> >>>> >>>> _______________________________________________ >>>> specs mailing list >>>> [email protected] >>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Eric Sachs | Senior Product Manager | [email protected] >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Eric Sachs | Senior Product Manager | [email protected] >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Eric Sachs | Senior Product Manager | [email protected] >>> >>> >> >> >> -- >> Eric Sachs | Senior Product Manager | [email protected] >> >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> > -- Eric Sachs | Senior Product Manager | [email protected]
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
