Potential post-quantum transition issues

[fkj]

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 suggested certification test for post quantum preparation - unparseable keys in server jwks #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.

[RalphBragg]

Raidiam has been disclosing this since late July. We ran a JWKS with one ML-DSA key (kty: "AKP", RFC 9964) next to normal RSA and EC keys against every library on jwt.io. That is 110 entries in 37 languages. 46 have a real JWK Set parser. 19 of those 46 fail the whole set on the one AKP key, so an RS256 token that verified a second ago stops verifying. Three separate harnesses agree. Every Rust crate fails. Both Ruby set parsers fail, including the official gem. Every Go set parser fails except kataras/jwt. The impact is simple: a bank or provider that starts advertising ML-DSA breaks its relying parties, and none of them can prevent or roll back the change. One more point for the list in this issue: tolerant is not the same as safe. Most tolerant libraries drop the AKP key in silence. That is fine now, but once issuers sign with ML-DSA the same consumers will only say "no matching key".

Timeline and engagement path:

• 21 Jul 2026. Found during our own ML-DSA enablement testing. First upstream ticket filed the same day (lestrrat-go/jwx #2263).
• 22 Jul 2026. Hit for real in pre production. An issuer published AKP keys, a downstream consumer on a strict library rejected every request, and login broke. The jwx maintainer patched v3 and v4 within the day.
• 23 Jul 2026. OIDF notified under selective disclosure. The view was that this is an availability problem, not a crypto vulnerability, so it can be discussed in public. Scheme notifications started.
• 24 Jul 2026. Sweep extended to all 110 jwt.io libraries. Nine more tickets filed, each with a reproduction and an offer of a PR.
• 25 Jul to 12 Aug 2026. Fixes merged in joserfc and jwcrypto. Authlib declined to patch the deprecated authlib.jose and moved the fix to joserfc.
• Ongoing. Every major ecosystem we work with has been notified. Most have other mitigations in place, or we have assessed their published SDKs: Open Banking UK, Open Finance Brazil, AP+ (ConnectID), NZBA and CBUAE Open Finance.

Actions in flight:

• Conformance. We looked at this with the conformance team and found the check only existed in the VCI and VP tests. Thanks to Joseph for carrying it across to the OP and RP side (!2036, !2119). This is the part that matters most for point 2 in this issue. RFC 7517 section 5 is a SHOULD, so only a conformance test reaches the rest, including the 61 jwt.io entries with no set parser of their own.
• Our own rollout stays staged, as the federation controller we'd brick our clients ecosystems so we're stuck until everyone has had sufficient time to test.

Tickets raised:

Library	Lang	Ticket	State
lestrrat-go/jwx	Go	#2263	Closed. v4 tolerant by default; v3 needs jwk.Configure(jwk.WithStrictKeySetParsing(false))
authlib/authlib	Python	#913, PR #914	Closed, will not fix. authlib.jose is deprecated
authlib/joserfc	Python	#104, PR #103	PR merged
latchset/jwcrypto	Python	#385, PR #388	Fixed, merged 12 Aug 2026
Keats/jsonwebtoken	Rust	#529	Closed. Fix agreed, deferred to v11
go-jose/go-jose	Go	#276, PR #277	Open
jwt/ruby-jwt	Ruby	#743, PR #744	Hash path fixed in #728; PR open for the array path
vapor/jwt-kit	Swift	#246	Open, maintainer will take a PR
airsidemobile/JOSESwift	Swift	#494	Open
FusionAuth/fusionauth-jwt	Java	#80	Open

Note the pattern: the fixes go forward, not backward. jwx makes v4 tolerant by default and leaves v3 strict unless you opt in. Keats/jsonwebtoken deferred the fix to v11 because it breaks the API. Authlib will not patch the deprecated module at all.

Raidiam-JWK-kty-advisory-report-rev2.pdf

Harness, the full 110 row matrix and the advisory are being published today at https://github.com/raidiam-oss/PQdos

[james-d-elliott]

Also see go-jose/go-jose#282

[sakimura]

I wonder if the underlying issue here is broader than PQC support itself.

To me, the more fundamental requirement is cryptographic agility, including both algorithm agility and key agility.

PQC transition is one immediate driver, but we should probably avoid treating it as a one-off migration from “classical” algorithms to a fixed set of “post-quantum” algorithms. The PQC algorithms we deploy today may themselves need to be replaced later, whether because of new cryptanalysis, implementation considerations, hardware constraints, or operational experience.

From that perspective, I think Connect implementations and profiles should be able to support at least the following properties:

• introduction of new alg and kty values without breaking use of already-supported algorithms;
• coexistence of multiple algorithm and key types during transition periods;
• rapid introduction, rotation, and retirement of keys;
• algorithm-policy changes without redesigning the protocol;
• downgrade-resistant expression of algorithm requirements where such requirements are needed; and
• conformance testing that verifies this behaviour across OPs, RPs, and underlying JOSE/JWT libraries.

The unknown-kty behaviour discussed above is a good example: the problem is not really ML-DSA-specific. It demonstrates that an implementation which appears algorithm-agile at the protocol level may in practice be unable to tolerate introduction of a new key type.

I would also distinguish the risk model for short-lived online assertions, such as ID Tokens, from long-lived signatures or confidentiality use cases. For an online assertion, the relevant security parameter is not only the algorithm, but also the public-key exposure period, signing-key cryptoperiod, token lifetime, and the period during which signatures under that key remain acceptable. If a future quantum attack requires non-negligible time per key, sufficiently short key and acceptance windows may materially reduce the practical attack surface, although this obviously does not remove the need for PQC transition.

So I suggest that the work here be framed not only as “how do we add PQC algorithms to OpenID Connect?”, but more broadly as:

What cryptographic-agility requirements must OpenID Connect and its implementations satisfy so that algorithms and keys can be introduced, rotated, deprecated, and replaced safely over time?

That seems likely to remain useful even after the first PQC transition is complete.

[PhilSchmieder]

To elaborate on potential issue 3:

Our concern is not with the general feasibility of making OIDC post-quantum secure, but with a smooth transition process. This is primarily driven by the need to support multiple signature schemes at the same time. For a smooth transition to post-quantum security it is sensible to initially support a post-quantum signature scheme like ML-DSA-44 and a classical one like RS256 at the same time. In that scenario, RPs must be able to somehow decide whether they want to receive tokens signed with ML-DSA-44 or RS256. Naturally, ML-DSA-44 is the favorable choice after Q-Day but before that (or maybe even after that) RPs may want to stay with RS256 for compatibility reasons.

As of now, RPs can specify in id_token_signed_response_alg the "JWS alg algorithm [...] REQUIRED for signing the ID Token issued to this Client". Depending on the nature of the RP and how the tokens are verified being able to specify one algorithm is not sufficient due to the aforementioned conflict of post-quantum security and compatibility. Therefore the possibility of specifying multiple algorithms and to change them without the need to re-register would be required.

Similar problems may arise for other metadata values such as: userinfo_signed_response_alg, request_object_signing_alg, token_endpoint_auth_signing_alg.

I agree with @sakimura, that while the post-quantum transition may be the motivating driver behind ideas like this, they should be seen more generally as a crypto agility improvements.

An additional thought: Some time after Q-Day when computation time on cryptographically relevant quantum computers becomes a quasi commodity tokens signed with RSA (assuming usual-ish parameters) are easily forged. From a security perspective they become essentially unsecured. Therefore, while I believe hard coding one signature scheme that every party must support is a good idea, specifying that RS256 is the only scheme that must be supported is dangerous and that choice should be changed to a post-quantum secure scheme.

[fkj]

As of now, RPs can specify in id_token_signed_response_alg the "JWS alg algorithm [...] REQUIRED for signing the ID Token issued to this Client". Depending on the nature of the RP and how the tokens are verified being able to specify one algorithm is not sufficient due to the aforementioned conflict of post-quantum security and compatibility. Therefore the possibility of specifying multiple algorithms and to change them without the need to re-register would be required.
Similar problems may arise for other metadata values such as: userinfo_signed_response_alg, request_object_signing_alg, token_endpoint_auth_signing_alg.

I'm not really sure I understand what the problem is here. Each client gets a list of algorithms to choose from in the Discovery metadata, but then they do actually need to choose one. What would it mean for the RP to specify multiple algorithms here? How would the OP decide which of them to use in a specific request, and if the RP supports both, why not just use the PQ algorithm?
I do of course understand the need to change the configuration, which is a separate topic that I have added as issue 5 in the top comment.

I agree with @sakimura, that while the post-quantum transition may be the motivating driver behind ideas like this, they should be seen more generally as a crypto agility improvements.

I agree, and I believe this is the general opinion of the working group as well.

An additional thought: Some time after Q-Day when computation time on cryptographically relevant quantum computers becomes a quasi commodity tokens signed with RSA (assuming usual-ish parameters) are easily forged. From a security perspective they become essentially unsecured. Therefore, while I believe hard coding one signature scheme that every party must support is a good idea, specifying that RS256 is the only scheme that must be supported is dangerous and that choice should be changed to a post-quantum secure scheme.

I agree and have added this as issue 4 in the top comment.

[james-d-elliott]

Really this is a job for DCR and MC OpenID Connect Relying Party Metadata Choices 1.0.

As to the overall issue I think the main problem is JWT libs rejecting unknown entries. I think if you read between the lines of the spec it's clear the client is meant to either pick the one that signed the token, or the one they want to use to encrypt.

I think it would be reasonable to enforce ignoring unknown phony alg/kty for conformance under an errata.

[fkj]

Really this is a job for DCR and MC OpenID Connect Relying Party Metadata Choices 1.0.

Yes for the negotiation parts (plus CIMD). But most clients are statically registered, so there is a separate challenge in communicating best practices for out-of-band configuration.

I think it would be reasonable to enforce ignoring unknown phony alg/kty for conformance under an errata.

Right now this is only a SHOULD in RFC 7517, but for conformance we could choose to interpret that in a stricter way.

[jogu]

Right now this is only a SHOULD in RFC 7517, but for conformance we could choose to interpret that in a stricter way.

This is basically the position we have taken with the conformance tests - once https://gitlab.com/openid/conformance-suite/-/merge_requests/2119 is merged/deployed people will be required to ignore unknown keys to be able to certify. (It's really difficult to actually write the test in a way that people who reject unknown keys would still be able to complete the test and certify.)

We technically don't yet have approval from the Connect WG on this, just a lack of objections and some support - a decision made at a quorum WG meeting and recorded by one of the chairs onto #2147 would be helpful to close that off please.

[fkj]

We technically don't yet have approval from the Connect WG on this, just a lack of objections and some support - a decision made at a quorum WG meeting and recorded by one of the chairs onto #2147 would be helpful to close that off please.

I will add this to our agenda today.

[RalphBragg]

Hi - I can't attend but obviously this gets my / Raidiam's vote if necessary!

[james-d-elliott]

Looking broadly at the intent of the spec here it seems very clear that the client should pick the appropriate JWK from the list of JWKs and not consider the others. I hope it's not a burden for me to harp on about this.

RFC7515 states:

Appendix D Notes on Key Selection

2. Filter the set of collected keys. For instance, some applications will use only keys referenced by "kid" (key ID) or "x5t" (X.509 certificate SHA-1 thumbprint) parameters. If the application uses the JWK "alg" (algorithm), "use" (public key use), or "key_ops" (key operations) parameters, keys with inappropriate values of those parameters would be excluded. Additionally, keys might be filtered to include or exclude keys with certain other member values in an application-specific manner. For some applications, no filtering will be applied.

RFC7517 Section 5 also states in addition to the kty SHOULD and separate to members within a JWK:

Additional members can be present in the JWK Set; if not understood by implementations encountering them, they MUST be ignored.

I understand there is wiggle room for interpretation here but I still believe there is an extremely strong argument that this is expected of clients.

There is no spec requirement for example that a client should not reject JWKS if it has a JWK with a key id it does not expect either, but it's not very logical to argue that it would be a compliant client if it rejected all JWKS that were not explicitly used for a specific token.

Would we also consider these theoretical clients compliant? Would a client which rejects a set of keys because it lists only kty RSA also be considered compliant? Would a client which rejects a set of keys because the client only supports RSA kty, but the set of keys includes an EC kty also be considered compliant?

[james-d-elliott]

Small additional consideration. This could also theoretically be addressed in an OpenID Connect 1.0 Core errata, and requiring all existing clients to recertify by a deadline or their certification would be revoked, provided there is relief in the terms / agreement for this.