Fwd: RA21 Adopts GEANT Data Protection Code of Conduct
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.
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:
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.
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(2016...) 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 mailto: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
Am 15.03.2019 um 10:37 schrieb Jiri Pavlik:
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 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
Hi Peter S.
This is getting a bit stressful...
Yes I know about entitlement common-lib-terms, and that it specially designed for libraries, and thanks for mentioning it, which I forgot, but I am not sure whether that will be the only entitlement that contracts will be based upon in the future. FIM will allow for more precise definition of users, which will make licenses cheaper for libraries. I may be wrong here, but I'd rather be corrected by librarians actually signing contracts.
Yes its is good to have such an technical expert like you in this list, but please be aware that we have to also tackle non-technical issues here. And please be also aware that some people subscribed to this list are rather non-technical. It is ok to correct things, and I very much appreciate this, but we should not get too much into technical details. There are more appropriate lists for that.
Yes we have new alternatives than targetedID, but I fear that attribute is still common practice and we should IMO name both targetedID and pairwise subjectID. Especially when RA21 only named targetedID. We are talking about a community that is rather slow in adapting new technologies and we cannot expect very current state of the art in software and in software configuration.
Cheers,
Peter G.
Am 19.03.2019 um 16:52 schrieb Peter Schober:
- 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
- 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.
- 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.
- 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").
- 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 _______________________________________________ Fim4l mailing list Fim4l@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Hi,
do you handle multiple contracts in Austria, Peter? University subscribes different content sets for different user groups with a provider.
Thanks a lot for all comments, both Peters 😊
Cheers
Jiri
On Wed, 20 Mar 2019 at 19:06, Peter Gietz peter.gietz@daasi.de wrote:
Hi Peter S.
This is getting a bit stressful...
Yes I know about entitlement common-lib-terms, and that it specially designed for libraries, and thanks for mentioning it, which I forgot, but I am not sure whether that will be the only entitlement that contracts will be based upon in the future. FIM will allow for more precise definition of users, which will make licenses cheaper for libraries. I may be wrong here, but I'd rather be corrected by librarians actually signing contracts.
Yes its is good to have such an technical expert like you in this list, but please be aware that we have to also tackle non-technical issues here. And please be also aware that some people subscribed to this list are rather non-technical. It is ok to correct things, and I very much appreciate this, but we should not get too much into technical details. There are more appropriate lists for that.
Yes we have new alternatives than targetedID, but I fear that attribute is still common practice and we should IMO name both targetedID and pairwise subjectID. Especially when RA21 only named targetedID. We are talking about a community that is rather slow in adapting new technologies and we cannot expect very current state of the art in software and in software configuration.
Cheers,
Peter G.
Am 19.03.2019 um 16:52 schrieb Peter Schober:
- 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
- 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.
- 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.
- 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").
- 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
https://maps.google.com/?q=%0A%3E+default+or+on+request)+only+has+that&entry=gmail&source=g 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 _______________________________________________ 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
Fim4l mailing list Fim4l@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
* Jiri Pavlik jiri.pavlik@mzk.cz [2019-03-20 21:18]:
do you handle multiple contracts in Austria, Peter?
ACOnet (the hat I'm wearing for this effort) does not handle e-resource contracts on behalf of institutions at this time.
In many cases there's no central legal entity that holds these contracts but individual (per-publisher) consortia where each institution licenses individually, but all buying "in-bulk" for cheaper licenses. Cf. https://konsortien.at run by https://www.obvsg.at
University subscribes different content sets for different user groups with a provider.
That use-case may exist but is not handled (well, or at all) by the eduPerson(Scoped)Affiliation attribute the guideline document (and Peter's email) recommended, AFAIR. So I was merely commenting on the use of the common-lib-terms entitlement attribute instead of the eduPerson(Scoped)Affiliation attribute but for the /same/ use-case, i.e., site-licenses that do not differentiate per department or similar schemes. If that is what you need you'll need something else anyway.
FWIW, I'm not aware of such licensing differentiation going on in Austria. AFAIK both publishers and institutions prefer to licese for the institutional core constituencies and not per department. (The publisher probably for higher total fees and the institutions for lower per-capita costs and lower management effforts, I'm guessing.)
But I can ask around or get someone e.g. from OBVSG subscribed to this list, if you think that would help. OBVSG knows what's going on in .at but does not have the technical knowledge, that's more on our side.)
Best, -peter
Hi,
I see. common-lib-terms in entitlement attribute or usage of eduPerson(Scoped)Affiliation are fine for authorisation handling based on single contract with publisher, but not sufficient for multiple contracts. The multiple contracts are pretty common in Czech Republic.
Cheers
Jiri
On Wed, 20 Mar 2019 at 20:55, Peter Schober peter.schober@univie.ac.at wrote:
- Jiri Pavlik jiri.pavlik@mzk.cz [2019-03-20 21:18]:
do you handle multiple contracts in Austria, Peter?
ACOnet (the hat I'm wearing for this effort) does not handle e-resource contracts on behalf of institutions at this time.
In many cases there's no central legal entity that holds these contracts but individual (per-publisher) consortia where each institution licenses individually, but all buying "in-bulk" for cheaper licenses. Cf. https://konsortien.at run by https://www.obvsg.at
University subscribes different content sets for different user groups with a provider.
That use-case may exist but is not handled (well, or at all) by the eduPerson(Scoped)Affiliation attribute the guideline document (and Peter's email) recommended, AFAIR. So I was merely commenting on the use of the common-lib-terms entitlement attribute instead of the eduPerson(Scoped)Affiliation attribute but for the /same/ use-case, i.e., site-licenses that do not differentiate per department or similar schemes. If that is what you need you'll need something else anyway.
FWIW, I'm not aware of such licensing differentiation going on in Austria. AFAIK both publishers and institutions prefer to licese for the institutional core constituencies and not per department. (The publisher probably for higher total fees and the institutions for lower per-capita costs and lower management effforts, I'm guessing.)
But I can ask around or get someone e.g. from OBVSG subscribed to this list, if you think that would help. OBVSG knows what's going on in .at but does not have the technical knowledge, that's more on our side.)
Best, -peter
* Jiri Pavlik jiri.pavlik@mzk.cz [2019-03-20 22:14]:
I see. common-lib-terms in entitlement attribute or usage of eduPerson(Scoped)Affiliation are fine for authorisation handling based on single contract with publisher
Exactly, and there are (technical) advantages in using one over the other, resulting in less need for 1:1 coordination between publisher and institution and therefore more "It Just Works".
but not sufficient for multiple contracts. The multiple contracts are pretty common in Czech Republic.
I have essentialy zero practical exposure to your scenario (as the opposite seems to be the case in Austria) so I'm happy to learn.
So I guess a guidelines document would have to differentiate between the single- and the multiple-contact cases? That adds complexity but this seems unavoidable if both use-cases are common and have to be dealt with.
-peter
Hi,
yes, the guidelines document is aiming to cover both the single- and the multiple-contract cases.
All the best
Jiri
On Wed, 20 Mar 2019 at 21:22, Peter Schober peter.schober@univie.ac.at wrote:
- Jiri Pavlik jiri.pavlik@mzk.cz [2019-03-20 22:14]:
I see. common-lib-terms in entitlement attribute or usage of eduPerson(Scoped)Affiliation are fine for authorisation handling based on single contract with publisher
Exactly, and there are (technical) advantages in using one over the other, resulting in less need for 1:1 coordination between publisher and institution and therefore more "It Just Works".
but not sufficient for multiple contracts. The multiple contracts are pretty common in Czech Republic.
I have essentialy zero practical exposure to your scenario (as the opposite seems to be the case in Austria) so I'm happy to learn.
So I guess a guidelines document would have to differentiate between the single- and the multiple-contact cases? That adds complexity but this seems unavoidable if both use-cases are common and have to be dealt with.
-peter _______________________________________________ Fim4l mailing list Fim4l@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
* Peter Gietz peter.gietz@daasi.de [2019-03-20 20:06]:
Yes I know about entitlement common-lib-terms, and that it specially designed for libraries, and thanks for mentioning it, which I forgot, but I am not sure whether that will be the only entitlement that contracts will be based upon in the future.
I specifically mention it as superior and established replacement (or alternative: like with identifiers one should be recommended and the other still allowed; an SP should be able to check both) for eduPerson(Scoped)Affiliation attributes.
FIM will allow for more precise definition of users, which will make licenses cheaper for libraries. I may be wrong here, but I'd rather be corrected by librarians actually signing contracts.
If the use-case changes then my answer also changes. But then you can't continue to only talk about eduPerson(Scoped)Affiliation at the same time, becuase that also doesn't handle new/different use-cases with more specific target audiences.
So again: For the cases you mention ePSA use of the common-lib-terms entitlement is superior for the reasons given earlier. For other cases neither may be suitable (and certainly not ePSA).
Yes its is good to have such an technical expert like you in this list, but please be aware that we have to also tackle non-technical issues here. And please be also aware that some people subscribed to this list are rather non-technical. It is ok to correct things, and I very much appreciate this, but we should not get too much into technical details. There are more appropriate lists for that.
Well, it's the guidelines that make statements about what attributes to use for recoginising returning subjects (if needed) and for authorisation -- even if it doesn't cleanly differentiate those use-cases yet, so the guidelines are technically specific. And if the choices made in that document are poor I will state this and also explain why. But I can limit myself to technical statements when suggesting concrete wording changes in the document. It's just that for a paper that should document shared agreement we'd have to agree first. Hence I thought I'd open discussions on a few items.
Yes we have new alternatives than targetedID, but I fear that attribute is still common practice and we should IMO name both targetedID and pairwise subjectID. Especially when RA21 only named targetedID.
I have no insight in what RA21 did and I'm sorry if that is one of the results. I'm not finished in my fight against identifier chaos due to continued co-existence of too many identifiers that do more or less the same thing only differently. The case-folding issue with eduPersonTargetedID (also affecting proper persistent NameIDs and eduPersonUniqieID, btw) is the last straw, IMO. But like I said, I'll try to get something going within the federations community first. -peter
To summarize:
In our recommendations:
* we will reflect single and multiple contract cases
* we will recommend common-lib-terms entitlement and scoped affiliation
* we will recommend targetedID quoting chapter 2.2.11 of eduperson201602 (https://wiki.refeds.org/pages/viewpage.action?pageId=38895708#eduPerson(2016...) and its follow up attribute pairwise subjectID quoting chapter 3.4. of the January 2019 specification (http://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-i...)
* we will address the fears of the library community and take over the reasonable privacy related recommendations found in blogs from that community
It wasn't that stressful after all to reach so much consensus between us.
@all can this be regarded as list consensus or are there more comments?
Cheers,
Peter G.
Am 20.03.2019 um 21:46 schrieb Peter Schober:
- Peter Gietz peter.gietz@daasi.de [2019-03-20 20:06]:
Yes I know about entitlement common-lib-terms, and that it specially designed for libraries, and thanks for mentioning it, which I forgot, but I am not sure whether that will be the only entitlement that contracts will be based upon in the future.
I specifically mention it as superior and established replacement (or alternative: like with identifiers one should be recommended and the other still allowed; an SP should be able to check both) for eduPerson(Scoped)Affiliation attributes.
FIM will allow for more precise definition of users, which will make licenses cheaper for libraries. I may be wrong here, but I'd rather be corrected by librarians actually signing contracts.
If the use-case changes then my answer also changes. But then you can't continue to only talk about eduPerson(Scoped)Affiliation at the same time, becuase that also doesn't handle new/different use-cases with more specific target audiences.
So again: For the cases you mention ePSA use of the common-lib-terms entitlement is superior for the reasons given earlier. For other cases neither may be suitable (and certainly not ePSA).
Yes its is good to have such an technical expert like you in this list, but please be aware that we have to also tackle non-technical issues here. And please be also aware that some people subscribed to this list are rather non-technical. It is ok to correct things, and I very much appreciate this, but we should not get too much into technical details. There are more appropriate lists for that.
Well, it's the guidelines that make statements about what attributes to use for recoginising returning subjects (if needed) and for authorisation -- even if it doesn't cleanly differentiate those use-cases yet, so the guidelines are technically specific. And if the choices made in that document are poor I will state this and also explain why. But I can limit myself to technical statements when suggesting concrete wording changes in the document. It's just that for a paper that should document shared agreement we'd have to agree first. Hence I thought I'd open discussions on a few items.
Yes we have new alternatives than targetedID, but I fear that attribute is still common practice and we should IMO name both targetedID and pairwise subjectID. Especially when RA21 only named targetedID.
I have no insight in what RA21 did and I'm sorry if that is one of the results. I'm not finished in my fight against identifier chaos due to continued co-existence of too many identifiers that do more or less the same thing only differently. The case-folding issue with eduPersonTargetedID (also affecting proper persistent NameIDs and eduPersonUniqieID, btw) is the last straw, IMO. But like I said, I'll try to get something going within the federations community first. -peter _______________________________________________ Fim4l mailing list Fim4l@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Although the opinion of librarians is more relevant: thank you 2 Peters for the discussion!!! Thank you for the summary as well. I think I read Peter S would rather recommend pairwise subjectID, with targetedID as 2nd best for as long SP’s are not able to use the recommended id? So those should be switched in the summary below?
Kindest regards,
Raoul tel:+31641195989
On 21/03/2019, 14:57, "FIM4L on behalf of Peter Gietz" <fim4l-bounces@lists.daasi.demailto:fim4l-bounces@lists.daasi.de on behalf of peter.gietz@daasi.demailto:peter.gietz@daasi.de> wrote:
To summarize:
In our recommendations:
* we will reflect single and multiple contract cases
* we will recommend common-lib-terms entitlement and scoped affiliation
* we will recommend targetedID quoting chapter 2.2.11 of eduperson201602 (https://wiki.refeds.org/pages/viewpage.action?pageId=38895708#eduPerson(2016...) and its follow up attribute pairwise subjectID quoting chapter 3.4. of the January 2019 specification (http://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-i...)
* we will address the fears of the library community and take over the reasonable privacy related recommendations found in blogs from that community
It wasn't that stressful after all to reach so much consensus between us.
@all can this be regarded as list consensus or are there more comments?
Cheers,
Peter G.
Am 20.03.2019 um 21:46 schrieb Peter Schober: * Peter Gietz <peter.gietz@daasi.demailto:peter.gietz@daasi.de> [2019-03-20 20:06]: Yes I know about entitlement common-lib-terms, and that it specially designed for libraries, and thanks for mentioning it, which I forgot, but I am not sure whether that will be the only entitlement that contracts will be based upon in the future. I specifically mention it as superior and established replacement (or alternative: like with identifiers one should be recommended and the other still allowed; an SP should be able to check both) for eduPerson(Scoped)Affiliation attributes.
FIM will allow for more precise definition of users, which will make licenses cheaper for libraries. I may be wrong here, but I'd rather be corrected by librarians actually signing contracts. If the use-case changes then my answer also changes. But then you can't continue to only talk about eduPerson(Scoped)Affiliation at the same time, becuase that also doesn't handle new/different use-cases with more specific target audiences.
So again: For the cases you mention ePSA use of the common-lib-terms entitlement is superior for the reasons given earlier. For other cases neither may be suitable (and certainly not ePSA).
Yes its is good to have such an technical expert like you in this list, but please be aware that we have to also tackle non-technical issues here. And please be also aware that some people subscribed to this list are rather non-technical. It is ok to correct things, and I very much appreciate this, but we should not get too much into technical details. There are more appropriate lists for that. Well, it's the guidelines that make statements about what attributes to use for recoginising returning subjects (if needed) and for authorisation -- even if it doesn't cleanly differentiate those use-cases yet, so the guidelines are technically specific. And if the choices made in that document are poor I will state this and also explain why. But I can limit myself to technical statements when suggesting concrete wording changes in the document. It's just that for a paper that should document shared agreement we'd have to agree first. Hence I thought I'd open discussions on a few items.
Yes we have new alternatives than targetedID, but I fear that attribute is still common practice and we should IMO name both targetedID and pairwise subjectID. Especially when RA21 only named targetedID. I have no insight in what RA21 did and I'm sorry if that is one of the results. I'm not finished in my fight against identifier chaos due to continued co-existence of too many identifiers that do more or less the same thing only differently. The case-folding issue with eduPersonTargetedID (also affecting proper persistent NameIDs and eduPersonUniqieID, btw) is the last straw, IMO. But like I said, I'll try to get something going within the federations community first. -peter _______________________________________________ Fim4l mailing list Fim4l@lists.daasi.demailto: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.demailto:peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
_______________________________________________ FIM4L mailing list FIM4L@lists.daasi.demailto:FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
* Peter Gietz peter.gietz@daasi.de [2019-03-21 14:55]:
- we will recommend common-lib-terms entitlement and scoped affiliation
One vital missing piece here is to recommend (though I'm in favor of much stronger wording) that authorization is actually performed by the SP based on transmitted attributes. I.e., "We don't need no attributes" should not be acceptable.
While there may be cases where indeed "everyone and everything that can authenticate" at an institution is covered by the contract (I know of exactly one such case) even then tying the contract to the IDP's entityID (there's nothing else to tie it to without any attributes) is an anti-pattern: Not every institution runs/maps to exactly one entityID.
In the vast majority not processing any attributes (as part of federated logins) will simply mean the SP expects the IDPs to only sends authorized subjects to the SP (i.e., abort SSO for those subjects which should not be allowed access to the SP according to the SP's rules), which does not scale: Federation is based on the IDP performing authentication and asserting things and the SP performing authorization based on the asserted data.
An SP not looking at any attributes makes it impossible for an IDP to tell the SP that someone should NOT be able to access licensed resources on behalf of the institution.
Should the IDP not completely block access to the SP that then creates a legal risk and potential fingerpointing between the SP ("The IDP should not send us unauthorised people") and IDP ("The SP should look at the data we sent were its clear the person is not authorized").
- we will recommend targetedID quoting chapter 2.2.11 of eduperson201602 (https://wiki.refeds.org/pages/viewpage.action?pageId=38895708#eduPerson(2016...)
and its follow up attribute pairwise subjectID quoting chapter 3.4. of the January 2019 specification (http://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-i...)
That would directly go against saml2int that has had an RFC-SHOULD there for many years:
"If an opaque targeted user identifier is being provided to the Service Provider, it is RECOMMENDED to use a saml2:NameID construct with a Format of urn:oasis:names:tc:SAML:2.0:nameid-format:persistent rather than transporting that identifier as an saml2:Attribute." ( https://saml2int.org/profile/current/#section7 )
It would also ignore the new saml2int which has much stronger language on not requiring any NameID or Attribute for identification.
But give me a couple of days/week to find out whether the former can be formally deprecated or something else to that effect. Our deployment profiles have been speaking out against ePTID for many years now, it's time to close that chapter.
-peter
Hi,
thanks, Peter & Peter, Raoul.
I’d suggest adding CoCo support for smooth attributes release and to be in-line with RA21 recommendations.
Cheers
Jiri
On Thu, 21 Mar 2019 at 14:14, Peter Schober peter.schober@univie.ac.at wrote:
- Peter Gietz peter.gietz@daasi.de [2019-03-21 14:55]:
- we will recommend common-lib-terms entitlement and scoped affiliation
One vital missing piece here is to recommend (though I'm in favor of much stronger wording) that authorization is actually performed by the SP based on transmitted attributes. I.e., "We don't need no attributes" should not be acceptable.
While there may be cases where indeed "everyone and everything that can authenticate" at an institution is covered by the contract (I know of exactly one such case) even then tying the contract to the IDP's entityID (there's nothing else to tie it to without any attributes) is an anti-pattern: Not every institution runs/maps to exactly one entityID.
In the vast majority not processing any attributes (as part of federated logins) will simply mean the SP expects the IDPs to only sends authorized subjects to the SP (i.e., abort SSO for those subjects which should not be allowed access to the SP according to the SP's rules), which does not scale: Federation is based on the IDP performing authentication and asserting things and the SP performing authorization based on the asserted data.
An SP not looking at any attributes makes it impossible for an IDP to tell the SP that someone should NOT be able to access licensed resources on behalf of the institution.
Should the IDP not completely block access to the SP that then creates a legal risk and potential fingerpointing between the SP ("The IDP should not send us unauthorised people") and IDP ("The SP should look at the data we sent were its clear the person is not authorized").
- we will recommend targetedID quoting chapter 2.2.11 of eduperson201602
( https://wiki.refeds.org/pages/viewpage.action?pageId=38895708#eduPerson(2016... )
and its follow up attribute pairwise subjectID quoting chapter 3.4. of
the
January 2019 specification (
http://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-i... )
That would directly go against saml2int that has had an RFC-SHOULD there for many years:
"If an opaque targeted user identifier is being provided to the Service Provider, it is RECOMMENDED to use a saml2:NameID construct with a Format of urn:oasis:names:tc:SAML:2.0:nameid-format:persistent rather than transporting that identifier as an saml2:Attribute." ( https://saml2int.org/profile/current/#section7 )
It would also ignore the new saml2int which has much stronger language on not requiring any NameID or Attribute for identification.
But give me a couple of days/week to find out whether the former can be formally deprecated or something else to that effect. Our deployment profiles have been speaking out against ePTID for many years now, it's time to close that chapter.
-peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
One more thing on entitlement vs scoped affiliation: If we want to quote state of the art avangarde, we might also quote AARC documents, namely "Guidelines on expressing group membership and role information" [1], which recommends the usage of eduPersonEntitlement in a different way than defined in eduPerson, namely to contain group or role information instead of "indicat[ing] a set of rights to specific resources". In that case the computation of the actual access rights would again be on the SP side based on the group or role information. Such a group could e.g. be member of the chemical department of University XYZ, who could be the only users interested in a chemical journal. This would not per se prevent interdisciplinarity, because a contract for that chemical journal could also include members in the department biochemistry or even biology.
A more general remark on this: the mode where SP computes is the defacto standard in SAML, which we can see that Attribute statements are very common and implemented, whereas authorization statements, specified in the same standard documents rather ist not.
On the other hand we should IMO not recommend (to libraries, our target group) to use another AARC result, namely "Specification for expressing resource capabilities" from December 2018[2] which is more in-line with the original idea of eduPersonEntitlement, namely defining access rights to resources.
[1] https://aarc-project.eu/wp-content/uploads/2017/11/AARC-JRA1.4A-201710.pdf (October 2017) [2] https://zenodo.org/record/2247446/files/AARC-G027-Specification_for_expressi...
Cheers, Peter
Am 21.03.2019 um 14:55 schrieb Peter Gietz:
To summarize:
In our recommendations:
we will reflect single and multiple contract cases
we will recommend common-lib-terms entitlement and scoped affiliation
we will recommend targetedID quoting chapter 2.2.11 of
eduperson201602 (https://wiki.refeds.org/pages/viewpage.action?pageId=38895708#eduPerson(2016...) and its follow up attribute pairwise subjectID quoting chapter 3.4. of the January 2019 specification (http://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-i...)
- we will address the fears of the library community and take over the
reasonable privacy related recommendations found in blogs from that community
It wasn't that stressful after all to reach so much consensus between us.
@all can this be regarded as list consensus or are there more comments?
Cheers,
Peter G.
Am 20.03.2019 um 21:46 schrieb Peter Schober:
- Peter Gietz peter.gietz@daasi.de [2019-03-20 20:06]:
Yes I know about entitlement common-lib-terms, and that it specially designed for libraries, and thanks for mentioning it, which I forgot, but I am not sure whether that will be the only entitlement that contracts will be based upon in the future.
I specifically mention it as superior and established replacement (or alternative: like with identifiers one should be recommended and the other still allowed; an SP should be able to check both) for eduPerson(Scoped)Affiliation attributes.
FIM will allow for more precise definition of users, which will make licenses cheaper for libraries. I may be wrong here, but I'd rather be corrected by librarians actually signing contracts.
If the use-case changes then my answer also changes. But then you can't continue to only talk about eduPerson(Scoped)Affiliation at the same time, becuase that also doesn't handle new/different use-cases with more specific target audiences.
So again: For the cases you mention ePSA use of the common-lib-terms entitlement is superior for the reasons given earlier. For other cases neither may be suitable (and certainly not ePSA).
Yes its is good to have such an technical expert like you in this list, but please be aware that we have to also tackle non-technical issues here. And please be also aware that some people subscribed to this list are rather non-technical. It is ok to correct things, and I very much appreciate this, but we should not get too much into technical details. There are more appropriate lists for that.
Well, it's the guidelines that make statements about what attributes to use for recoginising returning subjects (if needed) and for authorisation -- even if it doesn't cleanly differentiate those use-cases yet, so the guidelines are technically specific. And if the choices made in that document are poor I will state this and also explain why. But I can limit myself to technical statements when suggesting concrete wording changes in the document. It's just that for a paper that should document shared agreement we'd have to agree first. Hence I thought I'd open discussions on a few items.
Yes we have new alternatives than targetedID, but I fear that attribute is still common practice and we should IMO name both targetedID and pairwise subjectID. Especially when RA21 only named targetedID.
I have no insight in what RA21 did and I'm sorry if that is one of the results. I'm not finished in my fight against identifier chaos due to continued co-existence of too many identifiers that do more or less the same thing only differently. The case-folding issue with eduPersonTargetedID (also affecting proper persistent NameIDs and eduPersonUniqieID, btw) is the last straw, IMO. But like I said, I'll try to get something going within the federations community first. -peter _______________________________________________ Fim4l mailing list Fim4l@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
* Peter Gietz peter.gietz@daasi.de [2019-03-21 16:26]:
AARC document "Guidelines on expressing group membership and role information"
FWIW, I think none of that matters here for two reasons.
One is due to the lack/violation of the first item in its "General guidelines" which presumes the existance of a proxy component that alone has to deal with (and can therefore abstract away from the SPs) the complexity and heterogenity of group information in multi-party federation. I.e., the document acknoledges that its a mess ("Harmonisation of naming for groups, hierarchy and use of ontologies within different scientific domains is explicitly excluded from these guidelines.") but claims it can be made usable with proxies. There are no such proxies in FIM4L.
which recommends the usage of eduPersonEntitlement in a different way than defined in eduPerson, namely to contain group or role information instead of "indicat[ing] a set of rights to specific resources".
I wouldn't put too much into the original wording as the envisaged use-case for ePE never happened (due to some of the issues I already commented on), I think. There are mainly two kinds of ePE usage AFAIK:
* The common-lib-terms standardised, invariant attribute value. (There are hardly any other "standard" values. Even very commonly used values such as the TCS "urn:mace:terena.org:tcs:personal-user" and "urn:mace:terena.org:tcs:escience-user" ones are contract-specific and so fall under the next category.) * Values that are somewhat private/bilateral/tied to a *specific* contract (instance) and will need to be agreed upon in each case. I think all cases of the Czech "multiple contracts for the same resource an institution has with an e-resource provider" fall under that, among others.
So the second reason this AARC paper doesn't apply or matter here is that it's doubtful /any/ kind of standardization of attribute values in this area can make meaningful contributions to the latter cases: Standardising how one IDP sends its local groups tells the SP nothing about /which/ of those groups should be considered to be covered under a given contract -- each IDP will still have to tell the/each SP specifically which of those "groups" (i.e., strings to match) should be allowed (and for what product). (Only sending the ones that constitue pre-authorized groups is going back to the IDP pre-calculating those rights, which is an anti-pattern in FIM.)
The specific set of "considered authorized" groups/string values will necessarily be different for each IDP (at each SP) and likely different for each SP (at each IDP) there's not much that can be gained from standardization. (Note that there's also no global ontology for "departments" or "org units in academia" or whatever that would allow to automate parts of that parsing and decision making. No DCC etc. to help here.)
On the other hand we should IMO not recommend (to libraries, our target group) to use another AARC result, namely "Specification for expressing resource capabilities" from December 2018[2] which is more in-line with the original idea of eduPersonEntitlement, namely defining access rights to resources.
It does match exactly the library use-case (access to licensed resources), though. Obviously an IDP cannot enumerate all the resources (which are at the SP!) its own local groups/communities may have access [rights] to, but if <RESOURCE> is an identifier for a contract with an SP that doesn't sound unreasonable?
But reason number two above still applies, so the notational or semantic specifics don't matter.
-peter
Teilnehmer (4)
-
Jiri Pavlik -
Peter Gietz -
Peter Schober -
Raoul Teeuwen