Skip to Content.
Sympa Menu

inc-lib-vendor - RE: [InC-Lib-Vendor] [Fwd: [confluence] Confluence Changes in the last 24 hours]

Subject: InC-Lib-Vendor

List archive

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


Chronological Thread 
  • From: David Kennedy <>
  • To: "Kent Percival" <>
  • Cc: "'inc-lib-vendor'" <>
  • Subject: RE: [InC-Lib-Vendor] [Fwd: [confluence] Confluence Changes in the last 24 hours]
  • Date: Wed, 18 Nov 2009 11:43:33 -0500

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






Archive powered by MHonArc 2.6.16.

Top of Page