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

Thank you for reaching out!

I understand that you are asking for a reformatted overview of post-quantum cryptographic (PQC) algorithm support in the JWT ecosystem, specifically the ML-DSA family and their integration across JWT.io tools and language SDKs.

The JWT.io ecosystem is actively rolling out support for post-quantum signing with ML-DSA algorithms (ML-DSA-44, ML-DSA-65, ML-DSA-87), which have transitioned from experimental status to standardized reality following FIPS 204 standardization, RFC 9964 publication, and formal registration in the IANA JOSE Registry.

Current Implementation Status:

The JWT.io Libraries Catalog now includes filter tags and compatibility matrices for all three ML-DSA variants alongside classical algorithms like RS256 and EdDSA. Language SDKs across the ecosystem—including Python (PyJWT), Rust (jwt-simple), Ruby (jwt-pq), and Swift (JWTKit and CryptoKit)—have begun incorporating ML-DSA verification and signing capabilities.

JWT.io Debugger Tool Support:

The interactive browser debugger on jwt.io natively parses and decodes tokens with {"alg": "ML-DSA-44" | "ML-DSA-65" | "ML-DSA-87"} in the header, since the structural JSON and Base64URL specification remains unchanged. Client-side signature verification 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 and verification are rolling out via WebAssembly shims.

Important Considerations:

  1. HTTP Header Size Limits: A single ML-DSA-65 JWT produces an Authorization: Bearer <token> header of approximately 4.5–5 KB. Many reverse proxies (Nginx, Apache, cloud ALBs) default to 4 KB or 8 KB header line buffer limits, which may require configuration tuning to accommodate larger tokens.

  2. Hybrid and Dual Signature Modes: During the multi-year transition period, many implementations use composite or hybrid modes (for example, EdDSA + ML-DSA) to ensure compliance with both classical FIPS requirements and quantum-safety standards simultaneously.

Kind Regards,
Nik