Draft Minutes
InC-Library Collaboration, Phase 2
April 3, 2009

*Attending*

Steve Carmody, Brown University (chair)
Tom Barton, University of Chicago
Matt Bockol, Carleton College
Sarah Brownmiller, University of Oregon
Tony Byers, Michigan State University
Adam Chandler, Cornell University
Andy Dale, OCLC
Lynn Garrison, Penn State
Jim Green, Michigan State University
Eric Hinsdale, Carleton College
Sam Hooker, University of Vermont
Andy Ingham, University of North Carolina
Barry Johnson, Clemson University
Dave Kennedy, Duke University
Jon Kiser, University of Pennsylvania
Jonathan Lavigne, Stanford University
Mike McManaman, SUNY-Buffalo
Ben Morgan, UNC School of Arts
RL Bob Morgan, University of Washington
Lyman Ross, University of Vermont
Ernest Shaw, University of Missouri
Joy Verroneau, Cornell University
Ann West, Internet2
Jason Zabar, OCLC
Dean Woodbeck, Internet2 (scribe)

*Action Items*

(AI) Dean will send an overview of each subgroup to the email list, asking people to sign-up for one, and asking for volunteers to lead each.

(AI) Dean will set up wiki space for the subgroups and provide information on accessing and editing the wiki.

(AI) All - volunteer for one of the subgroups by sending a note to Dean (woodbeck@internet2.edu)

*Chat Room*

There was a chat room set up to facilitate the roll call and allow for side discussions during the meeting. Some could not access the room - perhaps more-detailed instructions before the next call would help.

Note that relevant questions/comments from the chat room will be posted at the end of these minutes.

*Wiki*

The group agreed that lists of names/organizations could be on the public wiki.

*NISO*

Adam Chandler is involved with this group as well as the National Information Standards Organization (NISO) group developing standards for user interfaces on library vendor sites. Steve Carmody reported that the UK Federation, JISC, is about to fund work on user interface issues.

*Use Cases*

Some of the use cases presented for discussion include these scenarios:

  • A user is the library or remote location, but going through the library's authentication
  • A user authenticates via the campus SSO, but the library uses EZproxy as an "authorization policy manager" when a user accesses a restricted URL.
  • Accommodating library walk-ins while still adhering to license agreements that restrict access to only those affiliated with the campus.
  • Maintaining equal status of all licensed resources whether or not the vendor is Shib-enabled (don't create a situation where a vendor receives more traffic as a by-product of being Shib-enabled)

Use cases in which Shibboleth adds something that isn't available with just EZproxy

  • Personalization at vendor site, save searches from one session to another without releasing personally identifying information to the vendor.
  • Using SFX: When instructors add protected resource links to websites, students cannot directly access those links without an extra step. With Shib, there would not be the extra step.
  • If EZproxy is set up as a Shib SP, there is SSO convenience with EZP and any other SP.
  • Providing location-independent access to resource with more fine-grained restrictions (access only for the law school, for example). With Shib, such add-on licenses are easier to implement.

Use cases declared out of scope at this point in the project:

  • A user goes directly to the vendor website
  • A user attempting to go from a Google search to a restricted resource

Use cases and groups/permissions

  • Increasingly, campuses with successful IdM programs have a way to manage groups, so that would not need to be replicated in EZproxy.
  • Library resource licenses typically will not provide access to alumni or applicants, so privileges need to be managed through the IdM system. If a campus IdM is able to authenticate each user and provide their affiliations, EZproxy would "know" whether to allow access to a resource.

There was a suggestion of three tiers for use cases involving groups.

  • Tier 1 involves a license that allows access for faculty, students and staff
  • Tier 2 might include a persistent ID attribute for personalization
  • Tier 3 involves restricting access based on course information, perhaps involving a campus-based course reserve system

*Next Steps*

There was a consensus that the working group is large enough to form three subgroups that would work in parallel, bringing back discussion points and progress to the calls.

After discussion, three subgroups were proposed. (AI) Dean will send an overview of each subgroup to the email list, asking people to sign-up for one, and asking for volunteers to lead each.

Use Case Subgroup - Develop a comprehensive list of use cases related to accessing information vendors from a variety of starting points, group them as appropriate and prioritize them.

Vendor Subgroup - Develop a prioritized list of information providers (e.g. JSTOR, Science Direct, etc) that the group would like to have support Shibboleth-enabled
access. Determine which vendors already support Shibboleth. Identify the top priorities for making the business case to support Shib. Include information about which vendors are already associated with InCommon.

Walk-in Patron Subgroup - Develop the use cases for walk-in patrons that may or may not have university credentials. Examples include the case in which a vendor contract allows use by a walk-up patron, and the case in which use is restricted to those affiliated with the university. Identify the more popular approaches that campuses use for allowing
access (e.g. GUEST login IDs, etc.).

(AI) Dean will set up wiki space for the subgroups and provide information on accessing and editing the wiki.

Other areas of interest - these were discussed, but included in the subgroup list:

  • accommodating alumni access
  • what authorization is required for electronic reserves?
  • which attributes vendors require
  • working with NISO group on standards for vendor user interfaces. Adam Chandler suggested queuing issues related to this and sending them to NISO. Example, the need for Shibbolized vendors to support session initiators
  • In the list of Shib-enabled resources, include "how-to" for each vendor.

Information from the chat session:

From Jim Green, Michigan State: Static navigation pages are labor intensive. Our library has expressed some consternation at the prospect of having to redo them to support a hybrid Shib/EZProxy access to resources.

There is a need for more fine-grained access control. Penn State has resource that medical students can access, for example, but not the general population. They also have a case with EBSCO and Ovid in which different subsets of users have access to different sets of resources. For example, medical students have access to one set of resources and another subset of students has access to another.

There is a need for best practices in setting up EZproxy and Shibboleth. A start may be documenting existing practices at institutions using both. This related to how fine-grained the IdP should be built.

*Next Call: Friday, April 17, 1:00 p.m. EDT*

  • No labels