Hi Jiri, Bernd et al,

thank you for this discussion. This is very meaningful for downplaying the FIM4L recommendations 4.A and 4.B to a more simple level.

We now have two recommendations which you have to (unfortunately) choose:

4.A. Transitory Access - eduPersonTargetedID as optional would be fine for this. 4.B. Personalized Access - eduPersonTargetedID required. - And for 4.B the recommendation is to let it be for the SP side to offer a profile, voluntarily to configure by users. So that in any way IdP's do not have to release PII. (https://www.fim4l.org/?page_id=257)

What would we actually recommend for librarians? Wouldn't it be nice to have just one option? I think it is too difficult for librarians to choose here.

Reading the discussion, we can say that we cannot recommend going just for 4.B. And if librarians consider switching form IP to SAML they are very suspicious about privacy.

Can we recommend for both IdP's and SP's to go for 4.A?

What about recommending 4.A and have the option for 4.B when there is an agreement between IdP and SP about creating profiles, anchored in a contract?

Should we recommend a contract clausula alongside 4.B?

As far as I understand, I'm aware of what Meshna says: If you opt for 4.A then it is simply not possible to have a profile, which is very annoying if not impossible for our patrons.

Best, Jos

________________________________ From: FIM4L fim4l-bounces@lists.daasi.de on behalf of Jiri Pavlik jiri.pavlik@techlib.cz Sent: 15 March 2021 14:58 To: Koren, Meshna (ELS-AMS) M.Koren@elsevier.com Cc: fim4l@lists.daasi.de fim4l@lists.daasi.de Subject: Re: [Fim4l] LexisNexis Advance

Hi Meshna,

thanks a lot for the comments.

At Elsevier SP metadata [1] I can see: eduPersonEntitlement (required) eduPersonTargetedID (optional) in DFN-AAI, IDEM or Australian Access Federation.

At the SP metadata in eduGAIN / UK Federation there are no requested attributes. At the SP metadata in eduID.at, SWITCHaai, InCommon, RENATER I can see: eduPersonEntitlement (required) eduPersonTargetedID (required)

It illustrates different approaches around the world how to express optional ePTID release in SP metadata and a challenge for one appropriate SP metadata in eduGAIN serving globally. To me eduPersonEntitlement (required) eduPersonTargetedID (optional) seems as the most appropriate.

Cheers Jiri

1. https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.c...https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmet.refeds.org%2Fmet%2Fentity%2Fhttps%25253A%25252F%25252Fsdauth.sciencedirect.com%25252F%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761630378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HmuCXxy9%2F1bQBVkGnsrbBcRmNJP9DsiETfB4g6uP0L4%3D&reserved=0

On Mon, Mar 15, 2021 at 12:01 PM Koren, Meshna (ELS-AMS) <M.Koren@elsevier.commailto:M.Koren@elsevier.com> wrote:

Please allow me to add something to this discussion.

"The university students and staff are free to use personalisation at Lexis Nexis, Elsevier, EBSCO, ProQuest services if they want to so eduPersonScopedAffiliation (required) eduPersonEntitlement (required) eduPersonTargetedID (optional)..."

The students and staff can only use personalization when the IdP releases ePTID (or pairwiseID), otherwise they can't. I am not sure that this is clear from the metadata nor that the labels we use to describe the required attributes are very clear on what 'optional' means.

For example, when a student accesses ScienceDirect they can read subscribed articles whether or not ePTID has been released for them, but if they want to 'create account' because they would like to save searches, alerts or their search history, they can only do that if the IdP has released a persistent identifier for them. Otherwise they can't, because there's nothing in their SAML assertions that allows us to recognize the returning individual. So we are working towards requiring a persistent ID. The personalization remains optional for the user.

That may not be the same for other SPs, but it is valid for Elsevier.

Kind regards,

Meshna

Meshna Koren

Product Manager II

Product Management - Identity and Access - Research Products

Elsevier BV

Radarweg 29, Amsterdam 1043 NX, The Netherlands

m.koren@elsevier.commailto:m.koren@elsevier.com

Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens, Institutional Login

Elsevier Access Support Center: https://service.elsevier.com/app/answers/list/c/10543/supporthub/elsevieracc...https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fservice.elsevier.com%2Fapp%2Fanswers%2Flist%2Fc%2F10543%2Fsupporthub%2Felsevieraccess%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761640371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=s2nQIh1Mocby%2Fnr0uG61jf%2Fg%2FWgqr%2FfHj6MhuH5sHHs%3D&reserved=0

for your questions about which access methods does Elsevier support, how to set them up, how do they work for users...

From: FIM4L <fim4l-bounces@lists.daasi.demailto:fim4l-bounces@lists.daasi.de> On Behalf Of Jiri Pavlik Sent: Sunday, March 14, 2021 15:28 To: Bernd Oberknapp <bo@ub.uni-freiburg.demailto:bo@ub.uni-freiburg.de> Cc: fim4l@lists.daasi.demailto:fim4l@lists.daasi.de Subject: Re: [Fim4l] LexisNexis Advance

*** External email: use caution ***

Hi Bernd,

I see, eduPersonScopedAffiliation (required) eduPersonEntitlement (required) is working for Freiburg University and eduPersonScopedAffiliation (required) eduPersonEntitlement (required) eduPersonTargetedID (required) is not.

The university students and staff are free to use personalisation at Lexis Nexis, Elsevier, EBSCO, ProQuest services if they want to so eduPersonScopedAffiliation (required) eduPersonEntitlement (required) eduPersonTargetedID (optional) is working for the University as well.

Is it correct?

All the best

Jiri

On Sat, Mar 13, 2021 at 2:40 PM Bernd Oberknapp <bo@ub.uni-freiburg.demailto:bo@ub.uni-freiburg.de> wrote:

Hi Jiri,

On 13.03.21 09:15, Jiri Pavlik wrote:

When checking ProQuest SP for ProQuest Central in DFN-AAI metadata [1] I can see both eduPersonEntitlement and eduPersonTargetedID as required attributes.

I assume you mean the SP https://shibboleth-sp.prod.proquest.com/shibbolethhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth-sp.prod.proquest.com%2Fshibboleth&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761640371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bosxymzT3WPyXBdeX0NnT5AvLDmTecE%2BEbZe6krDBwk%3D&reserved=0? That's obviously wrong, both eduPersonScopedAffiliation and eduPersonEntitlement are supported for authorization, but as far as I can tell you don't have to use them, and eduPersonTargetedID isn't required.

Is it safe to assume that if there is personalisation capability at a library service then all German universities, libraries are fine with releasing eduPersonTargetedID for recognising returning users and eduPersonEntitlement, eduPersonScopedAffiliation for authorisation?

No. I can't speak for other IdPs, but in my opinion that approach would be wrong, users by default should be able to use services anonymously, without being recognized as a returning user. Based on what I can see in the admin tools, only a very small percentage of our users actually uses the personalization features, so releasing eduPersonTargetedID by default just for personalization isn't an option. If publishers would force us to send an eduPersonTargetedID just for personalization I would consider dropping Shibboleth for those publishers and using our EZproxy instead.

Best regards, Bernd

-- 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.demailto:bo@ub.uni-freiburg.de Internet: www.ub.uni-freiburg.dehttps://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ub.uni-freiburg.de%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761650360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eLOZmpzI51ttj9vd4uSNyCcFAAxIPZKUWoSATsoVq1k%3D&reserved=0

________________________________

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

I assume the recommendation would be to use pairwise-id (not subject-id) for personalization, and eduPersonTargetedID as a fallback for IdPs or SPs that don't support pairwise-id yet.

If a SP supports eduPersonTargetedID it has to be prepared to transition to pairwise-id and preserve the personal accounts during that transition.

Best regards, Bernd

On 15.03.21 16:26, Heather Flanagan wrote:

I know it does not help matters, but I need to point out that eduPersonTargetedID is actually deprecated due to security concerns. Instead, organizations are encouraged to use the SAML attribute, subject-id

(https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-sub...).

Heather Flanagan — Translator of Geek to Human https://sphericalcowconsulting.com On Mar 15, 2021, 8:18 AM -0700, Jos Westerbeke jos.westerbeke@eur.nl, wrote:

...

Hi Jiri, Bernd et al,

thank you for this discussion. This is very meaningful for downplaying the FIM4L recommendations 4.A and 4.B to a more simple level.

We now have two recommendations which you have to (unfortunately)

choose:

...

4.A. Transitory Access - eduPersonTargetedID as optional would be fine for this. 4.B. Personalized Access - eduPersonTargetedID required.

• And for 4.B the recommendation is to let it be for the SP side to

offer a profile, voluntarily to configure by users. So that in any way IdP's do not have to release PII. (https://www.fim4l.org/?page_id=257)

What would we actually recommend for librarians? Wouldn't it be nice to have just one option? I think it is too difficult for librarians to choose here.

Reading the discussion, we can say that we cannot recommend going just for 4.B. And if librarians consider switching form IP to SAML they are very suspicious about privacy.

Can we recommend for both IdP's and SP's to go for 4.A?

What about recommending 4.A and have the option for 4.B when there is an agreement between IdP and SP about creating profiles, anchored in a contract?

Should we recommend a contract clausula alongside 4.B?

As far as I understand, I'm aware of what Meshna says: If you opt for 4.A then it is simply not possible to have a profile, which is very annoying if not impossible for our patrons.

Best, Jos

---

*From:* FIM4L fim4l-bounces@lists.daasi.de on behalf of Jiri Pavlik jiri.pavlik@techlib.cz *Sent:* 15 March 2021 14:58 *To:* Koren, Meshna (ELS-AMS) M.Koren@elsevier.com *Cc:* fim4l@lists.daasi.de fim4l@lists.daasi.de *Subject:* Re: [Fim4l] LexisNexis Advance Hi Meshna,

thanks a lot for the comments.

At Elsevier SP metadata [1] I can see: eduPersonEntitlement (required) eduPersonTargetedID (optional) in DFN-AAI, IDEM or Australian Access Federation.

At the SP metadata in eduGAIN / UK Federation there are no requested attributes. At the SP metadata in eduID.at, SWITCHaai, InCommon, RENATER I can see: eduPersonEntitlement (required) eduPersonTargetedID (required)

It illustrates different approaches around the world how to express optional ePTID release in SP metadata and a challenge for one appropriate SP metadata in eduGAIN serving globally. To me eduPersonEntitlement (required) eduPersonTargetedID (optional) seems as the most appropriate.

Cheers Jiri

https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.c...

...

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmet.refeds.org%2Fmet%2Fentity%2Fhttps%25253A%25252F%25252Fsdauth.sciencedirect.com%25252F%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761630378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HmuCXxy9%2F1bQBVkGnsrbBcRmNJP9DsiETfB4g6uP0L4%3D&reserved=0

...

On Mon, Mar 15, 2021 at 12:01 PM Koren, Meshna (ELS-AMS) <M.Koren@elsevier.com mailto:M.Koren@elsevier.com> wrote:

Please allow me to add something to this discussion. ____

__ __

"The university students and staff are free to use personalisation
at Lexis Nexis,
Elsevier, EBSCO, ProQuest services if they want to so
  eduPersonScopedAffiliation (required)
  eduPersonEntitlement  (required)
  eduPersonTargetedID (optional)..."

____

The students and staff can only use personalization when the IdP
releases ePTID (or pairwiseID), otherwise they can't. I am not
sure that this is clear from the metadata nor that the labels we
use to describe the required attributes are very clear on what
'optional' means.____

__ __

For example, when a student accesses ScienceDirect they can read
subscribed articles whether or not ePTID has been released for
them, but if they want to 'create account' because they would like
to save searches, alerts or their search history, they can only do
that if the IdP has released a persistent identifier for them.
Otherwise they can't, because there's nothing in their SAML
assertions that allows us to recognize the returning individual.
So we are working towards requiring a persistent ID. The
personalization remains optional for the user.____

__ __

That may not be the same for other SPs, but it is valid for
Elsevier. ____

__ __

Kind regards,____

Meshna____

__ __

__ __

*__ __*

*Meshna Koren* *____*


/Product Manager II____/

*/Product Management - Identity and Access/* */-/* */Research
Products/**/____/*

*/__ __/*

*/Elsevier BV/*/____/

/Radarweg 29, Amsterdam 1043 NX, The Netherlands____/

/m.koren@elsevier.com <mailto:m.koren@elsevier.com>____/

/__ __/

/Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens,
Institutional Login____/

/__ __/

/Elsevier Access Support Center:

https://service.elsevier.com/app/answers/list/c/10543/supporthub/elsevieracc...

...

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fservice.elsevier.com%2Fapp%2Fanswers%2Flist%2Fc%2F10543%2Fsupporthub%2Felsevieraccess%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761640371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=s2nQIh1Mocby%2Fnr0uG61jf%2Fg%2FWgqr%2FfHj6MhuH5sHHs%3D&reserved=0____/

...

/for your questions about which access methods does Elsevier
support, how to set them up, how do they work for users...____/

/__ __/

__ __

__ __

__ __

__ __

__ __

*From:* FIM4L <fim4l-bounces@lists.daasi.de
<mailto:fim4l-bounces@lists.daasi.de>> *On Behalf Of* Jiri Pavlik
*Sent:* Sunday, March 14, 2021 15:28
*To:* Bernd Oberknapp <bo@ub.uni-freiburg.de
<mailto:bo@ub.uni-freiburg.de>>
*Cc:* fim4l@lists.daasi.de <mailto:fim4l@lists.daasi.de>
*Subject:* Re: [Fim4l] LexisNexis Advance____

__ __

**** External email: use caution ****____

____

Hi Bernd,

I see,
  eduPersonScopedAffiliation (required)
  eduPersonEntitlement  (required)
is working for Freiburg University and
  eduPersonScopedAffiliation (required)
  eduPersonEntitlement  (required)
  eduPersonTargetedID (required)
is not.

The university students and staff are free to use personalisation
at Lexis Nexis,
Elsevier, EBSCO, ProQuest services if they want to so
  eduPersonScopedAffiliation (required)
  eduPersonEntitlement  (required)
  eduPersonTargetedID (optional)
is working for the University as well.

Is it correct?

All the best

          Jiri____

__ __

    ____

        On Sat, Mar 13, 2021 at 2:40 PM Bernd Oberknapp
        <bo@ub.uni-freiburg.de <mailto:bo@ub.uni-freiburg.de>>
        wrote:____

            Hi Jiri,

            On 13.03.21 09:15, Jiri Pavlik wrote:

             > When checking ProQuest SP for ProQuest Central in
            DFN-AAI metadata [1]
             > I can see both eduPersonEntitlement and
            eduPersonTargetedID as required
             > attributes.

            I assume you mean the SP
            https://shibboleth-sp.prod.proquest.com/shibboleth

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth-sp.prod.proquest.com%2Fshibboleth&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761640371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bosxymzT3WPyXBdeX0NnT5AvLDmTecE%2BEbZe6krDBwk%3D&reserved=0?

...

            That's obviously
            wrong, both eduPersonScopedAffiliation and
            eduPersonEntitlement are
            supported for authorization, but as far as I can tell
            you don't have to
            use them, and eduPersonTargetedID isn't required.

             > Is it safe to assume that if there is
            personalisation capability at a
             > library service then all German universities,
            libraries are fine with
             > releasing eduPersonTargetedID for recognising
            returning users and
             > eduPersonEntitlement, eduPersonScopedAffiliation
            for authorisation?

            No. I can't speak for other IdPs, but in my opinion
            that approach would
            be wrong, users by default should be able to use
            services anonymously,
            without being recognized as a returning user. Based on
            what I can see in
            the admin tools, only a very small percentage of our
            users actually uses
            the personalization features, so releasing
            eduPersonTargetedID by
            default just for personalization isn't an option. If
            publishers would
            force us to send an eduPersonTargetedID just for
            personalization I would
            consider dropping Shibboleth for those publishers and
            using our EZproxy
            instead.

            Best regards,
            Bernd

            --
            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
            <mailto:bo@ub.uni-freiburg.de>
            Internet: www.ub.uni-freiburg.de

https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ub.uni-freiburg.de%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761650360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eLOZmpzI51ttj9vd4uSNyCcFAAxIPZKUWoSATsoVq1k%3D&reserved=0____

...

------------------------------------------------------------------------

...

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

---

FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l

Hi Jos,

Please also look into the REFEDS entity categories and the recent work there. If your recommendations to librarians propose some new concepts or terminology (transitory access), or parallel decision making, that's going to cause a lot of confusion.

We're trying to build a system where the attribute release is automated while at the same time appropriate. If an SP requests pseudonymous entity category but the librarian makes a different decision, what happens then? The system breaks, the user has bad experience, people spend time troubleshooting and fixing.

I understand it may be difficult for some people to take my word for it, but we, too, take the user privacy seriously. And libraries should be guarding user data, by all means, they just need to be informed correctly.

Thanks, Meshna

From: Heather Flanagan hlf@sphericalcowconsulting.com Sent: Monday, March 15, 2021 16:26 To: Jiri Pavlik jiri.pavlik@techlib.cz; Koren, Meshna (ELS-AMS) M.Koren@elsevier.com; Jos Westerbeke jos.westerbeke@eur.nl Cc: fim4l@lists.daasi.de Subject: Re: [Fim4l] LexisNexis Advance

*** External email: use caution ***

I know it does not help matters, but I need to point out that eduPersonTargetedID is actually deprecated due to security concerns. Instead, organizations are encouraged to use the SAML attribute, subject-id (https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-sub...https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oasis-open.org%2Fsecurity%2Fsaml-subject-id-attr%2Fv1.0%2Fcs01%2Fsaml-subject-id-attr-v1.0-cs01.pdf&data=04%7C01%7CM.Koren%40elsevier.com%7C6538b3a981044dead48d08d8e7c6b037%7C9274ee3f94254109a27f9fb15c10675d%7C0%7C0%7C637514188524240324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=D7BExNGDJEAGUl2lF%2ByY0lVo9vLeyHP5ENac48Y6BCs%3D&reserved=0).

Heather Flanagan - Translator of Geek to Human https://sphericalcowconsulting.comhttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsphericalcowconsulting.com%2F&data=04%7C01%7CM.Koren%40elsevier.com%7C6538b3a981044dead48d08d8e7c6b037%7C9274ee3f94254109a27f9fb15c10675d%7C0%7C0%7C637514188524250314%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4Vdm41YFnRzfELUGZp%2B%2Bn0yZq3nyRPOUwavep3aSbjo%3D&reserved=0 On Mar 15, 2021, 8:18 AM -0700, Jos Westerbeke jos.westerbeke@eur.nl, wrote:

Hi Jiri, Bernd et al,

thank you for this discussion. This is very meaningful for downplaying the FIM4L recommendations 4.A and 4.B to a more simple level.

We now have two recommendations which you have to (unfortunately) choose:

4.A. Transitory Access - eduPersonTargetedID as optional would be fine for this. 4.B. Personalized Access - eduPersonTargetedID required. - And for 4.B the recommendation is to let it be for the SP side to offer a profile, voluntarily to configure by users. So that in any way IdP's do not have to release PII. (https://www.fim4l.org/?page_id=257)

What would we actually recommend for librarians? Wouldn't it be nice to have just one option? I think it is too difficult for librarians to choose here.

Reading the discussion, we can say that we cannot recommend going just for 4.B. And if librarians consider switching form IP to SAML they are very suspicious about privacy.

Can we recommend for both IdP's and SP's to go for 4.A?

What about recommending 4.A and have the option for 4.B when there is an agreement between IdP and SP about creating profiles, anchored in a contract?

Should we recommend a contract clausula alongside 4.B?

As far as I understand, I'm aware of what Meshna says: If you opt for 4.A then it is simply not possible to have a profile, which is very annoying if not impossible for our patrons.

Best, Jos

________________________________ From: FIM4L fim4l-bounces@lists.daasi.de on behalf of Jiri Pavlik jiri.pavlik@techlib.cz Sent: 15 March 2021 14:58 To: Koren, Meshna (ELS-AMS) M.Koren@elsevier.com Cc: fim4l@lists.daasi.de fim4l@lists.daasi.de Subject: Re: [Fim4l] LexisNexis Advance

Hi Meshna,

thanks a lot for the comments.

At Elsevier SP metadata [1] I can see: eduPersonEntitlement (required) eduPersonTargetedID (optional) in DFN-AAI, IDEM or Australian Access Federation.

At the SP metadata in eduGAIN / UK Federation there are no requested attributes. At the SP metadata in eduID.at, SWITCHaai, InCommon, RENATER I can see: eduPersonEntitlement (required) eduPersonTargetedID (required)

It illustrates different approaches around the world how to express optional ePTID release in SP metadata and a challenge for one appropriate SP metadata in eduGAIN serving globally. To me eduPersonEntitlement (required) eduPersonTargetedID (optional) seems as the most appropriate.

Cheers Jiri

1. https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.c...https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmet.refeds.org%2Fmet%2Fentity%2Fhttps%25253A%25252F%25252Fsdauth.sciencedirect.com%25252F%2F&data=04%7C01%7CM.Koren%40elsevier.com%7C6538b3a981044dead48d08d8e7c6b037%7C9274ee3f94254109a27f9fb15c10675d%7C0%7C0%7C637514188524250314%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QzMmiXfk0mpoaj%2FL%2BsSThMOsEjTNAjopxFSyMOEHFgs%3D&reserved=0

On Mon, Mar 15, 2021 at 12:01 PM Koren, Meshna (ELS-AMS) <M.Koren@elsevier.commailto:M.Koren@elsevier.com> wrote:

Please allow me to add something to this discussion.

"The university students and staff are free to use personalisation at Lexis Nexis, Elsevier, EBSCO, ProQuest services if they want to so eduPersonScopedAffiliation (required) eduPersonEntitlement (required) eduPersonTargetedID (optional)..."

The students and staff can only use personalization when the IdP releases ePTID (or pairwiseID), otherwise they can't. I am not sure that this is clear from the metadata nor that the labels we use to describe the required attributes are very clear on what 'optional' means.

For example, when a student accesses ScienceDirect they can read subscribed articles whether or not ePTID has been released for them, but if they want to 'create account' because they would like to save searches, alerts or their search history, they can only do that if the IdP has released a persistent identifier for them. Otherwise they can't, because there's nothing in their SAML assertions that allows us to recognize the returning individual. So we are working towards requiring a persistent ID. The personalization remains optional for the user.

That may not be the same for other SPs, but it is valid for Elsevier.

Kind regards,

Meshna

Meshna Koren

Product Manager II

Product Management - Identity and Access - Research Products

Elsevier BV

Radarweg 29, Amsterdam 1043 NX, The Netherlands

m.koren@elsevier.commailto:m.koren@elsevier.com

Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens, Institutional Login

Elsevier Access Support Center: https://service.elsevier.com/app/answers/list/c/10543/supporthub/elsevieracc...https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fservice.elsevier.com%2Fapp%2Fanswers%2Flist%2Fc%2F10543%2Fsupporthub%2Felsevieraccess%2F&data=04%7C01%7CM.Koren%40elsevier.com%7C6538b3a981044dead48d08d8e7c6b037%7C9274ee3f94254109a27f9fb15c10675d%7C0%7C0%7C637514188524260311%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Sz7%2F5CmZUFGQrpTHNfvs5DBquoA%2Bty2inLn6WO91vsc%3D&reserved=0

for your questions about which access methods does Elsevier support, how to set them up, how do they work for users...

From: FIM4L <fim4l-bounces@lists.daasi.demailto:fim4l-bounces@lists.daasi.de> On Behalf Of Jiri Pavlik Sent: Sunday, March 14, 2021 15:28 To: Bernd Oberknapp <bo@ub.uni-freiburg.demailto:bo@ub.uni-freiburg.de> Cc: fim4l@lists.daasi.demailto:fim4l@lists.daasi.de Subject: Re: [Fim4l] LexisNexis Advance

*** External email: use caution ***

Hi Bernd,

I see, eduPersonScopedAffiliation (required) eduPersonEntitlement (required) is working for Freiburg University and eduPersonScopedAffiliation (required) eduPersonEntitlement (required) eduPersonTargetedID (required) is not.

The university students and staff are free to use personalisation at Lexis Nexis, Elsevier, EBSCO, ProQuest services if they want to so eduPersonScopedAffiliation (required) eduPersonEntitlement (required) eduPersonTargetedID (optional) is working for the University as well.

Is it correct?

All the best

Jiri

On Sat, Mar 13, 2021 at 2:40 PM Bernd Oberknapp <bo@ub.uni-freiburg.demailto:bo@ub.uni-freiburg.de> wrote:

Hi Jiri,

On 13.03.21 09:15, Jiri Pavlik wrote:

When checking ProQuest SP for ProQuest Central in DFN-AAI metadata [1] I can see both eduPersonEntitlement and eduPersonTargetedID as required attributes.

I assume you mean the SP https://shibboleth-sp.prod.proquest.com/shibbolethhttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth-sp.prod.proquest.com%2Fshibboleth&data=04%7C01%7CM.Koren%40elsevier.com%7C6538b3a981044dead48d08d8e7c6b037%7C9274ee3f94254109a27f9fb15c10675d%7C0%7C0%7C637514188524260311%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kJ9GtR52J3od7YeoshhBJUVyu4ABNytCuFIHAyobzjo%3D&reserved=0? That's obviously wrong, both eduPersonScopedAffiliation and eduPersonEntitlement are supported for authorization, but as far as I can tell you don't have to use them, and eduPersonTargetedID isn't required.

Is it safe to assume that if there is personalisation capability at a library service then all German universities, libraries are fine with releasing eduPersonTargetedID for recognising returning users and eduPersonEntitlement, eduPersonScopedAffiliation for authorisation?

No. I can't speak for other IdPs, but in my opinion that approach would be wrong, users by default should be able to use services anonymously, without being recognized as a returning user. Based on what I can see in the admin tools, only a very small percentage of our users actually uses the personalization features, so releasing eduPersonTargetedID by default just for personalization isn't an option. If publishers would force us to send an eduPersonTargetedID just for personalization I would consider dropping Shibboleth for those publishers and using our EZproxy instead.

Best regards, Bernd

-- 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.demailto:bo@ub.uni-freiburg.de Internet: www.ub.uni-freiburg.dehttps://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ub.uni-freiburg.de%2F&data=04%7C01%7CM.Koren%40elsevier.com%7C6538b3a981044dead48d08d8e7c6b037%7C9274ee3f94254109a27f9fb15c10675d%7C0%7C0%7C637514188524270306%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HH1D%2FwDI4OMLJOvTJTJE%2Bf%2Bu64spTs%2B3fbxPp6RkWYI%3D&reserved=0

________________________________

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

________________________________

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

Hi,

Just want to say I agree with Meshna that "This system is too complicated for users to be able to make informed decisions." About the matter at hand.

Best, Jos

________________________________ From: FIM4L fim4l-bounces@lists.daasi.de on behalf of Bernd Oberknapp bo@ub.uni-freiburg.de Sent: 15 March 2021 18:03 To: fim4l@lists.daasi.de fim4l@lists.daasi.de Subject: Re: [Fim4l] LexisNexis Advance

Hi Meshna,

this could be addressed in the way I've described - as a result there only would be one category with an optional pairwise-id/eduPersonTargetedID, and the user would have the choice.

Note that enforcing the release of a pairwise-id/eduPersonTargetedID that actually isn't required for a service is problematic - if a users would object to releasing this attribute this would get the IdP operator or library into trouble. Giving the user the choice solves this problem.

Best regards, Bernd

On 15.03.21 17:35, Koren, Meshna (ELS-AMS) wrote:

Hi Jos,

Please also look into the REFEDS entity categories and the recent work there. If your recommendations to librarians propose some new concepts or terminology (transitory access), or parallel decision making, that's going to cause a lot of confusion.

We're trying to build a system where the attribute release is automated while at the same time appropriate. If an SP requests pseudonymous entity category but the librarian makes a different decision, what happens then? The system breaks, the user has bad experience, people spend time troubleshooting and fixing.

I understand it may be difficult for some people to take my word for it, but we, too, take the user privacy seriously. And libraries should be guarding user data, by all means, they just need to be informed

correctly.

Thanks,

Meshna

*From:* Heather Flanagan hlf@sphericalcowconsulting.com *Sent:* Monday, March 15, 2021 16:26 *To:* Jiri Pavlik jiri.pavlik@techlib.cz; Koren, Meshna (ELS-AMS) M.Koren@elsevier.com; Jos Westerbeke jos.westerbeke@eur.nl *Cc:* fim4l@lists.daasi.de *Subject:* Re: [Fim4l] LexisNexis Advance

**** External email: use caution ****

I know it does not help matters, but I need to point out that eduPersonTargetedID is actually deprecated due to security concerns. Instead, organizations are encouraged to use the SAML attribute, subject-id

(https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oasis...

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oasis-open.org%2Fsecurity%2Fsaml-subject-id-attr%2Fv1.0%2Fcs01%2Fsaml-subject-id-attr-v1.0-cs01.pdf&data=04%7C01%7Cjos.westerbeke%40eur.nl%7Cc0436c14482a495fd19f08d8e7d796a8%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514260980839001%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vfP5JhkGS%2F9c1WwMhEYEwS2eEsGNfv%2BzgFxW84TxVYY%3D&reserved=0).

Heather Flanagan — Translator of Geek to Human https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsphericalc...

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsphericalcowconsulting.com%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7Cc0436c14482a495fd19f08d8e7d796a8%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514260980848987%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QlxS24UPnoJy259FMz0KT%2BEgwpHMB8fWKV7Dd9xJCXQ%3D&reserved=0

On Mar 15, 2021, 8:18 AM -0700, Jos Westerbeke jos.westerbeke@eur.nl, wrote:

Hi Jiri, Bernd et al,

thank you for this discussion. This is very meaningful for
downplaying the FIM4L recommendations 4.A and 4.B to a more simple
level.

We now have two recommendations which you have to (unfortunately)
choose:

4.A. Transitory Access - eduPersonTargetedID as optional would be
fine for this.

4.B. Personalized Access - eduPersonTargetedID required.

- And for 4.B the recommendation is to let it be for the SP side to
offer a profile, voluntarily to configure by users. So that in any
way IdP's do not have to release PII.

(https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.fim4l.org%2F%3Fpage_id%3D257&data=04%7C01%7Cjos.westerbeke%40eur.nl%7Cc0436c14482a495fd19f08d8e7d796a8%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514260980848987%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4kH%2FirgOHDYzhkrHRoi0Ao1Hfs8aL85UtzyG4%2F1J2F0%3D&reserved=0)

What would we actually recommend for librarians? Wouldn't it be nice
to have just one option? I think it is too difficult for librarians
to choose here.

Reading the discussion, we can say that we cannot recommend going
just for 4.B. And if librarians consider switching form IP to SAML
they are very suspicious about privacy.

Can we recommend for both IdP's and SP's to go for 4.A?

What about recommending 4.A and have the option for 4.B when there
is an agreement between IdP and SP about creating profiles, anchored
in a contract?

Should we recommend a contract clausula alongside 4.B?

As far as I understand, I'm aware of what Meshna says: If you opt
for 4.A then it is simply not possible to have a profile, which is
very annoying if not impossible for our patrons.

Best,
Jos

------------------------------------------------------------------------

*From:*FIM4L <fim4l-bounces@lists.daasi.de> on behalf of Jiri Pavlik
<jiri.pavlik@techlib.cz>
*Sent:* 15 March 2021 14:58
*To:* Koren, Meshna (ELS-AMS) <M.Koren@elsevier.com>
*Cc:* fim4l@lists.daasi.de <fim4l@lists.daasi.de>
*Subject:* Re: [Fim4l] LexisNexis Advance

Hi Meshna,

thanks a lot for the comments.

At Elsevier SP metadata [1] I can see:
  eduPersonEntitlement (required)
  eduPersonTargetedID (optional)
in DFN-AAI, IDEM or Australian Access Federation.

At the SP metadata in eduGAIN / UK Federation there are no requested
attributes.

At the SP metadata in eduID.at, SWITCHaai, InCommon, RENATER I

can see:

    eduPersonEntitlement (required)
    eduPersonTargetedID (required)

It illustrates different approaches around the world how to express
optional ePTID release
in SP metadata and a challenge for one appropriate SP metadata in
eduGAIN serving globally.
To me
     eduPersonEntitlement (required)
     eduPersonTargetedID (optional)
seems as the most appropriate.

Cheers
                   Jiri

1.

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmet.refeds...

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmet.refeds.org%2Fmet%2Fentity%2Fhttps%25253A%25252F%25252Fsdauth.sciencedirect.com%25252F%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7Cc0436c14482a495fd19f08d8e7d796a8%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514260980848987%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LWVn7HohXktSSfcEJse8s60VQ%2FWzeoffRxpOpJPkcIM%3D&reserved=0

On Mon, Mar 15, 2021 at 12:01 PM Koren, Meshna (ELS-AMS)
<M.Koren@elsevier.com <mailto:M.Koren@elsevier.com>> wrote:

    Please allow me to add something to this discussion.

    "The university students and staff are free to use
    personalisation at Lexis Nexis,
    Elsevier, EBSCO, ProQuest services if they want to so
       eduPersonScopedAffiliation (required)
       eduPersonEntitlement  (required)
       eduPersonTargetedID (optional)..."

    The students and staff can only use personalization when the IdP
    releases ePTID (or pairwiseID), otherwise they can't. I am not
    sure that this is clear from the metadata nor that the labels we
    use to describe the required attributes are very clear on what
    'optional' means.

    For example, when a student accesses ScienceDirect they can read
    subscribed articles whether or not ePTID has been released for
    them, but if they want to 'create account' because they would
    like to save searches, alerts or their search history, they can
    only do that if the IdP has released a persistent identifier for
    them. Otherwise they can't, because there's nothing in their
    SAML assertions that allows us to recognize the returning
    individual. So we are working towards requiring a persistent ID.
    The personalization remains optional for the user.

    That may not be the same for other SPs, but it is valid for
    Elsevier.

    Kind regards,

    Meshna

    **

    *Meshna Koren*


    /Product Manager II/

    */Product Management - Identity and Access/**/-/**/Research
    Products/*

    *//*

    */Elsevier BV/*

    /Radarweg 29, Amsterdam 1043 NX, The Netherlands/

    /m.koren@elsevier.com <mailto:m.koren@elsevier.com>/

    //

    /Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens,
    Institutional Login/

    //

    /Elsevier Access Support Center:

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fservice.el...

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fservice.elsevier.com%2Fapp%2Fanswers%2Flist%2Fc%2F10543%2Fsupporthub%2Felsevieraccess%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7Cc0436c14482a495fd19f08d8e7d796a8%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514260980848987%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=D%2BpcpwxeUXxRm%2FXe%2BzdOeV4NYbx1G67VfZqy3dGh%2BJs%3D&reserved=0/

    /for your questions about which access methods does Elsevier
    support, how to set them up, how do they work for users.../

    //

    *From:* FIM4L <fim4l-bounces@lists.daasi.de
    <mailto:fim4l-bounces@lists.daasi.de>> *On Behalf Of* Jiri Pavlik
    *Sent:* Sunday, March 14, 2021 15:28
    *To:* Bernd Oberknapp <bo@ub.uni-freiburg.de
    <mailto:bo@ub.uni-freiburg.de>>
    *Cc:* fim4l@lists.daasi.de <mailto:fim4l@lists.daasi.de>
    *Subject:* Re: [Fim4l] LexisNexis Advance

    **** External email: use caution ****

    Hi Bernd,

    I see,
       eduPersonScopedAffiliation (required)
       eduPersonEntitlement  (required)
    is working for Freiburg University and
       eduPersonScopedAffiliation (required)
       eduPersonEntitlement  (required)
       eduPersonTargetedID (required)
    is not.

    The university students and staff are free to use
    personalisation at Lexis Nexis,
    Elsevier, EBSCO, ProQuest services if they want to so
       eduPersonScopedAffiliation (required)
       eduPersonEntitlement  (required)
       eduPersonTargetedID (optional)
    is working for the University as well.

    Is it correct?

    All the best

               Jiri

            On Sat, Mar 13, 2021 at 2:40 PM Bernd Oberknapp
            <bo@ub.uni-freiburg.de <mailto:bo@ub.uni-freiburg.de>>
            wrote:

                Hi Jiri,

                On 13.03.21 09:15, Jiri Pavlik wrote:

                  > When checking ProQuest SP for ProQuest Central
                in DFN-AAI metadata [1]
                  > I can see both eduPersonEntitlement and
                eduPersonTargetedID as required
                  > attributes.

                I assume you mean the SP
                https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth-sp.prod.proquest.com%2Fshibboleth&amp;data=04%7C01%7Cjos.westerbeke%40eur.nl%7Cc0436c14482a495fd19f08d8e7d796a8%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514260980858981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=5BveoLe5HjYZjpKg0F3zOzj%2B8xMsYXs0ovWwPNYkaNU%3D&amp;reserved=0

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth-sp.prod.proquest.com%2Fshibboleth&data=04%7C01%7Cjos.westerbeke%40eur.nl%7Cc0436c14482a495fd19f08d8e7d796a8%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514260980858981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5BveoLe5HjYZjpKg0F3zOzj%2B8xMsYXs0ovWwPNYkaNU%3D&reserved=0?

                That's obviously
                wrong, both eduPersonScopedAffiliation and
                eduPersonEntitlement are
                supported for authorization, but as far as I can
                tell you don't have to
                use them, and eduPersonTargetedID isn't required.

                  > Is it safe to assume that if there is
                personalisation capability at a
                  > library service then all German universities,
                libraries are fine with
                  > releasing eduPersonTargetedID for recognising
                returning users and
                  > eduPersonEntitlement, eduPersonScopedAffiliation
                for authorisation?

                No. I can't speak for other IdPs, but in my opinion
                that approach would
                be wrong, users by default should be able to use
                services anonymously,
                without being recognized as a returning user. Based
                on what I can see in
                the admin tools, only a very small percentage of our
                users actually uses
                the personalization features, so releasing
                eduPersonTargetedID by
                default just for personalization isn't an option. If
                publishers would
                force us to send an eduPersonTargetedID just for
                personalization I would
                consider dropping Shibboleth for those publishers
                and using our EZproxy
                instead.

                Best regards,
                Bernd

                --
                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
                <mailto:bo@ub.uni-freiburg.de>
                Internet: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ub.uni-freiburg.de%2F&amp;data=04%7C01%7Cjos.westerbeke%40eur.nl%7Cc0436c14482a495fd19f08d8e7d796a8%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514260980858981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ElTwfCzuKdJ5%2B0dsn8LSj%2BI90awy9mnU12j9E%2FnerK8%3D&amp;reserved=0

https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ub.uni-freiburg.de%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7Cc0436c14482a495fd19f08d8e7d796a8%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514260980858981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ElTwfCzuKdJ5%2B0dsn8LSj%2BI90awy9mnU12j9E%2FnerK8%3D&reserved=0

------------------------------------------------------------------------

    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
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.daasi.de%2Flistinfo%2Ffim4l&data=04%7C01%7Cjos.westerbeke%40eur.nl%7Cc0436c14482a495fd19f08d8e7d796a8%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514260980858981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ms2%2Bi4n0iDo5880asMTNQCLaL%2BDI5wS8j%2B4nS%2FIIbj0%3D&reserved=0

---

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 https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.daasi...

-- 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: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ub.uni-...

Hi,

I agree. The SP should not enforce the release of pairwise-id/eduPersonTargetedID, and if the IdP allows to release pairwise-id/eduPersonTargetedID the user should have the choice, so that the attribute is only released if the user wants to use the personalization based on that attribute. Additionally, when no pairwise-id/eduPersonTargetedID is passed to the SP, the SP still should offer personalization based on a registered account (as most publishers do, Elsevier as far as I know is one of very few publishers that don't allow this when an institutional login is used.).

Best regards, Bernd

On 15.03.21 16:46, Jiri Pavlik wrote:

Hi,

IMHO there are users who wish to have anonymous access and there are also users who wish to have a profile, use personalisation. So a solution there could be let users decide about releasing pairwise-id (eduPersonTargetedID) using CAR.

Best Jiri

On Mon, Mar 15, 2021 at 4:18 PM Jos Westerbeke <jos.westerbeke@eur.nl mailto:jos.westerbeke@eur.nl> wrote:

Hi Jiri, Bernd et al,

thank you for this discussion. This is very meaningful for
downplaying the FIM4L recommendations 4.A and 4.B to a more simple
level.

We now have two recommendations which you have to (unfortunately)
choose:

4.A. Transitory Access - eduPersonTargetedID as optional would be
fine for this.
4.B. Personalized Access - eduPersonTargetedID required.
- And for 4.B the recommendation is to let it be for the SP side to
offer a profile, voluntarily to configure by users. So that in any
way IdP's do not have to release PII.
(https://www.fim4l.org/?page_id=257)

What would we actually recommend for librarians? Wouldn't it be nice
to have just one option? I think it is too difficult for librarians
to choose here.

Reading the discussion, we can say that we cannot recommend going
just for 4.B. And if librarians consider switching form IP to SAML
they are very suspicious about privacy.

Can we recommend for both IdP's and SP's to go for 4.A?

What about recommending 4.A and have the option for 4.B when there
is an agreement between IdP and SP about creating profiles, anchored
in a contract?

Should we recommend a contract clausula alongside 4.B?

As far as I understand, I'm aware of what Meshna says: If you opt
for 4.A then it is simply not possible to have a profile, which is
very annoying if not impossible for our patrons.

Best,
Jos

------------------------------------------------------------------------

*From:* FIM4L <fim4l-bounces@lists.daasi.de
<mailto:fim4l-bounces@lists.daasi.de>> on behalf of Jiri Pavlik
<jiri.pavlik@techlib.cz <mailto:jiri.pavlik@techlib.cz>>
*Sent:* 15 March 2021 14:58
*To:* Koren, Meshna (ELS-AMS) <M.Koren@elsevier.com
<mailto:M.Koren@elsevier.com>>
*Cc:* fim4l@lists.daasi.de <mailto:fim4l@lists.daasi.de>
<fim4l@lists.daasi.de <mailto:fim4l@lists.daasi.de>>
*Subject:* Re: [Fim4l] LexisNexis Advance
Hi Meshna,

thanks a lot for the comments.

At Elsevier SP metadata [1] I can see:
  eduPersonEntitlement (required)
  eduPersonTargetedID (optional)
in DFN-AAI, IDEM or Australian Access Federation.

At the SP metadata in eduGAIN / UK Federation there are no requested
attributes.
At the SP metadata in eduID.at, SWITCHaai, InCommon, RENATER I 

can see:

    eduPersonEntitlement (required)
    eduPersonTargetedID (required)

It illustrates different approaches around the world how to express
optional ePTID release
in SP metadata and a challenge for one appropriate SP metadata in
eduGAIN serving globally.
To me
     eduPersonEntitlement (required)
     eduPersonTargetedID (optional)
seems as the most appropriate.

Cheers
                   Jiri


1.

https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.c...

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmet.refeds.org%2Fmet%2Fentity%2Fhttps%25253A%25252F%25252Fsdauth.sciencedirect.com%25252F%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761630378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HmuCXxy9%2F1bQBVkGnsrbBcRmNJP9DsiETfB4g6uP0L4%3D&reserved=0

On Mon, Mar 15, 2021 at 12:01 PM Koren, Meshna (ELS-AMS)
<M.Koren@elsevier.com <mailto:M.Koren@elsevier.com>> wrote:

    Please allow me to add something to this discussion. ____

    __ __

    "The university students and staff are free to use
    personalisation at Lexis Nexis,
    Elsevier, EBSCO, ProQuest services if they want to so
       eduPersonScopedAffiliation (required)
       eduPersonEntitlement  (required)
       eduPersonTargetedID (optional)..."

    ____

    The students and staff can only use personalization when the IdP
    releases ePTID (or pairwiseID), otherwise they can't. I am not
    sure that this is clear from the metadata nor that the labels we
    use to describe the required attributes are very clear on what
    'optional' means.____

    __ __

    For example, when a student accesses ScienceDirect they can read
    subscribed articles whether or not ePTID has been released for
    them, but if they want to 'create account' because they would
    like to save searches, alerts or their search history, they can
    only do that if the IdP has released a persistent identifier for
    them. Otherwise they can't, because there's nothing in their
    SAML assertions that allows us to recognize the returning
    individual. So we are working towards requiring a persistent ID.
    The personalization remains optional for the user.____

    __ __

    That may not be the same for other SPs, but it is valid for
    Elsevier. ____

    __ __

    Kind regards,____

    Meshna____

    __ __

    __ __

    *__ __*

    *Meshna Koren**____*


    /Product Manager II____/

    */Product Management - Identity and Access/**/- /**/Research
    Products/**/____/*

    */__ __/*

    */Elsevier BV/*/____/

    /Radarweg 29, Amsterdam 1043 NX, The Netherlands____/

    /m.koren@elsevier.com <mailto:m.koren@elsevier.com>____/

    /__ __/

    /Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens,
    Institutional Login____/

    /__ __/

    /Elsevier Access Support Center:

https://service.elsevier.com/app/answers/list/c/10543/supporthub/elsevieracc...

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fservice.elsevier.com%2Fapp%2Fanswers%2Flist%2Fc%2F10543%2Fsupporthub%2Felsevieraccess%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761640371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=s2nQIh1Mocby%2Fnr0uG61jf%2Fg%2FWgqr%2FfHj6MhuH5sHHs%3D&reserved=0____/

    /for your questions about which access methods does Elsevier
    support, how to set them up, how do they work for users...____/

    /__ __/

    __ __

    __ __

    __ __

    __ __

    __ __

    *From:* FIM4L <fim4l-bounces@lists.daasi.de
    <mailto:fim4l-bounces@lists.daasi.de>> *On Behalf Of *Jiri Pavlik
    *Sent:* Sunday, March 14, 2021 15:28
    *To:* Bernd Oberknapp <bo@ub.uni-freiburg.de
    <mailto:bo@ub.uni-freiburg.de>>
    *Cc:* fim4l@lists.daasi.de <mailto:fim4l@lists.daasi.de>
    *Subject:* Re: [Fim4l] LexisNexis Advance____

    __ __

    **** External email: use caution ****____

    ____

    Hi Bernd,

    I see,
       eduPersonScopedAffiliation (required)
       eduPersonEntitlement  (required)
    is working for Freiburg University and
       eduPersonScopedAffiliation (required)
       eduPersonEntitlement  (required)
       eduPersonTargetedID (required)
    is not.

    The university students and staff are free to use
    personalisation at Lexis Nexis,
    Elsevier, EBSCO, ProQuest services if they want to so
       eduPersonScopedAffiliation (required)
       eduPersonEntitlement  (required)
       eduPersonTargetedID (optional)
    is working for the University as well.

    Is it correct?

    All the best

               Jiri____

    __ __

        ____

            On Sat, Mar 13, 2021 at 2:40 PM Bernd Oberknapp
            <bo@ub.uni-freiburg.de <mailto:bo@ub.uni-freiburg.de>>
            wrote:____

                Hi Jiri,

                On 13.03.21 09:15, Jiri Pavlik wrote:

                  > When checking ProQuest SP for ProQuest Central
                in DFN-AAI metadata [1]
                  > I can see both eduPersonEntitlement and
                eduPersonTargetedID as required
                  > attributes.

                I assume you mean the SP
                https://shibboleth-sp.prod.proquest.com/shibboleth

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth-sp.prod.proquest.com%2Fshibboleth&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761640371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bosxymzT3WPyXBdeX0NnT5AvLDmTecE%2BEbZe6krDBwk%3D&reserved=0?

                That's obviously
                wrong, both eduPersonScopedAffiliation and
                eduPersonEntitlement are
                supported for authorization, but as far as I can
                tell you don't have to
                use them, and eduPersonTargetedID isn't required.

                  > Is it safe to assume that if there is
                personalisation capability at a
                  > library service then all German universities,
                libraries are fine with
                  > releasing eduPersonTargetedID for recognising
                returning users and
                  > eduPersonEntitlement, eduPersonScopedAffiliation
                for authorisation?

                No. I can't speak for other IdPs, but in my opinion
                that approach would
                be wrong, users by default should be able to use
                services anonymously,
                without being recognized as a returning user. Based
                on what I can see in
                the admin tools, only a very small percentage of our
                users actually uses
                the personalization features, so releasing
                eduPersonTargetedID by
                default just for personalization isn't an option. If
                publishers would
                force us to send an eduPersonTargetedID just for
                personalization I would
                consider dropping Shibboleth for those publishers
                and using our EZproxy
                instead.

                Best regards,
                Bernd

                --
                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
                <mailto:bo@ub.uni-freiburg.de>
                Internet: www.ub.uni-freiburg.de

https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ub.uni-freiburg.de%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761650360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eLOZmpzI51ttj9vd4uSNyCcFAAxIPZKUWoSATsoVq1k%3D&reserved=0____

------------------------------------------------------------------------

    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

Hi Jiri,

actually that approach only improves the user experience as long as a user is only affiliated with a single institution. If the user is affiliated with multiple institutions or leaves the institution (and probably also for other some use cases), a personal account not based on an institutional identity might be the better choice (at least as long users don't have an edu-ID).

Best regards, Bernd

On 15.03.21 17:20, Jiri Pavlik wrote:

Hi,

I prefer Elsevier's approach, personalization based on pairwise-id/eduPersonTargetedID. Another sign in for personalisation on top of institutional sign in is adding complexity, it leads to worse user experience IMHO.

Cheers Jiri

On Mon, Mar 15, 2021 at 5:01 PM Bernd Oberknapp <bo@ub.uni-freiburg.de mailto:bo@ub.uni-freiburg.de> wrote:

Hi,

I agree. The SP should not enforce the release of
pairwise-id/eduPersonTargetedID, and if the IdP allows to release
pairwise-id/eduPersonTargetedID the user should have the choice, so
that
the attribute is only released if the user wants to use the
personalization based on that attribute. Additionally, when no
pairwise-id/eduPersonTargetedID is passed to the SP, the SP still
should
offer personalization based on a registered account (as most 

publishers

do, Elsevier as far as I know is one of very few publishers that 

don't

allow this when an institutional login is used.).

Best regards,
Bernd


On 15.03.21 16:46, Jiri Pavlik wrote:
  > Hi,
  >
  > IMHO there are users who wish to have anonymous access and 

there are

  > also users
  > who wish to have a profile, use personalisation. So a 

solution there

  > could be let users
  > decide about releasing pairwise-id (eduPersonTargetedID) 

using CAR.

  >
  > Best
  >                   Jiri
  >
  > On Mon, Mar 15, 2021 at 4:18 PM Jos Westerbeke
<jos.westerbeke@eur.nl <mailto:jos.westerbeke@eur.nl>
  > <mailto:jos.westerbeke@eur.nl <mailto:jos.westerbeke@eur.nl>>>
wrote:
  >
  >     Hi Jiri, Bernd et al,
  >
  >     thank you for this discussion. This is very meaningful for
  >     downplaying the FIM4L recommendations 4.A and 4.B to a more
simple
  >     level.
  >
  >     We now have two recommendations which you have to
(unfortunately)
  >     choose:
  >
  >     4.A. Transitory Access - eduPersonTargetedID as optional
would be
  >     fine for this.
  >     4.B. Personalized Access - eduPersonTargetedID required.
  >     - And for 4.B the recommendation is to let it be for the SP
side to
  >     offer a profile, voluntarily to configure by users. So that
in any
  >     way IdP's do not have to release PII.
  >     (https://www.fim4l.org/?page_id=257)
  >
  >     What would we actually recommend for librarians? Wouldn't it
be nice
  >     to have just one option? I think it is too difficult for
librarians
  >     to choose here.
  >
  >     Reading the discussion, we can say that we cannot recommend
going
  >     just for 4.B. And if librarians consider switching form IP
to SAML
  >     they are very suspicious about privacy.
  >
  >     Can we recommend for both IdP's and SP's to go for 4.A?
  >
  >     What about recommending 4.A and have the option for 4.B when
there
  >     is an agreement between IdP and SP about creating profiles,
anchored
  >     in a contract?
  >
  >     Should we recommend a contract clausula alongside 4.B?
  >
  >     As far as I understand, I'm aware of what Meshna says: If
you opt
  >     for 4.A then it is simply not possible to have a profile,
which is
  >     very annoying if not impossible for our patrons.
  >
  >     Best,
  >     Jos
  >
  >
  >
  >

------------------------------------------------------------------------

  >     *From:* FIM4L <fim4l-bounces@lists.daasi.de
<mailto:fim4l-bounces@lists.daasi.de>
  >     <mailto:fim4l-bounces@lists.daasi.de
<mailto:fim4l-bounces@lists.daasi.de>>> on behalf of Jiri Pavlik
  >     <jiri.pavlik@techlib.cz <mailto:jiri.pavlik@techlib.cz>
<mailto:jiri.pavlik@techlib.cz <mailto:jiri.pavlik@techlib.cz>>>
  >     *Sent:* 15 March 2021 14:58
  >     *To:* Koren, Meshna (ELS-AMS) <M.Koren@elsevier.com
<mailto:M.Koren@elsevier.com>
  >     <mailto:M.Koren@elsevier.com <mailto:M.Koren@elsevier.com>>>
  >     *Cc:* fim4l@lists.daasi.de <mailto:fim4l@lists.daasi.de>
<mailto:fim4l@lists.daasi.de <mailto:fim4l@lists.daasi.de>>
  >     <fim4l@lists.daasi.de <mailto:fim4l@lists.daasi.de>
<mailto:fim4l@lists.daasi.de <mailto:fim4l@lists.daasi.de>>>
  >     *Subject:* Re: [Fim4l] LexisNexis Advance
  >     Hi Meshna,
  >
  >     thanks a lot for the comments.
  >
  >     At Elsevier SP metadata [1] I can see:
  >       eduPersonEntitlement (required)
  >       eduPersonTargetedID (optional)
  >     in DFN-AAI, IDEM or Australian Access Federation.
  >
  >     At the SP metadata in eduGAIN / UK Federation there are no
requested
  >     attributes.
  >     At the SP metadata in eduID.at, SWITCHaai, InCommon, 

RENATER I

can see:
  >         eduPersonEntitlement (required)
  >         eduPersonTargetedID (required)
  >
  >     It illustrates different approaches around the world how to
express
  >     optional ePTID release
  >     in SP metadata and a challenge for one appropriate SP
metadata in
  >     eduGAIN serving globally.
  >     To me
  >          eduPersonEntitlement (required)
  >          eduPersonTargetedID (optional)
  >     seems as the most appropriate.
  >
  >     Cheers
  >                        Jiri
  >
  >
  >     1.
  >

https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.c...

  >

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmet.refeds.org%2Fmet%2Fentity%2Fhttps%25253A%25252F%25252Fsdauth.sciencedirect.com%25252F%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761630378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HmuCXxy9%2F1bQBVkGnsrbBcRmNJP9DsiETfB4g6uP0L4%3D&reserved=0

  >
  >
  >
  >     On Mon, Mar 15, 2021 at 12:01 PM Koren, Meshna (ELS-AMS)
  >     <M.Koren@elsevier.com <mailto:M.Koren@elsevier.com>
<mailto:M.Koren@elsevier.com <mailto:M.Koren@elsevier.com>>> wrote:
  >
  >         Please allow me to add something to this discussion. ____
  >
  >         __ __
  >
  >         "The university students and staff are free to use
  >         personalisation at Lexis Nexis,
  >         Elsevier, EBSCO, ProQuest services if they want to so
  >            eduPersonScopedAffiliation (required)
  >            eduPersonEntitlement  (required)
  >            eduPersonTargetedID (optional)..."
  >
  >         ____
  >
  >         The students and staff can only use personalization when
the IdP
  >         releases ePTID (or pairwiseID), otherwise they can't. I
am not
  >         sure that this is clear from the metadata nor that the
labels we
  >         use to describe the required attributes are very clear
on what
  >         'optional' means.____
  >
  >         __ __
  >
  >         For example, when a student accesses ScienceDirect they
can read
  >         subscribed articles whether or not ePTID has been
released for
  >         them, but if they want to 'create account' because they
would
  >         like to save searches, alerts or their search history,
they can
  >         only do that if the IdP has released a persistent
identifier for
  >         them. Otherwise they can't, because there's nothing 

in their

  >         SAML assertions that allows us to recognize the returning
  >         individual. So we are working towards requiring a
persistent ID.
  >         The personalization remains optional for the user.____
  >
  >         __ __
  >
  >         That may not be the same for other SPs, but it is 

valid for

  >         Elsevier. ____
  >
  >         __ __
  >
  >         Kind regards,____
  >
  >         Meshna____
  >
  >         __ __
  >
  >         __ __
  >
  >         *__ __*
  >
  >         *Meshna Koren**____*
  >
  >
  >         /Product Manager II____/
  >
  >         */Product Management - Identity and Access/**/- 

/**/Research

  >         Products/**/____/*
  >
  >         */__ __/*
  >
  >         */Elsevier BV/*/____/
  >
  >         /Radarweg 29, Amsterdam 1043 NX, The Netherlands____/
  >
  >         /m.koren@elsevier.com <mailto:m.koren@elsevier.com>
<mailto:m.koren@elsevier.com <mailto:m.koren@elsevier.com>>____/
  >
  >         /__ __/
  >
  >         /Federated Access - SAML, Shibboleth, Corporate SSO,
OpenAthens,
  >         Institutional Login____/
  >
  >         /__ __/
  >
  >         /Elsevier Access Support Center:
  >

https://service.elsevier.com/app/answers/list/c/10543/supporthub/elsevieracc...

  >

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fservice.elsevier.com%2Fapp%2Fanswers%2Flist%2Fc%2F10543%2Fsupporthub%2Felsevieraccess%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761640371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=s2nQIh1Mocby%2Fnr0uG61jf%2Fg%2FWgqr%2FfHj6MhuH5sHHs%3D&reserved=0____/

  >
  >         /for your questions about which access methods does 

Elsevier

  >         support, how to set them up, how do they work for
users...____/
  >
  >         /__ __/
  >
  >         __ __
  >
  >         __ __
  >
  >         __ __
  >
  >         __ __
  >
  >         __ __
  >
  >         *From:* FIM4L <fim4l-bounces@lists.daasi.de
<mailto:fim4l-bounces@lists.daasi.de>
  >         <mailto:fim4l-bounces@lists.daasi.de
<mailto:fim4l-bounces@lists.daasi.de>>> *On Behalf Of *Jiri Pavlik
  >         *Sent:* Sunday, March 14, 2021 15:28
  >         *To:* Bernd Oberknapp <bo@ub.uni-freiburg.de
<mailto:bo@ub.uni-freiburg.de>
  >         <mailto:bo@ub.uni-freiburg.de
<mailto:bo@ub.uni-freiburg.de>>>
  >         *Cc:* fim4l@lists.daasi.de <mailto:fim4l@lists.daasi.de>
<mailto:fim4l@lists.daasi.de <mailto:fim4l@lists.daasi.de>>
  >         *Subject:* Re: [Fim4l] LexisNexis Advance____
  >
  >         __ __
  >
  >         **** External email: use caution ****____
  >
  >         ____
  >
  >         Hi Bernd,
  >
  >         I see,
  >            eduPersonScopedAffiliation (required)
  >            eduPersonEntitlement  (required)
  >         is working for Freiburg University and
  >            eduPersonScopedAffiliation (required)
  >            eduPersonEntitlement  (required)
  >            eduPersonTargetedID (required)
  >         is not.
  >
  >         The university students and staff are free to use
  >         personalisation at Lexis Nexis,
  >         Elsevier, EBSCO, ProQuest services if they want to so
  >            eduPersonScopedAffiliation (required)
  >            eduPersonEntitlement  (required)
  >            eduPersonTargetedID (optional)
  >         is working for the University as well.
  >
  >         Is it correct?
  >
  >         All the best
  >
  >                    Jiri____
  >
  >         __ __
  >
  >             ____
  >
  >                 On Sat, Mar 13, 2021 at 2:40 PM Bernd Oberknapp
  >                 <bo@ub.uni-freiburg.de
<mailto:bo@ub.uni-freiburg.de> <mailto:bo@ub.uni-freiburg.de
<mailto:bo@ub.uni-freiburg.de>>>
  >                 wrote:____
  >
  >                     Hi Jiri,
  >
  >                     On 13.03.21 09:15, Jiri Pavlik wrote:
  >
  >                       > When checking ProQuest SP for ProQuest
Central
  >                     in DFN-AAI metadata [1]
  >                       > I can see both eduPersonEntitlement and
  >                     eduPersonTargetedID as required
  >                       > attributes.
  >
  >                     I assume you mean the SP
  > https://shibboleth-sp.prod.proquest.com/shibboleth
  >

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth-sp.prod.proquest.com%2Fshibboleth&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761640371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bosxymzT3WPyXBdeX0NnT5AvLDmTecE%2BEbZe6krDBwk%3D&reserved=0?

  >                     That's obviously
  >                     wrong, both eduPersonScopedAffiliation and
  >                     eduPersonEntitlement are
  >                     supported for authorization, but as far 

as I can

  >                     tell you don't have to
  >                     use them, and eduPersonTargetedID isn't
required.
  >
  >                       > Is it safe to assume that if there is
  >                     personalisation capability at a
  >                       > library service then all German
universities,
  >                     libraries are fine with
  >                       > releasing eduPersonTargetedID for
recognising
  >                     returning users and
  >                       > eduPersonEntitlement,
eduPersonScopedAffiliation
  >                     for authorisation?
  >
  >                     No. I can't speak for other IdPs, but in my
opinion
  >                     that approach would
  >                     be wrong, users by default should be able 

to use

  >                     services anonymously,
  >                     without being recognized as a returning
user. Based
  >                     on what I can see in
  >                     the admin tools, only a very small
percentage of our
  >                     users actually uses
  >                     the personalization features, so releasing
  >                     eduPersonTargetedID by
  >                     default just for personalization isn't an
option. If
  >                     publishers would
  >                     force us to send an eduPersonTargetedID 

just for

  >                     personalization I would
  >                     consider dropping Shibboleth for those
publishers
  >                     and using our EZproxy
  >                     instead.
  >
  >                     Best regards,
  >                     Bernd
  >
  >                     --
  >                     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
<mailto:bo@ub.uni-freiburg.de>
  >                     <mailto:bo@ub.uni-freiburg.de
<mailto:bo@ub.uni-freiburg.de>>
  >                     Internet: www.ub.uni-freiburg.de
<http://www.ub.uni-freiburg.de>
  >

https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ub.uni-freiburg.de%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761650360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eLOZmpzI51ttj9vd4uSNyCcFAAxIPZKUWoSATsoVq1k%3D&reserved=0____

  >
  >
  >

------------------------------------------------------------------------

  >
  >         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 <mailto: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 <mailto:bo@ub.uni-freiburg.de>
Internet: www.ub.uni-freiburg.de <http://www.ub.uni-freiburg.de>

_______________________________________________
FIM4L mailing list
FIM4L@lists.daasi.de <mailto:FIM4L@lists.daasi.de>
http://lists.daasi.de/listinfo/fim4l

Hi Meshna,

On 15.03.21 18:14, Koren, Meshna (ELS-AMS) wrote:

"when no pairwise-id/eduPersonTargetedID is passed to the SP, the SP still should offer personalization based on a registered account ."

Human users tend to re-use passwords, and instead of protecting themselves behind the institutional credentials, they are sharing the password with SPs during the 'registration' and make themselves vulnerable. That's not how federated access is meant to work.

if you regard a registration as not secure enough, that's of course your choice. Maybe you could consider offering different options like PubMed does.

Also; as far as the user's choice goes; users don't understand what the consequences of releasing or not releasing a pesudonymous attribute are, and why should they. This system is too complicated for users to be able to make informed decisions.

Well, if the users don't understand why they release PII like a pairwise-id/eduPersonTargetedID, then we have a fundamental problem, because the consent wouldn't be free and informed and therefore would be invalid. So we have to explain this in a way the users can understand.

If you don't trust the SPs that they are not going to abuse personal data than that is what you need to address.

If an IdP doesn't trust an SP, an attribute like pairwise-id/eduPersonTargetedID of course shouldn't be released at all, and the trust issue indeed would have to be addressed. But that's not my point. The point is that we cannot force users to consent to releasing PII (like a pairwise-id/eduPersonTargetedID) that isn't necessary (if the user doesn't want to use the personalization) and deny access to resources necessary for their studies or research if the users don't give their consent - that again wouldn't be free and informed consent.

So this could get the institution into trouble, unless there is a comparable alternative (back to IP based access?) the users could be pointed to if they don't want the information to be released. Or the institution would have to argue that no consent is needed because releasing the attribute is necessary (which would be difficult for an optional feature like personalization).

Best regards, Bernd

Hi Peter,

On 15.03.21 20:07, Peter Schober wrote:

• Bernd Oberknapp bo@ub.uni-freiburg.de [2021-03-15 19:53]:

...

The point is that we cannot force users to consent to releasing PII (like a pairwise-id/eduPersonTargetedID) that isn't necessary (if the user doesn't want to use the personalization) and deny access to resources necessary for their studies or research if the users don't give their consent - that again wouldn't be free and informed consent.

Maybe my issues with the paragraph above are due to merely phrasing things in an unfortunate way (I'm not discounting the possibilty that we all agree on these issues), but not knowing that for sure all I have to go on is what's written above. To which I'll say this:

You can't ever "force users to consent", obviously. (You can certainly ask them to consent, though. Unless consent is not the legal basis for processing, see below.) And asking for consent in cases where the processing "isn't necessary" is exactly the right case to be asking for consent, IMO. Vice versa, asking for consent to processing that's necessary (e.g. GDPR Art. 6 1 b) is wrong anyway, then the legal bases is not consent and you shouldn't give the impression it is by asking for it.

the wording was indeed unfortunate. What I was trying to say is that if consent is used as a legal basis, the user must have a choice to not release the attribute and still get access to the resource (or have an comparable alternative to the institutional login), and that using a different legal basis might be difficult.

Best regards, Bernd

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.

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@techlib.cz Sent: Tuesday, March 16, 2021 09:5 To: Koren, Meshna (ELS-AMS) M.Koren@elsevier.com Cc: fim4l@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@elsevier.commailto:M.Koren@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@lists.daasi.demailto:fim4l-bounces@lists.daasi.de> On Behalf Of Ken Klingenstein Sent: Tuesday, March 16, 2021 04:19 To: fim4l@lists.daasi.demailto: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.demailto:FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4lhttps://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.daasi.de%2Flistinfo%2Ffim4l&data=04%7C01%7CM.Koren%40elsevier.com%7C1d798e76cee44cd02b5f08d8e8587d71%7C9274ee3f94254109a27f9fb15c10675d%7C0%7C0%7C637514814069076563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Uv1%2FqY3HwgXk6qn9IHV5lKypCQ44gmt24IEfEwUfFeQ%3D&reserved=0

________________________________

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

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@techlib.cz Sent: Tuesday, March 16, 2021 11:37 To: Koren, Meshna (ELS-AMS) M.Koren@elsevier.com Cc: fim4l@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@elsevier.commailto:M.Koren@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@techlib.czmailto:jiri.pavlik@techlib.cz> Sent: Tuesday, March 16, 2021 09:5 To: Koren, Meshna (ELS-AMS) <M.Koren@elsevier.commailto:M.Koren@elsevier.com> Cc: fim4l@lists.daasi.demailto:fim4l@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@elsevier.commailto:M.Koren@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@lists.daasi.demailto:fim4l-bounces@lists.daasi.de> On Behalf Of Ken Klingenstein Sent: Tuesday, March 16, 2021 04:19 To: fim4l@lists.daasi.demailto: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.demailto:FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4lhttps://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.

Hi,

I would support that suggestion - that's what I meant with "consider offering different options like PubMed":

https://account.ncbi.nlm.nih.gov/

Unfortunately ORCID is hidden in the long list of "more login options" even though the NLN recommends ORCID as "a good option for researchers and other academics" in the FAQ.

Best regards, Bernd

On 17.03.21 15:16, Jiri Pavlik wrote:

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@elsevier.com mailto:M.Koren@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@techlib.cz
<mailto:jiri.pavlik@techlib.cz>>
*Sent:* Tuesday, March 16, 2021 11:37
*To:* Koren, Meshna (ELS-AMS) <M.Koren@elsevier.com
<mailto:M.Koren@elsevier.com>>
*Cc:* fim4l@lists.daasi.de <mailto:fim4l@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@elsevier.com <mailto:M.Koren@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@techlib.cz
    <mailto:jiri.pavlik@techlib.cz>>
    *Sent:* Tuesday, March 16, 2021 09:5
    *To:* Koren, Meshna (ELS-AMS) <M.Koren@elsevier.com
    <mailto:M.Koren@elsevier.com>>
    *Cc:* fim4l@lists.daasi.de <mailto:fim4l@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@elsevier.com <mailto:M.Koren@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@lists.daasi.de
        <mailto:fim4l-bounces@lists.daasi.de>> *On Behalf Of *Ken
        Klingenstein
        *Sent:* Tuesday, March 16, 2021 04:19
        *To:* fim4l@lists.daasi.de <mailto: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 <mailto:FIM4L@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.

---

FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l

Hi Peter,

Completely agree here, for more reasons than one, I gave our picture of this last week, attached. There are your personal settings which you can access in any way, as long as you can prove to us you are you, and then there are institutional entitlements that you can only access when you can prove your association with the institution as well.

Kind regards, Meshna

-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Peter Schober Sent: Monday, March 22, 2021 12:53 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] a few meta-comments about the LexisNexis Advance Thread

*** External email: use caution ***

* Jiri Pavlik jiri.pavlik@techlib.cz [2021-03-17 15:16]:

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

I shouldn't have to explain any of this but anyway:

By avoiding the requirement for the subject to log in from their home institution you're also preventing that institution from having a say in whether that subject should be able to access those resources -- when it's that institituion that's likely paying for that access.

So while "account linking" may seem "great" that cannot transfer the right to access institutionally licensed resoures to arbitrary external identities logging in from other services.

At the very least the SP would have to regularly force the subject to renew the "account linking" with the institutionally provided account in order to allow access to institutionally licensed resource when logging in from /other/ services -- but how regularly? And does the institution have a say in that? While Meshna will be able to tell us how Elsevier implements this what about *other* SPs that offer the same "convenience"?

Also I guess institutions will also be missing any reporting (e.g. the newly proposed eduPerson attrribute) for access to "their" licensed resources then that access is being made avaiable even when not using the institutional authentication / authorisation service?

So before people are proclaiming the greatness of account linking as a technical solution to (optional) personalised access to institutionally licensed resources I'd like to see how the problems introduced that way should be dealt with, ideally consistently across Service Providers.

-peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.daasi...

________________________________

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

Meshna et al.,

When I proposed a way forward to enable (optional) personalisation features without the subject having a say about it: https://lists.daasi.de/pipermail/fim4l/2021-March/000432.html I explicitly excluded "local account registration" to keep this somewhat shorter and on-topic. Your own description heavily featured local account registration as an alternative means to achieve that so I'll finally (sorry for the delay) comment on that below.

* Koren, Meshna (ELS-AMS) M.Koren@elsevier.com [2021-03-16 09:32]:

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

Taken the above literally ("a local account will be linked to their pseudonymous ID") it would be easy to discount this solely on the fact that nowhere near all institutions/libraries today will be releasing such identifiers, "just in case", for optional personalisation features.

And if they /did/ always release a stable identifier the suggested "registration" for a "local account" wouldn't even be necessary as you'd already have a stable identifier to recognise returning subjects, i.e., you could already offer personalisation features without having to force/nudge the subject into creating a local account. In fact, it would be virtually identical to my proposal https://lists.daasi.de/pipermail/fim4l/2021-March/000432.html if you simply called the link for "local account registration" something like "Activate personalisation". Only in my proposal you'd ask that right away (at/immedeately after the subject logs in via her institution), making it clear(er) that no use of the identifier is being made before the subject has had a chance to dis-/agree. Whereas you are arguing for a (probably) less disruptive UX of asking *later* that comes at the cost of increased trust requirements that the service provider is not making use of that identifier before the subject was ever asked. (*Maybe* that latter difference is small enough that it could be rolled into one common approach. To the extent that the proposals benefit from having a stable identifier sent by the institution/library present I think it may make sense to tune things towards earning that trust.)

Taking the above less literally (at least) parts of your proposed method -- using local account registartion as the means to enable optional personalisation -- are possible to implement even without a stable identifier having been sent by the institution/library. (In fact the behaviour at the SP is identical in both cases: The subject logs in via her instiution and has a valid session at the SP. In that session they create a "local account" that's then tied to their institutional log in by having both connected to the same SP session.)

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

If the subject registers for a "local account" how's that not yet another "set of credentials" for her, in addition to the institutional account she had to use at least initially in order to prove her affiliation with the academic institution (which is what authorised her to access the resource in the first place, most likely)? That's still "multiple credentials" -- unless your use of what "register" and "local account" means here is totally different from mine. (As for a possible reading of "register account" to actually mean "activate personalisation"" see above.) To me an account always has a passwort of some kind associated with it, making this yet another "set of credentials".

And finally, any use of the local account would regularly needed to be prompted to be "re-linked" with the institution/library or otherwise lose access to resources only available through (continued) affiliation with the institution/library paying for that access: I don't see either your legal dept nor institutions being happy if you continned to provided access to institutionally licensed resources to people using locally registered acounts, without checking back whether those people are still considered to be entitled to that access by the institutions they initially used to log in with. We've had that conversation a bit over a year ago on the REFEDS list: https://lists.refeds.org/sympa/arc/refeds/2020-01/msg00019.html (were I argued that this is mostly your own problem, *IF* it was clear to everyone that institutions couldn't be held liable for any misuse resulting from that kind of access) but noone else ever chimed in there. Maybe re-starting this particular sub-topic here will give different results (once can always hope).

To summarise, I don't see any clear advantages in having subjects "register local accounts" -- neither in terms of UX (need to register an local account) nor security (Yet Another Username/Password for the local account) nor privacy (when identifiers from the institution or library are involved) nor licensing/legal certainty (due to the separation of the login method from the source of current authorisation data) -- that wouldn't be possible by implementing my proposal. (Which amounts to institutions/libraries always releasing a pseudonymous identifier to service providers of a certain category, where the service provider commits itself to asking the subject before making any use of the identifer for tracking/personalisation.)

Best regards, -peter

Hi Meshna,

On 15/03/2021, 17:37, "Koren, Meshna (ELS-AMS)" M.Koren@elsevier.com wrote: Hi Jos, Please also look into the REFEDS entity categories and the recent work there. If your recommendations to librarians propose some new concepts or terminology (transitory access), or parallel decision making, that's going to cause a lot of confusion.

We are aware of and very appreciate the work of Seamless Access and REFEDS and its two (brand)new entity categories "Anonymous" and "Pseudonymous". They functionally align with FIM4L recommendations resp. 4.A and 4.B.

We (on this FIM4L list) have chosen (early 2019) not to use the word anonymous because it pretends that you are anonymous, which is not, or at least disputable. But I agree (and we all perhaps) for the understanding and clarity the naming 'anonymous' is more clear. In the highly sensitive library privacy world they are watching us, and you can expect articles from e.g. Scholarly Kitchen contesting our privacy claims. Hence, we named it "Transitory" and "Personalized" referring to the functionality rather than the privacy. But aligning the wording with the now official REFEDS entity categories is something to consider for a next version. Has been noted😉

Best, Jos

Hi,

at the REFEDS entity categories specs there is:

"Service Providers SHOULD limit their data requirements to the bundle of attributes defined in Section 4."

at 5. Service Provider Requirements paragraph.

IMHO it leaves a room for FIM4L to specify whether samlPairwiseID, edPersonScopedAffialition, eduPersonEntitlement should be requested by SPs as required or optional. And what actually means required and optional for the attributes release from IdPs to SPs :-)

Best Jiri

On Wed, Mar 17, 2021 at 9:43 AM Peter Schober peter.schober@univie.ac.at wrote:

• Jos Westerbeke jos.westerbeke@eur.nl [2021-03-17 09:31]:

...

We (on this FIM4L list) have chosen (early 2019) not to use the word anonymous because it pretends that you are anonymous, which is not, or at least disputable.

There is no such thing as an anonymous federated login. So this terminology serves to confuse more if anything.

-peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l

Hi Peter,

I support your points.

I agree with Bernd's: "there are obviously different opinions about when "required" should be used."

I am all in with Meshna and Jos that FIM4L recommendations need to be modified now to play nicely with new REFEDS entity categories proposed by Seamless Access.

We also need to revisit: "eduPersonEntitlement, with other values, representing group or role memberships in alignment with AARC Guidelines on expressing group membership and role information" in FIM4L's recommendations. This is currently used at Prague's Charles University for example to describe users faculty affiliations and it is providing SPs with informations needed for authorisation when there are licences for faculty students and staff. This is not clear in the REFEDS entity categories specs how SPs are supposed to authorise faculty, campus, departments users.

Cheers

Jiri

On Wed, Mar 17, 2021 at 6:45 PM Peter Schober peter.schober@univie.ac.at wrote:

I can neither understand what you're trying to say not what this has to do with the specific message you are replying to (which was about Jos' statement about maybe adopting use of the "anonymous" terminology which I advise against). -peter

Full quote below because I wouldn't know what to quote.

• Jiri Pavlik jiri.pavlik@techlib.cz [2021-03-17 18:24]:

...

Hi,

at the REFEDS entity categories specs there is:

"Service Providers SHOULD limit their data requirements to the bundle of attributes defined in Section 4."

at 5. Service Provider Requirements paragraph.

IMHO it leaves a room for FIM4L to specify whether samlPairwiseID, edPersonScopedAffialition, eduPersonEntitlement should be requested by SPs as required or optional. And what actually means required and optional for the attributes release from IdPs to SPs

:-)

...

Best Jiri

On Wed, Mar 17, 2021 at 9:43 AM Peter Schober <

peter.schober@univie.ac.at>

...

wrote:

...

• Jos Westerbeke jos.westerbeke@eur.nl [2021-03-17 09:31]:

...

We (on this FIM4L list) have chosen (early 2019) not to use the word anonymous because it pretends that you are anonymous, which is not, or at least disputable.

There is no such thing as an anonymous federated login. So this terminology serves to confuse more if anything.

-peter

---

FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l

Hi Peter,

On 15.03.21 19:56, Peter Schober wrote:

Case in point: Bernd O. on this list would rather remove the most obvious and direct method of accessing an SP -- open its home page and "log in" -- than release a pseudonymous identifier to an SP for personalisation purposes. (I.e., the reservation here is not even specific to /optional/ personalisation, which I'm discussing here, but to any kind of personalisation based on a privacy-preserving identifier provided by the institution):

• Bernd Oberknapp bo@ub.uni-freiburg.de [2021-03-13 14:40]:

...

If publishers would force us to send an eduPersonTargetedID just for personalization I would consider dropping Shibboleth for those publishers and using our EZproxy instead.

just to clarify: I would only consider this if the SP would force us to send an eduPersonTargetedID (or any other attribte/identifier that allows to recognize returning users) for all users, i.e. by making it a requirement for using the institutional login. I don't have a problem with an optional attribute, i.e. if the user can choose whether to release that attribute for personalization or not.

Best regards, Bernd