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: "Mark Williams (JISC)" <>
  • To: 'inc-lib-vendor' <>
  • Cc: Nicole HARRIS <>
  • Subject: RE: [InC-Lib-Vendor] Change to our BestPractices needed?
  • Date: Thu, 8 Apr 2010 10:57:22 +0100
  • Accept-language: en-US, en-GB
  • Acceptlanguage: en-US, en-GB

Hi all,

 

Couple of comments below from Nicole Harris from JISC outlining UK position re Targeted ID etc

 

Hope that helps

 

Mark

 

Mark Williams

JISC Collections

T - 02030066042

M - 07891601909

E -

Blog: http://access.jiscinvolve.org

 



The UK federation is actually completely agnostic about what attributes are passed, we simply make a series of recommendations.  One of these recommendations is that when passing attributes about individuals you must comply with the UK Data Protection Act and it is this law that is strangling our use of attributes rather than any policy created by the UK federation.  It is entirely restrictive, at best poorly understand and does not work well with the leaps in technology that have taken place since it was created. 

We also struggle as we do not as yet have a good mechanism for managing user consent and consent revocation in a manageable way.  This is something we are working hard on with institutions as we help them improve their identity management infrastructures.  Once we have this process embedded, it will be easier to justify exchange of personal data against the current Data Protection Act. 

If US and Canadian law allows more freedom for institutions passing personal data on to third parties about their staff and students I would encourage you all to embrace every opportunity as I am entirely in favour in richer use of attributes and totally agree that these create a richer experience.  However, it isn't for Canadian librarians to decide whether there is a need for anonymity - they need to examine what their data protection laws allow them to do and create the best experience based on those laws. 

At the moment within UK law we cannot justify that there is a specific need for publishers to have PrincipleName rather than the pseudonymous TargetedID without full and explicit user consent so we have to work with the second. 

I hope that helps. 

Best wishes

Nicole

 

 

From: Kent Percival [mailto:]
Sent: 07 April 2010 22:18
To: 'inc-lib-vendor'
Subject: RE: [InC-Lib-Vendor] Change to our BestPractices needed?

 

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.

 




Archive powered by MHonArc 2.6.16.

Top of Page