I assume the recommendation would be to use pairwise-id (not subject-id)
for personalization, and eduPersonTargetedID as a fallback for IdPs or
SPs that don't support pairwise-id yet.
If a SP supports eduPersonTargetedID it has to be prepared to transition
to pairwise-id and preserve the personal accounts during that transition.
Best regards,
Bernd
On 15.03.21 16:26, Heather Flanagan wrote:
> I know it does not help matters, but I need to point out that
> eduPersonTargetedID is actually deprecated due to security concerns.
> Instead, organizations are encouraged to use the SAML attribute,
> subject-id
>
(https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1.0-cs01.pdf).
>
> Heather Flanagan — Translator of Geek to Human
> https://sphericalcowconsulting.com
> On Mar 15, 2021, 8:18 AM -0700, Jos Westerbeke <jos.westerbeke@eur.nl>,
> wrote:
>> Hi Jiri, Bernd et al,
>>
>> thank you for this discussion. This is very meaningful for downplaying
>> the FIM4L recommendations 4.A and 4.B to a more simple level.
>>
>> We now have two recommendations which you have to (unfortunately)
choose:
>>
>> 4.A. Transitory Access - eduPersonTargetedID as optional would be fine
>> for this.
>> 4.B. Personalized Access - eduPersonTargetedID required.
>> - And for 4.B the recommendation is to let it be for the SP side to
>> offer a profile, voluntarily to configure by users. So that in any way
>> IdP's do not have to release PII.
>> (https://www.fim4l.org/?page_id=257)
>>
>> What would we actually recommend for librarians? Wouldn't it be nice
>> to have just one option? I think it is too difficult for librarians to
>> choose here.
>>
>> Reading the discussion, we can say that we cannot recommend going just
>> for 4.B. And if librarians consider switching form IP to SAML they are
>> very suspicious about privacy.
>>
>> Can we recommend for both IdP's and SP's to go for 4.A?
>>
>> What about recommending 4.A and have the option for 4.B when there is
>> an agreement between IdP and SP about creating profiles, anchored in a
>> contract?
>>
>> Should we recommend a contract clausula alongside 4.B?
>>
>> As far as I understand, I'm aware of what Meshna says: If you opt for
>> 4.A then it is simply not possible to have a profile, which is very
>> annoying if not impossible for our patrons.
>>
>> Best,
>> Jos
>>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* FIM4L <fim4l-bounces@lists.daasi.de> on behalf of Jiri Pavlik
>> <jiri.pavlik@techlib.cz>
>> *Sent:* 15 March 2021 14:58
>> *To:* Koren, Meshna (ELS-AMS) <M.Koren@elsevier.com>
>> *Cc:* fim4l@lists.daasi.de <fim4l@lists.daasi.de>
>> *Subject:* Re: [Fim4l] LexisNexis Advance
>> Hi Meshna,
>>
>> thanks a lot for the comments.
>>
>> At Elsevier SP metadata [1] I can see:
>> eduPersonEntitlement (required)
>> eduPersonTargetedID (optional)
>> in DFN-AAI, IDEM or Australian Access Federation.
>>
>> At the SP metadata in eduGAIN / UK Federation there are no requested
>> attributes.
>> At the SP metadata in eduID.at, SWITCHaai, InCommon, RENATER I can see:
>> eduPersonEntitlement (required)
>> eduPersonTargetedID (required)
>>
>> It illustrates different approaches around the world how to express
>> optional ePTID release
>> in SP metadata and a challenge for one appropriate SP metadata in
>> eduGAIN serving globally.
>> To me
>> eduPersonEntitlement (required)
>> eduPersonTargetedID (optional)
>> seems as the most appropriate.
>>
>> Cheers
>> Jiri
>>
>>
>> 1.
>>
https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.com%252F/
>>
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmet.refeds.org%2Fmet%2Fentity%2Fhttps%25253A%25252F%25252Fsdauth.sciencedirect.com%25252F%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761630378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HmuCXxy9%2F1bQBVkGnsrbBcRmNJP9DsiETfB4g6uP0L4%3D&reserved=0>
>>
>>
>>
>> On Mon, Mar 15, 2021 at 12:01 PM Koren, Meshna (ELS-AMS)
>> <M.Koren@elsevier.com <mailto:M.Koren@elsevier.com>> wrote:
>>
>> Please allow me to add something to this discussion. ____
>>
>> __ __
>>
>> "The university students and staff are free to use personalisation
>> at Lexis Nexis,
>> Elsevier, EBSCO, ProQuest services if they want to so
>> eduPersonScopedAffiliation (required)
>> eduPersonEntitlement (required)
>> eduPersonTargetedID (optional)..."
>>
>> ____
>>
>> The students and staff can only use personalization when the IdP
>> releases ePTID (or pairwiseID), otherwise they can't. I am not
>> sure that this is clear from the metadata nor that the labels we
>> use to describe the required attributes are very clear on what
>> 'optional' means.____
>>
>> __ __
>>
>> For example, when a student accesses ScienceDirect they can read
>> subscribed articles whether or not ePTID has been released for
>> them, but if they want to 'create account' because they would like
>> to save searches, alerts or their search history, they can only do
>> that if the IdP has released a persistent identifier for them.
>> Otherwise they can't, because there's nothing in their SAML
>> assertions that allows us to recognize the returning individual.
>> So we are working towards requiring a persistent ID. The
>> personalization remains optional for the user.____
>>
>> __ __
>>
>> That may not be the same for other SPs, but it is valid for
>> Elsevier. ____
>>
>> __ __
>>
>> Kind regards,____
>>
>> Meshna____
>>
>> __ __
>>
>> __ __
>>
>> *__ __*
>>
>> *Meshna Koren* *____*
>>
>>
>> /Product Manager II____/
>>
>> */Product Management - Identity and Access/* */-/* */Research
>> Products/**/____/*
>>
>> */__ __/*
>>
>> */Elsevier BV/*/____/
>>
>> /Radarweg 29, Amsterdam 1043 NX, The Netherlands____/
>>
>> /m.koren@elsevier.com <mailto:m.koren@elsevier.com>____/
>>
>> /__ __/
>>
>> /Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens,
>> Institutional Login____/
>>
>> /__ __/
>>
>> /Elsevier Access Support Center:
>>
https://service.elsevier.com/app/answers/list/c/10543/supporthub/elsevieraccess/
>>
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fservice.elsevier.com%2Fapp%2Fanswers%2Flist%2Fc%2F10543%2Fsupporthub%2Felsevieraccess%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761640371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=s2nQIh1Mocby%2Fnr0uG61jf%2Fg%2FWgqr%2FfHj6MhuH5sHHs%3D&reserved=0>____/
>>
>> /for your questions about which access methods does Elsevier
>> support, how to set them up, how do they work for users...____/
>>
>> /__ __/
>>
>> __ __
>>
>> __ __
>>
>> __ __
>>
>> __ __
>>
>> __ __
>>
>> *From:* FIM4L <fim4l-bounces@lists.daasi.de
>> <mailto:fim4l-bounces@lists.daasi.de>> *On Behalf Of* Jiri Pavlik
>> *Sent:* Sunday, March 14, 2021 15:28
>> *To:* Bernd Oberknapp <bo@ub.uni-freiburg.de
>> <mailto:bo@ub.uni-freiburg.de>>
>> *Cc:* fim4l@lists.daasi.de <mailto:fim4l@lists.daasi.de>
>> *Subject:* Re: [Fim4l] LexisNexis Advance____
>>
>> __ __
>>
>> **** External email: use caution ****____
>>
>> ____
>>
>> Hi Bernd,
>>
>> I see,
>> eduPersonScopedAffiliation (required)
>> eduPersonEntitlement (required)
>> is working for Freiburg University and
>> eduPersonScopedAffiliation (required)
>> eduPersonEntitlement (required)
>> eduPersonTargetedID (required)
>> is not.
>>
>> The university students and staff are free to use personalisation
>> at Lexis Nexis,
>> Elsevier, EBSCO, ProQuest services if they want to so
>> eduPersonScopedAffiliation (required)
>> eduPersonEntitlement (required)
>> eduPersonTargetedID (optional)
>> is working for the University as well.
>>
>> Is it correct?
>>
>> All the best
>>
>> Jiri____
>>
>> __ __
>>
>> ____
>>
>> On Sat, Mar 13, 2021 at 2:40 PM Bernd Oberknapp
>> <bo@ub.uni-freiburg.de <mailto:bo@ub.uni-freiburg.de>>
>> wrote:____
>>
>> Hi Jiri,
>>
>> On 13.03.21 09:15, Jiri Pavlik wrote:
>>
>> > When checking ProQuest SP for ProQuest Central in
>> DFN-AAI metadata [1]
>> > I can see both eduPersonEntitlement and
>> eduPersonTargetedID as required
>> > attributes.
>>
>> I assume you mean the SP
>> https://shibboleth-sp.prod.proquest.com/shibboleth
>>
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth-sp.prod.proquest.com%2Fshibboleth&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761640371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bosxymzT3WPyXBdeX0NnT5AvLDmTecE%2BEbZe6krDBwk%3D&reserved=0>?
>> That's obviously
>> wrong, both eduPersonScopedAffiliation and
>> eduPersonEntitlement are
>> supported for authorization, but as far as I can tell
>> you don't have to
>> use them, and eduPersonTargetedID isn't required.
>>
>> > 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?
>>
>> No. I can't speak for other IdPs, but in my opinion
>> that approach would
>> be wrong, users by default should be able to use
>> services anonymously,
>> without being recognized as a returning user. Based on
>> what I can see in
>> the admin tools, only a very small percentage of our
>> users actually uses
>> the personalization features, so releasing
>> eduPersonTargetedID by
>> default just for personalization isn't an option. If
>> publishers would
>> force us to send an eduPersonTargetedID just for
>> personalization I would
>> consider dropping Shibboleth for those publishers and
>> using our EZproxy
>> instead.
>>
>> Best regards,
>> Bernd
>>
>> --
>> 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
>>
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ub.uni-freiburg.de%2F&data=04%7C01%7Cjos.westerbeke%40eur.nl%7C79db2eedf41a41cdeec208d8e7ba85c2%7C715902d6f63e4b8d929b4bb170bad492%7C0%7C0%7C637514136761650360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eLOZmpzI51ttj9vd4uSNyCcFAAxIPZKUWoSATsoVq1k%3D&reserved=0>____
>>
>>
>>
------------------------------------------------------------------------
>>
>> Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam,
>> The Netherlands, Registration No. 33158992, Registered in The
>> Netherlands.
>>
>> _______________________________________________
>> FIM4L mailing list
>> 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