Hi again,
yes I also came across this and it is IMO in general a Good
Thing. It seems to me that the RA21 people also learned from the
Berlin meeting.
I have a few comments here based on also reading between the lines:
Basically "RA21 endorses Coco" only says "RA21 endorses GDPR" which in Europe has not a lot more meaning than "we want to follow the law". But outside of Europe, especially in the US this is of course significant.Earlier this year (2019), the RA21 Security & Privacy group endorsed the GEANT Data Protection Code of Conduct as guidance that RA21 should follow: data minimization, purpose limitation, data retention, and more.
Having worked on Attribute release to research infrastructures, I
know Coco was used to promote attribute release. The general idea
was that SPs that support Coco and show this by marking the SP
with the respective entity category, generally get more data from
the IdP that can configure special attribute release rules for all
SPs supporting Coco.
This is more or less the opposite of:
unless the Service Provider (such as a publisher or other content vendor) has a specific agreement with an Identity Provider (IdP - usually an individual’s institution) to receive additional data the IdP should only send anonymous and pseudonymous identifiers to the Service Provider.
One more point to discuss:
Specifically, the service provider should only ask for eduPersonEntitlement and, optionally, a pseudonymous pairwise user identifier (e.g., eduPersonTargetedID)
eduPersonTargetedID is a very good choice since it does not allow for user tracking beyond one SP, since every SP gets a different ID for the same user.
But there are other Attributes in use in addition or in stead of the second attribute mentioned, eduPersonEntitlement, namely eduPersonScopedAffiliation. So why does RA21 recommend entitlement? Here is my hypothesis:
entitlement means that the IdP side knows about the rights at the service. The spec (https://wiki.refeds.org/pages/viewpage.action?pageId=38895708#eduPerson(201602)-eduPersonEntitlement) is quite clear here:
URI (either URN or URL) that indicates a set of rights to specific resources. [..]
A simple example would be a URL for a contract with a licensed resource provider.
This means that the complex algorithm, evaluating contracts to specify entitlements has to be implemented on the IdP side.
eduPersonAffiliation is defined as follows:
Specifies the person's affiliation within a particular security domain in broad categories such as student, faculty, staff, alum, etc. [...]and the example is also quite telling:
eduPersonScopedAffiliation: faculty@cs.berkeley.edu
This means: this user is member of the faculty of the Computer
Science Division at UC Berkeley.
The IdP can quite easily release the affiliation (IdPs generally know what relation exists between the user and the institution, and to which subdomain a user belongs). If this attribute is sent to publishers, the computing and comparing with the contracts is on the SP side.
If publishers require entitlement it means IMO that they trust
the institutions to tell the truth and that they want less work on
their own side.
Software creation or modification is a cost and with entitlements the costs are on the libraries, with affiliation they are on the publishers.
Thus my recommendations to libraries would be to rather agree to
contracts based on affiliation than on entitlement.
As I said pure hypothesis and thus just my 2 cent.
Cheers,
Peter
FYI ---------- Forwarded message --------- From: Julia Wallace <julia@ra21.org> Date: Fri, Mar 15, 2019 at 10:05 AM Subject: RA21 Adopts GEANT Data Protection Code of Conduct Privacy Matters! The RA21 project is pleased to announce its endorsement of the GEANT Data Protection Code of Conduct. Earlier this year (2019), the RA21 Security & Privacy group endorsed the GEANT Data Protection Code of Conduct as guidance that RA21 should follow: data minimization, purpose limitation, data retention, and more. What does data minimization mean in an RA21 context, where users are trying to access scholarly information resources, particularly in an academic setting? It means that unless the Service Provider (such as a publisher or other content vendor) has a specific agreement with an Identity Provider (IdP - usually an individual’s institution) to receive additional data the IdP should only send anonymous and pseudonymous identifiers to the Service Provider. Specifically, the service provider should only ask for eduPersonEntitlement and, optionally, a pseudonymous pairwise user identifier (e.g., eduPersonTargetedID). In the case that the IdP sends more attributes than those one or two requested by the Service Provider, the Service Provider must not collect or store that data under any circumstance. The endorsement of the GEANT Data Protection Code of Conduct and the specifics around what attributes may be requested feeds directly into the upcoming NISO Recommended Practices for Improved Access to Institutional Information Resources, expected to go out for public comment in the next few weeks. Expect another announcement from us as soon as that comment period opens. _______________________________________________ Fim4l mailing list Fim4l@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
-- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz