Hi,

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? 


Cheers

         Jiri




On Fri, 5 Apr 2019 at 17:37, Peter Schober <peter.schober@univie.ac.at> wrote:
* Jiri Pavlik <jiri.pavlik@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@lists.daasi.de
http://lists.daasi.de/listinfo/fim4l