Subject Re: publisher interface study
From "RL 'Bob' Morgan" <rlmorgan@xxxxxxxxxxxxxx>
Date Mon, 21 Sep 2009 01:47:52 -0700 (PDT)

We are nearing the end the of the consultation period for the publisher interface study and as yet have had no dissenting voices.

OK: I dissent. While the study does an excellent job of explaining the situation, identifying the problem and backing it up with real user data, I remain unconvinced that its main recommendation, that of a brand to represent academic federated access, makes sense. At the risk of over-simplifying, it seems to me that the problem facing JISC is: how to replace the "login via Athens" label that has served it so well for many years? I acknowledge that JISC and Athens have led the way for the world in federated access, and I'm glad you have done so; but how-to-replace-Athens is not the problem in the US, nor I think most other places.

The answer given is "login via something more inclusive than Athens", where the inclusion extends to "academic federations". But this choice of what to include is arbitrary, as the study itself explains (p 41):

  6.1 Access to resources
  The changing world:
   • The user base that many publishers sell to today is broadening;
   • Non academic customers need to supported;
   • Publishers provide what the market desires in terms of access methods

What advice is given to publishers to deal with their non-academic customers? None that I can see. So, publishers will handle those needs in inconsistent, conflicting ways that will continue to create confusion for our users even if the academic brand helps a little (and I wonder how much it will; more below).

The point is that any login branding that makes the user have to decide up front "am I one of those?" via selecting a logo just doesn't scale. This is the main point, I think, of the research Google and others did into the login problem:

I'm not sure if refeds folks are familiar with this work or not; I had thought the JISC report mentioned it but looking again I don't see it. In particular the Google folks were reacting to and rejecting the promotion of the OpenID logo as a brand for login. I'm sure we would all agree with that: it is far too narrow and limiting to tie user behavior to a particular protocol (especially one many of us don't like). But, from the point of view of a resource provider with customers in many markets, how could it make sense to tie user behavior to a label for one of those markets?

I don't have a strong alternative to propose; I don't think anyone does. I am, however, helping to lead a group just starting to work on the more general problem:

The group charter is appended. The group was just approved as a Kantara WG last week, so hasn't done anything yet; there has been some early discussion that led to developing the proposal for the group. The idea grew out of the Google work I reference above, and reaction to proposals from Information Card supporters of a login logo for that protocol, and of course everyone's observations about the login problem. The scope is wildly ambitious, but it is my opinion that the only way we'll be able to get beyond narrow, unsatisfactory solutions is to look at the big picture. I encourage others to participate in this group.

This means that we are preparing to move to the next stage - which will be to run an open design competition for a logo to represent federated access.

Can you clarify which "we" you mean here? Is JISC proposing to create this material for use by all of REFeds? Or by ... anyone? I don't want to stifle initiative, but it seems to me the practical questions about how such a brand would be used and administered are exactly the ones that make this proposal problematic. Could it be used by any site wanting to provide access to academic federations, or just publishers (and if so what defines a publisher)? As Josh asks, what common infrastructure would support signing on via this brand and what organizations would be eligible to participate in it? I guess the urgency here is to do something to solve the UK's Athens-replacement problem before things get any worse, and I can appreciate that this is important to you, but my concern is that if marketing gets ahead of reality both publishers and users will be turned off.

 - RL "Bob"


(1) WG NAME (and any acronym or abbreviation of the name): The WG name, acronym and abbreviation must not include trademarks not owned by the Organization, or content that is infringing, harmful, or inappropriate.

Universal Login User Experience (ULX) Work Group

(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 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 as well as logging out. Assumed is a range of initial conditions, protocols, and relationships between the application and identity services. The Work Group will facilitate the development of visually consistent, interoperable implementations of these specifications

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, OpenID, and IMI Information Card), communities supporting de facto standards (e.g. 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
    * Developing prototype implementations of the user interface
    * 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, 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 * 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.
    * 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, 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) for further work and completion:

    * Universal Login UX Specification
* Login Metadata Discovery – A mechanism whereby a browser with an add-on can discover the supported/preferred login method(s).

(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)

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 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. This 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

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.