(2) PURPOSE: Please provide a clear statement of purpose and justification why the proposed WG is necessary.
The purpose of the Work Group is to uncover, through a structured process (design and testing of prototypes, authoring draft specifications, building reference implementations), an integrated user interface and an enabling technical framework that best guides a person through the login lifecycle of a website. This does not include first time registration, but does include logging in during return visits, required consents, as well as logging out. It encompasses the process of the selection of the user's Identity Provider as described in the Liberty Identity Provider Selector MRD \ [ulx:1\]. Assumed is a range of initial conditions, protocols, and relationships between the application and identity services including identity providers and identity provider selection agents (ISAs). The Work Group will facilitate the development of visually consistent, interoperable implementations of these specifications Wiki Markup
The Work Group is necessary to expedite the process of gathering representatives from disparate communities each of which tends to focus on the user experience for a single protocol or approach. Key to success will be attracting participation from the communities developing formal standards (e.g. SAML, OAuth and IMI Information Card), communities supporting de facto standards (e.g. OpenID, Facebook Connect and Google Friend Connect), and communities involved in HTML username/password technology (e.g. browser developers). The output of the Work Group is a set of guidelines and draft specifications that embrace many different login technologies, along with reference applications that can be empirically demonstrated to be easy for people to learn and use. Specifically, this Work Group is responsible for:
• Designing a methodology and set of metrics for empirically testing the effectiveness, efficiency, and overall usability of various approaches to implementing the website login lifecycle.
• Developing a set of use cases and requirements that are specific enough to guide the specification design work, in addition to the already existing use-cases and requirements of the Liberty Alliance Identity Provider Selector MRD [ulx:1].
• Developing prototype implementations of the user interface and enabling technical frameworks
• Applying the testing methodology to these prototypes
• Developing a set of modular draft specifications based on the outcome of the design/prototype/testing process that meet the identified use cases and requirements (including use cases and requirements of the Liberty Alliance Identity Provider Selector MRD [ulx:1]), influenced by contributions as appropriate
• Developing and maintaining liaisons as appropriate with external bodies and other Kantara groups
• Fostering the creation of multiple interoperable reference implementations, particularly in open source
• Promoting progressive harmonization with existing specifications and protocols as appropriate
• Developing educational materials in support of the overall Work Group effort
• Overseeing the contribution of each resulting draft specification to a standards-setting organization
(3) SCOPE: Explain the scope and definition of the planned work.
The specifications must meet the following basic functional requirements, in addition to specific use cases and requirements later identified by this Work Group:
• Support the notion of an integrated user interface such that one or more protocol-specific implementations can fit within the overall visual interaction framework.
• Allows the person to login and to logout.
• Allows the person to use a variable number of computers and/or mobile devices
• Allows that the specific device being used may or may not have some kind of identity client software integrated into the browser hereafter referred to as a browser add-on (aka "Identity Selector Agent" in the device if we refer to the terminology used in the Liberty Alliance Identity Provider Selector MRD [ulx:1])
• The user experience will be optimized for the case where a browser add-on is present, but will still function although with perhaps a less than ideal experience in the browser-only case.
• Allows that the Identity Provider selection process may as well be delegated to a new actor/entity in the network ("Identity Selector Agent" in the network) playing more or less the same role as this browser add-on.
• Supports a wide range of sizes of display surface for the interface.
• Accommodates the fact that the Website (or local web-based application) supports one or more of the following interaction methods: username/password, OpenID, Facebook Connect, IMI Information Card, SAML, Google Friend Connect, Kerberos.
• Accommodates the fact that the browser add-on or new actor/entity in the network mentioned above, if present, supports one or more of the following login methods (that the person is capable of using): OpenID, Facebook Connect, IMI, SAML, Google Friend Connect, Kerberos.
• Accommodates the fact that the person may be visually impaired or have other disabilities
The specifications must meet the following basic design principles, in addition to any emergent design principles later identified by this Work Group:
• Simple to understand, implement in an interoperable fashion, and deploy on an Internet-wide scale
• Modular (e.g. incorporating other existing specifications by reference where appropriate, and breaking down this Work Group's draft specifications into multiple pieces where reuse by different communities is likely)
• Generative (able to be combined and extended to support a variety of use cases and emerging application functionality)
• Developed rapidly, in an "agile specification" process that can refactor for emerging needs
The following design solutions are initially out of scope for the first version of the group's output, though the group should avoid precluding such solutions, if possible, where they are analogous to in-scope solutions:
• Other types of networked applications besides Web-based ones
• Parties other than natural persons wishing to login
• Non-login/lout interactions including but not limited to account registration, password recovery, silent authentication (e.g. of a computer to a network), digital signature presentation, payment and credential presentation.
The group will develop materials for workshops and conferences, and the coordinate speakers on ULX topics for such events.
(4) DRAFT TECHNICAL SPECIFICATIONS: List Working Titles of draft Technical Specifications to be produced (if any), projected completion dates, and the Standards Setting Organization(s) to which they will be submitted upon approval by the Membership.
It is anticipated that the following technical specifications will be produced, with modular boundaries subject to change; they are anticipated to be submitted to the World Wide Web Consortium (W3C) or OASIS for further work and completion:
• Universal Login UX Specification and implementation guidelines.
• Login Metadata Discovery – A mechanism whereby an ISA in the device (browser with an add-on) or an ISA in the network (with an unmodified browser) can discover the supported/preferred login method(s) or requirements of the Relying Party for this interaction.
• Identity Provider Metadata Discovery – A mechanism whereby an ISA can discover relevant IDP metadata (such as supported claims, assurance characteristics, presentation requirements …) in order to enable consistent match between the Login Metadata expressed by the Relying Parties and these user's IDP(s) capabilities. Newly designed features should be as compatible and consistent as possible with existing IDP Metadata specifications (e.g. SAML metadata, XRD, etc.).
• ISA integration specification for Relying Parties.
(5) OTHER DRAFT RECOMMENDATIONS: Other Draft Recommendations and projected completion dates for submission for All Member Ballot.
Universal Login UX Best Practices and Walkthrough Documentation
At the group's option, some of this material may be considered non-normative (equivalent to white papers).
(6) LEADERSHIP: Proposed WG Chair and Editor(s) (if any) subject to confirmation by a vote of the WG Participants.
• Co-Chair: RL “Bob” Morgan, Internet2/University of Washington
• Co-Chair: Michael Graves, Janrain
• Co-Chair: Paul Trevithick, (individual participant affiliated with Azigo)
• Co-Chair: Philippe Clement, Orange-France Telecom
NOTE: For the purpose of formation, Paul Trevithick will act as the convener for the group and the initial primary point of contact.
(7) AUDIENCE: Anticipated audience or users of the work.
The anticipated audience for the documents produced by this Work Group includes developers, deployers, and designers of online services that act on behalf of individual users. The Work Group also anticipates gathering input from individual users of online services, in order to answer their needs and preferences to the extent possible.
(8) DURATION: Objective criteria for determining when the work of the WG has been completed (or a statement that the WG is intended to be a standing WG to address work that is expected to be ongoing).
This Work Group will target producing use cases and requirements including those of the Liberty Alliance Identity Provider Selector MRD [ulx:1] within 6 months of inception in order to guide its design effort, and will target 18-24 months to develop a V1.0 set of technical specifications and other auxiliary materials, facilitating the development of multiple independent reference implementations as appropriate during this time. The duration of this workgroup is intended to be indefinite, and charter may be amended from time to time, with changes approved by the Leadership Council.
(9) IPR POLICY: The Organization approved Intellectual Property Rights Policy under which the WG will operate.
Kantara IPR Policy – Option Liberty [ulx:2]
10) RELATED WORK AND LIAISONS: Related work being done in other WGs or other organizations and any proposed liaison with those other WGs or organizations.
This Work Group has a number of dependencies on, and shared goals with, the output of other efforts. Following are examples of other Kantara groups and external efforts with which this Work Group intends to liaise informally (absence from this list does not indicate a lack of interest in a liaison relationship):
• Kantara Consumer Identity Work Group
• Identity Provider Selection Work Group (IdP Selection WG)
• Information Card Foundation
• OpenID Foundation
• Eclipse Higgins Project
• W3C Rich Web Clients Activities, including the Web Apps WG
(11) CONTRIBUTIONS (optional): A list of contributions that the proposers anticipate will be made to the WG.
(12) PROPOSERS: Names, email addresses, and any constituent affiliations of at least the minimum set of proposers required to support forming the WG.
• Co-Chair: RL “Bob” Morgan, Internet2, University of Washington
• Co-Chair: Michael Graves, Janrain
• Co-Chair: Paul Trevithick, Azigo
• Co-Chair : Philippe Clement, Orange-France Telecom
• J. Trent Adams, Internet Society
• Ben Laurie, Google
• George Fletcher, AOL
• Ashish Jain, PayPal
• Pamela Dingle, Bonsai Identity
• Dieuine Monteiro, Azigo
• Drummond Reed, Information Card Foundation
• Valeska O’Leary, IDG
• Axel Nennker, openinfocard project
• Gael Gourmelen, Orange-France Telecom
• Benoit Bailleux, Orange-France Telecom
• Bob Sunday Government of Canada