InC-Lib-Vendor

[David Kennedy <>]

We have calls on Jan 22nd, Feb 5th, and Feb 12th, calls scheduled for 1PM 
ET.  My preference is either of the February dates.  Let me know if any of 
these dates work for you.

Dave

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




From:
Mark Montague <>
To:
David Kennedy <>
Cc:
, 
Date:
12/22/2009 10:01 AM
Subject:
Re: [InC-Lib-Vendor] InC-Library Best Practices question




Hi, David,

That would be great; we'd very much like that.  Let us know the day and 
time of the call and we'll let you know who we'll have call in -- it may 
not be me, as I'm a pointy-haired manager type.  The most likely 
candidates would be our technical lead for Shibboleth, plus possibly 
someone from our library's IT department.

Thanks for your help on this!


Mark Montague
ITS Web/Database Team




On December 22, 2009 09:54 , David Kennedy <> wrote:
> Hi Mark,
>
> We discussed your email in our last conference call.  We would like to
> help.  Over the last few months, we have had dialog with a lot of the
> vendors regarding Shibboleth, their implementations, and best practices.
> We are thinking that it would be a good idea to invite a number of 
vendors
> into a discussion on the topic, because we don't think there is an 
obvious
> solution that is "best".  Since many of these vendors have long change
> management cycles, we'd like to invite them into the process early.
>
> Would you be willing to join one of our calls in the next month or two 
to
> discuss with us?
>
> Thanks
> Dave
>
> -----
> David Kennedy
> Application Developer
> Perkins Library, Duke University
> (919) 613-6831
> 
>
>
>
> From:
> Mark Montague<>
> To:
> 
> Cc:
> shibboleth<>, ""
> <>
> Date:
> 12/15/2009 03:24 PM
> Subject:
> [InC-Lib-Vendor] InC-Library Best Practices question
>
>
>
>
> Dear members of the InCommon Library Collaboration Vendor Subgroup,
>
> First, thank you for drafting the Best Practices document for library
> resource providers and libraries; we have found it very helpful.
>
> We also have a question that we'd like your opinion on, and, if you feel
> it to be appropriate, to add to the Best Practices document:
>
> When a single institution has multiple campuses, each with a different
> license from a single library resource provider, but where each campus
> shares a single IdP, user directory, and authentication infrastructure,
> what is the best practice for the IdP communicating a user's campus
> affiliation with the library resource provider?  Note that a single
> individual may be affiliated with multiple campuses.
>
>
> We've asked this question on the  mailing
> list and included additional background information:
>
> 
https://mail.internet2.edu/wws/arc/shibboleth-users/2009-11/msg00003.html
>
>
> For a complete threaded list of replies, see "multi-campus IdPs /
> identifying campus/branch to an SP" at
>
> https://mail.internet2.edu/wws/arc/shibboleth-users/2009-11/thrd1.html
>
>
> The reason we're addressing this question to you is because in his first
> reply to us, Scott Cantor says:
>
> 
>> The "organizational ID" problem is coming up
>> repeatedly in a lot of use cases, but there's no consensus.
>> 
> We hope you can recommend a best practice in this area.
>
>
> Options that we can easily accommodate include any of the following:
>
> - asserting entitlements, in addition to common-lib-terms, to represent
> which campus license(s) should apply.
>
> - providing eduPersonScopedAffiliation to indicate campus affiliation.
>
> - providing the "locality" attribute from the eduOrg schema to indicate
> campus affiliation.
>
> - providing a special attribute specific to the University of Michigan
> to indicate campus affiliation, e.g., "umichCampus" (although this is
> obviously a poor choice for a solution).
>
>
>
> Options that are not good for us include:
>
> - setting up a separate IdP for each campus (this is very expensive, and
> would also be confusing to users who were affiliated with more than one
> campus; and it does not make sense as all campuses share common
> directory and authentication infrastructures).
>
> - providing the "ou" (organizational unit) attribute from our directory;
> our "ou"s are based on department affiliation and role, and are not, in
> general, reliable indicators of campus affiliation.  And restructuring
> all of our directory "ou"s for a resource provider is not feasible.
>
>
>
> The library resource provider in question can only support multiple IdPs
> or the "ou" attribute at the current time.  They are very reluctant to
> change any of their code, but they say:
>
> 
>> we'd prefer any development work we do to be to an
>> agreed standard, rather than implement anything one-off.
>> 
> We're hoping that, with clarification from you, we can present the
> library resource provider with a compelling case for modifying their
> code to support one of the options in the first list, above.
>
> Thanks in advance for any guidance or assistance you can provide.
>
>                  Mark Montague
>                  ITS Web/Database Team
>                  The University of Michigan
>                  
>
>
>
>
>
>
>
>