Skip to Content.
Sympa Menu

inc-lib-vendor - RE: [InC-Lib-Vendor] Change to our BestPractices needed?

Subject: InC-Lib-Vendor

List archive

RE: [InC-Lib-Vendor] Change to our BestPractices needed?


Chronological Thread 
  • 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




Archive powered by MHonArc 2.6.16.

Top of Page