[Fim4l] LexisNexis Advance
Jiri Pavlik
jiri.pavlik at techlib.cz
Fri Mar 12 08:58:33 CET 2021
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> 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>
> 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>> 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
>> >>>
>> > 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>>>
>> > 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>>> [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>>
>> > > http://lists.daasi.de/listinfo/fim4l
>> > >
>> > >
>> > > _______________________________________________
>> > > 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/20210312/76376dc6/attachment-0001.html>
More information about the FIM4L
mailing list