InC-Lib-Vendor

[David Kennedy <>]

forwarding this follow-up conversation with scott cantor on best practices 
that i mentioned in last call

i will be forwarding another follow-up as well

-----
David Kennedy
Application Developer
Perkins Library, Duke University
(919) 613-6831

----- Forwarded by David Kennedy/Libraries/Provost/Academic/Univ/Duke on 
12/01/2009 02:58 PM -----

From:
David Kennedy/Libraries/Provost/Academic/Univ/Duke
To:
"Scott Cantor" <>
Date:
11/20/2009 11:18 AM
Subject:
RE: comments on incommon best practices


Scott, I put some comments inline below.  Also is it ok with you for me to 
forward this communication back to the members of my group because you 
provide a lot of valuable perspective?
Thanks
Dave

> > You mention that the common-lib-terms doesn't solve real world 
problems,
> > at least not alone.  I understand and get the not alone piece and that 
it
> > doesn't speak at all to contracts that live within organizational
> > boundaries.  But, I wonder, in your opinion, if it does help the use 
case
> > where there is a single vanilla contract between a resource provider 
and a
> > university.  In my opinion, the common-lib-terms does at least give 
both
> > sides (vendor and institution) a standard means to meet in the middle.
> 
> I don't know that it accomplishes enough to justify the confusion it 
creates
> for the (seemingly common) exception cases. It isn't clear to me from 
the
> limited set of situations I've been asked about or involved with that 
the
> "single contract with no other relevant data" case is actually the 
common
> case. But even assuming that, there are simple solutions to the more
> advanced cases that "degenerate" into basically the same amount of work 
for
> the standard case without creating two separate approaches.
> 
> What I mean is that people continue to read *way* too much into this
> common-lib-terms entitlement, to the point that they act as though 
you're
> breaking some rule by not using it, and trying to bend every other case 
to
> match it.
> 
> I'm in favor of avoiding arguments about *what* the entitlement value 
should
> be and focusing on the *concept* of using entitlements to represent 
access
> under a contract. If there's one contract for everybody, then there's 
one
> value. If not, there's more than one.
> 
> But I think it's critical that SPs start investing effort. They need to 
step
> up and provide simple interfaces by which a campus simply fills in the
> entitlement value it wants to use for their contract(s). This is not 
hard.
> We're talking intern-level work here.
> 
> In return, you immediately get a solution that scales to many more cases 
and
> nobody argues about entitlement values. If the campus wants to reuse 
values
> across SPs, it's free to do that.
> 
> But it's a mistake for the SPs to hardcode this stuff, and to the extent
> that these proposals encourage that, I think they do as much harm as 
good.
> 

I agree with a lot of what you are saying here.  Especially about making 
authorization configurable at the service provider based on 
attributes/values that a campus can fill into a form.  Maybe some good 
examples of this are ThomsonReuters (
http://science.thomsonreuters.com/info/shibbolethsetup/) and EBSCO's admin 
interface (although I admittedly haven't looked at this interface in a 
while.)

I do hope that vendors will put in place solutions that are scalable and 
an entitlement value is not hard-coded into their authorization logic. But 
I think we have seen some examples of that happening, and I am thinking of 
JSTOR, who was an early adopter of some of this technology.

I do still feel that centering around a specific entitlement value as a 
'standard' helps to get implementation off the ground.  And in many cases, 
I think universities and resource providers are still at that stage of 
getting off the ground. 
I wonder if it would be helpful if the recommendations regarding attribute 
use included some verbage that discussed going beyond the "single 
authorization for a campus community" use case.  I know there is a need 
for this, although I don't know a clear simple path to put into a list of 
best practices.

I will discuss this with the rest of the vendor group.

> > Regarding contracts that live within organizational boundaries, are 
there
> > any hopes for being able to represent attributes in standard ways to
> > facilitate this?  Do you know anything about a revising of eduPerson, 
or
> > if this use case is supposed to be addressed by that effort?
> 
> I think it's a rathole that can be avoided for the most part by using
> entitlements more flexibly.
> 
> I'll give you a concrete example with WebAssign. They started out with 
just
> authentication, and Penn State wanted them to support auto-enrolling 
users
> into courses. They initially did that by parsing data out of the
> entitlements they got to try and map them to WebAssign sections. 
Obviously
> that approach is unworkable as soon as you start adding more customers, 
and
> if the customer already uses course entitlements without any semantic
> connection to WebAssign data.
> 
> I simply told them to drop the complexity and stick a form field on the
> section sheet for the instructor to populate with all the entitlement 
values
> to map to the section. That immediately decouples their data from our 
data
> and puts the control into the hands of the administrator (in this case
> faculty, in your cases, librarians) to do whatever they want.
> 

In my experience, there is a baseline here that may cause some limitations 
on the side of the insitution or identity provider, in terms of 
flexibility of entitlements.  Although the implementation may seem trivial 
(or may be trivial), I have experienced a lot of pushback and delay just 
to get eduPersonEntitlement: common-lib-terms implemented by my IDM 
office.  And I have heard similar experiences from other campuses that I 
am dealing with.

It helps me at Duke to have a standard starting point in common-lib-terms, 
even though I do absolutely agree with your forward-looking and flexible 
approach.  I think implementation needs baby steps in some cases.

> > Thank you for the note about IdP-side URLs.  I am not too familiar 
with
> > a lot of the technical aspects of Shibboleth and SAML and how they 
have
> > developed over the years.  Does the recommendation we make for Session
> > Initiators play well with other SAML-based authentication methods
> > besides Shib?
> 
> No, certainly not in a standard way.
> 
> -- Scott
> 
>