Comment Details - National Information Standards Organization

#00120 Comment Details - RP-11-201x_ESPReSSO_for_comment.pdf

Document Information
Title	ESPReSSO: Establishing Suggested Practices Regarding Single Sign-On
File Name	RP-11-201x_ESPReSSO_for_comment.pdf	State	Draft
Date Added	2011-05-22 18:46:54	Revision Number	0
Submitter Name	Cynthia Hodgson	Size	1MB

Comment Information
Summary	Comments from Publishing Technology	State (Disposition)	New (Unresolved)
Date Added	2011-06-21 04:21:44	Last Updated	2011-06-21 04:21:44
Submitter Name	Rose Robinson	Assigned To	Unassigned
Company Name	Publishing Technology	Response	None
Interest Category		Category	N/A
Origin	Public Review	Section, Page, Line
Item		Item Description

Submitter Comment
Publishing Technology welcomes the following improvements to the Shibboleth user experience: * Stipulation of location for sign-in field on page design in righthand corner. * Deprecation of presentation of phrases like ‘Shibboleth’ to the end user. * Auto-suggest on the institution search field * Inclusion of city or postcode as search parameters * Recall of user settings for future sign-ins * Geo-detection to suggest appropriate institutions However, we do have some concerns regarding aspects of the proposal: * If search is to be the primary interface, it would be useful to advise on what synonyms, acronyms or nicknames the search should support e.g. St Edmund Hall College Oxford is often referred to as SEH or Teddy Hall. * It would be useful to clarify whether you are recommending auto-suggest or auto-complete for the search box as the two patterns are quite distinct, the former making suggestions, the latter completing the form for the user. We would strongly suggest the former. * In Section 4.4.2 you recommend that search suggestions start appearing after the first character is typed. The general convention on auto-suggest is for it to be triggered from the third character at which point it can provide meaningful suggestions. * We think the option to filter IdPs by country is useful if a site supports multiple federations. As more institutions join federations, the listing is going to grow longer and longer, which tends to suggest that if it is to be used at all then some way of filtering the list remains highly desirable. Although the proposal has search as the primary way of locating an IdP filtering by country first would significantly reduce the options presented to the user. The proposal does not make a distinction between different types of logins, for example personal passwords and institutional authentication options. A significant proportion of users to our sites are individuals who are not associated with an academic institution for example members of a professional organisation, such as the Institute of Civil Engineers. The proposal talks about a single login page, is this just for institutional users or intended for all users to the site? If the proposal is to have a single login page we would raise the following concerns. * Placing all sign-in techniques on the same page risks creating quite long and unwieldy pages e.g. in cases where personal username, Shibboleth, Athens and authentication via an OpenID 3rd party (e.g. sign-in with Google) are all supported. * At present where we present the user with a sign-in link the link directly expands to allow the user to enter a username and password without having to go down a level, which is in line with current best practice for authentication (e.g. a similar approach to that taken by Google or Facebook). By placing this on a page lower down as per your scenario, it does seem that we are unnecessarily penalising users who do wish to sign in with a personal username and forcing them down an unnecessarily length path. As such, our view would be that the standard should: * Flag how to distinguish between different sign-in types and preferably do so in line with the advice the JISC has already issued. * Remove the requirement for all sign-in types to be shown on the same page. There are a couple of areas that aren’t included in the guidelines that might be beneficial to cover: * WAYFless URLs are mentioned in the proposal, but there is no recommendation that these should be supported. Should the recommendations cover support for WAYFless URLs and guidance on how to construct these? * Should the recommendation include guidelines for how often the Federation metadata should be refreshed, once a day for example, and the removal of test federations once testing in complete? Test federations in the metadata could result in some confusion for users if multiple results are returned following an IdP search. On the whole the guidelines are good and it is great to see efforts to standardise how SSO is presented across sites.

Submitter Comment

Publishing Technology welcomes the following improvements to the Shibboleth user experience:
* Stipulation of location for sign-in field on page design in righthand corner.
* Deprecation of presentation of phrases like ‘Shibboleth’ to the end user.
* Auto-suggest on the institution search field
* Inclusion of city or postcode as search parameters
* Recall of user settings for future sign-ins
* Geo-detection to suggest appropriate institutions

However, we do have some concerns regarding aspects of the proposal:
* If search is to be the primary interface, it would be useful to advise on what synonyms, acronyms or nicknames the search should support e.g. St Edmund Hall College Oxford is often referred to as SEH or Teddy Hall.
* It would be useful to clarify whether you are recommending auto-suggest or auto-complete for the search box as the two patterns are quite distinct, the former making suggestions, the latter completing the form for the user. We would strongly suggest the former.
* In Section 4.4.2 you recommend that search suggestions start appearing after the first character is typed. The general convention on auto-suggest is for it to be triggered from the third character at which point it can provide meaningful suggestions.
* We think the option to filter IdPs by country is useful if a site supports multiple federations. As more institutions join federations, the listing is going to grow longer and longer, which tends to suggest that if it is to be used at all then some way of filtering the list remains highly desirable. Although the proposal has search as the primary way of locating an IdP filtering by country first would significantly reduce the options presented to the user.

The proposal does not make a distinction between different types of logins, for example personal passwords and institutional authentication options. A significant proportion of users to our sites are individuals who are not associated with an academic institution for example members of a professional organisation, such as the Institute of Civil Engineers. The proposal talks about a single login page, is this just for institutional users or intended for all users to the site? If the proposal is to have a single login page we would raise the following concerns.
* Placing all sign-in techniques on the same page risks creating quite long and unwieldy pages e.g. in cases where personal username, Shibboleth, Athens and authentication via an OpenID 3rd party (e.g. sign-in with Google) are all supported.
* At present where we present the user with a sign-in link the link directly expands to allow the user to enter a username and password without having to go down a level, which is in line with current best practice for authentication (e.g. a similar approach to that taken by Google or Facebook). By placing this on a page lower down as per your scenario, it does seem that we are unnecessarily penalising users who do wish to sign in with a personal username and forcing them down an unnecessarily length path.

As such, our view would be that the standard should:
* Flag how to distinguish between different sign-in types and preferably do so in line with the advice the JISC has already issued.
* Remove the requirement for all sign-in types to be shown on the same page.

There are a couple of areas that aren’t included in the guidelines that might be beneficial to cover:

* WAYFless URLs are mentioned in the proposal, but there is no recommendation that these should be supported. Should the recommendations cover support for WAYFless URLs and guidance on how to construct these?

* Should the recommendation include guidelines for how often the Federation metadata should be refreshed, once a day for example, and the removal of test federations once testing in complete? Test federations in the metadata could result in some confusion for users if multiple results are returned following an IdP search.

On the whole the guidelines are good and it is great to see efforts to standardise how SSO is presented across sites.