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
>
>
>
> 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@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-personal-user-account?language=en_US
>
> 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.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>>
> > > <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+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>>
> > <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