<div dir="ltr">Excellent, I think I have a good enough handle on it now to interact with the vendor. Appreciate it!<div><br></div><div>Jason</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 9, 2021 at 2:14 PM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/9/21, 2:00 PM, "users on behalf of Jason Rotunno" <<a href="mailto:users-bounces@shibboleth.net" target="_blank">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:jrotunno@swarthmore.edu" target="_blank">jrotunno@swarthmore.edu</a>> wrote:<br>
<br>
>    Ah, ok. Thanks for the info. I'd like to explain the issue to the SP but it sounds like<br>
> urn:mace:shibboleth:1.0:nameIdentifier is the name Shib uses for that format. Is there platform-agnostic<br>
> terminology to refer to that request format that the SP operators would (hopefully) recognize?<br>
<br>
There is no SAML 1.1 equivalent, which doesn't matter because this isn't SAML 1.1. The SAML 2.0 transient format identifier is the other default format in the saml-nameid.propetties configuration and is documented in the standard.<br>
<br>
There is no reason why any SP should ever *require* either format and asking/demanding that it be used is a bug. It makes no sense to demand somebody send you an identifier that's intentionally non-persistent. <br>
<br>
>    Also, just out of curiosity, since there are no required Name ID formats in the SP's metadata, how does the<br>
> IdP know that it's requiring urn:mace:shibboleth:1.0:nameIdentifier?<br>
<br>
The NameIDPolicy element in Its request is forcing the IdP the use the requested format or fail. Failure in this case is caused by the inability to supply a SAML 2.0 NameID corresponding to a SAML 1.1-only Format.<br>
<br>
In short:<br>
<br>
a) SPs need to STOP using NameIDPolicy/@Format<br>
b) Any that did should never be asking for transient, in either SAML version.<br>
c) Even if they do, you can't ask for a SAML 1.1 Format in a SAML 2.0 request.<br>
<br>
-- Scott<br>
<br>
<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/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><pre cols="72">Jason Rotunno
System & Security Administrator
Swarthmore College
500 College Ave
Swarthmore, PA 19081
610.328.8505<br></pre><pre cols="72"><b>VERIFY before you click!!</b>
  - Attackers make their emails look like they come from someone they don't.
  - Attackers make links look like they go to websites they don't.
  - Attackers disguise malware as receipts, invoices, faxes, etc.</pre><pre cols="72">Forward suspicious emails to <a href="mailto:phishing@swarthmore.edu" style="font-family:Arial,Helvetica,sans-serif" target="_blank">phishing@swarthmore.edu</a><span style="font-family:Arial,Helvetica,sans-serif">.</span></pre></div></div></div></div></div></div></div></div></div></div></div></div>