[Fim4l] LexisNexis Advance
Jiri Pavlik
jiri.pavlik at techlib.cz
Sat Mar 13 09:15:07 CET 2021
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.proquest.com%252Fshibboleth/?federation=dfn-aai
On Fri, Mar 12, 2021 at 11:10 PM Bernd Oberknapp <bo at 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=&pcat=&icat=
> 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
> >
> > 1.
> >
>
> https://met.refeds.org/met/entity/https%253A%252F%252Fsp.ebrary.com%252Fshibboleth/?federation=edugain
> >
> > On Fri, Mar 12, 2021 at 6:50 PM Bernd Oberknapp <bo at ub.uni-freiburg.de
> > <mailto:bo at 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.com%252F/
> > >
> > >
> > >
> > > On Thu, Mar 11, 2021 at 8:22 PM Jiri Pavlik
> > <jiri.pavlik at techlib.cz <mailto:jiri.pavlik at techlib.cz>
> > > <mailto:jiri.pavlik at techlib.cz <mailto:jiri.pavlik at 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-personal-user-account?language=en_US
> > >
> > > On Thu, Mar 11, 2021 at 7:31 PM Bernd Oberknapp
> > > <bo at ub.uni-freiburg.de <mailto:bo at ub.uni-freiburg.de>
> > <mailto:bo at ub.uni-freiburg.de <mailto:bo at 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 at ub.uni-freiburg.de <mailto:bo at ub.uni-freiburg.de>
> > <mailto:bo at ub.uni-freiburg.de <mailto:bo at ub.uni-freiburg.de>>
> > > > <mailto:bo at ub.uni-freiburg.de
> > <mailto:bo at ub.uni-freiburg.de>
> > > <mailto:bo at ub.uni-freiburg.de
> > <mailto:bo at 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.com/?federation=haka
> > > > >
> > > > > 2.
> > > > >
> > > >
> > >
> >
>
> https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.com/?federation=australian-access-federation
> > > > >
> > > > > 3.
> > > > >
> > > >
> > >
> >
>
> https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.com/?federation=edugain
> > > > >
> > > > > 4.
> > > > >
> > > >
> > >
> >
>
> https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.com/?federation=incommon-federation
> > > > >
> > > > >
> > > > > On Thu, Mar 11, 2021 at 3:28 PM Jiri Pavlik
> > > > <jiri.pavlik at techlib.cz
> > <mailto:jiri.pavlik at techlib.cz> <mailto:jiri.pavlik at techlib.cz
> > <mailto:jiri.pavlik at techlib.cz>>
> > > <mailto:jiri.pavlik at techlib.cz
> > <mailto:jiri.pavlik at techlib.cz> <mailto:jiri.pavlik at techlib.cz
> > <mailto:jiri.pavlik at techlib.cz>>>
> > > > > <mailto:jiri.pavlik at techlib.cz
> > <mailto:jiri.pavlik at techlib.cz>
> > > <mailto:jiri.pavlik at techlib.cz
> > <mailto:jiri.pavlik at techlib.cz>> <mailto:jiri.pavlik at techlib.cz
> > <mailto:jiri.pavlik at techlib.cz>
> > > <mailto:jiri.pavlik at techlib.cz
> > <mailto:jiri.pavlik at 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+Attribute+Release+system#:~:text=initially%20designed%20to%20be%20a,Consent%2Dinformed%20Attribute%20Release.%22
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Mar 11, 2021 at 12:03 PM Peter
> > Schober
> > > > > <peter.schober at univie.ac.at
> > <mailto:peter.schober at univie.ac.at>
> > > <mailto:peter.schober at univie.ac.at
> > <mailto:peter.schober at univie.ac.at>>
> > > > <mailto:peter.schober at univie.ac.at
> > <mailto:peter.schober at univie.ac.at>
> > > <mailto:peter.schober at univie.ac.at
> > <mailto:peter.schober at univie.ac.at>>>
> > > > <mailto:peter.schober at univie.ac.at
> > <mailto:peter.schober at univie.ac.at>
> > > <mailto:peter.schober at univie.ac.at
> > <mailto:peter.schober at univie.ac.at>>
> > > > <mailto:peter.schober at univie.ac.at
> > <mailto:peter.schober at univie.ac.at>
> > > <mailto:peter.schober at univie.ac.at
> > <mailto:peter.schober at univie.ac.at>>>>>
> > > > wrote:
> > > > >
> > > > > * Jiri Pavlik
> > <jiri.pavlik at techlib.cz <mailto:jiri.pavlik at techlib.cz>
> > > <mailto:jiri.pavlik at techlib.cz
> > <mailto:jiri.pavlik at techlib.cz>>
> > > > <mailto:jiri.pavlik at techlib.cz
> > <mailto:jiri.pavlik at techlib.cz>
> > > <mailto:jiri.pavlik at techlib.cz
> > <mailto:jiri.pavlik at techlib.cz>>>
> > > > > <mailto:jiri.pavlik at techlib.cz
> > <mailto:jiri.pavlik at techlib.cz>
> > > <mailto:jiri.pavlik at techlib.cz
> > <mailto:jiri.pavlik at techlib.cz>>
> > > > <mailto:jiri.pavlik at techlib.cz
> > <mailto:jiri.pavlik at techlib.cz>
> > > <mailto:jiri.pavlik at techlib.cz
> > <mailto:jiri.pavlik at 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 at lists.daasi.de
> > <mailto:FIM4L at lists.daasi.de> <mailto:FIM4L at lists.daasi.de
> > <mailto:FIM4L at lists.daasi.de>>
> > > <mailto:FIM4L at lists.daasi.de
> > <mailto:FIM4L at lists.daasi.de> <mailto:FIM4L at lists.daasi.de
> > <mailto:FIM4L at lists.daasi.de>>>
> > > > <mailto:FIM4L at lists.daasi.de
> > <mailto:FIM4L at lists.daasi.de>
> > > <mailto:FIM4L at lists.daasi.de
> > <mailto:FIM4L at lists.daasi.de>> <mailto:FIM4L at lists.daasi.de
> > <mailto:FIM4L at lists.daasi.de>
> > > <mailto:FIM4L at lists.daasi.de
> > <mailto:FIM4L at lists.daasi.de>>>>
> > > > > http://lists.daasi.de/listinfo/fim4l
> > > > >
> > > > >
> > > > >
> _______________________________________________
> > > > > FIM4L mailing list
> > > > > FIM4L at lists.daasi.de
> > <mailto:FIM4L at lists.daasi.de> <mailto:FIM4L at lists.daasi.de
> > <mailto:FIM4L at lists.daasi.de>>
> > > <mailto:FIM4L at lists.daasi.de
> > <mailto:FIM4L at lists.daasi.de> <mailto:FIM4L at lists.daasi.de
> > <mailto:FIM4L at 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 at ub.uni-freiburg.de
> > <mailto:bo at ub.uni-freiburg.de>
> > > <mailto:bo at ub.uni-freiburg.de
> > <mailto:bo at ub.uni-freiburg.de>> <mailto:bo at ub.uni-freiburg.de
> > <mailto:bo at ub.uni-freiburg.de>
> > > <mailto:bo at ub.uni-freiburg.de
> > <mailto:bo at 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 at lists.daasi.de <mailto:FIM4L at lists.daasi.de>
> > <mailto:FIM4L at lists.daasi.de <mailto:FIM4L at lists.daasi.de>>
> > > <mailto:FIM4L at lists.daasi.de
> > <mailto:FIM4L at lists.daasi.de> <mailto:FIM4L at lists.daasi.de
> > <mailto:FIM4L at 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 at ub.uni-freiburg.de
> > <mailto:bo at ub.uni-freiburg.de> <mailto:bo at ub.uni-freiburg.de
> > <mailto:bo at 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 at lists.daasi.de <mailto:FIM4L at 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 at ub.uni-freiburg.de <mailto:bo at ub.uni-freiburg.de>
> > Internet: www.ub.uni-freiburg.de <http://www.ub.uni-freiburg.de>
> >
> > _______________________________________________
> > FIM4L mailing list
> > FIM4L at lists.daasi.de <mailto:FIM4L at 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 at ub.uni-freiburg.de
> Internet: www.ub.uni-freiburg.de
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.daasi.de/pipermail/fim4l/attachments/20210313/288b5573/attachment-0001.html>
More information about the FIM4L
mailing list