Question around multiple keys in SAML Metadata

[Steven Premeau]

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 Metadata
for the OASIS SAML v2.0 standard
<https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf> (on
page 15 of the linked PDF).   (Of course, that document doesn't say really
anything about what you DO with multiple keys.)

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.

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 ...

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 ...

Steve.

On Mon, May 4, 2026 at 6:40 PM Paul B. Henson via users <
users at shibboleth.net> wrote:

> On Mon, May 04, 2026 at 05:25:14PM -0500, James Epp via users wrote:
>
> > I've come into disagreement with a vendor
> [...]
> > I was all but certain SAML-compliance required SPs
>
> Hehehehe... Vendors and standards compliance mix like oil and water ;).
>
> Section 2.6.1 "Key Processing" is pretty clear:
>
> "Each key expressed by a <md:KeyDescriptor> element within a particular
> role MUST be treated as valid when processing messages or assertions in
> the context of that role. Specifically, any signatures or transport
> communications (e.g., TLS/SSL sessions) verifiable with a signing key
> MUST be treated as valid, and any encryption keys found MAY be used to
> encrypt messages or assertions (or encryption keys) intended for the
> containing entity."
>
> The standard allows multiple keys to be included in metadata, the
> standard says each key MUST be treated as valid.
>
> Your vendor doesn't have a leg to stand on, although sadly that will
> likely have no impact on their desire or ability to fix their broken
> implementation <sigh>.
>
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20260504/8b2b5780/attachment.htm>