<< Previous Comment in Document
| Next Comment in Document >>
Document Details
Comment Submitted by
Susan Campbell
2011-06-17 11:25:15
|
Comments re the ESPReSSO: Establishing Suggested Practices Regarding Single Sign-On Draft for Public Comment
1. In the ESPReSSO Draft for Public Comment it states, in the Overview of Issues, page 1 paragraph 3: , “The working group did not address the situation where an individual would obtain a license for his or her own personal use and then use a social account to authenticate themselves to the service provider. Service providers are reporting that users are not currently requesting this functionality. In addition, supporting this approach requires as much work for the publisher in managing userids and passwords within their site as it does for the licensee organization.”
I may be misinterpreting “social account.” I take it to mean personal use in this context, not Facebook, Twitter, etc. I wonder about this claim because it seems to me to be exactly what the New York Times did when it moved content behind a pay wall after a reader accesses 20 articles. The NYT is not just managing userids and passwords, they’re also counting uses. If a big player like NYT chooses to deal with individuals directly, is ESPReSSO ignoring an important trend with the language above? Additionally, database vendors seem quite willing to sell articles on an on-demand basis if the licensing organization doesn’t offer a particular database or service. This seems to be another important individual use.
Would it be better if the ESPReSSO document said it considers this trend out-of-scope rather than imply it doesn’t exist?
Is this relevant to a standard: “…supporting this approach requires as much work for the publisher in managing userids and passwords within their site as it does for the licensee organization.”
2. In section 2.2 Library Community (p 4) the emphasis is on libraries’ concerns about patron privacy. This is an ongoing concern; however another library concern related to effective SSO is that it must not come at the expense of the library’s branding and identity. It’s important for the user to reach the content they need seamlessly and effectively, but it’s also important that users know the library provided the funding and access for that content.
3. The illustrations in Figures 5 and 6 introduce ambiguity in definition of “service provider (SP). On p 1, it seems to refer to publishers and Figure5 (p 22) and Figure 6 (p 24) which identify Brown University as a “Service Provider” doesn’t make it clear that this is a local respository. Identification of Brown University as a Service Provider initially seems inconsistent with the other uses of Service Provider in the document. (Perhaps a different example, where the identity provider is not also related to a local repository and instead is a more typical Service Provider would be better. Even replacing “Brown University” with “Service Provider Name” in image editing software would improve this example.)
4. The recommendations beginning on page 18 present explicit compliance with existing technologies (e.g. cookies in 4.4.2) at the potential expense of future solutions. Would it be better to have more descriptive rather than prescriptive recommendations?
5. Branding isn’t defined in the list of terms, but it has multiple uses in the document. A definition of Service Provider branding and Institutional branding for this document and consistent usage would improve the document. Section 4.8 (p 26) recommends branding usage, but an additional definition in the term list would be helpful.
6. In Service Provider Identity Discovery Page (p21 item 3), the recommendation that the Identity Discovery Page take on UI elements of the SP site may not be possible or practical. It may be possible to do in a frame, but the choice and implementation method should be optional as the library has a valid need to retain library branding and recognition for their user community. (See also Institution Login Page (p23, item 2).
7. In Service Provider Identity Discovery Page, (p 22, item 7), “Display one or more preferred IdPs…”, preferred IdP is not defined. If it only means they have a cookie from a previous visit, then it is a “previous” IdP and not a “preferred” IdP. See also p 19, 4.4.2 “Ability to change the user’s preferred institution (if a previous selection was remembered via a browser cookie.)” A definition of “preferred IdP” would be a useful addition to the document.
|
| Submitter Proposed Solution |
see above
|
ESPReSSO: Establishing Suggested Practices Regarding Single Sign-On (Revision 0)