<div dir="ltr">Thank you both, these are more or less the responses I expected. Glad to hear my understanding of the standards isn't unreasonable.<div><br></div><div>I very much doubt this vendor will correct their ways. From some of the log output I saw I suspect they're using an open source SAML library (not shibboleth). Whether they're regularly importing updates from that library is anyone's guess.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, May 4, 2026 at 5:52 PM Steven Premeau via users <<a href="mailto:users@shibboleth.net">users@shibboleth.net</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"><div dir="ltr">To build a bit on Paul's comment, if you need to prove that multiple keys in metadata is valid syntax, that is defined at 

Section 2.4.1.1 of the <a href="https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf" target="_blank">Metadata for the OASIS SAML v2.0 standard</a> (on page 15 of the linked PDF).   (Of course, that document doesn't say really anything about what you DO with multiple keys.)<div><br></div><div>All of that being said, this may be a case where you have as much luck getting it addressed by reminding them that it is Microsoft-generated metadata that creates this issue.</div><div><br></div><div>But, like Paul, I have way too many stories about vendors that do not budge even after being confronted with detailed facts  on how their implementation is broken or that they are deviating from a standard ... </div><div><br></div><div>In some cases, I was able to make it a procurement or contract issue which could add some "real" pressure... but (too) often, my only option was to find a workaround ...</div><div><br></div><div>Steve.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 4, 2026 at 6:40 PM Paul B. Henson via users <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</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 Mon, May 04, 2026 at 05:25:14PM -0500, James Epp via users wrote:<br>
<br>
> I've come into disagreement with a vendor<br>
[...]<br>
> I was all but certain SAML-compliance required SPs<br>
<br>
Hehehehe... Vendors and standards compliance mix like oil and water ;).<br>
<br>
Section 2.6.1 "Key Processing" is pretty clear:<br>
<br>
"Each key expressed by a <md:KeyDescriptor> element within a particular<br>
role MUST be treated as valid when processing messages or assertions in<br>
the context of that role. Specifically, any signatures or transport<br>
communications (e.g., TLS/SSL sessions) verifiable with a signing key<br>
MUST be treated as valid, and any encryption keys found MAY be used to<br>
encrypt messages or assertions (or encryption keys) intended for the<br>
containing entity."<br>
<br>
The standard allows multiple keys to be included in metadata, the<br>
standard says each key MUST be treated as valid.<br>
<br>
Your vendor doesn't have a leg to stand on, although sadly that will<br>
likely have no impact on their desire or ability to fix their broken<br>
implementation <sigh>.<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</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>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</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>