15 Mär
2021
15 Mär
'21
17:58
Hi Jiri,
actually that approach only improves the user experience as long as a user is only affiliated with a single institution. If the user is affiliated with multiple institutions or leaves the institution (and probably also for other some use cases), a personal account not based on an institutional identity might be the better choice (at least as long users don't have an edu-ID).
Best regards, Bernd
On 15.03.21 17:20, Jiri Pavlik wrote:
Hi,
I prefer Elsevier's approach, personalization based on pairwise-id/eduPersonTargetedID. Another sign in for personalisation on top of institutional sign in is adding complexity, it leads to worse user experience IMHO.
Cheers Jiri
On Mon, Mar 15, 2021 at 5:01 PM Bernd Oberknapp <bo@ub.uni-freiburg.de mailto:bo@ub.uni-freiburg.de> wrote:
Hi, I agree. The SP should not enforce the release of pairwise-id/eduPersonTargetedID, and if the IdP allows to release pairwise-id/eduPersonTargetedID the user should have the choice, so that the attribute is only released if the user wants to use the personalization based on that attribute. Additionally, when no pairwise-id/eduPersonTargetedID is passed to the SP, the SP still should offer personalization based on a registered account (as most
publishers
do, Elsevier as far as I know is one of very few publishers that
don't
allow this when an institutional login is used.). Best regards, Bernd On 15.03.21 16:46, Jiri Pavlik wrote: > Hi, > > IMHO there are users who wish to have anonymous access and
there are
> also users > who wish to have a profile, use personalisation. So a
solution there
> could be let users > decide about releasing pairwise-id (eduPersonTargetedID)
using CAR.
> > Best > Jiri > > On Mon, Mar 15, 2021 at 4:18 PM Jos Westerbeke <jos.westerbeke@eur.nl <mailto:jos.westerbeke@eur.nl> > <mailto:jos.westerbeke@eur.nl <mailto: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 <mailto:fim4l-bounces@lists.daasi.de> > <mailto:fim4l-bounces@lists.daasi.de <mailto:fim4l-bounces@lists.daasi.de>>> on behalf of Jiri Pavlik > <jiri.pavlik@techlib.cz <mailto:jiri.pavlik@techlib.cz> <mailto:jiri.pavlik@techlib.cz <mailto:jiri.pavlik@techlib.cz>>> > *Sent:* 15 March 2021 14:58 > *To:* Koren, Meshna (ELS-AMS) <M.Koren@elsevier.com <mailto:M.Koren@elsevier.com> > <mailto:M.Koren@elsevier.com <mailto:M.Koren@elsevier.com>>> > *Cc:* fim4l@lists.daasi.de <mailto:fim4l@lists.daasi.de> <mailto:fim4l@lists.daasi.de <mailto:fim4l@lists.daasi.de>> > <fim4l@lists.daasi.de <mailto:fim4l@lists.daasi.de> <mailto:fim4l@lists.daasi.de <mailto: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.c...
>
> > > > On Mon, Mar 15, 2021 at 12:01 PM Koren, Meshna (ELS-AMS) > <M.Koren@elsevier.com <mailto:M.Koren@elsevier.com> <mailto: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> <mailto: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/elsevieracc...
>
> > /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> > <mailto: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> > <mailto:bo@ub.uni-freiburg.de <mailto:bo@ub.uni-freiburg.de>>> > *Cc:* fim4l@lists.daasi.de <mailto:fim4l@lists.daasi.de> <mailto: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> <mailto: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 >
> 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> > <mailto:bo@ub.uni-freiburg.de <mailto:bo@ub.uni-freiburg.de>> > Internet: www.ub.uni-freiburg.de <http://www.ub.uni-freiburg.de> >
> > >
------------------------------------------------------------------------
> > 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 <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