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

Wed Mar 17 15:16:04 CET 2021

Hi Meshna,

I see, thanks a lot for the clarification.

I managed to link my institutional account to my personal e-mail address.
That's great.

Let me suggest linking institutional accounts to personal
Apple / Google / ORCID accounts in the future to avoid a need
to set up a password at Elsevier account. There are
SAML - Apple / Google / ORCID gateways available which can
be used for the account linking and sign in using Apple / Google / ORCID
account via SAML -
   https://www.eduid.cz/cs/tech/socialidps (info currently in Czech only,
sorry)

Best
               Jiri

On Wed, Mar 17, 2021 at 1:29 PM Koren, Meshna (ELS-AMS) <
M.Koren at elsevier.com> wrote:

> 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> 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>
> *Sent:* Tuesday, March 16, 2021 09:5
> *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 ****
>
>
>
> 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
> <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/7ca50d82/attachment-0001.html>