Hi Caroline,

thanks for UK perspective, nice to hear that proposed - eduPersonScopedAffiliation (required) - eduPersonTargetedID (optional) - givenName (optional) - sn (optional) - mail (optional) - CoCo & Sirtfy support would work for the University of Essex.

Best Jiri

On Thu, Mar 11, 2021 at 11:26 AM Checkley, Caroline R checkc@essex.ac.uk wrote:

Hi Jiri

This would be ok with me.

When Nexis introduced their refreshed user interface in the UK we had some discussion on our eResources listserv and I raised it with the UKFAM.

Nexis replied:

*“If customers do not wish to authenticate directly this is OK. We are in the final stages of setting up OpenAthens & UK Federation (Shibboleth) against the refreshed user interface. So long as a Permanent identifier (rather than Transient) is sent we have relaxed the validation rules against Forename, Surname, and Email Address to allow accounts to be created without these items being present.” *

This did cause us a few issues, as we had some problems a few months ago when I think they made some further changes and (perhaps) forgot we had requested this (because some users were being asked for name and e-mail again) so the more we can standardise this the better.

All the best

Caroline

*Caroline Checkley*

Digital Systems and Services Librarian

Library Services

University of Essex

E checkc@essex.ac.uk

► http://library.essex.ac.uk/

*From:* FIM4L fim4l-bounces@lists.daasi.de *On Behalf Of *Jiri Pavlik *Sent:* 11 March 2021 08:05 *To:* fim4l@lists.daasi.de *Subject:* [Fim4l] LexisNexis Advance

*CAUTION:* This email was sent from outside the University of Essex. Please do not click any links or open any attachments unless you recognise and trust the sender. If you are unsure whether the content of the email is safe or have any other queries, please contact the IT Helpdesk.

Deal all,

in eduGAIN LexisNexis Advance SP request optionally eduPersonScopedAffiliation and eduPersonTargetedID attributes. [1] In Austrian eduID.at https://linkprotect.cudasvc.com/url?a=https%3a%2f%2feduID.at&c=E,1,vekOlOJTQ2JO4CxQyfPt4og9YtcRRcZAGN8wfeDejSZP3nvwRm1OOiJ1Utf75MmO1FqA8hVbeq7FEtY2dFWp0jLGXape9OoZTlkK6R4x1B3vpmTi-EeJBiBjVZOb&typo=1&ancr_add=1 it requests these two attributes as required. [2] In French RENATER it requires eduPersonScopedAffiliation, eduPersonTargetedID, givenName, sn, mail attributes and supports Code of Conduct and Sirtfy entity categories. [3]

I am wondering whether everyone could be fine with following set of attributes along with CoCo and Sirtfy entity categories support:

eduPersonScopedAffiliation (required)

eduPersonTargetedID (optional)

givenName (optional)

sn (optional)

mail (optional)

Universities/libraries may choose to release just eduPersonScopedAffiliation and be FIM4L privacy stars. It will correspond to the upcoming REFEDS Anonymous Authorisation entity category. [4]

Universities/libraries may also choose to release eduPersonScopedAffiliation and eduPersonTargetedID for enabling personalisation capabilities. It will correspond to the upcoming REFEDS Pseudonymous Authorisation entity category. [5]

And finally universities/libraries may also choose to release eduPersonScopedAffiliation, eduPersonTargetedID and let users decide about releasing name and e-mail address. [6]

Do you like this kind of approach?

Take care

       Jiri Pavlik, techlib.cz

https://linkprotect.cudasvc.com/url?a=http%3a%2f%2ftechlib.cz&c=E,1,isdDrccH2ECgDKm-Eyru3kke4jDTwPe2JvlQUKCgu1DFG7bRGjhwPHyIcVQUmlTzcE6kHWNddgT7uhV6XcIDIMYzZRowsMjHI69W7R-E8S4Sb11a9GRuGSiY&typo=1

https://met.refeds.org/met/entity/https%253A%252F%252Fsignin.lexisnexis.com%... https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fmet.refeds.org%2fmet%2fentity%2fhttps%25253A%25252F%25252Fsignin.lexisnexis.com%25252Flnaccess%25252Ffed%25252Fauthn%2f%3ffederation%3dedugain&c=E,1,uU_9KIG3lXO1Tobcb8Sq30E9STs0ZpAIZUe73RKcLR8cAJcYwBoCtzxdEcVyYWuEm2jhx5EwTYtSTlGcuBqrBge7z9cDpnigSLX8NrsNiP5yOg,,&typo=1

https://met.refeds.org/met/entity/https%253A%252F%252Fsignin.lexisnexis.com%... https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fmet.refeds.org%2fmet%2fentity%2fhttps%25253A%25252F%25252Fsignin.lexisnexis.com%25252Flnaccess%25252Ffed%25252Fauthn%2f%3ffederation%3daconet-identity-federation-eduidat&c=E,1,p10xP-c-nAmQIeuv7L4bz2ByCTzBBJbg9H7U838RGJ3Aw4IF4VjQmrSV-O7EFtTcgcync3DUL4cCvQY2Lyxbb0K7xgbglbWJC8-scWHMsQ,,&typo=1

https://met.refeds.org/met/entity/https%253A%252F%252Fsignin.lexisnexis.com%... https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fmet.refeds.org%2fmet%2fentity%2fhttps%25253A%25252F%25252Fsignin.lexisnexis.com%25252Flnaccess%25252Ffed%25252Fauthn%2f%3ffederation%3dfederation-education-recherche&c=E,1,85BsQoE_4qyDnFr18C6-FKg3M_CwBlkwC7HEnA7bVEhZgYFW4vSBWg-QHMMWQRjIrqZyClZW8uErJRintpHxn80R4xuM-S8deNwJx5Mc6pTrgnz4cjFb8m1BjtHQ&typo=1

https://wiki.refeds.org/display/CON/Entity+Category+Consultation+Anonymous+A... https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwiki.refeds.org%2fdisplay%2fCON%2fEntity%2bCategory%2bConsultation%2bAnonymous%2bAuthorization&c=E,1,HoY1Dw1GOlk4knh5_ANVvY_ScrLsWQOk1JK56z_hFJXzjkb8RQKVZWCWdhAdyEGI5BLHSuDHdbQOGBqEBPntpSjNBkuBBlix62QKyp5mFhA,&typo=1

https://wiki.refeds.org/display/CON/Entity+Category+Consultation+Pseudonymou... https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwiki.refeds.org%2fdisplay%2fCON%2fEntity%2bCategory%2bConsultation%2bPseudonymous%2bAuthorization&c=E,1,MvMWL-5dONJ-X68ZM2B45S48JzAdS_o8zwi9b6vjvF0STIWJ7lSvbnOlAVAu9jHoUN6ZUDdELlBJhxXYZF7e4bAK3ncsrR6F7b8QxK4kf-eQFG7ZBQ,,&typo=1

6. https://www.youtube.com/watch?v=znpjHR6LOxs

Hi Peter,

The intent here is worldwide agreement within FIM4L actually what is the best fit for LexisNexis Advance and all similar SPs out there. IMHO your suggestion is: - eduPersonScopedAffiliation (required) - eduPersonTargetedID (required) - Sirtfy support And rather SAML pairwise-id than eduPersonTargetedID as described in FIM4L recommendations and REFEDS Pseudonymous Authorisation entity category specification.

I am wondering whether there is an opportunity of employing a Consent-informed Attribute Release system (CAR) [1] for releasing name and e-mail address with user consent. I can see that French colleagues at least may be interested in that.

Best

Jiri

1. https://spaces.at.internet2.edu/display/CAR/CAR%3A+Consent-informed+Attribut...

On Thu, Mar 11, 2021 at 12:03 PM Peter Schober peter.schober@univie.ac.at wrote:

• Jiri Pavlik jiri.pavlik@techlib.cz [2021-03-11 09:05]:

...

I am wondering whether everyone could be fine with following set of attributes along with CoCo and Sirtfy entity categories support: eduPersonScopedAffiliation (required) eduPersonTargetedID (optional) givenName (optional) sn (optional) mail (optional)

Ignoring the fact that ultimately existing bilateral (or consortial) contracts (here with LN) will always trump what GÉANT CoCo says, note that CoCo v1 (the only released version that currently exists) explicitly only covers strictly *required* (isRequired="true" in SAML Metadata) attributes. It cannot be used for optional data. People should also be aware that there is no clear indication that LexisNexis even intended to adhere to the GÉANT CoCo specification: All that I've seen so far is RENATER's claim that the LN SP is covered by CoCo. But CoCo also requires that the Privacy Policy for a SAML SP adhering to CoCo contains a reference to the GÉANT CoCo and this is NOT the case with LexisNexis here (not even in the URL referenced in the RENATER metadata). So the CoCo-support of the LexisNexis SP is (1) highly questionable, IMO, and (2) very likely meaningless in light of actual contracts governing use of / access to the service.

As to the actual question above: If the service continues to work fine with only the commonly released minimal set of data (common-lib-terms or eduPersonScopedAffiliation for authorisation; SAML persistent NameID or eduPersonTargetedID or SAML pairwise-id for personalisation functionality) I see no reason to change anything in order to encourge institutions to send *more* personal data to the publisher. (And even if we did, what makes LN so special here? Wouldn't we also have to have this discussion then for every other of the hundreds of SPs we have for "institutionally licensed e-resource access"?)

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

Hello,

eduPersonTargetedID is not necessary for EBSCOhost, the login works fine with just eduPersonScopedAffiliation or eduPersonEntitlement.

We should not recommend to make eduPersonTargetedID a requirement or declare it as required if it isn't necessary.

Best regards, Bernd

On 11.03.21 18:32, Jiri Pavlik wrote:

Hi,

Let me point out to EBSCOhost as a similar service. Similar set of requested attributes:

• eduPersonScopedAffiliation (required)
• eduPersonTargetedID (required)
• eduPersonEntitlement (required)

should be the right fit here because EBSCOhost is using eduPersonScopedAffiliation and eduPersonEntitlement values for authorisation, eduPersonTargetedID for recognising returning user and providing personalisation.

Looking at EBSCOhost SP metadata I can see that in Finland [1] or in Australia [2] there is an interest in releasing givenName, sn, mail attributes.

Listing eduPersonScopedAffiliation, eduPersonTargetedID, eduPersonEntitlement as optional in UK Federation / eduGAIN [3] or listing no requested attributes at all in US InCommon Federations seems like a mistake to me.

All the best

        Jiri

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

On Thu, Mar 11, 2021 at 3:28 PM Jiri Pavlik <jiri.pavlik@techlib.cz mailto:jiri.pavlik@techlib.cz> wrote:

Hi Peter,

The intent here is worldwide agreement within FIM4L actually what is
the best fit for LexisNexis Advance
and all similar SPs out there. IMHO your suggestion is:
- eduPersonScopedAffiliation (required)
- eduPersonTargetedID (required)
- Sirtfy support
And rather SAML pairwise-id than eduPersonTargetedID as described in
FIM4L recommendations and
REFEDS Pseudonymous Authorisation entity category specification.

I am wondering whether there is an opportunity of employing a
Consent-informed Attribute Release system (CAR) [1]
for releasing name and e-mail address with user consent. I can see
that French colleagues at least may be interested
in that.

Best

               Jiri


1.

https://spaces.at.internet2.edu/display/CAR/CAR%3A+Consent-informed+Attribut...

On Thu, Mar 11, 2021 at 12:03 PM Peter Schober
<peter.schober@univie.ac.at <mailto:peter.schober@univie.ac.at>> 

wrote:

    * Jiri Pavlik <jiri.pavlik@techlib.cz
    <mailto:jiri.pavlik@techlib.cz>> [2021-03-11 09:05]:
     > I am wondering whether everyone could be fine with following
    set of
     > attributes along with CoCo and Sirtfy entity categories 

support:

     > eduPersonScopedAffiliation (required)
     > eduPersonTargetedID (optional)
     > givenName  (optional)
     > sn   (optional)
     > mail  (optional)

    Ignoring the fact that ultimately existing bilateral (or 

consortial)

    contracts (here with LN) will always trump what GÉANT CoCo says,
    note
    that CoCo v1 (the only released version that currently exists)
    explicitly only covers strictly *required* (isRequired="true" in
    SAML
    Metadata) attributes. It cannot be used for optional data.
       People should also be aware that there is no clear indication
    that
    LexisNexis even intended to adhere to the GÉANT CoCo 

specification:

    All that I've seen so far is RENATER's claim that the LN SP is
    covered
    by CoCo. But CoCo also requires that the Privacy Policy for a
    SAML SP
    adhering to CoCo contains a reference to the GÉANT CoCo and 

this is

    NOT the case with LexisNexis here (not even in the URL 

referenced in

    the RENATER metadata).
       So the CoCo-support of the LexisNexis SP is (1) highly
    questionable,
    IMO, and (2) very likely meaningless in light of actual contracts
    governing use of / access to the service.

    As to the actual question above: If the service continues to
    work fine
    with only the commonly released minimal set of data
    (common-lib-terms
    or eduPersonScopedAffiliation for authorisation; SAML persistent
    NameID or eduPersonTargetedID or SAML pairwise-id for
    personalisation
    functionality) I see no reason to change anything in order to
    encourge
    institutions to send *more* personal data to the publisher.
    (And even if we did, what makes LN so special here? Wouldn't 

we also

    have to have this discussion then for every other of the 

hundreds of

    SPs we have for "institutionally licensed e-resource access"?)

    Best regards,
    -peter
    _______________________________________________
    FIM4L mailing list
    FIM4L@lists.daasi.de <mailto:FIM4L@lists.daasi.de>
    http://lists.daasi.de/listinfo/fim4l

---

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

Hi Jiri,

for EBSCOhost yes, it doesn't seem to make a difference whether I'm logged in with a personal account or not, the number of ebooks available for download and also the limitations seem to be the same.

I couldn't try if this works with the EBSCO Mobile app because the sign in either fails or fails to connect to the app (for all methods, not just for Shibboleth).

Best regards, Bernd

On 11.03.21 18:46, Jiri Pavlik wrote:

Hi Bernd,

Is downloading of e-books at EBSCO eBooks for off-line reading working as well when eduPersonTargetedID is not provided?

BR Jiri

On Thu, Mar 11, 2021 at 6:37 PM Bernd Oberknapp <bo@ub.uni-freiburg.de mailto:bo@ub.uni-freiburg.de> wrote:

Hello,

eduPersonTargetedID is not necessary for EBSCOhost, the login works
fine
with just eduPersonScopedAffiliation or eduPersonEntitlement.

We should not recommend to make eduPersonTargetedID a requirement or
declare it as required if it isn't necessary.

Best regards,
Bernd


On 11.03.21 18:32, Jiri Pavlik wrote:
  > Hi,
  >
  > Let me point out to  EBSCOhost as a similar service. Similar 

set of

  > requested attributes:
  > - eduPersonScopedAffiliation (required)
  > - eduPersonTargetedID (required)
  > - eduPersonEntitlement (required)
  > should be the right fit here because EBSCOhost is
  > using eduPersonScopedAffiliation and
  > eduPersonEntitlement values for authorisation,
eduPersonTargetedID for
  > recognising returning user and providing personalisation.
  >
  > Looking at EBSCOhost SP metadata I can see that in Finland 

[1] or in

  > Australia [2] there is an interest in releasing givenName, 

sn, mail

  > attributes.
  >
  > Listing eduPersonScopedAffiliation, eduPersonTargetedID,
  > eduPersonEntitlement as optional in UK Federation / eduGAIN 

[3] or

  > listing no requested attributes at all in US InCommon
Federations seems
  > like a mistake to me.
  >
  > All the best
  >
  >             Jiri
  >
  >
  >
  > 1.
  >

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

  >
  > 2.
  >

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

  >
  > 3.
  >

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

  >
  > 4.
  >

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

  >
  >
  > On Thu, Mar 11, 2021 at 3:28 PM Jiri Pavlik
<jiri.pavlik@techlib.cz <mailto:jiri.pavlik@techlib.cz>
  > <mailto:jiri.pavlik@techlib.cz <mailto:jiri.pavlik@techlib.cz>>>
wrote:
  >
  >     Hi Peter,
  >
  >     The intent here is worldwide agreement within FIM4L actually
what is
  >     the best fit for LexisNexis Advance
  >     and all similar SPs out there. IMHO your suggestion is:
  >     - eduPersonScopedAffiliation (required)
  >     - eduPersonTargetedID (required)
  >     - Sirtfy support
  >     And rather SAML pairwise-id than eduPersonTargetedID as
described in
  >     FIM4L recommendations and
  >     REFEDS Pseudonymous Authorisation entity category 

specification.

  >
  >     I am wondering whether there is an opportunity of employing a
  >     Consent-informed Attribute Release system (CAR) [1]
  >     for releasing name and e-mail address with user consent. I
can see
  >     that French colleagues at least may be interested
  >     in that.
  >
  >     Best
  >
  >                    Jiri
  >
  >
  >     1.
  >

https://spaces.at.internet2.edu/display/CAR/CAR%3A+Consent-informed+Attribut...

  >
  >
  >
  >     On Thu, Mar 11, 2021 at 12:03 PM Peter Schober
  >     <peter.schober@univie.ac.at
<mailto:peter.schober@univie.ac.at>
<mailto:peter.schober@univie.ac.at
<mailto:peter.schober@univie.ac.at>>>
wrote:
  >
  >         * Jiri Pavlik <jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>
  >         <mailto:jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>>> [2021-03-11 09:05]:
  >          > I am wondering whether everyone could be fine with
following
  >         set of
  >          > attributes along with CoCo and Sirtfy entity 

categories

support:
  >          > eduPersonScopedAffiliation (required)
  >          > eduPersonTargetedID (optional)
  >          > givenName  (optional)
  >          > sn   (optional)
  >          > mail  (optional)
  >
  >         Ignoring the fact that ultimately existing bilateral (or
consortial)
  >         contracts (here with LN) will always trump what GÉANT
CoCo says,
  >         note
  >         that CoCo v1 (the only released version that currently
exists)
  >         explicitly only covers strictly *required*
(isRequired="true" in
  >         SAML
  >         Metadata) attributes. It cannot be used for optional 

data.

  >            People should also be aware that there is no clear
indication
  >         that
  >         LexisNexis even intended to adhere to the GÉANT CoCo
specification:
  >         All that I've seen so far is RENATER's claim that the LN
SP is
  >         covered
  >         by CoCo. But CoCo also requires that the Privacy Policy
for a
  >         SAML SP
  >         adhering to CoCo contains a reference to the GÉANT 

CoCo and

this is
  >         NOT the case with LexisNexis here (not even in the URL
referenced in
  >         the RENATER metadata).
  >            So the CoCo-support of the LexisNexis SP is (1) highly
  >         questionable,
  >         IMO, and (2) very likely meaningless in light of actual
contracts
  >         governing use of / access to the service.
  >
  >         As to the actual question above: If the service 

continues to

  >         work fine
  >         with only the commonly released minimal set of data
  >         (common-lib-terms
  >         or eduPersonScopedAffiliation for authorisation; SAML
persistent
  >         NameID or eduPersonTargetedID or SAML pairwise-id for
  >         personalisation
  >         functionality) I see no reason to change anything in
order to
  >         encourge
  >         institutions to send *more* personal data to the 

publisher.

  >         (And even if we did, what makes LN so special here?
Wouldn't
we also
  >         have to have this discussion then for every other of the
hundreds of
  >         SPs we have for "institutionally licensed e-resource
access"?)
  >
  >         Best regards,
  >         -peter
  >         _______________________________________________
  >         FIM4L mailing list
  > FIM4L@lists.daasi.de <mailto:FIM4L@lists.daasi.de>
<mailto:FIM4L@lists.daasi.de <mailto:FIM4L@lists.daasi.de>>
  > http://lists.daasi.de/listinfo/fim4l
  >
  >
  > _______________________________________________
  > 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

Hello,

we can check Elsevier Science Direct for inspiration as well. Here eduPersonEntitlement is used for authorisation and eduPersonTargetedID is used for recognising returning users and for personalisation. So the right fit of requested attributes here could be: - eduPersonEntitlement (required) - eduPersonTargetedID (optional)

If eduPersonTargetedID attribute is released according to user consent then the user is in charge whether he/she could use personalisation or prefers anonymous access.

This set of requested attributes in Elsevier SD metadata [1] is registered in Australian Access Federation and in IDEM.

There is a vast variety of other requested attributes sets ranging from - eduPersonEntitlement (required) - eduPersonTargetedID (required) (eduID.at, RENATER, SWITCHaai, Edugate, LIAF) via - eduPersonEntitlement (required) (DFN-AAI) and - eduPersonEntitlement (optional) - eduPersonTargetedID (optional) (InCommon) to no required attributes at all. (eduGAIN/UK Federation, Belnet, CAFe, CARSI, CORFe, GakuNin)

There are also federations where eduPersonScopedAffiliation is among required attributes and federations where there is eduPersonTargetedID attribute required only.

Take care, stay healthy

Jiri

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

On Thu, Mar 11, 2021 at 8:22 PM Jiri Pavlik jiri.pavlik@techlib.cz wrote:

Hi Bernd,

I see, thanks.

IMHO if eduPersonTargetedID is released, an institutional account is used as a personal user account at EBSCOhost as well. If eduPersonTargetedID is not released users need to sign in with a Google or local account and institutional sign in could be used for authorisation [1].

That said the right fit for EBSCOhost could be:

• eduPersonScopedAffiliation (required)
• eduPersonEntitlement (required)
• eduPersonTargetedID (optional)

When an organisation chooses to release eduPersonTargetedID attribute then users of the organization can use an institutional account as a personal account at EBSCOhost as well.

If eduPersonTargetedID attribute is released according to user consent then the user is in charge whether his/her institutional account is used as personal account at EBSCOhost or it is not.

Best Jiri

https://connect.ebsco.com/s/article/How-do-I-authorize-reauthorize-my-person...

On Thu, Mar 11, 2021 at 7:31 PM Bernd Oberknapp bo@ub.uni-freiburg.de wrote:

...

Hi Jiri,

for EBSCOhost yes, it doesn't seem to make a difference whether I'm logged in with a personal account or not, the number of ebooks available for download and also the limitations seem to be the same.

I couldn't try if this works with the EBSCO Mobile app because the sign in either fails or fails to connect to the app (for all methods, not just for Shibboleth).

Best regards, Bernd

On 11.03.21 18:46, Jiri Pavlik wrote:

...

Hi Bernd,

Is downloading of e-books at EBSCO eBooks for off-line reading working as well when eduPersonTargetedID is not provided?

BR Jiri

On Thu, Mar 11, 2021 at 6:37 PM Bernd Oberknapp <bo@ub.uni-freiburg.de mailto:bo@ub.uni-freiburg.de> wrote:

Hello,

eduPersonTargetedID is not necessary for EBSCOhost, the login works
fine
with just eduPersonScopedAffiliation or eduPersonEntitlement.

We should not recommend to make eduPersonTargetedID a requirement

or

...

declare it as required if it isn't necessary.

Best regards,
Bernd


On 11.03.21 18:32, Jiri Pavlik wrote:
  > Hi,
  >
  > Let me point out to  EBSCOhost as a similar service. Similar

set of

...

  > requested attributes:
  > - eduPersonScopedAffiliation (required)
  > - eduPersonTargetedID (required)
  > - eduPersonEntitlement (required)
  > should be the right fit here because EBSCOhost is
  > using eduPersonScopedAffiliation and
  > eduPersonEntitlement values for authorisation,
eduPersonTargetedID for
  > recognising returning user and providing personalisation.
  >
  > Looking at EBSCOhost SP metadata I can see that in Finland

[1] or in

...

  > Australia [2] there is an interest in releasing givenName,

sn, mail

...

  > attributes.
  >
  > Listing eduPersonScopedAffiliation, eduPersonTargetedID,
  > eduPersonEntitlement as optional in UK Federation / eduGAIN

[3] or

...

  > listing no requested attributes at all in US InCommon
Federations seems
  > like a mistake to me.
  >
  > All the best
  >
  >             Jiri
  >
  >
  >
  > 1.
  >

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

...

  >
  > 2.
  >

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

...

  >
  > 3.
  >

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

...

  >
  > 4.
  >

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

...

  >
  >
  > On Thu, Mar 11, 2021 at 3:28 PM Jiri Pavlik
<jiri.pavlik@techlib.cz <mailto:jiri.pavlik@techlib.cz>
  > <mailto:jiri.pavlik@techlib.cz <mailto:jiri.pavlik@techlib.cz

...

...

wrote:
  >
  >     Hi Peter,
  >
  >     The intent here is worldwide agreement within FIM4L

actually

...

what is
  >     the best fit for LexisNexis Advance
  >     and all similar SPs out there. IMHO your suggestion is:
  >     - eduPersonScopedAffiliation (required)
  >     - eduPersonTargetedID (required)
  >     - Sirtfy support
  >     And rather SAML pairwise-id than eduPersonTargetedID as
described in
  >     FIM4L recommendations and
  >     REFEDS Pseudonymous Authorisation entity category

specification.

...

  >
  >     I am wondering whether there is an opportunity of

employing a

...

  >     Consent-informed Attribute Release system (CAR) [1]
  >     for releasing name and e-mail address with user consent. I
can see
  >     that French colleagues at least may be interested
  >     in that.
  >
  >     Best
  >
  >                    Jiri
  >
  >
  >     1.
  >

https://spaces.at.internet2.edu/display/CAR/CAR%3A+Consent-informed+Attribut...

...

  >
  >
  >
  >     On Thu, Mar 11, 2021 at 12:03 PM Peter Schober
  >     <peter.schober@univie.ac.at
<mailto:peter.schober@univie.ac.at>
<mailto:peter.schober@univie.ac.at
<mailto:peter.schober@univie.ac.at>>>
wrote:
  >
  >         * Jiri Pavlik <jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>
  >         <mailto:jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>>> [2021-03-11 09:05]:
  >          > I am wondering whether everyone could be fine with
following
  >         set of
  >          > attributes along with CoCo and Sirtfy entity

categories

...

support:
  >          > eduPersonScopedAffiliation (required)
  >          > eduPersonTargetedID (optional)
  >          > givenName  (optional)
  >          > sn   (optional)
  >          > mail  (optional)
  >
  >         Ignoring the fact that ultimately existing bilateral

(or

...

consortial)
  >         contracts (here with LN) will always trump what GÉANT
CoCo says,
  >         note
  >         that CoCo v1 (the only released version that currently
exists)
  >         explicitly only covers strictly *required*
(isRequired="true" in
  >         SAML
  >         Metadata) attributes. It cannot be used for optional

data.

...

  >            People should also be aware that there is no clear
indication
  >         that
  >         LexisNexis even intended to adhere to the GÉANT CoCo
specification:
  >         All that I've seen so far is RENATER's claim that the

LN

...

SP is
  >         covered
  >         by CoCo. But CoCo also requires that the Privacy Policy
for a
  >         SAML SP
  >         adhering to CoCo contains a reference to the GÉANT

CoCo and

...

this is
  >         NOT the case with LexisNexis here (not even in the URL
referenced in
  >         the RENATER metadata).
  >            So the CoCo-support of the LexisNexis SP is (1)

highly

...

  >         questionable,
  >         IMO, and (2) very likely meaningless in light of actual
contracts
  >         governing use of / access to the service.
  >
  >         As to the actual question above: If the service

continues to

...

  >         work fine
  >         with only the commonly released minimal set of data
  >         (common-lib-terms
  >         or eduPersonScopedAffiliation for authorisation; SAML
persistent
  >         NameID or eduPersonTargetedID or SAML pairwise-id for
  >         personalisation
  >         functionality) I see no reason to change anything in
order to
  >         encourge
  >         institutions to send *more* personal data to the

publisher.

...

  >         (And even if we did, what makes LN so special here?
Wouldn't
we also
  >         have to have this discussion then for every other of

the

...

hundreds of
  >         SPs we have for "institutionally licensed e-resource
access"?)
  >
  >         Best regards,
  >         -peter
  >         _______________________________________________
  >         FIM4L mailing list
  > FIM4L@lists.daasi.de <mailto:FIM4L@lists.daasi.de>
<mailto:FIM4L@lists.daasi.de <mailto:FIM4L@lists.daasi.de>>
  > http://lists.daasi.de/listinfo/fim4l
  >
  >
  > _______________________________________________
  > 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

-- 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: www.ub.uni-freiburg.de

Hi Bernd,

when checking ProQuest Ebook Central SP metadata in DFN-AAI/eduGAIN [1], I can see: eduPersonScopedAffiliation (required) eduPersonTargetedID (optional)

Is it correct that universities, libraries in Germany are free to choose whether release eduPersonScopedAffiliation or eduPersonScopedAffiliation eduPersonTargetedID to ProQuest Ebook Central?

Have a nice weekend

Jiri

1. https://met.refeds.org/met/entity/https%253A%252F%252Fsp.ebrary.com%252Fshib...

On Fri, Mar 12, 2021 at 6:50 PM Bernd Oberknapp bo@ub.uni-freiburg.de wrote:

Hi Jiri,

I'm not sure if eduPersonEntitlement is still required for the DFN-AAI (in the past common-lib-terms was the default authorization rule for IdPs in the DFN-AAI), but eduPersonTargetedID (optional) is clearly missing.

Best regards, Bernd

On 12.03.21 08:58, Jiri Pavlik wrote:

...

Hello,

we can check Elsevier Science Direct for inspiration as well. Here eduPersonEntitlement is used for authorisation and eduPersonTargetedID is used for recognising returning users and for personalisation. So the right fit of requested attributes here could be:

• eduPersonEntitlement (required)
• eduPersonTargetedID (optional)

If eduPersonTargetedID attribute is released according to user consent then the user is in charge whether he/she could use personalisation or prefers anonymous access.

This set of requested attributes in Elsevier SD metadata [1] is registered in Australian Access Federation and in IDEM.

There is a vast variety of other requested attributes sets ranging from

• eduPersonEntitlement (required)
• eduPersonTargetedID (required)

(eduID.at, RENATER, SWITCHaai, Edugate, LIAF) via

• eduPersonEntitlement (required)

(DFN-AAI) and

• eduPersonEntitlement (optional)
• eduPersonTargetedID (optional)

(InCommon) to no required attributes at all. (eduGAIN/UK Federation, Belnet, CAFe, CARSI, CORFe, GakuNin)

There are also federations where eduPersonScopedAffiliation is among required attributes and federations where there is eduPersonTargetedID attribute required only.

Take care, stay healthy

       Jiri

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

...

On Thu, Mar 11, 2021 at 8:22 PM Jiri Pavlik <jiri.pavlik@techlib.cz mailto:jiri.pavlik@techlib.cz> wrote:

Hi Bernd,

I see, thanks.

IMHO if eduPersonTargetedID is released, an institutional account is
used as a personal
user account at EBSCOhost as well. If eduPersonTargetedID is not
released users need to sign
in with a Google or local account and institutional sign in could be
used for authorisation [1].

That said the right fit for EBSCOhost could be:
- eduPersonScopedAffiliation (required)
- eduPersonEntitlement (required)
- eduPersonTargetedID (optional)

When an organisation chooses to release eduPersonTargetedID
attribute then users of the organization
can use an institutional account as a personal account at EBSCOhost
as well.

If eduPersonTargetedID attribute is released according to user
consent then the user
is in charge whether his/her institutional account is used as
personal account at EBSCOhost or it is not.

Best
                 Jiri


1.

https://connect.ebsco.com/s/article/How-do-I-authorize-reauthorize-my-person...

...

On Thu, Mar 11, 2021 at 7:31 PM Bernd Oberknapp
<bo@ub.uni-freiburg.de <mailto:bo@ub.uni-freiburg.de>> wrote:

    Hi Jiri,

    for EBSCOhost yes, it doesn't seem to make a difference

whether I'm

...

    logged in with a personal account or not, the number of ebooks
    available
    for download and also the limitations seem to be the same.

    I couldn't try if this works with the EBSCO Mobile app because
    the sign
    in either fails or fails to connect to the app (for all methods,
    not
    just for Shibboleth).

    Best regards,
    Bernd


    On 11.03.21 18:46, Jiri Pavlik wrote:
      > Hi Bernd,
      >
      > Is downloading of e-books at EBSCO eBooks for off-line
    reading working
      > as well
      > when eduPersonTargetedID is not provided?
      >
      > BR
      >                    Jiri
      >
      >
      > On Thu, Mar 11, 2021 at 6:37 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:
      >
      >     Hello,
      >
      >     eduPersonTargetedID is not necessary for EBSCOhost, the
    login works
      >     fine
      >     with just eduPersonScopedAffiliation or
    eduPersonEntitlement.
      >
      >     We should not recommend to make eduPersonTargetedID a
    requirement or
      >     declare it as required if it isn't necessary.
      >
      >     Best regards,
      >     Bernd
      >
      >
      >     On 11.03.21 18:32, Jiri Pavlik wrote:
      >       > Hi,
      >       >
      >       > Let me point out to  EBSCOhost as a similar service.
    Similar
    set of
      >       > requested attributes:
      >       > - eduPersonScopedAffiliation (required)
      >       > - eduPersonTargetedID (required)
      >       > - eduPersonEntitlement (required)
      >       > should be the right fit here because EBSCOhost is
      >       > using eduPersonScopedAffiliation and
      >       > eduPersonEntitlement values for authorisation,
      >     eduPersonTargetedID for
      >       > recognising returning user and providing
    personalisation.
      >       >
      >       > Looking at EBSCOhost SP metadata I can see that in
    Finland
    [1] or in
      >       > Australia [2] there is an interest in releasing
    givenName,
    sn, mail
      >       > attributes.
      >       >
      >       > Listing eduPersonScopedAffiliation,

eduPersonTargetedID,

...

      >       > eduPersonEntitlement as optional in UK Federation /
    eduGAIN
    [3] or
      >       > listing no requested attributes at all in US

InCommon

...

      >     Federations seems
      >       > like a mistake to me.
      >       >
      >       > All the best
      >       >
      >       >             Jiri
      >       >
      >       >
      >       >
      >       > 1.
      >       >
      >

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

...

      >       >
      >       > 2.
      >       >
      >

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

...

      >       >
      >       > 3.
      >       >
      >

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

...

      >       >
      >       > 4.
      >       >
      >

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

...

      >       >
      >       >
      >       > On Thu, Mar 11, 2021 at 3:28 PM Jiri Pavlik
      >     <jiri.pavlik@techlib.cz <mailto:jiri.pavlik@techlib.cz>
    <mailto:jiri.pavlik@techlib.cz <mailto:jiri.pavlik@techlib.cz>>
      >       > <mailto:jiri.pavlik@techlib.cz
    <mailto:jiri.pavlik@techlib.cz> <mailto:jiri.pavlik@techlib.cz
    <mailto:jiri.pavlik@techlib.cz>>>>
      >     wrote:
      >       >
      >       >     Hi Peter,
      >       >
      >       >     The intent here is worldwide agreement within
    FIM4L actually
      >     what is
      >       >     the best fit for LexisNexis Advance
      >       >     and all similar SPs out there. IMHO your
    suggestion is:
      >       >     - eduPersonScopedAffiliation (required)
      >       >     - eduPersonTargetedID (required)
      >       >     - Sirtfy support
      >       >     And rather SAML pairwise-id than
    eduPersonTargetedID as
      >     described in
      >       >     FIM4L recommendations and
      >       >     REFEDS Pseudonymous Authorisation entity

category

...

    specification.
      >       >
      >       >     I am wondering whether there is an opportunity
    of employing a
      >       >     Consent-informed Attribute Release system

(CAR) [1]

...

      >       >     for releasing name and e-mail address with user
    consent. I
      >     can see
      >       >     that French colleagues at least may be

interested

...

      >       >     in that.
      >       >
      >       >     Best
      >       >
      >       >                    Jiri
      >       >
      >       >
      >       >     1.
      >       >
      >

https://spaces.at.internet2.edu/display/CAR/CAR%3A+Consent-informed+Attribut...

...

      >       >
      >       >
      >       >
      >       >     On Thu, Mar 11, 2021 at 12:03 PM Peter Schober
      >       >     <peter.schober@univie.ac.at
    <mailto:peter.schober@univie.ac.at>
      >     <mailto:peter.schober@univie.ac.at
    <mailto:peter.schober@univie.ac.at>>
      >     <mailto:peter.schober@univie.ac.at
    <mailto:peter.schober@univie.ac.at>
      >     <mailto:peter.schober@univie.ac.at
    <mailto:peter.schober@univie.ac.at>>>>
      >     wrote:
      >       >
      >       >         * Jiri Pavlik <jiri.pavlik@techlib.cz
    <mailto:jiri.pavlik@techlib.cz>
      >     <mailto:jiri.pavlik@techlib.cz
    <mailto:jiri.pavlik@techlib.cz>>
      >       >         <mailto:jiri.pavlik@techlib.cz
    <mailto:jiri.pavlik@techlib.cz>
      >     <mailto:jiri.pavlik@techlib.cz
    <mailto:jiri.pavlik@techlib.cz>>>> [2021-03-11 09:05]:
      >       >          > I am wondering whether everyone could be
    fine with
      >     following
      >       >         set of
      >       >          > attributes along with CoCo and Sirtfy

entity

...

    categories
      >     support:
      >       >          > eduPersonScopedAffiliation (required)
      >       >          > eduPersonTargetedID (optional)
      >       >          > givenName  (optional)
      >       >          > sn   (optional)
      >       >          > mail  (optional)
      >       >
      >       >         Ignoring the fact that ultimately existing
    bilateral (or
      >     consortial)
      >       >         contracts (here with LN) will always trump
    what GÉANT
      >     CoCo says,
      >       >         note
      >       >         that CoCo v1 (the only released version that
    currently
      >     exists)
      >       >         explicitly only covers strictly *required*
      >     (isRequired="true" in
      >       >         SAML
      >       >         Metadata) attributes. It cannot be used for
    optional
    data.
      >       >            People should also be aware that there is
    no clear
      >     indication
      >       >         that
      >       >         LexisNexis even intended to adhere to the
    GÉANT CoCo
      >     specification:
      >       >         All that I've seen so far is RENATER's claim
    that the LN
      >     SP is
      >       >         covered
      >       >         by CoCo. But CoCo also requires that the
    Privacy Policy
      >     for a
      >       >         SAML SP
      >       >         adhering to CoCo contains a reference to the
    GÉANT
    CoCo and
      >     this is
      >       >         NOT the case with LexisNexis here (not even
    in the URL
      >     referenced in
      >       >         the RENATER metadata).
      >       >            So the CoCo-support of the LexisNexis SP
    is (1) highly
      >       >         questionable,
      >       >         IMO, and (2) very likely meaningless in
    light of actual
      >     contracts
      >       >         governing use of / access to the service.
      >       >
      >       >         As to the actual question above: If the

service

...

    continues to
      >       >         work fine
      >       >         with only the commonly released minimal set
    of data
      >       >         (common-lib-terms
      >       >         or eduPersonScopedAffiliation for
    authorisation; SAML
      >     persistent
      >       >         NameID or eduPersonTargetedID or SAML
    pairwise-id for
      >       >         personalisation
      >       >         functionality) I see no reason to change
    anything in
      >     order to
      >       >         encourge
      >       >         institutions to send *more* personal data to
    the
    publisher.
      >       >         (And even if we did, what makes LN so
    special here?
      >     Wouldn't
      >     we also
      >       >         have to have this discussion then for every
    other of the
      >     hundreds of
      >       >         SPs we have for "institutionally licensed
    e-resource
      >     access"?)
      >       >
      >       >         Best regards,
      >       >         -peter
      >       >

---

...

      >       >         FIM4L mailing list
      >       > FIM4L@lists.daasi.de <mailto:FIM4L@lists.daasi.de>
    <mailto:FIM4L@lists.daasi.de <mailto:FIM4L@lists.daasi.de>>
      >     <mailto:FIM4L@lists.daasi.de
    <mailto:FIM4L@lists.daasi.de> <mailto:FIM4L@lists.daasi.de
    <mailto:FIM4L@lists.daasi.de>>>
      >       > http://lists.daasi.de/listinfo/fim4l
      >       >
      >       >
      >       > _______________________________________________
      >       > FIM4L mailing list
      >       > FIM4L@lists.daasi.de <mailto:FIM4L@lists.daasi.de>
    <mailto: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> <mailto:bo@ub.uni-freiburg.de
    <mailto:bo@ub.uni-freiburg.de>>
      >     Internet: www.ub.uni-freiburg.de
    <http://www.ub.uni-freiburg.de> <http://www.ub.uni-freiburg.de>
      >
      >     _______________________________________________
      >     FIM4L mailing list
      > FIM4L@lists.daasi.de <mailto:FIM4L@lists.daasi.de>
    <mailto: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 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 Internet: www.ub.uni-freiburg.de

---

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

Hi Bernd,

I see, thanks a lot for the clarification.

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

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?

Cheers Jiri

1. https://met.refeds.org/met/entity/https%253A%252F%252Fshibboleth-sp.prod.pro...

On Fri, Mar 12, 2021 at 11:10 PM Bernd Oberknapp bo@ub.uni-freiburg.de wrote:

Hi Jiri,

I don't think so, but the configuration of ProQuest Ebook Central is quite complex, and I cannot exclude that some configurations don't require an ID (for example if downloading/lending ebooks is disabled).

I ran some tests when I created our setup in 2017 because the support wasn't able to answer my questions about the supported attribute combinations. The documentation

https://support.proquest.com/articledetail?id=kA23r000000FVtKCAW&key=&am... seems to be wrong, just sending eduPersonTargetedID didn't work. Maybe it would work with the deprecated scoped format, I haven't tried that. The documentation suggests that eduPersonPrincipalName or a persistent ID could be used instead of eduPersonTargetedID, but I haven't tried that either. Both eduPersonScopedAffiliation or eduPersonEntitlement (common-lib-terms) worked fine for authorization.

Best regards, Bernd

On 12.03.21 19:34, Jiri Pavlik wrote:

...

Hi Bernd,

when checking ProQuest Ebook Central SP metadata in DFN-AAI/eduGAIN [1], I can see: eduPersonScopedAffiliation (required) eduPersonTargetedID (optional)

Is it correct that universities, libraries in Germany are free to choose whether release eduPersonScopedAffiliation or eduPersonScopedAffiliation eduPersonTargetedID to ProQuest Ebook Central?

Have a nice weekend

       Jiri

https://met.refeds.org/met/entity/https%253A%252F%252Fsp.ebrary.com%252Fshib...

...

On Fri, Mar 12, 2021 at 6:50 PM Bernd Oberknapp <bo@ub.uni-freiburg.de mailto:bo@ub.uni-freiburg.de> wrote:

Hi Jiri,

I'm not sure if eduPersonEntitlement is still required for the

DFN-AAI

...

(in the past common-lib-terms was the default authorization rule for
IdPs in the DFN-AAI), but eduPersonTargetedID (optional) is clearly
missing.

Best regards,
Bernd


On 12.03.21 08:58, Jiri Pavlik wrote:
  > Hello,
  >
  > we can check Elsevier Science Direct for inspiration as well.

Here

...

  > eduPersonEntitlement is used for authorisation and
eduPersonTargetedID
  > is used for recognising returning users and for personalisation.
So the
  > right fit
  > of requested attributes here could be:
  > - eduPersonEntitlement (required)
  > - eduPersonTargetedID (optional)
  >
  > If eduPersonTargetedID attribute is released according to user
consent
  > then the user
  > is in charge whether he/she could use personalisation or prefers
  > anonymous access.
  >
  > This set of requested attributes in Elsevier SD metadata [1] is
  > registered in  Australian Access Federation and in IDEM.
  >
  > There is a vast variety of other requested attributes sets
ranging from
  > - eduPersonEntitlement (required)
  > - eduPersonTargetedID (required)
  > (eduID.at, RENATER, SWITCHaai, Edugate, LIAF)
  > via
  > - eduPersonEntitlement (required)
  > (DFN-AAI)
  > and
  > - eduPersonEntitlement (optional)
  > - eduPersonTargetedID (optional)
  > (InCommon)
  > to
  > no required attributes at all.
  > (eduGAIN/UK Federation, Belnet, CAFe, CARSI, CORFe, GakuNin)
  >
  > There are also federations where eduPersonScopedAffiliation

is among

...

  > required attributes and
  > federations where there is eduPersonTargetedID attribute
required only.
  >
  >
  > Take care, stay healthy
  >
  >            Jiri
  >
  >
  >
  > 1.
  >

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

...

  >
  >
  >
  > On Thu, Mar 11, 2021 at 8:22 PM Jiri Pavlik
<jiri.pavlik@techlib.cz <mailto:jiri.pavlik@techlib.cz>
  > <mailto:jiri.pavlik@techlib.cz <mailto:jiri.pavlik@techlib.cz

...

...

wrote:
  >
  >     Hi Bernd,
  >
  >     I see, thanks.
  >
  >     IMHO if eduPersonTargetedID is released, an institutional
account is
  >     used as a personal
  >     user account at EBSCOhost as well. If eduPersonTargetedID

is not

...

  >     released users need to sign
  >     in with a Google or local account and institutional sign in
could be
  >     used for authorisation [1].
  >
  >     That said the right fit for EBSCOhost could be:
  >     - eduPersonScopedAffiliation (required)
  >     - eduPersonEntitlement (required)
  >     - eduPersonTargetedID (optional)
  >
  >     When an organisation chooses to release eduPersonTargetedID
  >     attribute then users of the organization
  >     can use an institutional account as a personal account at
EBSCOhost
  >     as well.
  >
  >     If eduPersonTargetedID attribute is released according to

user

...

  >     consent then the user
  >     is in charge whether his/her institutional account is used

as

...

  >     personal account at EBSCOhost or it is not.
  >
  >     Best
  >                      Jiri
  >
  >
  >     1.
  >

https://connect.ebsco.com/s/article/How-do-I-authorize-reauthorize-my-person...

...

  >
  >     On Thu, Mar 11, 2021 at 7:31 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,
  >
  >         for EBSCOhost yes, it doesn't seem to make a difference
whether I'm
  >         logged in with a personal account or not, the number of
ebooks
  >         available
  >         for download and also the limitations seem to be the

same.

...

  >
  >         I couldn't try if this works with the EBSCO Mobile app
because
  >         the sign
  >         in either fails or fails to connect to the app (for all
methods,
  >         not
  >         just for Shibboleth).
  >
  >         Best regards,
  >         Bernd
  >
  >
  >         On 11.03.21 18:46, Jiri Pavlik wrote:
  >           > Hi Bernd,
  >           >
  >           > Is downloading of e-books at EBSCO eBooks for

off-line

...

  >         reading working
  >           > as well
  >           > when eduPersonTargetedID is not provided?
  >           >
  >           > BR
  >           >                    Jiri
  >           >
  >           >
  >           > On Thu, Mar 11, 2021 at 6:37 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>>
  >           > <mailto:bo@ub.uni-freiburg.de
<mailto:bo@ub.uni-freiburg.de>
  >         <mailto:bo@ub.uni-freiburg.de
<mailto:bo@ub.uni-freiburg.de>>>> wrote:
  >           >
  >           >     Hello,
  >           >
  >           >     eduPersonTargetedID is not necessary for
EBSCOhost, the
  >         login works
  >           >     fine
  >           >     with just eduPersonScopedAffiliation or
  >         eduPersonEntitlement.
  >           >
  >           >     We should not recommend to make
eduPersonTargetedID a
  >         requirement or
  >           >     declare it as required if it isn't necessary.
  >           >
  >           >     Best regards,
  >           >     Bernd
  >           >
  >           >
  >           >     On 11.03.21 18:32, Jiri Pavlik wrote:
  >           >       > Hi,
  >           >       >
  >           >       > Let me point out to  EBSCOhost as a similar
service.
  >         Similar
  >         set of
  >           >       > requested attributes:
  >           >       > - eduPersonScopedAffiliation (required)
  >           >       > - eduPersonTargetedID (required)
  >           >       > - eduPersonEntitlement (required)
  >           >       > should be the right fit here because
EBSCOhost is
  >           >       > using eduPersonScopedAffiliation and
  >           >       > eduPersonEntitlement values for

authorisation,

...

  >           >     eduPersonTargetedID for
  >           >       > recognising returning user and providing
  >         personalisation.
  >           >       >
  >           >       > Looking at EBSCOhost SP metadata I can see
that in
  >         Finland
  >         [1] or in
  >           >       > Australia [2] there is an interest in

releasing

...

  >         givenName,
  >         sn, mail
  >           >       > attributes.
  >           >       >
  >           >       > Listing eduPersonScopedAffiliation,
eduPersonTargetedID,
  >           >       > eduPersonEntitlement as optional in UK
Federation /
  >         eduGAIN
  >         [3] or
  >           >       > listing no requested attributes at all in US
InCommon
  >           >     Federations seems
  >           >       > like a mistake to me.
  >           >       >
  >           >       > All the best
  >           >       >
  >           >       >             Jiri
  >           >       >
  >           >       >
  >           >       >
  >           >       > 1.
  >           >       >
  >           >
  >

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

...

  >           >       >
  >           >       > 2.
  >           >       >
  >           >
  >

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

...

  >           >       >
  >           >       > 3.
  >           >       >
  >           >
  >

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

...

  >           >       >
  >           >       > 4.
  >           >       >
  >           >
  >

https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.co...

...

  >           >       >
  >           >       >
  >           >       > On Thu, Mar 11, 2021 at 3:28 PM Jiri Pavlik
  >           >     <jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz> <mailto:jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>>
  >         <mailto:jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz> <mailto:jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>>>
  >           >       > <mailto:jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>
  >         <mailto:jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>> <mailto:jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>
  >         <mailto:jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>>>>>
  >           >     wrote:
  >           >       >
  >           >       >     Hi Peter,
  >           >       >
  >           >       >     The intent here is worldwide agreement
within
  >         FIM4L actually
  >           >     what is
  >           >       >     the best fit for LexisNexis Advance
  >           >       >     and all similar SPs out there. IMHO your
  >         suggestion is:
  >           >       >     - eduPersonScopedAffiliation (required)
  >           >       >     - eduPersonTargetedID (required)
  >           >       >     - Sirtfy support
  >           >       >     And rather SAML pairwise-id than
  >         eduPersonTargetedID as
  >           >     described in
  >           >       >     FIM4L recommendations and
  >           >       >     REFEDS Pseudonymous Authorisation entity
category
  >         specification.
  >           >       >
  >           >       >     I am wondering whether there is an
opportunity
  >         of employing a
  >           >       >     Consent-informed Attribute Release

system

...

(CAR) [1]
  >           >       >     for releasing name and e-mail address
with user
  >         consent. I
  >           >     can see
  >           >       >     that French colleagues at least may be
interested
  >           >       >     in that.
  >           >       >
  >           >       >     Best
  >           >       >
  >           >       >                    Jiri
  >           >       >
  >           >       >
  >           >       >     1.
  >           >       >
  >           >
  >

https://spaces.at.internet2.edu/display/CAR/CAR%3A+Consent-informed+Attribut...

...

  >           >       >
  >           >       >
  >           >       >
  >           >       >     On Thu, Mar 11, 2021 at 12:03 PM Peter
Schober
  >           >       >     <peter.schober@univie.ac.at
<mailto:peter.schober@univie.ac.at>
  >         <mailto:peter.schober@univie.ac.at
<mailto:peter.schober@univie.ac.at>>
  >           >     <mailto:peter.schober@univie.ac.at
<mailto:peter.schober@univie.ac.at>
  >         <mailto:peter.schober@univie.ac.at
<mailto:peter.schober@univie.ac.at>>>
  >           >     <mailto:peter.schober@univie.ac.at
<mailto:peter.schober@univie.ac.at>
  >         <mailto:peter.schober@univie.ac.at
<mailto:peter.schober@univie.ac.at>>
  >           >     <mailto:peter.schober@univie.ac.at
<mailto:peter.schober@univie.ac.at>
  >         <mailto:peter.schober@univie.ac.at
<mailto:peter.schober@univie.ac.at>>>>>
  >           >     wrote:
  >           >       >
  >           >       >         * Jiri Pavlik
<jiri.pavlik@techlib.cz <mailto:jiri.pavlik@techlib.cz>
  >         <mailto:jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>>
  >           >     <mailto:jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>
  >         <mailto:jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>>>
  >           >       >         <mailto:jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>
  >         <mailto:jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>>
  >           >     <mailto:jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>
  >         <mailto:jiri.pavlik@techlib.cz
<mailto:jiri.pavlik@techlib.cz>>>>> [2021-03-11 09:05]:
  >           >       >          > I am wondering whether everyone
could be
  >         fine with
  >           >     following
  >           >       >         set of
  >           >       >          > attributes along with CoCo and
Sirtfy
entity
  >         categories
  >           >     support:
  >           >       >          > eduPersonScopedAffiliation

(required)

...

  >           >       >          > eduPersonTargetedID (optional)
  >           >       >          > givenName  (optional)
  >           >       >          > sn   (optional)
  >           >       >          > mail  (optional)
  >           >       >
  >           >       >         Ignoring the fact that ultimately
existing
  >         bilateral (or
  >           >     consortial)
  >           >       >         contracts (here with LN) will always
trump
  >         what GÉANT
  >           >     CoCo says,
  >           >       >         note
  >           >       >         that CoCo v1 (the only released
version that
  >         currently
  >           >     exists)
  >           >       >         explicitly only covers strictly
*required*
  >           >     (isRequired="true" in
  >           >       >         SAML
  >           >       >         Metadata) attributes. It cannot be
used for
  >         optional
  >         data.
  >           >       >            People should also be aware that
there is
  >         no clear
  >           >     indication
  >           >       >         that
  >           >       >         LexisNexis even intended to adhere
to the
  >         GÉANT CoCo
  >           >     specification:
  >           >       >         All that I've seen so far is
RENATER's claim
  >         that the LN
  >           >     SP is
  >           >       >         covered
  >           >       >         by CoCo. But CoCo also requires

that the

...

  >         Privacy Policy
  >           >     for a
  >           >       >         SAML SP
  >           >       >         adhering to CoCo contains a
reference to the
  >         GÉANT
  >         CoCo and
  >           >     this is
  >           >       >         NOT the case with LexisNexis here
(not even
  >         in the URL
  >           >     referenced in
  >           >       >         the RENATER metadata).
  >           >       >            So the CoCo-support of the
LexisNexis SP
  >         is (1) highly
  >           >       >         questionable,
  >           >       >         IMO, and (2) very likely

meaningless in

...

  >         light of actual
  >           >     contracts
  >           >       >         governing use of / access to the
service.
  >           >       >
  >           >       >         As to the actual question above:

If the

...

service
  >         continues to
  >           >       >         work fine
  >           >       >         with only the commonly released
minimal set
  >         of data
  >           >       >         (common-lib-terms
  >           >       >         or eduPersonScopedAffiliation for
  >         authorisation; SAML
  >           >     persistent
  >           >       >         NameID or eduPersonTargetedID or

SAML

...

  >         pairwise-id for
  >           >       >         personalisation
  >           >       >         functionality) I see no reason to

change

...

  >         anything in
  >           >     order to
  >           >       >         encourge
  >           >       >         institutions to send *more* personal
data to
  >         the
  >         publisher.
  >           >       >         (And even if we did, what makes LN

so

...

  >         special here?
  >           >     Wouldn't
  >           >     we also
  >           >       >         have to have this discussion then
for every
  >         other of the
  >           >     hundreds of
  >           >       >         SPs we have for "institutionally
licensed
  >         e-resource
  >           >     access"?)
  >           >       >
  >           >       >         Best regards,
  >           >       >         -peter
  >           >       >
_______________________________________________
  >           >       >         FIM4L mailing list
  >           >       > FIM4L@lists.daasi.de
<mailto:FIM4L@lists.daasi.de> <mailto:FIM4L@lists.daasi.de
<mailto:FIM4L@lists.daasi.de>>
  >         <mailto:FIM4L@lists.daasi.de
<mailto:FIM4L@lists.daasi.de> <mailto:FIM4L@lists.daasi.de
<mailto:FIM4L@lists.daasi.de>>>
  >           >     <mailto:FIM4L@lists.daasi.de
<mailto:FIM4L@lists.daasi.de>
  >         <mailto:FIM4L@lists.daasi.de
<mailto:FIM4L@lists.daasi.de>> <mailto:FIM4L@lists.daasi.de
<mailto:FIM4L@lists.daasi.de>
  >         <mailto:FIM4L@lists.daasi.de
<mailto:FIM4L@lists.daasi.de>>>>
  >           >       > http://lists.daasi.de/listinfo/fim4l
  >           >       >
  >           >       >
  >           >       >

---

...

  >           >       > FIM4L mailing list
  >           >       > FIM4L@lists.daasi.de
<mailto:FIM4L@lists.daasi.de> <mailto:FIM4L@lists.daasi.de
<mailto:FIM4L@lists.daasi.de>>
  >         <mailto:FIM4L@lists.daasi.de
<mailto:FIM4L@lists.daasi.de> <mailto: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>
  >         <mailto:bo@ub.uni-freiburg.de
<mailto:bo@ub.uni-freiburg.de>> <mailto: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>
  >         <http://www.ub.uni-freiburg.de>
<http://www.ub.uni-freiburg.de>
  >           >
  >           >     _______________________________________________
  >           >     FIM4L mailing list
  >           > FIM4L@lists.daasi.de <mailto:FIM4L@lists.daasi.de>
<mailto:FIM4L@lists.daasi.de <mailto:FIM4L@lists.daasi.de>>
  >         <mailto:FIM4L@lists.daasi.de
<mailto:FIM4L@lists.daasi.de> <mailto: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> <mailto:bo@ub.uni-freiburg.de
<mailto:bo@ub.uni-freiburg.de>>
  >         Internet: www.ub.uni-freiburg.de
<http://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
  >


--
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

-- 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: www.ub.uni-freiburg.de