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]
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
