InC-Lib-Vendor

["Hamparian,Don" <>]

Hello Andy and all, 
During the call I agreed to get an inventory of symbols and authos (rights 
profiles) for UNC in order to give you a feel for the raw number to convert 
rights profiles to released attributes.

Including all locations of UNC we have 8 institutions (symbols) with First 
Search authos. Of those 8 institutions, 3 have one autho, 1 has two authos, 1 
has three authos, 2 have four authos, and 1 has five authos.

I don't know if this is typical for other  larger institutions but maybe this 
manageable. Essentially we would go through the exercise of hopefully 
eliminating authos that aren't needed and then determining what attributes 
would need to be released for each autho (rights profile).


Don Hamparian
Manager OCLC Grid Portfolio
OCLC

614.764.6017 (voice)
614.975.5750 (mobile)
IM, IP Phone (Skype) donhamp2
ICQ: 412-913-446
http://worldcat.org/devnet




> -----Original Message-----
> From: Andy Ingham []
> Sent: Thursday, October 15, 2009 2:44 PM
> To: David Kennedy
> Cc: Hamparian,Don; Dale,Andy; ;
> Zavar,Jason
> Subject: Re: [InC-Lib-Vendor] RE: InCommon Library Services / OCLC -
> conference call - 10/9 1PM ET
> 
> A thorny issue, indeed.
> 
> I would strongly second the notion that the negotiations be centered
> around the IdP releasing certain agreed-upon (standard) attributes
> about
> the user (e.g., nursing undergrad, to use Dave's example) RATHER than
> centered around setting entitlements at the IdP based upon a given set
> of criteria specific to the negotiations.
> 
> Not only does it strike me as the "appropriate" way, I am FAR more
> confident, on a pragmatic level, of my ability to convince the identity
> management staff here at UNC to release those sorts of attributes than
> to implement the processes to create, manage, and release entitlements
> that have very specific use and therefore limited value (in the larger
> context of the University).
> 
> I want to be very judicious with my requests and expectations for the
> campus's ID management staff, as they are very busy folks managing
> identities for tens of thousands of users for scores of applications.
> 
> Having said all this, I am not at all sure to what degree we presently
> HAVE attributes for things as specific as "nursing undergrad" set in
> the
> campus LDAP.  To me, though, that simply means we need to expect
> heading
> in that getting the "right" environment set up will take time and
> inclusive communications.  (Note to self:  try to find out WHO on my
> campus is even involved with negotiating contracts with resource
> vendors
> in the hopes that shifting technological requirements can be included
> in
> those negotiations ...)
> 
> Andy
> 
> Andy Ingham
> Assistant Head, Library Systems
> University Library
> UNC-Chapel Hill
> 919-962-1288
> 
> 
> David Kennedy wrote:
> > Don,
> >
> > It has been a busy week for me so far, sorry for the delay in
> response.
> >  I have been remiss in thanking you for the engaging conversation
> last
> > week.  Thank you.
> >
> > I have put notes from our conversation up on the group's wiki:
> >
> https://spaces.internet2.edu/display/inclibrary/Minutes+from+Vendor+sub
> group+call+10-9-09
> >
> >
> > Thank you for the update and especially in incorporating the best
> > practices into your future plans.
> >
> > Regarding the business problem that you note below and that we have
> > talked about, we did discuss in our call that the best practices
> > discussion regarding attribute usage was based on contracts defined
> for
> > common library terms.  And that the best practices gives us all an
> > opportunity to possibly rethink how we are doing things.  Although
> the
> > use case that you describe with Ohio State doesn't fit within the
> > assumed common library terms, I would like to indulge in some more
> > conversation, because this is certainly an interesting challenge.
> >
> > Although not a unique challenge, I think it is one that is shared
> > probably in particular by a lot of journals in fields of medicine or
> > law.  I wonder how these challenges are dealt with at the
> institutional
> > level as much as at the vendor level.  In your experience, have the
> > universities that you have set up multiple authos for been able to
> > distinguish the groups at their university?  And how (what methods)
> do
> > the users of these separate groups authenticate to your services?
> >
> > In thinking this through with Shib, I look at eduPerson, and wonder
> if
> > any combination of the standard attribute set can be used to define
> > these subsets of campus populations.  In some cases, probably yes,
> but
> > in others, probably no.
> >
> > I am not sure that I am getting to a point, except that Shibboleth,
> the
> > technology, seems to be a good fit for passing user attributes to a
> > service and allowing the service to make the authorization decision.
> >  Which is what we are talking about here, attribute-based
> authorization.
> >  With Shibboleth though, do you anticipate that an institution's IdP
> > administrator will be able to assign different entitlements to
> different
> > subsets of the campus population that correspond to their access to
> your
> > resources?  Or would it be appropriate for the identity provider to
> > provide attributes about the individual and the service to perform
> the
> > authorization logic based on the user's attributes?
> >
> > An example of this might be a resource that is restricted to nursing
> > students.  Ideally, I think the identity provider in a Shib scenario
> > would be presenting information about the user, such as the user's
> field
> > of study (nursing) and institutional affiliation (undergrad), without
> > needing to understand too much about the service that it is providing
> > the information to.  And then the service provider would be
> configured
> > with the logic that determines what resources a user is granted
> access
> > to based on their supplied attributes.
> >
> > Conceptually, I personally think this is a better model than asking
> the
> > identity provider to determine, based on its own internal logic, the
> > authorizations (or entitlements) for a particular resource or set of
> > resources with a service provider that a user should be granted.
> >
> > In taking this simple example and applying it to OCLC IDM structure,
> > could you conceive of allowing identity providers to release to you
> > arbitrary (well hopefully standard) sets of user attributes, and
> allow
> > for configurations or mappings of those attributes to authos for
> cases
> > that do not fit within the common library terms agreements?  I may be
> > oversimplifying the complexities, and this has already been thought
> > through to a different conclusion.  What do you think?
> >
> > Dave
> >
> > -----
> > David Kennedy
> > Application Developer
> > Perkins Library, Duke University
> > (919) 613-6831
> > 
> >
> >
> > From:       "Hamparian,Don" <>
> > To:         "David Kennedy" <>, "Zavar,Jason"
> > <>, "Dale,Andy" <>
> > Cc:         <>
> > Date:       10/12/2009 10:32 AM
> > Subject:    [InC-Lib-Vendor] RE: InCommon Library Services / OCLC -
> > conference call - 10/9 1PM ET
> >
> >
> > ---------------------------------------------------------------------
> ---
> >
> >
> >
> > Hello all, it was a good, engaging conversation. I think where we
> left
> > it was how we can resolve the business problem of resolving fine
> grained
> > rights access to institution’s content:
> >
> > Institution x has three ‘rights profiles’ for access to content owned
> or
> > hosted at OCLC.  Institution is defined as the Law Library Ohio State
> > University, for example.  There is an OCLC ‘symbol’ for this library.
> >  There are three content ‘rights profiles’ or ‘authos’ for this
> > institutions: law students, law school alumni, and undergrad
> students.
> >  Assuming a IdP at the university level, not at the law school level,
> > how do we represent this via incoming attributes?
> >
> > Regarding the best practices document, we have placed the WAYFless
> URL
> > support on the new content platform, and authenticated links to
> > resources on the new content platform on our enhancement list. No
> > guarantees yet but these look like good enhancements from my
> standpoint.
> >
> > I believe ‘authorization via eduPerson attributes’ is desirable but
> we
> > don’t have solution to the above stated business problem yet.
> >
> > Don
> >
> > *From:* David Kennedy [] *
> > Sent:* Thursday, October 08, 2009 10:06 AM*
> > To:* Hamparian,Don; Zavar,Jason; Dale,Andy*
> > Cc:* *
> > Subject:* InCommon Library Services / OCLC - conference call - 10/9
> 1PM ET
> >
> > Don,
> >
> > I have below a draft agenda for our conversation tomorrow.  Let me
> know
> > if there are any changes you would like.
> >
> > Notice that I have some pre-reading listed.  It would be helpful if
> you
> > have a chance to look at these documents.  Also, here is a link to
> our
> > wiki so that you know who we are: _
> > __https://spaces.internet2.edu/display/inclibrary/Vendor+Subgroup_
> >
> > Dave
> >
> > Call Details:
> > Friday, October 9, 2009 - 1PM EDT
> > 866-411-0013 (US & Canada)
> > 734-615-7474 (non-US/Canada)
> > Access code: 0122004#
> >
> > AGENDA
> >
> > Pre-reading: _
> > __https://spaces.internet2.edu/display/inclibrary/Best+Practices_ _
> >
> __https://spaces.internet2.edu/display/inclibrary/RegistryOfResources_
> >
> > Introductions
> >  - including brief overview of InCommon Library Services
> Collaboration
> >
> > OCLC - overview of Shibboleth implementation
> >  - usage of Shibboleth SP software (SessionInitiators?)
> >  - implementation of WAYFless URLs and direct links to resources
> >  - what has or hasn't worked
> >  - future plans
> >
> > Implementation-specific questions/comments
> >  - When using ezproxy, library can construct a link to go directly to
> > the database to start a search; the url looks like: _
> > __http://firstsearch.oclc.org/dbname=AGRICOLA_
> > When using oclc shib wayfless url, the dbname attribute is not
> > available, so the default db on first search is always defaulting to
> > worldcat
> >  - eduPersonEntitlement - OCLC requires customer specific string to
> be
> > coded in edupersonentitlement.  This implementation does not use the
> > 'standard' value of common-lib-terms.  Also, for some IdP
> > implementations, this value is also shared with other service
> providers.
> >  Can this be changed to use 'common-lib-terms'?
> >
> > Topics for discussion:
> >
> > Best Practices
> >  - are these feasible for resource providers
> >  - do these make sense
> >  - thoughts on how to go about making this best practice amongst
> > resource providers
> >
> > What role should InCommon or the InCommon Library Services
> Collaboration
> > play?
> >  - policy setters
> >  - documenters
> >  - testers
> >  - implementation documentation/assistance
> >
> > Is there a desire/need for standardization across federation members'
> > identity provider implementations that would simplify the process for
> > resource providers' configurations?
> >
> > What are we missing, especially things that you have learned from
> > dealing with other federations besides InCommon?
> >
> >
> >
> > -----
> > David Kennedy
> > Application Developer
> > Perkins Library, Duke University
> > (919) 613-6831
> > 
> >