InC-Lib-Vendor

[David Kennedy <>]

Don,

I have below a draft agenda for our
conversation tomorrow.  Let me know if there are any changes you would
like.  

Notice that I have some pre-reading
listed.  It would be helpful if you have a chance to look at these
documents.  Also, here is a link to our wiki so that you know who
we are:
https://spaces.internet2.edu/display/inclibrary/Vendor+Subgroup

Dave

Call Details: 
Friday, October 9, 2009 - 1PM EDT 
866-411-0013 (US & Canada) 
734-615-7474 (non-US/Canada) 
Access code: 0122004# 

AGENDA 

Pre-reading: 
https://spaces.internet2.edu/display/inclibrary/Best+Practices
https://spaces.internet2.edu/display/inclibrary/RegistryOfResources

Introductions 
  - including brief overview of InCommon Library Services Collaboration

OCLC - overview of Shibboleth implementation 
  - usage of Shibboleth SP software (SessionInitiators?)
  - implementation of WAYFless URLs and direct links to resources
  - what has or hasn't worked 
  - future plans

Implementation-specific questions/comments
  - When using ezproxy, library
can construct a link to go directly to the database to start a search;
the url looks like:
http://firstsearch.oclc.org/dbname=AGRICOLA
When using oclc shib wayfless url, the
dbname attribute is not available, so the default db on first search is
always defaulting to worldcat
  - eduPersonEntitlement - OCLC
requires customer specific string to be coded in edupersonentitlement.
 This implementation does not use the 'standard' value of common-lib-terms.
 Also, for some IdP implementations, this value is also shared with
other service providers.  Can this be changed to use 'common-lib-terms'?

Topics for discussion: 

Best Practices 
  - are these feasible for resource providers
  - do these make sense 
  - thoughts on how to go about making this best practice amongst
resource providers 

What role should InCommon or the InCommon Library Services Collaboration
play? 
  - policy setters 
  - documenters 
  - testers 
  - implementation documentation/assistance 

Is there a desire/need for standardization across federation members' identity
provider implementations that would simplify the process for resource providers'
configurations? 

What are we missing, especially things that you have learned from dealing
with other federations besides InCommon? 



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