
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.pro...
On Fri, Mar 12, 2021 at 11:10 PM Bernd Oberknapp bo@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=&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