
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