Hi,
Let me point out to EBSCOhost as a similar service. Similar set of requested attributes: - eduPersonScopedAffiliation (required) - eduPersonTargetedID (required) - eduPersonEntitlement (required) should be the right fit here because EBSCOhost is using eduPersonScopedAffiliation and eduPersonEntitlement values for authorisation, eduPersonTargetedID for recognising returning user and providing personalisation.
Looking at EBSCOhost SP metadata I can see that in Finland [1] or in Australia [2] there is an interest in releasing givenName, sn, mail attributes.
Listing eduPersonScopedAffiliation, eduPersonTargetedID, eduPersonEntitlement as optional in UK Federation / eduGAIN [3] or listing no requested attributes at all in US InCommon Federations seems like a mistake to me.
All the best
Jiri
1. https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...
2. https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...
3. https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...
4. https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...
On Thu, Mar 11, 2021 at 3:28 PM Jiri Pavlik jiri.pavlik@techlib.cz wrote:
Hi Peter,
The intent here is worldwide agreement within FIM4L actually what is the best fit for LexisNexis Advance and all similar SPs out there. IMHO your suggestion is:
- eduPersonScopedAffiliation (required)
- eduPersonTargetedID (required)
- Sirtfy support
And rather SAML pairwise-id than eduPersonTargetedID as described in FIM4L recommendations and REFEDS Pseudonymous Authorisation entity category specification.
I am wondering whether there is an opportunity of employing a Consent-informed Attribute Release system (CAR) [1] for releasing name and e-mail address with user consent. I can see that French colleagues at least may be interested in that.
Best
Jiri
https://spaces.at.internet2.edu/display/CAR/CAR%3A+Consent-informed+Attribut...
On Thu, Mar 11, 2021 at 12:03 PM Peter Schober peter.schober@univie.ac.at wrote:
- Jiri Pavlik jiri.pavlik@techlib.cz [2021-03-11 09:05]:
I am wondering whether everyone could be fine with following set of attributes along with CoCo and Sirtfy entity categories support: eduPersonScopedAffiliation (required) eduPersonTargetedID (optional) givenName (optional) sn (optional) mail (optional)
Ignoring the fact that ultimately existing bilateral (or consortial) contracts (here with LN) will always trump what GÉANT CoCo says, note that CoCo v1 (the only released version that currently exists) explicitly only covers strictly *required* (isRequired="true" in SAML Metadata) attributes. It cannot be used for optional data. People should also be aware that there is no clear indication that LexisNexis even intended to adhere to the GÉANT CoCo specification: All that I've seen so far is RENATER's claim that the LN SP is covered by CoCo. But CoCo also requires that the Privacy Policy for a SAML SP adhering to CoCo contains a reference to the GÉANT CoCo and this is NOT the case with LexisNexis here (not even in the URL referenced in the RENATER metadata). So the CoCo-support of the LexisNexis SP is (1) highly questionable, IMO, and (2) very likely meaningless in light of actual contracts governing use of / access to the service.
As to the actual question above: If the service continues to work fine with only the commonly released minimal set of data (common-lib-terms or eduPersonScopedAffiliation for authorisation; SAML persistent NameID or eduPersonTargetedID or SAML pairwise-id for personalisation functionality) I see no reason to change anything in order to encourge institutions to send *more* personal data to the publisher. (And even if we did, what makes LN so special here? Wouldn't we also have to have this discussion then for every other of the hundreds of SPs we have for "institutionally licensed e-resource access"?)
Best regards, -peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l