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