Question around multiple keys in SAML Metadata

[James Epp]

Thank you both, these are more or less the responses I expected. Glad to
hear my understanding of the standards isn't unreasonable.

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.

On Mon, May 4, 2026 at 5:52 PM Steven Premeau via users <
users at shibboleth.net> wrote:

> 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
>>
> --
> 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/20260509/eaf4b8c8/attachment.htm>