InCommon Library Services

At 10:15 AM -0400 4/3/09, John M. Kiser wrote:
> In other words, what's unclear to me, and what I want to remain mindful
> of, is 1) how vendors participating in InCommon go about implementing
> "Shib enabled"; and 2) where are there possibilities for this group to
> inform vendors' efforts to realize the promise of federated SSO.
> Ideally, Shib could move into place with a minimum of change in how
> researchers get what they need.

re this specific question, I think a NISO working group ( 
http://www.niso.org/news/events/2009/authentication09/ ; click on 
Additional resources, and then look at "A Proposed NISO Work Item ") 
is working on the "consistent interface at the vendor" issue. Adam 
Chandler from Cornell is a member of both this group and the NISO 
group -- and has generously volunteered to serve as a conduit between 
the groups.

> Apologies for the lengthy, possibly irrelevant reply :) ... spending
> time thinking about use cases raised a lot of questions for me.

I think you're right on target. One of the hardest aspects of the 
problem we're attacking is that users have multiple paths to a 
resource, and we're trying to minimize their pain across all of those 
paths. We're trying to provide a consistent experience from multiple 
starting points, and long multiple dynamic paths.

thinking about use cases..... even the basic use cause is starting to 
look to me to be a multi-dimensional matrix....

-- access by on-campus users, off-campus users

-- access to IP controlled sites, to Shib controlled sites

-- various user starting points (local library maintained static Nav 
page, some sort of local search service (eg MetaLib, serials 
solutions, etc) , direct to vendor, start at google and get a url 
pointing at a vendor, or into a vendor, or into an eBook, , Guelph 
scenario --

At 1:45 PM -0400 3/31/09, Kent Percival wrote:
> Date: Tue, 31 Mar 2009 13:45:35 -0400 (EDT)
> From: Kent Percival <>
> Subject: RE: [inc-librsvcs] InC-Library Notes - 20-Mar-2009 - Conference Call

-- search starts with an abstract service (eg PubMed, click an 
OpenURL button, redirect to campus link resolver, redirect to loal 
EZP server, redirect with deep link to the licensed content provider 
(actually, during Phase 1 David Kennedy demonstrated a solution to 
this that works very nicely!)
-- users in multiple local authN systems and attribute sources

-- the need for "persistent url's (for instructors to add to LMS pages)