<div dir="ltr"><div><font color="#000000">Scott, you may have been eavesdropping on my phone call with this service provider.<br>As an IdP operator I share your frustration, and I'm doubling down because in my experience it's getting worse not better, which doesn't bode well. <br><br>I posted this query here because these folks insist that other IdPs including at least one InCommon IdP is working with their configuration and metadata that:<br>- includes a digital signature of the metadata in the file, which might add some confidence in the integrity of the metadata if it weren't that the certificate to validate the signature is also just part of the same file ("if you don't trust the top part of this file, you can validate it with another part of the same file - isn't that convenient?")<br>- redirects the user's browser to the published POST endpoint of the IdP; they seemed put out that I asked them to redirect to the redirect endpoint.<br>- does not sign the request despite asserting in their metadata that requests will be signed; they cannot fathom why our IdP <font face="arial, sans-serif">refuses the request in that case<br>- has an enitityID like "urn:67dd80b***10e971cd29:***astage" which I'm pretty sure is not a "real" urn / uri\<br></font></font></div><div><font color="#000000"><font face="arial, sans-serif"><br></font></font></div><div><font color="#000000"><font face="arial, sans-serif">Apart from the silly waste of time and resources to cobble together a working integration, why on earth should my institution be trusting this service to manage sensitive institutional data?<br><br>Why are we in this mess?<br></font></font></div>





<br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jul 18, 2025 at 1:47 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">When various folks tell me the standard is "vague" and I react somewhat aggressively, this is why.<br>
<br>
Quoting:<br>
<br>
"However, an identity provider that receives an unsigned <samlp:AuthnRequest> message from a service provider whose metadata contains this attribute with a value of true MUST return a SAML error response and MUST NOT fulfill the request."<br>
<br>
Is that somehow unclear?<br>
<br>
-- Scott<br>
<br>
<br>
</blockquote></div></div>