* Peter Gietz peter.gietz@daasi.de [2019-03-19 15:46]:
I have a few comments here based on also reading between the lines:
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.
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.
I remember the old (v1) GEANT CoCo saying that contracts always overrule whatever the CoCo requires because they're more specific. (Last time I looked I didn't find language to that regardin in v2 but that doesn't mean that contracts between two parties won't prevail nonetheless.)
Since instiuttionally licensed resources will almost always be covered by contracts I don't see the significance of that announcement (as well). But of course getting the word out about the GEANT CoCo and maybe getting it validated in commercial contexts (licensed resources cost a lot of money which satisfies my ad.hoc criterion of "commercial context" here) can only be benefitial.
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.
Well, ignoring "anonymous" for now (as there's no use for that within federated identity management ever so could well be removed from any documents) there's a realization that pretty much everything today (under GRPD at least) will be considered personal data, incl. pseudonyms, and so the CoCo could still provide legal support for transferring and processing this.
But see the argument about contracts > code of conducts above.
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.
The idea of "targeted"/"pairwise"/SP-specific identifiers is good, but not the eduPersonTargetedID attribute itself, in 2019. eduPersonTargetedID is dead, or should long have been. https://wiki.univie.ac.at/display/federation/eduPersonTargetedID
1. It should never have been defined for use with SAML2 (according to some of the people involved), instead it should have been replaced with proper SAML2 persistent NameIDs once SAML2 defined those in 2005.
2. saml2int ("old") -- the best standard for interop we have -- has been reommending againt eduPersonTargetedID (and for proper persistent NameIDs, i.e., in the Subject elelement of the SAML2 Assertion) for many, many years now.
3. There's a case-folding issue both with "proper" persistent NameID and therefore equally with eduPersonTargetedID attributes that could cause information disclosure (one person seeing someone elses data at an SP, e.g. the history of the content they searched for!). We/You can't continue pretending this does not exist and on the other hand claim we are sooo concerned about privacy, even more so than the federations themselfs (cf. "talk to InCommon about privacy").
4. saml2int ("new") requires use of the replacement identifiers and is veryy clearly worded in this regard.
Short version: We all need to adopt and prompte pairwise-id and stop even mentioning the old eduPersonTargetedID attribute, except in some legacy/migration from old-to-current documents.
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's the simple reasoning: https://wiki.univie.ac.at/display/federation/Library+Services The common-lib-terms value for the eduPersonEntitlement attribute is static and the same for every SP and from every IDP. (No other entitlement is relevant for this discussion/sector.)
That alone creates massive scalability benefits for everyone, because IDPs do not have to tell the SP just what eduPersonScopedAffiliation attribute values they consider to be covered by the specific contract. (Unless the SP makes assumptions about how the IDP implemented eduPersonAffiliations every IDP will need to tell every SP just what affiliation values are to be considered authrorized.)
But the common-lib-terms entitlement (value) also has further scalability advantages: In SAML 2.0 Metadata (cf. eduID.at) you can list not only the RequestedAttribute' names (as is commonly done) but also the *values* a given SP requires. With sufficiently powerful software (e.g. the Shibboleth IDP) that means the attributes released by the IDP can be automatically filtered to the values provided in metadata, without manual intervention.
A single and static configuration rule in the IDP can tell the IDP to release the (non-PII) common-lib-terms value to any SP that says it needs it. *Nothing* *else* is required from the IDP if the SP supports his attribute (and can work without identifiers).
On the other hand affiliations are mostly (or exclusively) used in their "scoped" variant, and that prevents an SP from ever listing the expected attribute *values* in metadata, as the SP would have to list the acceptable affiliations mutiplied by the scopes of all their customers' scopes, i.e.: staff@univie.ac.at faculty@univie.ac.at student@univie.ac.at employee@univie.ac.at staff@jku.at faculty@jku.at student@jku.at faculty@mci.edu student@mci.edu etc.
Here is my hypothesis: entitlement means that the IdP side knows about the rights at the service.
[...]
This means that the complex algorithm, evaluating contracts to specify entitlements has to be implemented on the IdP side.
That's correct only in the fully abstract and ignoring the /one/ attribute *value* for the eduPersonEntitlement attribute that has been agreed for this use-case specifically (access to institutionally licensed resources). So I also only speak to that one entitlement *value*, not to using entitlements in general.
In fact looking at the eduID.at documentation (link below) you can see that an IDP can simply and automatically derive the common-lib-terms entitlement from an existing affiliation.
I.e., if an IDP can produce eduPerson(Scoped)Affiliation attributes -- which arguably are the main/only remaining value proposition of academic IDPs and so should be supported by any academic IDP on the planet -- then the IDP only needs to add one trivial rule that creates the common-lib-terms entitlement from a set of (locally decided) affiliations and be done with this. For *all* SPs that can support common-lib-terms entitlments.
Example from our documentation: "If the subject has the 'member' affiliation then give it the common-lib-terms entitlemen', too". https://wiki.univie.ac.at/display/federation/IDP+3+Attribute+resolution#IDP3... (That's the simplest possible case since 'member' is defined in eduPerson to include 'staff', 'faculty', 'employee' and 'student'. So all of these will also have 'member' and so all of these groups will get the common-lib-terms entitlement added.)
It's trivial to create on the IDP side and makes comparison and agreement much easier for everyone involved: IDPs (no guessing or per-SP-configuration overhead what affiliation values the SP wants), for federation operators (all e-resource services are handled the same way) and IDPs (one attribute with one static value means no more per-IDP configuration).
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.
Not yet achievable just from your decription, though: The IDP would also have to configure (via a self-service interface at the SP or via their request/ticket system or sales contact) *which* of their values should be allowed and which should not. Repeated for every SP they use. Repeated at every IDP that uses such SPs. And it's all completely avoidable!
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.
Obviously that's always the case (trusting that IDPs don't lie), same with affiliations or anything else. If an IDP lies that IDP risks getting thrown out of the federation and possibly worse (contract violations). In other words: My IDP might as well lie to just one SP using affiliations. How is anyone supposed to detect that?)
Thus my recommendations to libraries would be to rather agree to contracts based on affiliation than on entitlement.
For the reasons stated above (and on the wiki page I referenced) I think the opposite should be the case. ;)
Currently IDPs simply have to support both models because some SPs only support one or the other, increasing the effort slightly (both are trivially easy to support, but knowing when to use what is an overhead, of course). Within eduID.at I curate the metadata such that any SP that's known to support the common-lib-terms entitlement for authorization (either by default or on request) only has that attribute listed. I.e., those that play by the rules have it Just Work. Make those do extra steps that insist on doing it in less efficient ways.
Best regards, -peter