[Fim4l] [refeds] Deprecating eduPersonTargetedID

Jiri Pavlik jiri.pavlik at mzk.cz
Fri Apr 5 18:08:00 CEST 2019


thanks a lot comments, Peter. I can see that IdPs in eduID.at still need to
release eduPersonTargetedID for Elsevier SP at least.

Have you already tried to encourage Elsevier to request pairwise-id instead
of eduPersonTargetedID?



On Fri, 5 Apr 2019 at 17:37, Peter Schober <peter.schober at univie.ac.at>

> * Jiri Pavlik <jiri.pavlik at mzk.cz> [2019-04-05 16:58]:
> > could you comment, please, on eduPersonTargetedID as requested
> > attribute at Elsevier SP in eduID.at metadata? -
> >
> https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.com%252F/?federation=aconet-identity-federation-eduidat
> What is it you're asking speficically? Why the Elsevier SAML SP as
> registered in eduID.at lists eduPersonTargetedID as a requested
> attribute?
> If no existing SP in the world were still using eduPersonTargetedID we
> wouldn't be having these discussions, would we?  So obviously there
> are SPs that use ePTID today, even in the federation I operate.
> If you could clarify what the question is I can try to be more
> specific, instead of having to guess what contradiction you're looking
> for (or whatever).
> [ Of course looking closer at our metadata you'd see that we also
> modified our copy to contain a NameIDFormat element with 'persistent'
> listed first.  So any Shibboleth IDP that supported the SAML2 standard
> NameIDs -- not the eduPerson legacy attribute -- would work with that
> SP just fine using proper persistent NameIDs. I.e., none of our IDPs
> have to send eduPersonTargetedID to that SP to make it work.)
> In case this is still not clear: The ongoing activity to deprecate
> eduPersonTargetedID will not magically make it disappear from
> established SPs, nor will it forbid its continued use.
> But what it will do is prevent new guideline documents being written
> such as FIM4L's from claiming to support or establish or adhere to
> Best Current Practices and international standards while at the same
> time perpetuating or even recommending use of attributes that should
> not be used per those very standards.
> That's what I'm after: To avoid new standards from being created that
> cement use of obsolete legacy technology even if that legacy
> technology is still being used today. (Otherwise why bother?)
> -peter
> _______________________________________________
> FIM4L mailing list
> FIM4L at lists.daasi.de
> http://lists.daasi.de/listinfo/fim4l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.daasi.de/pipermail/fim4l/attachments/20190405/d782786a/attachment.html>

More information about the FIM4L mailing list