InCommon Library Services

[Dean Woodbeck <>]

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

**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**