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 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> 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. Similarset 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.czwrote: > > 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 categoryspecification.
> > I am wondering whether there is an opportunity of employinga
> 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>>> wrote: > > * Jiri Pavlik <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 entitycategories
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 optionaldata.
> 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ÉANTCoCo 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 servicecontinues 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 thepublisher.
> (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>> > http://lists.daasi.de/listinfo/fim4l > > > _______________________________________________ > 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