Dear all,
Elsevier requests eduPersonTargetedID and eduPersonEntitlement attributes in metadata at eduID.at for Scopus and other services - https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.c...
Requested attributes are missing in eduGAIN metadata - https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.c...
At Scopus users can activate personalisation adding name and e-mail address. A screenshot attached.
This is very close match with our FIM4L guidelines and recommendations.
Have a great summer days
Jiri
* Jiri Pavlik jiri.pavlik@mzk.cz [2019-07-18 14:49]:
Elsevier requests eduPersonTargetedID and eduPersonEntitlement attributes in metadata at eduID.at for Scopus and other services - https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.c...
Requested attributes are missing in eduGAIN metadata -
Note that we also include a proper persistent NameID in our copy of the Elsevier Scopus SP: <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat> which most other federations are missing as well.
At Scopus users can activate personalisation adding name and e-mail address. A screenshot attached.
Sorry, but no: It's simply impossible to "activate personalisation" on top of a federated login if the IDP does not already release an identifier that allows the SP to recognise a returning subject.
So either the IDP is /already/ sending a suitable identifier -- in which case the SP does not need to "activate personalisation" as all requests are traced back to an identified individual (even if that individual is not known by name from the data the IDP provided) -- or the IDP is /not/ sending such an identifier in which case you cannot add "personalisation" to that federated login.
(This is why "optional personalisation" by choice of the SP or of the subject herself is a hard problem to solve cleanly: Anything/-one deciding that outside/after the IDP is simply too late: Either the SP can always track the subject whether the subject wants personalisation or not or no subject from an IDP can get personalisation at that SP if the relevant IDP decided not to release a suitable identifier.)
In that second case the only way to "activate personalisation" is to force the subject to register and use Yet Another local account (with Yet Another Password) to log in /instead/ of using the institutionally provided one. But this local account then isn't easily connected with any institutionally licensed resources so that creates not only the problem of increased password overload but also of authorisation:
Either you'd always have to log in /twice/ now -- first via your institution, to get access to institutionally licensed content, then again using Yet Another Username and Password, to get personalisation features -- which could be considered the worst possible user experience. Or the SP "tags" your locally registered Yet Another Account to be authorised with your institutional affiliation but then this creates the issue of when you'd lose those rights again: If access rights are transfered from a federated login (with only an entitlement or scoped affiliation) to a locally registered account in a one-time event how would I ever lose those rights when going forward I'll only be using the local account to log in (in order to benefit from personalisation)? Never? After some default period after which I'd have to log in twice (see above), again?
I have zero experience with how publishers are doing any of that in practice and I'm doubtful that registering local accounts (and logging in with those each time) is an appropriate measure only in order to allow personalisation features, btu YMMV.
But unless I'm overlooking something rather fundamental offering local account registration cannot be seen to be in line with any kind of best practices, IMHO.
Best, -peter
On 2019-07-18 16:10, Peter Schober wrote:
Sorry, but no: It's simply impossible to "activate personalisation" on top of a federated login if the IDP does not already release an identifier that allows the SP to recognise a returning subject.
So either the IDP is /already/ sending a suitable identifier -- in which case the SP does not need to "activate personalisation" as all requests are traced back to an identified individual (even if that individual is not known by name from the data the IDP provided) -- or the IDP is /not/ sending such an identifier in which case you cannot add "personalisation" to that federated login.
Elsevier forces users to register with their names and email addresses (and maybe also additional data), otherwise the personalized features cannot be used, even though the IdP sends a suitable identifier. This could be regarded as activating the personalization. While asking the users for additional data in exchange for the personalized features might be okay, this of course shouldn't be the recommendation.
If the IdP doesn't send a suitable identifier, the users cannot use personalized features on the Elsevier platforms, they can't even register a personal account as with IP access. This is a problem when the IdP for whatever reason can or does not want to release a suitable identifier.
Best regards, Bernd
* Bernd Oberknapp bo@ub.uni-freiburg.de [2019-07-18 16:55]:
On 2019-07-18 16:10, Peter Schober wrote:
So either the IDP is /already/ sending a suitable identifier -- in which case the SP does not need to "activate personalisation" as all requests are traced back to an identified individual (even if that individual is not known by name from the data the IDP provided) -- or the IDP is /not/ sending such an identifier in which case you cannot add "personalisation" to that federated login.
Elsevier forces users to register with their names and email addresses (and maybe also additional data), otherwise the personalized features cannot be used, even though the IdP sends a suitable identifier.
Oh my... :(
This could be regarded as activating the personalization. While asking the users for additional data in exchange for the personalized features might be okay, this of course shouldn't be the recommendation.
So it's not enough to provide them with the ability to track every movement and every resource one accesses (based on a pseudonymous identifier released by the IDP), they will /only/ offer you the benefit of personalisation features if you /also/ tell them exctly who you are with name and email?!
Of course that fully undermines the point of sending them pseudonymous identifiers in the first place. So this more of a collection of anti-patterns contrary to what Jiří suggested:
* Jiri Pavlik jiri.pavlik@mzk.cz [2019-07-18 14:49]:
This is very close match with our FIM4L guidelines and recommendations.
As to the other case:
If the IdP doesn't send a suitable identifier, the users cannot use personalized features on the Elsevier platforms, they can't even register a personal account as with IP access.
Offering that may not be part of any recommendationy yet but clearly is another drawback in this case. Though it's of course not an easy task to combine all access methods and authorisation modes in functionally useful ways (and without throwing out the window any remains of patron privacy). I don't know how many SPs support creation of local accounts (not that those would consitute any kind of best practice[1]) and additionally are able to track which resources you're authorised to access on each request based on your current IP address, e.g. as you're moving on- or off-campus even while logged in to their system. (I know a local publisher that does just that and now adding federated logins to that system makes things quite involved.)
-peter
[1] Due to password overload and re-use of passwords across systems, though WebAuthn may well change that.
So it's not enough to provide them with the ability to track every movement and every resource one accesses (based on a pseudonymous identifier released by the IDP), they will /only/ offer you the benefit of personalisation features if you /also/ tell them exctly who you are with name and email?!
Dude you can provide any information you like there... Thats exactly what a pseudonym is!
Cheers Leif
We (Elsevier; as Scopus doesn't have its own SP) tie a targetedID to an 'Elsevier user account' which is created in our database when a user decides to 'activate personalization', so that next time when a user accesses Elsevier product via the IdP, they can access their institutional entitlements AND their personal features with one set of credentials in one go. ('Activate personalization' means the same as 'register' or 'create user account'.)
That is the only way we use targetedID.
"So it's not enough to provide them with the ability to track every movement and every resource one accesses (based on a pseudonymous identifier released by the IDP), they will /only/ offer you the benefit of personalization features if you /also/ tell them exactly who you are with name and email?!
Of course that fully undermines the point of sending them pseudonymous identifiers in the first place."
That's upside down. Something to do with GDPR. We don't create user profiles without user's action. We don't use targetedID to track a user or to maintain a session across different products; that would be useless and unnecessarily complicated, seeing most of our users don't use federated access in the first place.
An IdP doesn't need to release a targetedID. A user can register without it (email + password) if they want to, but then they'll have two sets of credentials and some of them will be eternally confused or annoyed because they can either access subscribed content or their personal features, but not both. They will of course register at other SPs and end up with more credentials, or all these emails with different passwords, or with the same passwords... which completely defies the purpose of federated access.
Kind regards, Meshna
Meshna Koren
Associate Product Manager Product Management - Identity and Platform - Research Products
Elsevier BV Radarweg 29, Amsterdam 1043 NX, The Netherlands m.koren@elsevier.com
Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens, Institutional Login
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Leif Johansson Sent: Thursday, July 18, 2019 22:01 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Scopus
*** External email: use caution ***
So it's not enough to provide them with the ability to track every movement and every resource one accesses (based on a pseudonymous identifier released by the IDP), they will /only/ offer you the benefit of personalisation features if you /also/ tell them exctly who you are with name and email?!
Dude you can provide any information you like there... Thats exactly what a pseudonym is!
Cheers Leif _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
________________________________
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands.
Hi,
thanks a lot for your comments, Meshna, Leif, Raoul, Peter, Bernd.
Could you share with us, Meshna, whether there are some IdPs which are not releasing targetedID to Elsevier SP currently? This would worth to address in order to avoid users confusion and discomfort when using federated authentication at Elsevier services. I belive there are no such IdPs from eduID.cz despide that requested attributes are missing in Elsevier SP metadata registered in eduGAIN.
Best regards
Jiri
On Thu, Jul 18, 2019 at 10:18 PM Koren, Meshna (ELS-AMS) M.Koren@elsevier.com wrote:
We (Elsevier; as Scopus doesn't have its own SP) tie a targetedID to an 'Elsevier user account' which is created in our database when a user decides to 'activate personalization', so that next time when a user accesses Elsevier product via the IdP, they can access their institutional entitlements AND their personal features with one set of credentials in one go. ('Activate personalization' means the same as 'register' or 'create user account'.)
That is the only way we use targetedID.
"So it's not enough to provide them with the ability to track every movement and every resource one accesses (based on a pseudonymous identifier released by the IDP), they will /only/ offer you the benefit of personalization features if you /also/ tell them exactly who you are with name and email?!
Of course that fully undermines the point of sending them pseudonymous identifiers in the first place."
That's upside down. Something to do with GDPR. We don't create user profiles without user's action. We don't use targetedID to track a user or to maintain a session across different products; that would be useless and unnecessarily complicated, seeing most of our users don't use federated access in the first place.
An IdP doesn't need to release a targetedID. A user can register without it (email + password) if they want to, but then they'll have two sets of credentials and some of them will be eternally confused or annoyed because they can either access subscribed content or their personal features, but not both. They will of course register at other SPs and end up with more credentials, or all these emails with different passwords, or with the same passwords... which completely defies the purpose of federated access.
Kind regards, Meshna
Meshna Koren
Associate Product Manager Product Management - Identity and Platform - Research Products
Elsevier BV Radarweg 29, Amsterdam 1043 NX, The Netherlands m.koren@elsevier.com
Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens, Institutional Login
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Leif Johansson Sent: Thursday, July 18, 2019 22:01 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Scopus
*** External email: use caution ***
So it's not enough to provide them with the ability to track every movement and every resource one accesses (based on a pseudonymous identifier released by the IDP), they will /only/ offer you the benefit of personalisation features if you /also/ tell them exctly who you are with name and email?!
Dude you can provide any information you like there... Thats exactly what a pseudonym is!
Cheers Leif
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands. _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Hi all,
This is an interesting use case, thanks. And I agree with Jiri; Elsevier (ScienceDirect/Scopus/etc.) could be an example for our Recommendation option 5b. I said 'could be' because it depends on how you establish your connection between IdP and SP, of course. Perhaps Elsevier has different SSO connections for libraries due to the lack of a good FIM4L reference;)
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. Our (hub-spoke) SURFconext federation has a connection (through eduGAIN) with Elsevier. Hence all SURFconext members (almost all higher education schools of the Netherlands) are able to connect to Elsevier in prescribed way. See screenshot 1 in the email attachment for our connection info. (Thanks for the wonderful IdP dashboard, Raoul;)
When you're logged in through federated SSO at www.sciencedirect.com you'll have access and you'll stay anonymous, based on a persistent identifier.
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. (Screenshot 2) I perfectly carry my profile with me by using Elsevier federated login.
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.
@Meshna: I can't find a button to delete my profile;)
all the best! Jos
On 19/07/2019, 10:24, "FIM4L on behalf of Jiri Pavlik" <fim4l-bounces@lists.daasi.de on behalf of jiri.pavlik@mzk.cz> wrote:
Hi,
thanks a lot for your comments, Meshna, Leif, Raoul, Peter, Bernd.
Could you share with us, Meshna, whether there are some IdPs which are not releasing targetedID to Elsevier SP currently? This would worth to address in order to avoid users confusion and discomfort when using federated authentication at Elsevier services. I belive there are no such IdPs from eduID.cz despide that requested attributes are missing in Elsevier SP metadata registered in eduGAIN.
Best regards
Jiri
On Thu, Jul 18, 2019 at 10:18 PM Koren, Meshna (ELS-AMS) M.Koren@elsevier.com wrote: > > We (Elsevier; as Scopus doesn't have its own SP) tie a targetedID to an 'Elsevier user account' which is created in our database when a user decides to 'activate personalization', so that next time when a user accesses Elsevier product via the IdP, they can access their institutional entitlements AND their personal features with one set of credentials in one go. ('Activate personalization' means the same as 'register' or 'create user account'.) > > That is the only way we use targetedID. > > "So it's not enough to provide them with the ability to track every movement and every resource one accesses (based on a pseudonymous identifier released by the IDP), they will /only/ offer you the benefit of personalization features if you /also/ tell them exactly who you are with name and email?! > > Of course that fully undermines the point of sending them pseudonymous identifiers in the first place." > > That's upside down. Something to do with GDPR. We don't create user profiles without user's action. We don't use targetedID to track a user or to maintain a session across different products; that would be useless and unnecessarily complicated, seeing most of our users don't use federated access in the first place. > > An IdP doesn't need to release a targetedID. A user can register without it (email + password) if they want to, but then they'll have two sets of credentials and some of them will be eternally confused or annoyed because they can either access subscribed content or their personal features, but not both. They will of course register at other SPs and end up with more credentials, or all these emails with different passwords, or with the same passwords... which completely defies the purpose of federated access. > > Kind regards, > Meshna > > > > Meshna Koren > > Associate Product Manager > Product Management - Identity and Platform - Research Products > > Elsevier BV > Radarweg 29, Amsterdam 1043 NX, The Netherlands > m.koren@elsevier.com > > Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens, Institutional Login > > > > > -----Original Message----- > From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Leif Johansson > Sent: Thursday, July 18, 2019 22:01 > To: fim4l@lists.daasi.de > Subject: Re: [Fim4l] Scopus > > *** External email: use caution *** > > > > > > > So it's not enough to provide them with the ability to track every > > movement and every resource one accesses (based on a pseudonymous > > identifier released by the IDP), they will /only/ offer you the > > benefit of personalisation features if you /also/ tell them exctly who > > you are with name and email?! > > > > Dude you can provide any information you like there... Thats exactly what a pseudonym is! > > Cheers Leif > _______________________________________________ > FIM4L mailing list > FIM4L@lists.daasi.de > http://lists.daasi.de/listinfo/fim4l > > ________________________________ > > Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands. > _______________________________________________ > FIM4L mailing list > FIM4L@lists.daasi.de > http://lists.daasi.de/listinfo/fim4l _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
* 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
On 20/07/2019, 13:25, "FIM4L on behalf of Peter Schober" <fim4l-bounces@lists.daasi.de on behalf of peter.schober@univie.ac.at> wrote:
* 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...
Hi Peter. I'm told you have been discussing this in the past, and apparently the Dutch federation team sees it differently than you. Maybe not repeat that discussion on this list.
Op 20-07-19 13:25 heeft FIM4L namens Peter Schober <fim4l-bounces@lists.daasi.de namens peter.schober@univie.ac.at> geschreven:
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.)
Can't we say that, with regard to a persistent identifier, - for an IdP it is pseudonymous (for they can translate it to a person) - for an SP it is anonymous (for they are not able to translate it to a person)?
regards, Jos
Documenting the same attribute in different ways (based on perspective) is a receipt for disaster.
Everybody should call it in the same way; the IdP, the SP, the federation, the government and software developers. An attribute is pseudonymous from the SP perspective, too.
(The attribute can be more anonymous than pseudonymous, there are other words for that, for example transient, when it's session based.)
Kind regards, Meshna
Meshna Koren
Associate Product Manager Product Management - Identity and Platform - Research Products
Elsevier BV Radarweg 29, Amsterdam 1043 NX, The Netherlands m.koren@elsevier.com
Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens, Institutional Login
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Jos Westerbeke Sent: Monday, July 22, 2019 08:34 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Scopus
*** External email: use caution ***
Op 20-07-19 13:25 heeft FIM4L namens Peter Schober <fim4l-bounces@lists.daasi.de namens peter.schober@univie.ac.at> geschreven:
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.)
Can't we say that, with regard to a persistent identifier, - for an IdP it is pseudonymous (for they can translate it to a person) - for an SP it is anonymous (for they are not able to translate it to a person)?
regards, Jos
_______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
________________________________
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands.
On 2019-07-20 13:24, Peter Schober wrote:
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.)
According to the assessment of GEANT https://www.geant.org/Projects/GEANT_Project_GN4/deliverables/M9-2_Assessmen... both persistent and non-persistent identifiers are personal data according to GDPR because they can both be used to indirectly identify the person. So the only way to avoid personal data would be to not sent any identifier which probably wouldn't be acceptable for many content providers.
Best regards, Bernd
On Mon, Jul 22, 2019 at 1:27 PM Bernd Oberknapp bo@ub.uni-freiburg.de wrote:
On 2019-07-20 13:24, Peter Schober wrote:
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.)
According to the assessment of GEANT https://www.geant.org/Projects/GEANT_Project_GN4/deliverables/M9-2_Assessmen... both persistent and non-persistent identifiers are personal data according to GDPR because they can both be used to indirectly identify the person. So the only way to avoid personal data would be to not sent any identifier which probably wouldn't be acceptable for many content providers.
Thank you, Bernd, Peter, for clarifying this.
Could be Albert-Ludwigs-Universität Freiburg a representative of a group of universitites, libraries who don't want to release any identifier and want their users to sign-in twice for personalisation? We should tune up 5a in our recommentations according to wishes of this group.
Moravian Library, Czech National Library of Technology, Charles University are among a group of libraries, universitites, who wish to release persistent identifier to allow SPs to provide users with one seamless sign in for personalisation. So Moravian Library, Czech National Library of Technology, Charles University are fine with 5b and 5c options in our recommentations, wish SPs to request persistent identifier in SP metadata and comply with CoCo.
Best regards
Jiri
* Jiri Pavlik jiri.pavlik@mzk.cz [2019-07-23 14:19]:
Could be Albert-Ludwigs-Universität Freiburg a representative of a group of universitites, libraries who don't want to release any identifier and want their users to sign-in twice for personalisation?
That's not what he said, though. He was merely extending my argument that the term "anonymous" should be avoided when releasing some kinds of identifiers to apply to essentially any kind of identifiers (and rightfully so), at least for IDPs and SPs that need to adhere to GDPR. -peter
On Tue, Jul 23, 2019 at 2:29 PM Peter Schober peter.schober@univie.ac.at wrote:
- Jiri Pavlik jiri.pavlik@mzk.cz [2019-07-23 14:19]:
Could be Albert-Ludwigs-Universität Freiburg a representative of a group of universitites, libraries who don't want to release any identifier and want their users to sign-in twice for personalisation?
That's not what he said, though. He was merely extending my argument that the term "anonymous" should be avoided when releasing some kinds of identifiers to apply to essentially any kind of identifiers (and rightfully so), at least for IDPs and SPs that need to adhere to GDPR. -peter
At eduID.at all IdPs are fine with releasing eduPersonTargetedID according to
<md:EntityDescriptor... entityID="https://sdauth.sciencedirect.com/%22%3E ... md:NameIDFormat urn:oasis:names:tc:SAML:2.0:nameid-format:persistent </md:NameIDFormat> md:NameIDFormat urn:oasis:names:tc:SAML:2.0:nameid-format:transient </md:NameIDFormat> ... <md:RequestedAttribute FriendlyName="eduPersonTargetedID" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/> <md:RequestedAttribute FriendlyName="eduPersonEntitlement" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"> saml:AttributeValueurn:mace:dir:entitlement:common-lib-terms</saml:AttributeValue> </md:RequestedAttribute>
I suppose. Is it correct, Peter?
BR Jiri
* Jiri Pavlik jiri.pavlik@mzk.cz [2019-07-23 15:03]:
At eduID.at all IdPs are fine with releasing eduPersonTargetedID according to
<md:EntityDescriptor... entityID="https://sdauth.sciencedirect.com/%22%3E ... I suppose. Is it correct, Peter?
Not sure what this is supposed to demonstrate but anyway:
Naturally -- being neither the IDP that sends data nor the SP who recieves data -- I have no way of knowing this for all euID.at IDPs.
(Full mesh federations are built that way so that no data passes though a central system. The benefits of that architecture for data protection and resilience far outweigh the drawback of limited visibility/insight, IMO.)
Having said that, it's a certainty not all eduID.at IDPs will support eduPersonTargetedID specifically (e.g. none of the ones installed in the last few years, I guess, since I don't even document that attribute anymore) and I'm pretty sure not all eduID.at IDPs suppport proper persistent NameIDs at all. E.g. some IDPs simply cannot deliver on the absolute non-reassignment requirement persistent NameIDs (of either format) have, because of local IDM system or process limitations. Others simply don't follow our recommendations, etc.
-peter
* Peter Schober peter.schober@univie.ac.at [2019-07-23 15:28]:
- Jiri Pavlik jiri.pavlik@mzk.cz [2019-07-23 15:03]:
At eduID.at all IdPs are fine with releasing eduPersonTargetedID according to
<md:EntityDescriptor... entityID="https://sdauth.sciencedirect.com/%22%3E ... I suppose. Is it correct, Peter?
Not sure what this is supposed to demonstrate but anyway:
Naturally -- being neither the IDP that sends data nor the SP who recieves data -- I have no way of knowing this for all euID.at IDPs.
I can add that for any IDP I *know* supports persistent NameIDs in principle -- which is still different from releasing it to anyone in particular -- I do record that in their metadata (NameIDFormat elements with "persistent" as value).
From a quick look that's a bit more than a third of our IDPs (19 out
of 55 production IDPs), which still is higher than the current count in eduGAIN (720 out of 3062, so less than a fourth of the IDPs).
But there may be some supporting proper persistent NameIDs without us knowing about it. And there's no record of support for eduPersonTargetedID specifically.
-peter
On Tue, Jul 23, 2019 at 3:57 PM Peter Schober peter.schober@univie.ac.at wrote:
- Peter Schober peter.schober@univie.ac.at [2019-07-23 15:28]:
- Jiri Pavlik jiri.pavlik@mzk.cz [2019-07-23 15:03]:
At eduID.at all IdPs are fine with releasing eduPersonTargetedID according to
<md:EntityDescriptor... entityID="https://sdauth.sciencedirect.com/%22%3E ... I suppose. Is it correct, Peter?
Not sure what this is supposed to demonstrate but anyway:
Naturally -- being neither the IDP that sends data nor the SP who recieves data -- I have no way of knowing this for all euID.at IDPs.
I can add that for any IDP I *know* supports persistent NameIDs in principle -- which is still different from releasing it to anyone in particular -- I do record that in their metadata (NameIDFormat elements with "persistent" as value).
From a quick look that's a bit more than a third of our IDPs (19 out of 55 production IDPs), which still is higher than the current count in eduGAIN (720 out of 3062, so less than a fourth of the IDPs).
But there may be some supporting proper persistent NameIDs without us knowing about it. And there's no record of support for eduPersonTargetedID specifically.
I can see a way ahead here:
- Encourage IdPs to release persistent NameID for Elsevier SP. - Request persistent NameID in Elsevier SP metadata and comply with CoCo. - Offer personalisation at Elsevier services when persistent NameID is released. - Roll out pairwise-id support eduGAIN wide.
Could you agree with that?
Thanks a lot, Peter.
Cheers
Jiri
* Jiri Pavlik jiri.pavlik@mzk.cz [2019-07-24 10:53]:
On Tue, Jul 23, 2019 at 3:57 PM Peter Schober peter.schober@univie.ac.at wrote:
From a quick look that's a bit more than a third of our IDPs (19 out of 55 production IDPs), which still is higher than the current count in eduGAIN (720 out of 3062, so less than a fourth of the IDPs).
I can see a way ahead here:
- Encourage IdPs to release persistent NameID for Elsevier SP.
We've been doing that all along, which brought us to the current status quo you quoted above (about 2/3 of our IDPs not supporting persistent NameIDs, nor their modern-day replacement, pairwise-id). Not sure what else we should do. So any good ideas about steps "ahead" stop right there: We tried your step 1, but that only brought us 1/3 of the IDPs (plus the estimated number of false negatives).
We might be able to introduce a few high-visibility (non-library) SPs that require/mandate use of pairwise-id and so would help widen adoption. (For eduPersonTargetedID that comes too late, I wouldn't want to promote new deployments of that.) But then we'd have a hypothetical 100% of IDPs supporting pairwise-id against roughly 0% of (library) SPs supporting it, so that also wouldn't change anything even medium-term.
-peter
On 23.07.19 14:19, Jiri Pavlik wrote:
On Mon, Jul 22, 2019 at 1:27 PM Bernd Oberknapp bo@ub.uni-freiburg.de wrote:
On 2019-07-20 13:24, Peter Schober wrote:
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.)
According to the assessment of GEANT https://www.geant.org/Projects/GEANT_Project_GN4/deliverables/M9-2_Assessmen... both persistent and non-persistent identifiers are personal data according to GDPR because they can both be used to indirectly identify the person. So the only way to avoid personal data would be to not sent any identifier which probably wouldn't be acceptable for many content providers.
Thank you, Bernd, Peter, for clarifying this.
Could be Albert-Ludwigs-Universität Freiburg a representative of a group of universitites, libraries who don't want to release any identifier and want their users to sign-in twice for personalisation? We should tune up 5a in our recommentations according to wishes of this group.
No. In my opinion the solution should be to only release a persistent identifier (as an attribute) when the user wants to use the personalization, so we will look at optionally releasing attributes in the medium/long term.
Best regards, Bernd
On Tue, Jul 23, 2019 at 7:03 PM Bernd Oberknapp bo@ub.uni-freiburg.de wrote:
Could be Albert-Ludwigs-Universität Freiburg a representative of a group of universitites, libraries who don't want to release any identifier and want their users to sign-in twice for personalisation? We should tune up 5a in our recommentations according to wishes of this group.
No. In my opinion the solution should be to only release a persistent identifier (as an attribute) when the user wants to use the personalization, so we will look at optionally releasing attributes in the medium/long term.
I see, thanks!
Best regards
Jiri
On Tue, Jul 23, 2019 at 7:03 PM Bernd Oberknapp bo@ub.uni-freiburg.de wrote:
Could be Albert-Ludwigs-Universität Freiburg a representative of a group of universitites, libraries who don't want to release any identifier and want their users to sign-in twice for personalisation? We should tune up 5a in our recommentations according to wishes of this group.
No. In my opinion the solution should be to only release a persistent identifier (as an attribute) when the user wants to use the personalization, so we will look at optionally releasing attributes in the medium/long term.
I can see there is CAR: Consent-informed Attribute Release system available for optional release of attributes - https://spaces.at.internet2.edu/display/CAR/CAR%3A+Consent-informed+Attribut...
Thanks to Tom Cramer for mentioning the system developed at Duke University.
Best regards
Jiri
Am 30.07.19 um 11:18 schrieb Jiri Pavlik:
On Tue, Jul 23, 2019 at 7:03 PM Bernd Oberknapp bo@ub.uni-freiburg.de wrote:
Could be Albert-Ludwigs-Universität Freiburg a representative of a group of universitites, libraries who don't want to release any identifier and want their users to sign-in twice for personalisation? We should tune up 5a in our recommentations according to wishes of this group.
No. In my opinion the solution should be to only release a persistent identifier (as an attribute) when the user wants to use the personalization, so we will look at optionally releasing attributes in the medium/long term.
I can see there is CAR: Consent-informed Attribute Release system available for optional release of attributes - https://spaces.at.internet2.edu/display/CAR/CAR%3A+Consent-informed+Attribut...
Thanks to Tom Cramer for mentioning the system developed at Duke University.
Yes I remeber a number of Talks Ken Klingenstein gave on that. Concept-wise I think it is good stuff. There also is an integration with Shibboleth IdP done by Shilen Patel also from Duke Univerity. But to be honest, I am not familiar who except Duke is using it
Cheers,
Peter
Best regards
Jiri
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Yes, there are. I don't exactly know how many because no way of reporting on this, but there have always been users from institutions that aren't able to activate personalization because of that and they come and complain.
Please note that our SP, specifically, can make use of eduPersonTargetedID or a Persistent NameID for this purpose; which one the IdP releases depends, I guess, on the software they use (and in some cases on what the federation recommends/configures).
We're currently not requesting or requiring any attributes through our UK Federation metadata because there isn't a perfect way of doing that, and not requesting anything seems to be a lesser problem than otherwise. We don't need to alarm any existing IdPs into changing the released attributes because that would again cause trouble for end users... until we address that problem. It's a work in progress.
We are requesting them through some federations, as you've noticed; that's because at the time of integration that was possible, and done, and it doesn't need to change.
Kind regards, Meshna
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Jiri Pavlik Sent: Friday, July 19, 2019 10:24 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Scopus
*** External email: use caution ***
Hi,
thanks a lot for your comments, Meshna, Leif, Raoul, Peter, Bernd.
Could you share with us, Meshna, whether there are some IdPs which are not releasing targetedID to Elsevier SP currently? This would worth to address in order to avoid users confusion and discomfort when using federated authentication at Elsevier services. I belive there are no such IdPs from eduID.cz despide that requested attributes are missing in Elsevier SP metadata registered in eduGAIN.
Best regards
Jiri
On Thu, Jul 18, 2019 at 10:18 PM Koren, Meshna (ELS-AMS) M.Koren@elsevier.com wrote:
We (Elsevier; as Scopus doesn't have its own SP) tie a targetedID to an 'Elsevier user account' which is created in our database when a user decides to 'activate personalization', so that next time when a user accesses Elsevier product via the IdP, they can access their institutional entitlements AND their personal features with one set of credentials in one go. ('Activate personalization' means the same as 'register' or 'create user account'.)
That is the only way we use targetedID.
"So it's not enough to provide them with the ability to track every movement and every resource one accesses (based on a pseudonymous identifier released by the IDP), they will /only/ offer you the benefit of personalization features if you /also/ tell them exactly who you are with name and email?!
Of course that fully undermines the point of sending them pseudonymous identifiers in the first place."
That's upside down. Something to do with GDPR. We don't create user profiles without user's action. We don't use targetedID to track a user or to maintain a session across different products; that would be useless and unnecessarily complicated, seeing most of our users don't use federated access in the first place.
An IdP doesn't need to release a targetedID. A user can register without it (email + password) if they want to, but then they'll have two sets of credentials and some of them will be eternally confused or annoyed because they can either access subscribed content or their personal features, but not both. They will of course register at other SPs and end up with more credentials, or all these emails with different passwords, or with the same passwords... which completely defies the purpose of federated access.
Kind regards, Meshna
Meshna Koren
Associate Product Manager Product Management - Identity and Platform - Research Products
Elsevier BV Radarweg 29, Amsterdam 1043 NX, The Netherlands m.koren@elsevier.com
Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens, Institutional Login
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Leif Johansson Sent: Thursday, July 18, 2019 22:01 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Scopus
*** External email: use caution ***
So it's not enough to provide them with the ability to track every movement and every resource one accesses (based on a pseudonymous identifier released by the IDP), they will /only/ offer you the benefit of personalisation features if you /also/ tell them exctly who you are with name and email?!
Dude you can provide any information you like there... Thats exactly what a pseudonym is!
Cheers Leif
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands. _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
_______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
________________________________
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands.
I'm wondering what happens if the identifiers sent by an IdP change (identifier added or removed, switch from eduPersonTargetedID to persistent ID or vice versa)? Would the users be able to request an initial password for their email address and, if the IdP sends an identifier, connect their existing Elsevier user account to a new identifier?
Best regards, Bernd
On 19.07.19 15:01, Koren, Meshna (ELS-AMS) wrote:
Yes, there are. I don't exactly know how many because no way of reporting on this, but there have always been users from institutions that aren't able to activate personalization because of that and they come and complain.
Please note that our SP, specifically, can make use of eduPersonTargetedID or a Persistent NameID for this purpose; which one the IdP releases depends, I guess, on the software they use (and in some cases on what the federation recommends/configures).
We're currently not requesting or requiring any attributes through our UK Federation metadata because there isn't a perfect way of doing that, and not requesting anything seems to be a lesser problem than otherwise. We don't need to alarm any existing IdPs into changing the released attributes because that would again cause trouble for end users... until we address that problem. It's a work in progress.
We are requesting them through some federations, as you've noticed; that's because at the time of integration that was possible, and done, and it doesn't need to change.
Kind regards, Meshna
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Jiri Pavlik Sent: Friday, July 19, 2019 10:24 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Scopus
*** External email: use caution ***
Hi,
thanks a lot for your comments, Meshna, Leif, Raoul, Peter, Bernd.
Could you share with us, Meshna, whether there are some IdPs which are not releasing targetedID to Elsevier SP currently? This would worth to address in order to avoid users confusion and discomfort when using federated authentication at Elsevier services. I belive there are no such IdPs from eduID.cz despide that requested attributes are missing in Elsevier SP metadata registered in eduGAIN.
Best regards
JiriOn Thu, Jul 18, 2019 at 10:18 PM Koren, Meshna (ELS-AMS) M.Koren@elsevier.com wrote:
We (Elsevier; as Scopus doesn't have its own SP) tie a targetedID to an 'Elsevier user account' which is created in our database when a user decides to 'activate personalization', so that next time when a user accesses Elsevier product via the IdP, they can access their institutional entitlements AND their personal features with one set of credentials in one go. ('Activate personalization' means the same as 'register' or 'create user account'.)
That is the only way we use targetedID.
"So it's not enough to provide them with the ability to track every movement and every resource one accesses (based on a pseudonymous identifier released by the IDP), they will /only/ offer you the benefit of personalization features if you /also/ tell them exactly who you are with name and email?!
Of course that fully undermines the point of sending them pseudonymous identifiers in the first place."
That's upside down. Something to do with GDPR. We don't create user profiles without user's action. We don't use targetedID to track a user or to maintain a session across different products; that would be useless and unnecessarily complicated, seeing most of our users don't use federated access in the first place.
An IdP doesn't need to release a targetedID. A user can register without it (email + password) if they want to, but then they'll have two sets of credentials and some of them will be eternally confused or annoyed because they can either access subscribed content or their personal features, but not both. They will of course register at other SPs and end up with more credentials, or all these emails with different passwords, or with the same passwords... which completely defies the purpose of federated access.
Kind regards, Meshna
Meshna Koren
Associate Product Manager Product Management - Identity and Platform - Research Products
Elsevier BV Radarweg 29, Amsterdam 1043 NX, The Netherlands m.koren@elsevier.com
Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens, Institutional Login
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Leif Johansson Sent: Thursday, July 18, 2019 22:01 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Scopus
*** External email: use caution ***
So it's not enough to provide them with the ability to track every movement and every resource one accesses (based on a pseudonymous identifier released by the IDP), they will /only/ offer you the benefit of personalisation features if you /also/ tell them exctly who you are with name and email?!
Dude you can provide any information you like there... Thats exactly what a pseudonym is!
Cheers Leif
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands. _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands. _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
That will be different per SP.
Elsevier is updating the access management system from old to new. In the old system a user would lose access to their previous user account when the value of targetedID changed. A persistent NameID is generated in a different way than ePTID so that value would most likely change. There's nothing we can do for such user because a SAML attribute is only validated via a SAML assertion.
In the new system we allow a user to 'link their new credentials' to their existing user account if their attributes change, provided they use the same email address they have used before. You can see that here: https://service.elsevier.com/app/answers/detail/a_id/29105/supporthub/elsevi...
This new system is gradually being implemented across products; quite a lot of work.
Kind regards, Meshna
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Bernd Oberknapp Sent: Friday, July 19, 2019 16:22 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Scopus
*** External email: use caution ***
I'm wondering what happens if the identifiers sent by an IdP change (identifier added or removed, switch from eduPersonTargetedID to persistent ID or vice versa)? Would the users be able to request an initial password for their email address and, if the IdP sends an identifier, connect their existing Elsevier user account to a new identifier?
Best regards, Bernd
On 19.07.19 15:01, Koren, Meshna (ELS-AMS) wrote:
Yes, there are. I don't exactly know how many because no way of reporting on this, but there have always been users from institutions that aren't able to activate personalization because of that and they come and complain.
Please note that our SP, specifically, can make use of eduPersonTargetedID or a Persistent NameID for this purpose; which one the IdP releases depends, I guess, on the software they use (and in some cases on what the federation recommends/configures).
We're currently not requesting or requiring any attributes through our UK Federation metadata because there isn't a perfect way of doing that, and not requesting anything seems to be a lesser problem than otherwise. We don't need to alarm any existing IdPs into changing the released attributes because that would again cause trouble for end users... until we address that problem. It's a work in progress.
We are requesting them through some federations, as you've noticed; that's because at the time of integration that was possible, and done, and it doesn't need to change.
Kind regards, Meshna
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Jiri Pavlik Sent: Friday, July 19, 2019 10:24 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Scopus
*** External email: use caution ***
Hi,
thanks a lot for your comments, Meshna, Leif, Raoul, Peter, Bernd.
Could you share with us, Meshna, whether there are some IdPs which are not releasing targetedID to Elsevier SP currently? This would worth to address in order to avoid users confusion and discomfort when using federated authentication at Elsevier services. I belive there are no such IdPs from eduID.cz despide that requested attributes are missing in Elsevier SP metadata registered in eduGAIN.
Best regards
JiriOn Thu, Jul 18, 2019 at 10:18 PM Koren, Meshna (ELS-AMS) M.Koren@elsevier.com wrote:
We (Elsevier; as Scopus doesn't have its own SP) tie a targetedID to an 'Elsevier user account' which is created in our database when a user decides to 'activate personalization', so that next time when a user accesses Elsevier product via the IdP, they can access their institutional entitlements AND their personal features with one set of credentials in one go. ('Activate personalization' means the same as 'register' or 'create user account'.)
That is the only way we use targetedID.
"So it's not enough to provide them with the ability to track every movement and every resource one accesses (based on a pseudonymous identifier released by the IDP), they will /only/ offer you the benefit of personalization features if you /also/ tell them exactly who you are with name and email?!
Of course that fully undermines the point of sending them pseudonymous identifiers in the first place."
That's upside down. Something to do with GDPR. We don't create user profiles without user's action. We don't use targetedID to track a user or to maintain a session across different products; that would be useless and unnecessarily complicated, seeing most of our users don't use federated access in the first place.
An IdP doesn't need to release a targetedID. A user can register without it (email + password) if they want to, but then they'll have two sets of credentials and some of them will be eternally confused or annoyed because they can either access subscribed content or their personal features, but not both. They will of course register at other SPs and end up with more credentials, or all these emails with different passwords, or with the same passwords... which completely defies the purpose of federated access.
Kind regards, Meshna
Meshna Koren
Associate Product Manager Product Management - Identity and Platform - Research Products
Elsevier BV Radarweg 29, Amsterdam 1043 NX, The Netherlands m.koren@elsevier.com
Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens, Institutional Login
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Leif Johansson Sent: Thursday, July 18, 2019 22:01 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Scopus
*** External email: use caution ***
So it's not enough to provide them with the ability to track every movement and every resource one accesses (based on a pseudonymous identifier released by the IDP), they will /only/ offer you the benefit of personalisation features if you /also/ tell them exctly who you are with name and email?!
Dude you can provide any information you like there... Thats exactly what a pseudonym is!
Cheers Leif
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands. _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands. _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
-- Bernd Oberknapp Gesamtleitung ReDI
Albert-Ludwigs-Universität Freiburg Universitätsbibliothek Platz der Universität 2 | Postfach 1629 D-79098 Freiburg | D-79016 Freiburg
Telefon: +49 761 203-3852 Telefax: +49 761 203-3987 E-Mail: bo@ub.uni-freiburg.de Internet: www.ub.uni-freiburg.de
________________________________
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands.
On Sat, 20 Jul 2019 at 00:46, Koren, Meshna (ELS-AMS) M.Koren@elsevier.com wrote:
That will be different per SP.
Elsevier is updating the access management system from old to new. In the old system a user would lose access to their previous user account when the value of targetedID changed. A persistent NameID is generated in a different way than ePTID so that value would most likely change. There's nothing we can do for such user because a SAML attribute is only validated via a SAML assertion.
In the new system we allow a user to 'link their new credentials' to their existing user account if their attributes change, provided they use the same email address they have used before. You can see that here: https://service.elsevier.com/app/answers/detail/a_id/29105/supporthub/elsevi...
👏🏻
Cheers
Jiri
This new system is gradually being implemented across products; quite a lot of work.
Kind regards, Meshna
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Bernd Oberknapp Sent: Friday, July 19, 2019 16:22 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Scopus
*** External email: use caution ***
I'm wondering what happens if the identifiers sent by an IdP change (identifier added or removed, switch from eduPersonTargetedID to persistent ID or vice versa)? Would the users be able to request an initial password for their email address and, if the IdP sends an identifier, connect their existing Elsevier user account to a new identifier?
Best regards, Bernd
On 19.07.19 15:01, Koren, Meshna (ELS-AMS) wrote:
Yes, there are. I don't exactly know how many because no way of
reporting on this, but there have always been users from institutions that aren't able to activate personalization because of that and they come and complain.
Please note that our SP, specifically, can make use of
eduPersonTargetedID or a Persistent NameID for this purpose; which one the IdP releases depends, I guess, on the software they use (and in some cases on what the federation recommends/configures).
We're currently not requesting or requiring any attributes through our
UK Federation metadata because there isn't a perfect way of doing that, and not requesting anything seems to be a lesser problem than otherwise. We don't need to alarm any existing IdPs into changing the released attributes because that would again cause trouble for end users... until we address that problem. It's a work in progress.
We are requesting them through some federations, as you've noticed;
that's because at the time of integration that was possible, and done, and it doesn't need to change.
Kind regards, Meshna
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Jiri Pavlik Sent: Friday, July 19, 2019 10:24 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Scopus
*** External email: use caution ***
Hi,
thanks a lot for your comments, Meshna, Leif, Raoul, Peter, Bernd.
Could you share with us, Meshna, whether there are some IdPs which are
not releasing targetedID to Elsevier SP currently?
This would worth to address in order to avoid users confusion and
discomfort when using federated authentication at Elsevier services. I belive there are no such IdPs from eduID.cz despide that requested attributes are missing in Elsevier SP metadata registered in eduGAIN.
Best regards
JiriOn Thu, Jul 18, 2019 at 10:18 PM Koren, Meshna (ELS-AMS) <
M.Koren@elsevier.com> wrote:
We (Elsevier; as Scopus doesn't have its own SP) tie a targetedID to an 'Elsevier user account' which is created in our database when a user decides to 'activate personalization', so that next time when a user accesses Elsevier product via the IdP, they can access their institutional entitlements AND their personal features with one set of credentials in one go. ('Activate personalization' means the same as 'register' or 'create user account'.)
That is the only way we use targetedID.
"So it's not enough to provide them with the ability to track every
movement and every resource one accesses (based on a pseudonymous identifier released by the IDP), they will /only/ offer you the benefit of personalization features if you /also/ tell them exactly who you are with name and email?!
Of course that fully undermines the point of sending them pseudonymous
identifiers in the first place."
That's upside down. Something to do with GDPR. We don't create user
profiles without user's action. We don't use targetedID to track a user or to maintain a session across different products; that would be useless and unnecessarily complicated, seeing most of our users don't use federated access in the first place.
An IdP doesn't need to release a targetedID. A user can register
without it (email + password) if they want to, but then they'll have two sets of credentials and some of them will be eternally confused or annoyed because they can either access subscribed content or their personal features, but not both. They will of course register at other SPs and end up with more credentials, or all these emails with different passwords, or with the same passwords... which completely defies the purpose of federated access.
Kind regards, Meshna
Meshna Koren
Associate Product Manager Product Management - Identity and Platform - Research Products
Elsevier BV Radarweg 29, Amsterdam 1043 NX, The Netherlands m.koren@elsevier.com
Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens, Institutional Login
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Leif Johansson Sent: Thursday, July 18, 2019 22:01 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Scopus
*** External email: use caution ***
So it's not enough to provide them with the ability to track every movement and every resource one accesses (based on a pseudonymous identifier released by the IDP), they will /only/ offer you the benefit of personalisation features if you /also/ tell them exctly who you are with name and email?!
Dude you can provide any information you like there... Thats exactly
what a pseudonym is!
Cheers Leif
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The
Netherlands, Registration No. 33156677, Registered in The Netherlands.
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The
Netherlands, Registration No. 33156677, Registered in The Netherlands.
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
-- Bernd Oberknapp Gesamtleitung ReDI
Albert-Ludwigs-Universität Freiburg Universitätsbibliothek Platz der Universität 2 | Postfach 1629 D-79098 Freiburg | D-79016 Freiburg
Telefon: +49 761 203-3852 Telefax: +49 761 203-3987 E-Mail: bo@ub.uni-freiburg.de Internet: www.ub.uni-freiburg.de
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands. _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Hi Meshna and thanks for chiming in.
* Koren, Meshna (ELS-AMS) M.Koren@elsevier.com [2019-07-18 22:18]:
We (Elsevier; as Scopus doesn't have its own SP) tie a targetedID to an 'Elsevier user account' which is created in our database when a user decides to 'activate personalization', so that next time when a user accesses Elsevier product via the IdP, they can access their institutional entitlements AND their personal features with one set of credentials in one go. ('Activate personalization' means the same as 'register' or 'create user account'.)
In your service, OK. Some of the issues I mentioned are specific to sites where account creation includes setting Yet Another Password, which IMO has too many drawbacks to be a viable option only in order to get access to personalisation functions. Lets ignore that since it's not applicable here.
Of course that fully undermines the point of sending them pseudonymous identifiers in the first place.
That's upside down. Something to do with GDPR. We don't create user profiles without user's action. We don't use targetedID to track a user or to maintain a session across different products
You'll understand that all we have to go on here is your word that this is the case (and that it is the case Right Now). Because you fully have ability to perform such tracking once an institution releases a suitably persistent identifier. Will that remain that way a few weeks down the road, a few years? E.g. if someone discovers thi a new way to generate "usage patterns" from the current site(s)? What if management and/or ownership changes?
I fully believe you when you state the above but you'll have to realise that this may not be good enough for everyone.
And IDPs would have to /always/ send an identifier along that technically /already/ allows you to track all users' every move -- just in case one of them ever decided to "activate personalisation" and provide (even) more information about herself.
Speaking of personalisation: Wouldn't it suffice if I just let you know that I want to activate personalisation, without also providing more personal data? I don't see why the former would require the latter.
Sure, email notifications won't work without providing an email address. But maybe that's fine for me a I'm not interested in recieving emails? And I certainly don't need to be greeted by my own name and you don't need my name in order to provide a personalised UX. So the whole "because GDPR" isn't all that convinging if you force me to reveal more data than necessary for procesing (if I wanted peronsaliastion) and then use my freely given (?!) consent as justfication for that processing?
An IdP doesn't need to release a targetedID. A user can register without it (email + password) if they want to, but then they'll have two sets of credentials and some of them will be eternally confused or annoyed because they can either access subscribed content or their personal features, but not both. They will of course register at other SPs and end up with more credentials, or all these emails with different passwords, or with the same passwords... which completely defies the purpose of federated access.
Sure, completely agree.
But IDPs are still confronted with the hard question of whether the potential for hypothetical, individual activation of personalisation features justifies always releasing data to the SP that factually allows it to track every subject's every move (whether the SP promises to do that today or not).
The main -- or in fact *only* -- argument to always take that risk as an IDP (and arguably lessen all users' privacy) is exactly the above: The nightmarei-sh UX subjects will be exposed to /if/ they positively need personalisation features but the IDP doesn't release a suitable identifer. That's to be balanced with the number of subjects who don't care about personalisation (or who are not prepared to accept the added requirement for personal data, in your example) and for whom always sending along a suitable identifier increases their exposure and lessens their privacy.
Happy to hear counter-arguments or dissenting observations!
Best regards, -peter
Hi All,
Thanks for this really interesting discussion. That is exactly what I envisaged in this group: technical and political discussions between different interest groups.
We should always make a distinction between actual practice and our recommendations for libraries. Of course it will be ideal, if everyone will adhere to the recommendations ...
I more or less side with Peter S. on the point that permanent targeted Identifier should be sufficient for personalisation (without being addressed by name). Getting consent from the user via "activate personalisation" sounds good and GDPR compliant to me as well, if the user gets informed that
"by pushing this button, I agree that the service provider stores my person related data (ID, affiliation, entitlements sent by my IdP, my IP address sent by my client, and my actions on this platform). Only if I want to receive emails from the service or if I want to be addressed by my name, I will add my email address and name respectively, but this is not needed for any other personalisation features like 'point me to the last document and its last page I read', 'my last searches', <include your personalisation feature here>, etc. Whenever I wish to, I may request to see and to have deleted all these data stored about me."
I propose that we address this use case in more detail in our recommendation than it is by now.
If the service decides for trading personalisation features with name and email address it should make this also transparent. But we would not recommend such a trade in our recommendations.
Once again: Thanks a lot for this really fruitful discussion.
Cheers,
Peter G.
Am 19.07.19 um 15:08 schrieb Peter Schober:
Hi Meshna and thanks for chiming in.
- Koren, Meshna (ELS-AMS) M.Koren@elsevier.com [2019-07-18 22:18]:
We (Elsevier; as Scopus doesn't have its own SP) tie a targetedID to an 'Elsevier user account' which is created in our database when a user decides to 'activate personalization', so that next time when a user accesses Elsevier product via the IdP, they can access their institutional entitlements AND their personal features with one set of credentials in one go. ('Activate personalization' means the same as 'register' or 'create user account'.)
In your service, OK. Some of the issues I mentioned are specific to sites where account creation includes setting Yet Another Password, which IMO has too many drawbacks to be a viable option only in order to get access to personalisation functions. Lets ignore that since it's not applicable here.
Of course that fully undermines the point of sending them pseudonymous identifiers in the first place.
That's upside down. Something to do with GDPR. We don't create user profiles without user's action. We don't use targetedID to track a user or to maintain a session across different products
You'll understand that all we have to go on here is your word that this is the case (and that it is the case Right Now). Because you fully have ability to perform such tracking once an institution releases a suitably persistent identifier. Will that remain that way a few weeks down the road, a few years? E.g. if someone discovers thi a new way to generate "usage patterns" from the current site(s)? What if management and/or ownership changes?
I fully believe you when you state the above but you'll have to realise that this may not be good enough for everyone.
And IDPs would have to /always/ send an identifier along that technically /already/ allows you to track all users' every move -- just in case one of them ever decided to "activate personalisation" and provide (even) more information about herself.
Speaking of personalisation: Wouldn't it suffice if I just let you know that I want to activate personalisation, without also providing more personal data? I don't see why the former would require the latter.
Sure, email notifications won't work without providing an email address. But maybe that's fine for me a I'm not interested in recieving emails? And I certainly don't need to be greeted by my own name and you don't need my name in order to provide a personalised UX. So the whole "because GDPR" isn't all that convinging if you force me to reveal more data than necessary for procesing (if I wanted peronsaliastion) and then use my freely given (?!) consent as justfication for that processing?
An IdP doesn't need to release a targetedID. A user can register without it (email + password) if they want to, but then they'll have two sets of credentials and some of them will be eternally confused or annoyed because they can either access subscribed content or their personal features, but not both. They will of course register at other SPs and end up with more credentials, or all these emails with different passwords, or with the same passwords... which completely defies the purpose of federated access.
Sure, completely agree.
But IDPs are still confronted with the hard question of whether the potential for hypothetical, individual activation of personalisation features justifies always releasing data to the SP that factually allows it to track every subject's every move (whether the SP promises to do that today or not).
The main -- or in fact *only* -- argument to always take that risk as an IDP (and arguably lessen all users' privacy) is exactly the above: The nightmarei-sh UX subjects will be exposed to /if/ they positively need personalisation features but the IDP doesn't release a suitable identifer. That's to be balanced with the number of subjects who don't care about personalisation (or who are not prepared to accept the added requirement for personal data, in your example) and for whom always sending along a suitable identifier increases their exposure and lessens their privacy.
Happy to hear counter-arguments or dissenting observations!
Best regards, -peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
* Peter Gietz peter.gietz@daasi.de [2019-07-19 21:12]:
Getting consent from the user via "activate personalisation" sounds good and GDPR compliant to me as well, if the user gets informed that
"by pushing this button, I agree that the service provider stores my person related data (ID, affiliation, entitlements sent by my IdP, my IP address sent by my client, and my actions on this platform). Only if I want to receive emails from the service or if I want to be addressed by my name, I will add my email address and name respectively, but this is not needed for any other personalisation features like 'point me to the last document and its last page I read', 'my last searches', <include your personalisation feature here>, etc. Whenever I wish to, I may request to see and to have deleted all these data stored about me."
Sounds good!
I propose that we address this use case in more detail in our recommendation than it is by now.
If the service decides for trading personalisation features with name and email address it should make this also transparent. But we would not recommend such a trade in our recommendations.
+1
Thanks, -peter
On 18/07/2019, 16:13, "FIM4L on behalf of Peter Schober" <fim4l-bounces@lists.daasi.demailto:fim4l-bounces@lists.daasi.de on behalf of peter.schober@univie.ac.atmailto:peter.schober@univie.ac.at> wrote:
* Jiri Pavlik <jiri.pavlik@mzk.czmailto:jiri.pavlik@mzk.cz> [2019-07-18 14:49]:
At Scopus users can activate personalisation adding name and e-mail address. A screenshot attached.
Sorry, but no: It's simply impossible to "activate personalisation" on top of a federated login if the IDP does not already release an identifier that allows the SP to recognise a returning subject.
I think it depends on your definition of ‘personalisation’? If being welcomed by your actual name, seeing your name in certain screens, getting emails directly etc is your definition of personalisation, I would say I concur with Jiri.
Raoul.
Teilnehmer (8)
-
Bernd Oberknapp -
Jiri Pavlik -
Jos Westerbeke -
Koren, Meshna (ELS-AMS) -
Leif Johansson -
Peter Gietz -
Peter Schober -
Raoul Teeuwen