<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's intentional (and should be documented that way).<br></blockquote><div><br></div><div>Indeed it is documented [1]:</div><div><br></div><div>It must be released (in terms of attribute filter policy) to the relying party, but need not have any attribute encoders attached (which means it won't actually be visible to the relying party in the SAML response).</div><div><br></div><div>Obviously I haven't made my way through all the v3 docs yet.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If I didn't do it that way, handling custom NameID formats that actually expose data would have either been accident-prone or I would have have had to somehow completely separate different NameID types and generate them in different places</blockquote><div><br></div><div>I have to admit I don't understand your justification in detail, but I trust you. In any case I can meet my needs by not attaching an encoder to the source attribute to prevent disclosure.</div><div><br></div><div>M<a href="mailto:users-unsubscribe@shibboleth.net" target="_blank"></a><br>
</div><div><br></div><div>[1] <a href="https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfiguration#NameIDGenerationConfiguration-PersistentIdentifierGeneration">https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfiguration#NameIDGenerationConfiguration-PersistentIdentifierGeneration</a></div><div><br></div></div></div>