Re: [Fim4l] LexisNexis Advance

12 Mär 2021

      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