<div dir="ltr"><div>Thank Scott for the detailed explanation</div><div><br></div><div>Regarding first para, I don't intend to use the legacy feature basically it is disabled, rather migrate across to the need of new V 3</div><div><br></div><div>Confusion I had was, documentation states those two types are deprecated but I was not sure, for V 3.x do I have to use anything else instead.</div><div>That is, If I am not mistaken, not only It is deprecated in V 3.x also we don't need to use any type at all in saml-nameid.xml for the nameID?</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 21, 2017 at 12:45 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> However it is not clear to be what is the new way and how to encode it in V3,<br>
> does this mean, if the previous V2 encoding is SAML2StringNameID (as an<br>
> e.g.) and we can ignore this in V3 and don't need to do anything with respect<br>
> to NameID encoding?<br>
<br>
</span>If you mean will it still work, yes, there's a property that's enabled by default on upgrades that enables "legacy" use of the resolver to generate NameIDs. If you mean whether the IdP will ignore the deprecated encoders entirely, it will if that legacy property is not enabled, which is the case on fresh non-upgrade installs. The properties are in saml-nameid.properties and are marked pretty explicitly.<br>
<span><br>
> Also if I am not mistaken with the new approach from below V2 resolver<br>
> definition as an example, and in new V3, below will split into two, that is<br>
> resolver will still continue to have this attribute with encoding<br>
> enc:SAML2String but only higligthted SAML2StringNameID will be moved to<br>
> saml-nameid.xml obviously without SAML2StringNameID<br>
<br>
</span>In effect, yes. They are separate functions. They always were, we just overloaded it all syntactically and that was ultimately more confusing in the end.<br>
<br>
And to be clear, NameIDs suck for all sorts of reasons. They shouldn't be used. When you have to use them, you grin and bear it. There is a reason they are painful to use, they are not how Shibooleth is meant to work, and they will continue to be second-class citizens. Always ask the vendor to use an Attribute.<br>
<span><br>
> Please confirm is that the correct understanding, if so, kind of double work in<br>
> two files obviously with clarity<br>
<br>
</span>It's not double the work, it's just moving a step from one place to another, and adding clarity, as well as a bunch of additional features.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</font></span></blockquote></div><br></div>