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

Wed Mar 17 13:29:20 CET 2021

Hi Jiri,

I will send you a separate email, listing user accounts you already have with us...

There are two different things;

1. institutional entitlements -

Institutions pay for access and they also want to know what the real usage is, such as COUNTER reports, so it's not possible to get joint entitlements of multiple institutions at the same time. If you got access both NLT and Zlin at the same time, and downloaded an article from a journal to which both institutions happen to subscribe to, we wouldn't know whether to report the download through NLT or Zlin account, and it wouldn't be right to report it through both; that's just one example of why that's not possible (today, anyhow).

So as a user, if you have the rights to access Elsevier through mutliple institutions, you need to make a choice through which one you will get access. If you want to change the institution, you'll first need to sign out and then sign in via other means.

2. user identity -

This is what I was referring to; your user account is in your control and you should be able to sign in to it (and see your personal features) regardless of which institution you have access... although that may be tricky, too, because some personal features are linked to institutional subscriptions and you aren't able to view them without also having access to the product.

Now some users already have multiple user accounts (that's your situation) due to historical reasons and those can't be merged, the only solution is for them to contact our helpdesk and have the accounts they don't need, deleted.

The problem we have solved is in that when a user has one Elsevier account, but they change institution, or their institution changes access methods, or institution changes entityID or pseudonymous IDs, those user can sign in to their existing user account with their new credentials. And users can also add additional emails to their account to be sure they can still sign in to it after they don't have institutional email anymore...

In most cases what happens is that a user signs in with their new credentials, click on 'register' or 'crete account' and when they provide email, we detect and existing account and if they are able to confirm they are the owner of that mailbox, we will link their new credentials to their existing account. That's what you should try.

Kind regards,
Meshna

From: Jiri Pavlik <jiri.pavlik at techlib.cz>
Sent: Tuesday, March 16, 2021 11:37
To: Koren, Meshna (ELS-AMS) <M.Koren at elsevier.com>
Cc: fim4l at lists.daasi.de
Subject: Re: [Fim4l] a few meta-comments about the LexisNexis Advance Thread

*** External email: use caution ***

Just signed with my National library of Technology account at SD and I can't see how to link
my Tomas Bata University in Zlin account. Is there a how-to available? p-)
Accessing university content enriched with a public library content would be amazing :-)

Cheers

             Jiri

On Tue, Mar 16, 2021 at 11:14 AM Koren, Meshna (ELS-AMS) <M.Koren at elsevier.com<mailto:M.Koren at elsevier.com>> wrote:
Yes Jiri!

There are several different linking flows that you can go into, depending on whether your existing Elsevier user account is email/pw or institutional credential, and depending on whether you want to add a new email to it, or a new institutional credential, or a password... Why don't you explore it :)

Cheers,
Meshna

From: Jiri Pavlik <jiri.pavlik at techlib.cz<mailto:jiri.pavlik at techlib.cz>>
Sent: Tuesday, March 16, 2021 09:5
To: Koren, Meshna (ELS-AMS) <M.Koren at elsevier.com<mailto:M.Koren at elsevier.com>>
Cc: fim4l at lists.daasi.de<mailto:fim4l at lists.daasi.de>
Subject: Re: [Fim4l] a few meta-comments about the LexisNexis Advance Thread

*** External email: use caution ***

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<mailto: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<mailto:fim4l-bounces at lists.daasi.de>> On Behalf Of Ken Klingenstein
Sent: Tuesday, March 16, 2021 04:19
To: fim4l at lists.daasi.de<mailto: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<mailto:FIM4L at lists.daasi.de>
http://lists.daasi.de/listinfo/fim4l<https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.daasi.de%2Flistinfo%2Ffim4l&data=04%7C01%7CM.Koren%40elsevier.com%7C209a18944db24b848e2608d8e867704a%7C9274ee3f94254109a27f9fb15c10675d%7C0%7C0%7C637514878282742289%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aTfdKB4W08xyXqLG9aV0CoQ65%2FJ6Fo0lrHSzYJbTuA8%3D&reserved=0>

________________________________

Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33158992, Registered in The Netherlands.

________________________________

Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33158992, Registered in The Netherlands.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.daasi.de/pipermail/fim4l/attachments/20210317/fe9b0c08/attachment-0001.html>