<div><div><div dir="auto">Hi,</div></div><div dir="auto"><br></div><div dir="auto">thanks a lot comments, Peter. I can see that IdPs in eduID.at still need to release eduPersonTargetedID for Elsevier SP at least.</div><div dir="auto"><br></div><div dir="auto">Have you already tried to encourage Elsevier to request pairwise-id instead of eduPersonTargetedID? </div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Cheers</div><div dir="auto"><br></div><div dir="auto">         Jiri</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 5 Apr 2019 at 17:37, Peter Schober <<a href="mailto:peter.schober@univie.ac.at" target="_blank">peter.schober@univie.ac.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Jiri Pavlik <<a href="mailto:jiri.pavlik@mzk.cz" target="_blank">jiri.pavlik@mzk.cz</a>> [2019-04-05 16:58]:<br>
> could you comment, please, on eduPersonTargetedID as requested<br>
> attribute at Elsevier SP in eduID.at metadata? -<br>
> <a href="https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.com%252F/?federation=aconet-identity-federation-eduidat" rel="noreferrer" target="_blank">https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.com%252F/?federation=aconet-identity-federation-eduidat</a><br>
<br>
What is it you're asking speficically? Why the Elsevier SAML SP as<br>
registered in eduID.at lists eduPersonTargetedID as a requested<br>
attribute?<br>
If no existing SP in the world were still using eduPersonTargetedID we<br>
wouldn't be having these discussions, would we?  So obviously there<br>
are SPs that use ePTID today, even in the federation I operate.<br>
If you could clarify what the question is I can try to be more<br>
specific, instead of having to guess what contradiction you're looking<br>
for (or whatever).<br>
<br>
[ Of course looking closer at our metadata you'd see that we also<br>
modified our copy to contain a NameIDFormat element with 'persistent'<br>
listed first.  So any Shibboleth IDP that supported the SAML2 standard<br>
NameIDs -- not the eduPerson legacy attribute -- would work with that<br>
SP just fine using proper persistent NameIDs. I.e., none of our IDPs<br>
have to send eduPersonTargetedID to that SP to make it work.)<br>
<br>
In case this is still not clear: The ongoing activity to deprecate<br>
eduPersonTargetedID will not magically make it disappear from<br>
established SPs, nor will it forbid its continued use.<br>
But what it will do is prevent new guideline documents being written<br>
such as FIM4L's from claiming to support or establish or adhere to<br>
Best Current Practices and international standards while at the same<br>
time perpetuating or even recommending use of attributes that should<br>
not be used per those very standards.<br>
<br>
That's what I'm after: To avoid new standards from being created that<br>
cement use of obsolete legacy technology even if that legacy<br>
technology is still being used today. (Otherwise why bother?)<br>
<br>
-peter<br>
_______________________________________________<br>
FIM4L mailing list<br>
<a href="mailto:FIM4L@lists.daasi.de" target="_blank">FIM4L@lists.daasi.de</a><br>
<a href="http://lists.daasi.de/listinfo/fim4l" rel="noreferrer" target="_blank">http://lists.daasi.de/listinfo/fim4l</a><br>
</blockquote></div></div>
</div>