* Jos Westerbeke jos.westerbeke@eur.nl [2019-07-19 19:23]:
I think we (Erasmus University) have such a 'Recommendation 5b' example with ScienceDirect.
We exchange the urn:mace:dir:attribute-def:eduPersonTargetedID attribute (Persistant Identifier) with Elsevier.
JFYI, if this is using the SAML 2.0 protocol then the above is not legal according to the relevant specification governing use of eduPerson attributes within SAML: These attribute names were already declared "legacy names" (section 2.2.1) even for use with SAML 1.x back in 2008 when the MACE-Dir SAML Attribute Profiles[1] were published, but for SAML 2.0 "[t]he legacy names assigned for use with the SAML 1.x attribute profile MUST NOT be used with this profile" (section 3.2, p.11, lines 367f)
If not even our own community (!) adheres to our own community standards (!) then it's no wonder this is all such a big mess...
you'll stay anonymous, based on a persistent identifier.
Nit: If the SP recieves a persistent identifier (i.e., one that doesn't change from session to session) the subject is not "anonymous" but merely "pseudonymous", at least under GDPR terminology. (This matters to those of us that have to compy with GDPR because "anonymous data" isn't personal data and doesn't fall under GDPR, but "pseudonymous" is personal data just as if it were not pseudonymised.)
Now, you're offered by Elsevier to voluntarily 'activate personalization'. Whatever you fill in there, it will be bound to the persistent identifier. And there you'll have your own build profile, even with 'fake' name and email, as I did with my spam Yahoo email address.
Since this has now ben brought up twice here on this list (leifj, jos): Are people seriously suggesting to recommend to subjects to lie and provide false data to service providers (potenially violating those SP's Terms of Use) in the context of us here trying to establish best practices? If that's the *only* way to keep some of our basic rights when confronted with the processes forced upon us by publishers then I think we've already failed and a more constructive approach is warranted. E.g. challenging those requirements that in order to get personalisation I would have to provide my name (and possibly email address, unless I actually intend to recieve emails from them), instead of just ticking a box that I want them to use the identifer already provided.
And as you said Peter S., Elsevier is also able to build a personal profile based on the persistent identifier, but they must find the information themselves, with advanced algorithms e.g. Which they do not, according to Meshna. But I think this goes beyond our scope.
There's nothing remotely advanced or algorithmic about simply reading/using an attribute that has been sent. (That's the point of having federation-enabled software.)
And if actually protecting the privacy of subjects accessing institutionally licensed resources really isn't within scope of this work I'm beginning to understand some of the criticism that the RA21 effort was met with. But maybe you're only saying that federation isn't possible without trust. And while trust there usually comes in forms of cryptographically signed messages sometimes all we have to rely on is the statement of a single non-management-level employee that they are not using data already provided to them? That's fine but I still think we could do better than that, no?
-peter
[1] http://macedir.org/docs/internet2-mace-dir-saml-attributes-latest.pdf