[Fim4l] LexisNexis Advance

Jiri Pavlik jiri.pavlik at techlib.cz
Thu Mar 11 18:46:56 CET 2021


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>
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>> 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>>
> wrote:
>  >
>  >         * Jiri Pavlik <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>
>  >         http://lists.daasi.de/listinfo/fim4l
>  >
>  >
>  > _______________________________________________
>  > FIM4L mailing list
>  > 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
>
> _______________________________________________
> FIM4L mailing list
> FIM4L at lists.daasi.de
> http://lists.daasi.de/listinfo/fim4l
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.daasi.de/pipermail/fim4l/attachments/20210311/fa25d4b2/attachment-0001.html>


More information about the FIM4L mailing list