<div dir="ltr"><div><div>Thanks.<br></div><div><br></div><div>>Supporting the new attributes is going to necessitate doing it all in the resolver so that is likely it. <br></div><div><br></div>Via attribute-resolver -- Is it possible to configure for UUID to be issued on the first entry for user (per SP) --  storedonto SHIBID table?  Pairwise ID not required.</div><div><br></div><div>If not possible -- we may go with Hash.<br></div><div><br></div><div><br>> The NameID support in the IdP is about commercial SAML integrations, none of which will ever rely on any form of pairwise ID.</div><div><br></div><div>Yup -- make sense.<br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 29, 2018 at 1:27 PM, 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 class="">> So on longer term -- if we wish to leverage persistence ID (i.e. unique to the<br>
> user per IdP/SP combination) --- where available both as SAML2String and as<br>
> a SAML2NameID -- what is the best configuration option?<br>
<br>
</span>Supporting the new attributes is going to necessitate doing it all in the resolver so that is likely it. The NameID support in the IdP is about commercial SAML integrations, none of which will ever rely on any form of pairwise ID.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/<wbr>confluence/x/coFAAg</a><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>