InC-Lib-Vendor

[Mark Montague <>]

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