inc-lib-vendor - RE: [InC-Lib-Vendor] Change to our BestPractices needed?
Subject: InC-Lib-Vendor
List archive
- From: "Kent Percival" <>
- To: "'inc-lib-vendor'" <>
- Subject: RE: [InC-Lib-Vendor] Change to our BestPractices needed?
- Date: Wed, 7 Apr 2010 17:17:37 -0400 (EDT)
Andy, I
hope your conclusion, " the community of libraries and publishers is
tipping the scales toward TargetedID" is a little hasty. I propose that
policies, such as identify privacy, are the responsibility of the institutional
owners of the Identity Management system, not with a central technology
interest group. SAML provides the opportunity to share identity information or
to restrict it depending on the institution’s relationship with a Provider. However,
I would agree that a general statement for any best practise document is a
minimalist approach … share only what is necessary. TargetedID provides the
persistency for “personalized” service without giving out much information – a very
good starting point. I
don’t know the US framework well but I react a bit about the level of control
in the UK federation! And it’s important to scope decisions related to policy.
Nicole Harris represents a Federation that grew out of the library community in
the UK. Their approach of limiting personal information sharing worked great
for that community but, according to some people in the UK research community,
JISC is throttling the use of the SAML federation for research because of its generic
policies on privacy. Researchers really do need to use personal information to
identify themselves in applications with higher security risks. I’m
also finding that some administrators in Canadian libraries do not share the
need for anonymity for some personalized services. They feel that they have a
solid contractual relationship with a company providing personalized services
and feel there is value in sharing (with user approval) basic identity
information such as email address for communication and even an id to
facilitate chargeback. For such applications, I would not want “the network” or
“the federation” imposing any restraints. Further Best Practise depends on
local cultural, organizational, and governance frameworks. Best practise in the
UK the US and Canada will all have their subtle differences, especially
concerning policy issues. Regarding
your question about the BP document, I still support the statement you quoted.
It identifies both alternatives and briefly compares them, identifying the
privacy risk. The decision of which to use is left to those developing the
relationship with the vendor. What could be added is that the vendor BP should
be to accept either identifier, based on the concerns of their customer. ....Kent _ > -----Original Message----- > From: Andy Ingham
[mailto:] > Sent: April 7, 2010 09:07 > To: inc-lib-vendor > Subject: [InC-Lib-Vendor] Change to
our BestPractices needed? > > Vendor subgroup -- > > A document from the NISO SSO group that Dave Kennedy
and I are on is > referenced in the forwarded message below. In that
document (which I > realize some of you won't be able to access) there
is the following > transcript of part of the discussion: > > " > Steve [Carmody]: ... We shouldencourage publishers
to > adopt support for Personalization via the
targetedID attribute. > > ... > > Nicole [Harris]: Publishers often ask for principal
name for > personalization when > they should use targetedID instead. Publishers
should not handle > personal data. We explain why targetedID is
preferred. Most are using > affiliation and targetedID. > " > > > > I thought it was interesting, given what we've
written into our best > practices document > (https://spaces.internet2.edu/display/inclibrary/Best+Practices
): > > "While the eduPersonEntitlement should be the
initial focus for making > Shibboleth Single Sign On feasible on a wide-spread
basis, it does not > provide the user specificity necessary for enhanced
services such a > personalization. > > For such personalization, we recommend use of either
the > eduPersonPrincipalName OR eduPersonTargetedID
attributes. In large > part, the decision point between these two choices
is weighing the > relative importance of privacy vs interoperability.
The former tends to > provide more human-friendly identification of an
individual (e.g, > VS. kl83HlsnblqYskgh72Kfqkl)
and therefore it > will likely be preferred for use across multiple
vendors / resources. > By identifying an individual in a more
human-readable way, however, > might elicit greater privacy concerns. In either
case, it is important > to realize that the identifier will still UNIQUELY
identify a given > individual." > > > We may want to think about altering what we've got
in the BestPractices > document based on this, as it sounds as if the
community of libraries > and publishers is tipping the scales toward
TargetedID. > > > Thoughts? > > > Andy > > > -------- Original Message -------- > Subject: [NISO sso] Groups - Notes from call
on March 19, 2010 > (FedPubRels.doc) uploaded > Date: 30 Mar 2010 05:23:51 -0700 > From: Heather Staines
<> > To: > > > > A new document has been submitted to the National
Information Standards > Organization: SSO Authentication document
repository. > Document: Notes from call on March 19, 2010
(FedPubRels.doc) > Workgroup: SSO Authentication > Folder: Publisher-Federation Issues > Submitter: Heather Staines > > Link: View Document Details > <http://www.niso.org/apps/org/workgroup/sso/document.php?document_id=3761> > Link: Download Latest Revision > <http://www.niso.org/apps/org/workgroup/sso/download.php/3761/latest/FedPubRels.doc> > > Document Description: > Notes from preliminary telephone call including
libraries, publishers, and > federations. |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
- Change to our BestPractices needed?, Andy Ingham, 04/07/2010
- RE: [InC-Lib-Vendor] Change to our BestPractices needed?, Kent Percival, 04/07/2010
- RE: [InC-Lib-Vendor] Change to our BestPractices needed?, Mark Williams (JISC), 04/08/2010
- RE: [InC-Lib-Vendor] Change to our BestPractices needed?, Kent Percival, 04/07/2010
Archive powered by MHonArc 2.6.16.