JsonWebKey.import_key_set raises KeyError on an unknown kty, failing the whole JWK Set (RFC 7517 §5) #913

Summary

JsonWebKey.import_key_set() raises KeyError: 'AKP' when any key in the set has a kty it does not recognise, so the entire key set fails to import. Per RFC 7517 section 5 an unrecognised key should be ignored, not fatal. A single post-quantum key in a published JWKS therefore takes down verification of the classical keys alongside it.

Reproduction

A JWK Set with a classical RSA key, an EC key, and one post-quantum ML-DSA key (kty: "AKP", RFC 9964):

from authlib.jose import JsonWebKey
JsonWebKey.import_key_set(mixed_jwks)   # RSA + EC + one {"kty":"AKP", ...}
# KeyError: 'AKP'

Measured against Authlib 1.7.2. The same set imports fine once the AKP key is removed, so the failure is attributable to the unknown key, not the fixture. Full 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) key publication is beginning across the ecosystem (Node ships it, Go stdlib in 1.27, RFC 9964 defines the AKP JWK form). The moment an issuer adds an ML-DSA key to a JWKS that Authlib consumers read, those consumers stop verifying every signature from that issuer, including the classical ones, on a key publication they do not control. In federated deployments (OpenID Connect, open banking) this is an externally triggered outage.

Suggested fix

In import_key_set, when a member's kty has no registered key type, skip that member (optionally warn) instead of raising, so the rest of the set still loads. This matches the RFC section 5 SHOULD and does not change behaviour for recognised keys.

Offer

Happy to share the cross-language reproduction harness (a mixed classical + AKP JWKS with a control set) and to open a PR with the per-key tolerance and a regression test.