[Fim4l] a few meta-comments about the LexisNexis Advance Thread

Jiri Pavlik jiri.pavlik at techlib.cz
Tue Mar 16 09:49:48 CET 2021


Hi Meshna,

great to learn that Elsevier already supports accounts linking. Is it
available at Science Direct?
I'd love to try it out :-)

Best
               Jiri


On Tue, Mar 16, 2021 at 9:32 AM Koren, Meshna (ELS-AMS) <
M.Koren at elsevier.com> wrote:

> 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 at lists.daasi.de> *On Behalf Of *Ken
> Klingenstein
> *Sent:* Tuesday, March 16, 2021 04:19
> *To:* fim4l at 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 at lists.daasi.de
> http://lists.daasi.de/listinfo/fim4l
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.daasi.de/pipermail/fim4l/attachments/20210316/7dcfafe4/attachment.html>


More information about the FIM4L mailing list