_______________________________________________Hi Bernd, all,
I'm all for a consent screen (yes, of the right kind :) ) and I hope the community will have a good discussion and take fine measures on it.
But the fact is that it's the IdPs homework to either trust or not trust an SP and to either send or not send any PII. You can't shove that responsibility into a user's lap.
Let's explore something:
1. A user
A user wants to read 3 articles that happen to be on 3 different platforms, and conveniently uses their institutional credentials for doing so. They sign in with one set of creds to their trusted website. They get access to articles and save or read them, and perhaps explore some related content or recommendations on one or more of those platforms. Perhaps they find something interesting and want to store some personal features; they click on 'register' or the equivalent and are able to create local account, sometimes providing some additional information about themselves. <- There's nothing preventing them from focusing on the topic of their research in this flow and a local account will be linked to their pseudonymous ID.
Next time they return via their institution, they will get access to other articles *and* their personal features.
Such a user has one set of credentials rather than 4 separate ones. They don't need to remember multiple creds and passwords, change them at random times, and they don't need to sign out / sign in to be able to either read subscribed content or manage their personal features.
They don't have time and are not focused, during their workflow, to read, understand and comprehend the system behind this, and to make an informed decision of whether or not to allow the IdP to release a pseudonymous identifier (or any other data) to the SP behind that article. They also are never making a decision on whether to register or not at the point they are entering a new platform, that comes later.
2. There's a whole *trust infrastructure* in place for the IdP to be able to make an informed decision about what to send in SAML assertion in advance; the academic community has been working really hard for the last 20 years to build, maintain, scale and improve it; through federations, REFEDS, Baseline Expectations, CoCo, SIRTFI, etc.
There's room for improvement, it's a process, but what you're saying by inserting a 'pick and choose PII' screen between a user and an article is that as an IdP you essentially don't trust this trust infrastructure, and that a student is able to make a better decision about that than a manager of an IdP... and well, that's just not true.
===
It is possible to allow the user to keep their user accounts when they move between institutions or work for multiple ones, we've already done that. A person can easily sign in to their account with any credentials, as long as they're able to prove they're the same person when they link their new credentials to their existing Elsevier account.
We want to make things easier *and* safer for users, not more complicated. Adding of an additional screen in front of a user always generates a ton of complaints from libraries and researchers. Breaking federated access flow into even more steps and introducing different sets of credentials is not doing anyone a favor, it breaks Seamless Access and similar tools that are built for that very purpose and it confuses people (once I get access, once I don't, no idea why, the publisher's site is broken).
I'm not sure what you're referring to by pointing to Pubmed, please elaborate.
Kind regards,
Meshna
From: FIM4L <fim4l-bounces@lists.daasi.de> On Behalf Of Ken Klingenstein
Sent: Tuesday, March 16, 2021 04:19
To: fim4l@lists.daasi.de
Subject: [Fim4l] a few meta-comments about the LexisNexis Advance Thread
*** External email: use caution ***
All,
I just wanted to make a few comments about the thread going on about attribute release/consent for LexisNexis et al.
First of all, it is the best discussion that I have seen about the details of attribute release, legal bases, personalization, etc. in the federated landscape. I really appreciate the issues and subtleties that we are exploring.
Peter’s proposal was rich with topics worth some exploring on their own. For example, the pluses and minuses of IdP vs SP consent approaches, including trust, consolidated user consent consoles, purpose of use fields. For example, developing a modest purpose of use taxonomy for R&E. (The new cookie-based consent taxonomy that the advertising industry did recently under GDPR prodding doesn’t work for us but is indicative that a simple set of purposes is possible.) For example, combining consent and notification (e.g. of a release based on legitimate interest) in a single UI. I hope we continue discussion on these and other topics.
Finally, I share Peter’s realism about the scale issues in changing behaviors of IdP’s, but the FIM4R community has been successful in driving large scale IdP behavior changes (such as in incident handling). It is possible that FIM4L can find success in fostering privacy-preserving behaviors.
Ken
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33158992, Registered in The Netherlands.
FIM4L mailing list
FIM4L@lists.daasi.de
http://lists.daasi.de/listinfo/fim4l