Potential post-quantum transition issues

This issue exists to track requirements and initiatives towards ensuring support for Connect with post-quantum cryptography in the ecosystem.

The following potential issues have been brought up so far:

1. Many implementations are throwing away the entire JWK set if they see a single JWK with an algorithm/key type they don't understand. The certification team has already brought this up in #2147 for the server case. A similar issue has previously been seen for RFC 9864 support where new algorithm identifiers also appeared. This is a general cryptographic agility issue, not anything specific to post-quantum transition.
2. It's not clear that RFC 7517 actually requires implementations to ignore "unknown" keys in a JWKS and still keep the rest of the set, so 1 is not necessarily possible to handle completely with conformance testing.
3. How can a client indicate that they only want post-quantum cryptography if the server also offers traditional cryptography? This can't be per-request since that would allow downgrade attacks. Potential solutions include DCR, CIMD and out-of-band configuration.
4. Connect Core (and potentially other of our specifications) mention RS256 as a default signing algorithm. This might have to be updated to some other algorithm eventually. But what to update to and when is not clear.
5. How can a client that was originally (potentially dynamically) registered to use a non-PQ algorithm change its configuration to use PQ algorithms?

The following initiatives have been proposed so far:

1. Defining a conformance test suite for the various layers that need to be correctly implemented for PQC transition to function well. This will require tests at several layers, so it might need to be multiple test suites to ensure easy adoption at each layer.
2. Writing a blog post/whitepaper containing best practices and informing the general community of the potential issues mentioned above, ideally while also providing an overview of potential solutions.
3. Proactively reaching out to major implementers of OpenID Connect and informing them of the potential issues mentioned above (especially if we can externally observe the issue in their implementation).
4. Proactively reaching out to implementers of underlying library code (such as a JWT library) and informing them of the potential issues relevant to their layer.
5. Reaching out to security analysis providers and asking them to register the potential issues above as security issues (as opposed to just interoperability issues) since they may prevent PQC adoption in a surprising way.

If you have anything to add to this list, please write it as a comment.

Start with the five transition questions in this issue, RFC 7517, and the related server concern in #2147. Review the proposed conformance-test, guidance, and outreach initiatives; done requires turning this broad tracker into scoped, agreed work items with explicit requirements and acceptance criteria.