<div dir="ltr"><div><div><div>I agree with you (about the SPs being brain dead), not because I can distinguish between the merits of an SP requesting a set of attributes versus requiring a NameID, but because dealing with the SPs that require a NameID is infinitely more difficult that those requesting attributes.  However, when my boss says "Get SSO working with .... and we've already signed a contract with them", I don't have the liberty to say "NO WAY, that SP is brain dead".<br><br></div>Finally, thank you so much for the V3 documentation.  I know you and others did the V2 as well, but you made it significantly better; I especially like the added examples.<br><br></div>Thanks,<br></div>Mike <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 27, 2016 at 5:25 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=""> > The data the SP provides is the NameIDPolicy in the AuthnRequest and its<br>
> metadata, that's it.<br>
<br>
</span>More to the point, no SP brain dead enough to need a NameID (or think they do) wil provide either of these inputs. Many federations (e.g. InCommon) don't support NameIDFormat elements in metadata, but a good number of cases where it even comes up aren't providing metadata anyway. The most common approach is to add it to the metadata you have to generate, or locally load, into the IdP.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>