InC-Lib-Vendor

[Foster Zhang <>]

Agreed! In most cases of the shibboleth wayfless url implementation, Information providers do not require eduPersonAffiliation or other details. Only EBSCO requires such info so far, and OCLC requires specific eduPersonEntitlement that only applies to OCLC applicaiton.

 

In the best practice doc, should we not only recommend to use standard string valuable, but also not encourage the use of eduPersonaffiliation or other additional attributes to grant access permission?  

 

For EBSCO, we had problems with a long list of possible values of affiliation and still miss some from JHU community, and for examples, retired professor with the affiliation type of retiree is eligible to use Ebsco, but not retired staff. It would be difficult to request university IDP to issue different eduPersonAffiliation. University should simply remove retired staff from valid user list, therefore there is no need to IP to monitor.

 

After a successful shibboleth authentication, user should be given access permission, it is university/library’s responsibility who is eligible to use the shib to login to the resource, not the IP to try to limit access by shib attributes returned from successful login session.

 

This is my opinion.

Foster

 

From: David Kennedy [mailto:]
Sent: Monday, August 31, 2009 13:27
To: Andy Ingham
Cc: ; Foster Zhang;
Subject: Re: [InC-Lib-Vendor] Agenda, Fri Aug 28, 1PM (note new PIN)

 

Andy,

This looks great.  I agree with you, this should either be #1 or by itself.  Probably it needs to stand on its own outside of a set of steps.

Dave

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

From:	Andy Ingham <>
To:	David Kennedy <>, , , Foster Zhang <>
Date:	08/31/2009 01:11 PM
Subject:	Re: [InC-Lib-Vendor] Agenda, Fri Aug 28, 1PM  (note new PIN)

 

---

Hi all --

I've finished the edits I intended to make to *step 4* of

https://spaces.internet2.edu/display/inclibrary/Best+Practices


Please let me know what you think?

I do have a concern about the "placement" of step 4 as step 4.  That is,
having attributes released to the vendors (SPs) is a critical (and
fundamental) part of Shibboleth working properly.  For this reason, I
don't think we should list it as the fourth "step" of a series of
building blocks.  Rather, it should either be removed from the ordered
list (and be off by itself) OR it should be listed as #1.  Thoughts?

Andy

Andy Ingham
Assistant Head, Library Systems
University Library
UNC-Chapel Hill
919-962-1288


Andy Ingham wrote:
> Hi everyone --
>
> Dave was unable to make the call today due to extenuating circumstances.
>  As of about 10 minutes after 1, we only had 3 people on the call and
> decided to cancel it.
>
> I will be continuing to work on section 4 of the Best Practices document
> and perhaps we can drum up some discussion via email about that page.
> (When I get to a good stopping place with it, I will send out a separate
> email about questions I have.)  As Dave mentioned before, we should try
> to have it pretty well crystallized by a week from today.
>
> As for the agenda for the NEXT call (TWO weeks from now on 9/11), it
> sounds like Dave has an idea of the general outline he's considering.
> Dave, perhaps the best next step is for you to jot that down and
> circulate it to this group via email sometime next week?
>
> Have a nice weekend everyone.
>
> Andy
>
> David Kennedy wrote:
>> Agenda for Vendor Subgroup
>>
>> Call details:
>> 1PM EDT
>> 866-411-0013 (US & Canada)
>> 734-615-7474 (non US/Canada)
>> PIN: 0122004
>>
>> Agenda items:
>>
>> ** Our next call will be on Sep 11, and JSTOR reps will be on the
>> call.  My desired outcome from today's call is that I would like to
>> share an agenda for the sep 11th call and our best practices doc with
>> JSTOR by next Friday. **
>>
>> 1 - Best Practices document
>>       - feedback on document as it stands now (still a work in progress)
>>      2 - Input on agenda for sep 11th call - I haven't written an
>> agenda yet for that call, but intend to base it on our notes from the
>> 7/10 conference call
>>
>>
>> Dave
>>
>> -----
>> David Kennedy
>> Application Developer
>> Perkins Library, Duke University
>> (919) 613-6831
>>