InC-Lib-Vendor

[David Kennedy <>]

forwarding a 2nd message from convo with scott cantor

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

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

From:
"Scott Cantor" <>
To:
"'David Kennedy'" <>
Date:
11/20/2009 01:08 PM
Subject:
RE: comments on incommon best practices



David Kennedy wrote on 2009-11-20:
> 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?

Sure.

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

Yes, we have, and we need to send a strong message that half-assing this 
is
not acceptable.
 
> 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.

That's why I think we need a better starting point. When you 
over-simplify,
you box people in. Developers these days implement what you tell them to
without any thought about design. It's critical that the solution you 
start
with have some flexibility or you never get there.

> 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 think there needs to more material at least explaining *how* to 
implement
properly, rather than just on the "what".

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

Sure, but if the IdP is screwed up, so be it; at least the SP needs to be
able to support a sound design.

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

Those are red flags that really have to be kept separate from best 
practice
discussions, though.
 
-- Scott