Subgroup Charge:

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.

Next meeting time and information

• Time: Noon EDT (30 minute meeting prior to full group)
• Dates: July 17
• Dial-in numbers:
  • +1-866-411-0013 (toll free US/Canada Only)
  • +1-734-615-7474
  • PIN: 0136010#

Subgroup Members

Thomas Howell (Northwestern U) -- Chair
Andy Dale (OCLC)
Lynn Garrison (Penn State)
Paul Hill (MIT)
Barry Johnson (Clemson)
John Kiser (U of Penn)
Tim Mori (NC State)
Tod Olson (U of Chicago)
Heather Tones White (U of Saskatchewan)
Rich Wenger (MIT)

Additional Wiki Pages

• Meeting Notes
• Jabber Conversations
• Useful E-mails

Models :

   Models: Each model below organizes a series of use cases with commonalities in the technological implementation and has several related use cases of both the basic and advanced category. Specific vendor situations may be separately categorized as a model when approriate. Otherwise most use cases list the vendors of the software that are assumed to have an impact.

   Basic Use Cases: This type of use case is most likely to be implemented by almost all institutions (libraries). A cookbook for how to go about implementing each of these use cases is intended to be created.

   Advanced Cases: This type of use case is implemented by more then one institution but includes complex variations on a basic use case. Cookbooks may be developed for some of these use cases and then used as a starting point to extrapolate to other similarly complex use cases.

• Models for Use Cases - Template
• Shibbolized EZproxy (need to review the following two cases and put into template)
• Refworks Model

(The following use cases will be edited and moved into the list of above based on the Models for Use Cases Template.)

• Internet2 Wiki - This is the simplest use case and is a useful case needed by anyone who wishes permission to edit these wiki pages.
• Direct to Vendor
• Seamless ILLiad
• ER Librarian Workflow
• ER Librarian Workflow v2
• Ares
• On phone or In person user verification
• User goes to external service (abstracts), does a search, finds a useful openlink hit, goes back to campus, goes directly to the referenced article. Do this from home to a Shibb enabled resource.

• Walk In
• Institution hosts an IdP in addition to the Primary Institutions IdP
• User not in primary authentication source
• PDS Ex Libris PDS (patron directory service) module for support of many of their products.
• Circe Dynex: Shibb enabling java app.
• Shibb enable staff user access in addition to patron users
• Instructor wants to add a deeplink to a course in an LMS system and we want the link to work no matter where the user happens to be. The link has to be durable from year to year.
• Blackboard
• An instructor chooses a list of books in the OPAC and then wants them to be automatically pushed into the eShelf of students so that they can view them while inside the LMS.
• Federated Search which returns results that a user is allowed to view.
• Federated Search which returns results that are based on facets related to a group (or other shibb attribute)
• Refworks
• Two seperate federations accessing the same SP
• Two seperate shibb enabled IDs, ie. I have campus credentials and I also have an account with the ALA or ACM
• How to link two identies?

Category 3: Singular Cases

This type of use case is generally so specialized that it is only implemented by a single institution.

• Singular Use Case Template
• Replacing existing Java applications which store user password tables in the clear (either DB or in file on the file system)

Use cases useful notes and links:

• link to Pacman Project Use case examples

User Types (User Profiles) -

• Admin
• LDAP defined
• Local file defined

Attribute Sets (there are four general sets that we have identified)-

• Single attribute - the user is identified by the IdP as an authenticated member of the institution
• Minimum recommended - the user is identified by the IdP as an authenticated member of the institution plus several commonly used attributes are transmitted to the SP.
• Optional attributes - these are those additional attributes that extend the minimum recommended set for added usability

• Recommended "do not use" list of attributes - these are those attributes which can be provided but aren't in a best practices environment \[for example users social security number (ssn)\]

License issues -

• It is suggested that institutions work together as a group with vendors to attempt to modify language in contracts which supports the outdated IP authentication model and supports a move towards user defined group models.

  ---

Abstracted Library Authentication and Authorization Models -

• We have mediating authentication/authorization application
• We have individual staff/back office access versus individual user/client/patron access
• Differentiated experiences for two groups of users because their grouping information/attributes have been exposed.
• Non-differentiated experiences for two groups because their grouping information/attributes have been hidden.

  ---

Questions:

• primary and tertiary sets of attributes, uApprove (developed by the Swiss federation), how does a users know which sites should be properly accessable to their Shibb account?, how does a user know the state of their various cookies as associated with their ID?