InC-Lib-Vendor

[David Kennedy <>]

A reminder below about our phone call tomorrow. 

Friday, February 5th
1 p.m. EDT / Noon CDT / 10 a.m. PDT
Access code: 0122004#
To join the call, dial +1-734-615-7474 (use if you don't pay for long distance
- preferred)
1--866-411-0013 (toll free US/Canada Only) 

Topic for discussion:
University of Michigan use case and
defining associated best practice

Background on the topic:
https://lists.incommonfederation.org/wws/arc/inc-lib-vendor/2009-12/msg00012.html


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

From:	David Kennedy/Libraries/Provost/Academic/Univ/Duke
To:	Mark Montague <>
Cc:	, ,
Date:	01/07/2010 05:53 PM
Subject:	Re: [InC-Lib-Vendor] InC-Library Best Practices question

---

Mark,

Let's do February 5th 1PM ET.  I
will send out connection information for the call closer to the date.

Dave

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

From:	Mark Montague <>
To:	David Kennedy <>
Cc:	, ,
Date:	01/05/2010 04:27 PM
Subject:	Re: [InC-Lib-Vendor] InC-Library Best Practices question

---

Hi, David,

Sorry for the delay in getting back with you -- we've checked with 
everyone here and either February 5th or February 12th at 1pm ET would
work great for us.  (We could also probably do January 22nd if that
day 
becomes better for you).  Please let us know how you would like to
proceed.

Thanks again for your help on this!

                 Mark Montague
                 ITS Web/Database
Team
                 The University
of Michigan
                 



On December 22, 2009 10:15 , David Kennedy <>
wrote:
> 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
>>                  
>>
>>
>>
>>
>>
>>
>>
>>
>>      
>
>
>
>
>
>