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. 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@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+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@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 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>>
> > 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