<div dir="ltr"><div>We have a myriad of vendors ---- some  accept nameIDs, a minority are still only eduPersonTargetedID ......it wasn't by choice, but keeping the ship running..<br><br></div>Beyond unelegance, does it create any unorthodox behaviors on the IdP or future upgrade path.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 11, 2017 at 1:43 AM, Peter Schober <span dir="ltr"><<a href="mailto:peter.schober@univie.ac.at" target="_blank">peter.schober@univie.ac.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Lionel Samuel <<a href="mailto:lionel.samuel01@gmail.com">lionel.samuel01@gmail.com</a>> [2017-09-11 06:22]:<br>
<span class="">> We are recently on idp3.3.0 and enabled:<br>
<br>
</span>Also want to share why you're creating NameIDs in the attribute<br>
resolver? Any application that requires eduPersonTargetedID to work<br>
but can't use (the same) persistent NameIDs when sent in the<br>
Assertion's Subject element should be fixed (and have a bug reported).<br>
<span class="HOEnZb"><font color="#888888">-peter<br>
</font></span><div class="HOEnZb"><div class="h5">--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</div></div></blockquote></div><br></div>