InC-Lib-Vendor

["Kent Percival" <>]

I guess it all depends on our understanding of timeframe.

·         I agree IdP SSO should be removed because there is a more definite timeline deprecating that features as we move to SAML 2 compliance.

·         I’m not so clear on the roadmap for needing something better than common-lib-terms.

o   How many of the larger institutions already do contracts targeting only some internal units?

o   Given the option, how many institutions would want to arrange contracts with these targeted units?  In Canada, I’ve already talked to people at 3 universities who understand this may be a needed option to deal with the budget crunch, though there is great concern about “academic accessibility”.

o   From my scribbles, I understand that OCLC was looking a alternative for deployment in their new platform.  i.e. the vendors are looking at it so should we provide some leadership to promote a common approach?

That said, I agree the for the shorter term purpose of momentum building, the current “convention” is the appropriate one to state in the Best Practice document.  Let’s not lose the opportunity to influence next steps with the vendor community.

 

....Kent

 _

 

 

> -----Original Message-----

> From: Andy Ingham [mailto:]

> Sent: November 18, 2009 13:22

> To: David Kennedy

> Cc: Kent Percival; 'inc-lib-vendor'

> Subject: Re: [InC-Lib-Vendor] [Fwd: [confluence] Confluence Changes in the last 24 hours]

>

> I'm with you Dave. I think the common-lib-terms is about as good as

> we're going to get near-term.  My sense is that there is momentum

> building to put all the pieces together at a number of institutions

> nationwide, and having something that is clear, feasible, and workable

> (from both the vendor and institution ends) is critical to riding that

> momentum.

>

> I was not aware of the IdP SSO issues, so I'm all for removing it from

> the best practices.  Unlike the common-lib-terms concerns, it is a

> definite in terms of deprecation and so would be best not to encourage.

>

> Andy

>

> David Kennedy wrote:

> > Kent,

> >

> > These are really good points

> >

> > There is one point that I am not sure I am fully in alignment with you and

> > Scott on.  It seems to me from our vendor conversations that

> > eduPersonEntitlement, while problematic in implementation maybe, still is

> > a laudable goal.  To me, it seems that it provides a concrete way for

> > vendors and libraries to meet in the middle on how to implement a standard

> > contract for an institution.  I think there is a good point that we

> > provide no guidance for cases where contracts that live within

> > organizational boundaries.  I am not sure what guidance can be provided

> > along those lines though.

> >

> > Based on your thoughts on transition and Scott's comments on the IDP urls,

> > should we even be including them in a best practices document if they will

> > be obsolete in a relatively short timeframe compared to the timeline for

> > vendors to incorporate into their platforms?  If we are gearing these best

> > practices towards new InCommon members, maybe we should remove the IdP SSO

> > option.  Or at least indicate that it is SAML1.1 specific,

> > Shibboleth-specific, and may be deprecated in the near future.

> >

> > Dave

> >

> > -----

> > David Kennedy

> > Application Developer

> > Perkins Library, Duke University

> > (919) 613-6831

> >

> >

> >

> >

> > From:

> > "Kent Percival" <>

> > To:

> > "'inc-lib-vendor'" <>

> > Date:

> > 11/18/2009 10:39 AM

> > Subject:

> > RE: [InC-Lib-Vendor] [Fwd: [confluence] Confluence Changes in the last 24

> > hours]

> >

> >

> >

> > Scott makes some interesting and useful points to guide our development.

> > 1.      I think it was clear from our vendor discussions that

> > common-lib-terms is more of a problem than a solution, at least in the

> > long run and not being used by some..  Should we  revise the “strongly

> > recommend” downward and add something that suggests the convention is

> > changing.

> > 2.      As Scott notes some of our examples include Shib1.x-only

> > functionality.  With Shib 1.x being EOL’d next summer and InCommon

> > recommending new implementations be Shib 2 (SAML 2.0) compliant, we will

> > be in a transition period for some time.  A couple things to clarify ..

> > a.       Where are the leading vendors at?  What’s the roadmap?   BTW I

> > just had a conversation with a big LMS vendor who are talking about

> > implementing Shib in a new platform using Sun Open SSO which is “pure SAML

> > 2.0” and does not play with Shib 1.3 sites!

> > b.      Do we need to further clarify the audience for our best practices

> > documents.  Or universities with an existing Shib 1.3 deployment, and for

> > c.       Should we also develop a Best Practise for newer vendor

> > participants focusing on best SAML 2.0 design?  - would that have

> > implications on the client (IdP) side?   Perhaps, we could find out a bit

> > more from the JISC planning team who are looking at Shib 1.3 – Shib 2.0

> > transition too.

> > The current Best Practice document serves some immediate needs and speaks

> > to current implementations.  The best way to deal with transition issues

> > may be to leave our document as is and develop a Roadmap document to

> > describe a common understanding of what the next few transition steps are,

> > as we currently see them.  The roadmap would also help us understand who

> > the players are in these processes.

> > ·         Transition from Shib 1.3 to SAML 2.0 compliance

> > ·         Replacement/improvement (and international standardization) of

> > eduPersonEntitlement for entitlement assertion to library vendors

> > ·         Standardization of the “SessionInitiator” URL format for deep

> > linking to resources.

> > ·          … ??

> >

> > BTW, Norman Wiseman, Head of Services and Outreach, JISC, presented

> > Lessons from the United Kingdom's Experience with Federated Access

> > Management (click for video/slides of session) at EDUCAUSE 2009.   One of

> > the things he talks about is that JISC is concerned about the shortcomings

> > of eduPerson and that they are planning to revise it.  In a conversation

> > afterwards, limitations of “entitlement” assertion was one of the issues

> > they want to address.  Norman talked about doing this revision with REFeds

> > so that it is internationally recognized and adopted by multinational

> > vendors.

> >

> >

> > ....Kent

> >  _

> >

> >

> >> -----Original Message-----

> >> From: Andy Ingham [mailto:]

> >> Sent: November 18, 2009 09:19

> >> To: inc-lib-vendor

> >> Subject: [InC-Lib-Vendor] [Fwd: [confluence] Confluence Changes in the

> > last 24 hours]

> >> For those who aren't signed up to receive notices from the InCommon wiki

> >> upon updates there, note that we have our first "comment" on the Best

> >> Practices doc:

> >>

> >> See BOTTOM of:

> >>

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

> >>

> >> Andy

> >>

> >

> >

> >

Attachment: smime.p7s
Description: S/MIME cryptographic signature