Post-quantum signatures join M7 Identity

M7 Identity now offers 15 asymmetric 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 describe the 15 asymmetric profiles alongside three HMAC profiles for eligible confidential clients, bringing the documented total to 18. See the HMAC setup guide for that separate shared-secret option. 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 asymmetric 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

Token/PHP 0.1.4 includes the optional verifier for the additional asymmetric profiles, including ML-DSA, with a compatible m7crypto extension and backend required for those profiles. The SDK download and compatibility guides help you choose a released package and supported runtime; older published archives remain immutable. 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.