Re: [Fim4l] LexisNexis Advance

12 Mär 2021

      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