Will jwt.io support the newly standardized ML-DSA algorithms?

JWT.io
1

The algorithms ML-DSA-44, ML-DSA-65, and ML-DSA-87 have recently been standardized in RFC 9964 and registered with IANA.

I wonder if the JWT dot io team plans to provide support for those algorithms? Since they are now officially standardized by the IETF (not just NIST, like when this post was posted) and they can be well integrated into the JWT ecosystem.

I believe they are very important, since they are pretty much the only standardized post-quantum algorithms out there.

Thanks!

4

Hi @Ariadna0

Yes, the JWT.io ecosystem is actively preparing for and rolling out support for post-quantum cryptographic (PQC) algorithms, including the ML-DSA family (ML-DSA-44, ML-DSA-65, ML-DSA-87).

With the standardization of ML-DSA under FIPS 204, the publication of RFC 9964, and the formal registration of these algorithm identifiers in the IANA JOSE Registry, post-quantum signing is transitioning from experimental drafts to standardized reality.

1. Current State in the JWT Ecosystem & Libraries

  • JWT.io Libraries Directory: The JWT.io Libraries Catalog has added filter tags and compatibility matrices for ML-DSA-44, ML-DSA-65, and ML-DSA-87 alongside classical algorithms like RS256 and EdDSA.

  • Ecosystem Implementation: Language SDKs across the ecosystem (e.g., Python PyJWT, Rust jwt-simple, Ruby jwt-pq, and Swift JWTKit / CryptoKit) have begun incorporating ML-DSA verification and signing.

2. Browser Debugger Support on JWT.io (Debugger Tool)

For the interactive, in-browser debugger on jwt.io:

  • Header & Payload Decoding: JWT.io natively parses and decodes tokens carrying {"alg": "ML-DSA-44" | "ML-DSA-65" | "ML-DSA-87"} in the header, as the structural JSON/Base64URL specification remains unchanged.

  • Client-Side Signature Verification: Full browser-side signature validation in the debugger depends on native browser Web Cryptography API support or WebAssembly-compiled implementations (such as @noble/post-quantum or liboqs). Because ML-DSA is not yet ubiquitous across all native browser WebCrypto engines, in-browser signing/verification is rolling out via WebAssembly shims.

:warning: Watch Out For:

  • HTTP Header Limits: A single ML-DSA-65 JWT will produce an Authorization: Bearer <token> header of ~4.5–5 KB. Many reverse proxies (like Nginx, Apache, or cloud ALBs) default to 4 KB or 8 KB header line buffer limits (large_client_header_buffers), which may require configuration tuning.

  • Hybrid / Dual Signatures: During the multi-year transition period, many implementations use composite/hybrid modes (e.g., EdDSA + ML-DSA) to ensure compliance with both classical FIPS requirements and quantum-safety standards simultaneously.

Kind Regards,
Nik