suggested certification test for post quantum preparation - unparseable keys in server jwks

The certification team would appreciate feedback on a suggested new test - in thinking about the rollout of post quantum algorithms, it seems like we should ensure that clients cope okay with a server jwks that contains a key they can't parse. This would mean servers could start listing post quantum keys (in addition to the current keys) in their jwks knowing the clients would not stop working.

Not sure how to do this test in practice - having an unparseable key in the server jwks_uri all the time seems most reliable so is I think my recommendation - having a specific test that adds a key to the jwks just for that test could work unreliably if the client is caching the jwks and/or openid-configuration contents.

The slightly annoying this is that this is only a 'should' in the spec as far as I can see, https://www.rfc-editor.org/rfc/rfc7517#section-5 :

Implementations SHOULD ignore JWKs within a JWK Set that use "kty" (key type) values that are not understood by them, that are missing required members, or for which values are out of the supported ranges.

There's not really any practical way we can make this only a 'warning' in the test suite (we can't see that the client is aborting because it found an unsupported key) so in practice we would be treating it as a 'must'.

Start with the proposed certification test described in the issue and read RFC 7517 section 5 to confirm the expected handling of unsupported JWKs. Determine how the certification suite can provide a server JWKS containing an unparseable key despite JWKS or OpenID configuration caching; done means clients continue working with the additional key present.