Post-quantum signatures join M7 Identity

M7 Identity now offers 15 signing profiles for ID tokens, including the post-quantum ML-DSA-44, ML-DSA-65, and ML-DSA-87 profiles standardized by NIST. It gives developers a practical new choice: use the signing profile their application is ready to verify today, while gaining a clear route to explore post-quantum signatures when their stack is ready.

A signature is part of how an ID token earns trust

An ID token carries identity claims from M7 to an application. As one part of verifying it, the application checks its signature against keys from the expected issuer; it also validates the token’s claims for its own integration. That signature helps show that the signed token content came from M7 and has not been altered on the way.

M7’s discovery documents and signing keys now advertise all 15 ID-token profiles. The classical families include RSA choices such as RS256, RSA-PSS, ECDSA such as ES256, and Edwards signatures such as Ed25519; the provider profile lists every profile and its matching key material.

A path toward post-quantum signing

The three ML-DSA choices are a meaningful addition because public-key cryptography has a long future. Large-scale quantum computers could eventually weaken some classical public-key methods, so having standardized post-quantum signatures available gives teams something concrete to evaluate before a transition becomes urgent. NIST describes ML-DSA in FIPS 204; M7 uses it here as a digital signature for ID tokens, protecting signed token authenticity and integrity rather than encrypting the token.

Opting in stays explicit. Registrations without id_token_signed_response_alg keep the existing RS256 default. When a registration selects an ID-token profile, its ID tokens and matching provider keys use that exact algorithm. Your verifier must support both the selected algorithm and its JWK key type—for example, AKP for ML-DSA—not merely a generic JWT setting.

Trying it today

M7 Identity SDK source can verify the additional profiles with the optional m7crypto capability, while existing published SDK ZIPs remain unchanged until an artifact explicitly adds support. ML-DSA is tested in device/native and machine JSON-response paths. It is not currently suitable for the Web/PHP SDK’s full-token-cookie integration, where the larger signatures can exceed browser cookie limits as token claims grow. The browser-storage guidance explains the boundary.

For many teams, RS256 remains the sensible starting point. For applications with a compatible verifier and delivery path, M7 now offers a deliberate next step: choose the signing profile that fits your application today, and a path to evaluate post-quantum signatures when it is useful.