On Thu, Mar 11, 2021 at 6:37 PM Bernd Oberknapp <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>> 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>>
wrote:
>
> * Jiri Pavlik <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>
> http://lists.daasi.de/listinfo/fim4l
>
>
> _______________________________________________
> 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