Summary
Building a JWT::JWK::Set from a JWKS that contains a key with an unrecognised kty raises JWT::JWKError: Key type AKP not supported, so the whole set fails. Per RFC 7517 section 5 an unrecognised key should be ignored, not fatal, so one post-quantum key in a published JWKS takes down verification of the classical keys with it.
Reproduction
require "jwt"
JWT::JWK::Set.new(mixed_jwks) # RSA + one {"kty" => "AKP", ...} (ML-DSA, RFC 9964)
# JWT::JWKError: Key type AKP not supported
Measured against ruby-jwt 3.2.0. The set builds fine once the AKP key is removed. Fixture and probe available on request.
Why this matters
RFC 7517 section 5: "Implementations SHOULD ignore JWKs within a JWK Set that use kty values that are not understood by them." ML-DSA (FIPS 204 / RFC 9964, kty: "AKP") is starting to appear in published key sets as post-quantum migration begins. When an issuer adds one to a JWKS that ruby-jwt consumers read, those consumers stop verifying every signature from that issuer, including classical RS256/ES256, on a spec-compliant key publication they do not control. In federated deployments that is an externally triggered outage.
Suggested fix
When constructing a JWT::JWK::Set, skip a member whose kty is unsupported (optionally surface it) rather than raising, so the recognised keys still load and remain usable for kid lookup. This implements the RFC section 5 SHOULD and leaves recognised keys unchanged.
Offer
Happy to share the reproduction harness (mixed classical + AKP JWKS plus a control) and to open a PR with the per-key skip and a test.
Summary
Building a
JWT::JWK::Setfrom a JWKS that contains a key with an unrecognisedktyraisesJWT::JWKError: Key type AKP not supported, so the whole set fails. Per RFC 7517 section 5 an unrecognised key should be ignored, not fatal, so one post-quantum key in a published JWKS takes down verification of the classical keys with it.Reproduction
Measured against ruby-jwt 3.2.0. The set builds fine once the AKP key is removed. Fixture and probe available on request.
Why this matters
RFC 7517 section 5: "Implementations SHOULD ignore JWKs within a JWK Set that use
ktyvalues that are not understood by them." ML-DSA (FIPS 204 / RFC 9964,kty: "AKP") is starting to appear in published key sets as post-quantum migration begins. When an issuer adds one to a JWKS that ruby-jwt consumers read, those consumers stop verifying every signature from that issuer, including classical RS256/ES256, on a spec-compliant key publication they do not control. In federated deployments that is an externally triggered outage.Suggested fix
When constructing a
JWT::JWK::Set, skip a member whosektyis unsupported (optionally surface it) rather than raising, so the recognised keys still load and remain usable forkidlookup. This implements the RFC section 5 SHOULD and leaves recognised keys unchanged.Offer
Happy to share the reproduction harness (mixed classical + AKP JWKS plus a control) and to open a PR with the per-key skip and a test.