M7 provider capability card

Status: Release-candidate summary
Derived from: M7 OAuth 2.0 and OpenID Connect Provider Profile
Last reviewed: 2026-09-16

This is the short compatibility card for the M7 authorization server. The provider profile is normative; live discovery is authoritative for endpoints and currently advertised feature sets.

Category Capability Status
Discovery OpenID Connect and OAuth authorization-server metadata Supported
Browser authorization Authorization code with mandatory PKCE S256 Supported
Plain authorization responses query, form_post, fragment Supported, advertised and live-tested
Signed authorization responses query.jwt, form_post.jwt, fragment.jwt, jwt; RS256/RS512 JARM Supported, advertised and live-tested; signed, not encrypted
Web Message responses web_message.opener, web_message.parent, web_message Supported and advertised; popup and approved-origin iframe live checks passed
Back-channel authorization PAR with HTTP 201 response Supported
Signed authorization requests JAR by value or registered HTTPS URI; RS256, RS384, RS512, ES256 Supported at /authorize; per-client opt-in
Consumer email sign-in Magic link and one-time code in one message; original-browser confirmation and optional email 2FA Supported; email sign-in
Consumer two-factor authentication Independent TOTP checks for password login, email sign-in, Device Code approval, and account/session reuse; recovery codes and unlink options Supported; user-configurable behavior
Device sign-in OAuth Device Authorization Grant Supported
Machine access client_credentials for confidential clients Supported
Refresh Rotating user refresh-token lineage Supported
Public clients none authentication with PKCE and revocation Supported
Secret authentication Basic, POST, and HMAC JWT (HS256/384/512) Supported
Asymmetric authentication Private-key JWT (RS256/384/512, ES256) Supported
ID tokens 18 signing profiles: 15 asymmetric plus HS256/384/512 Issuance accepted; all 18 profiles deployed and advertised, verified from both discovery URLs
HMAC token signing HS256/384/512 for confidential clients with a recoverable client secret Client credentials, device/strict refresh and browser login/profile/refresh accepted; none eligibility restriction locally tested, deployment verification pending; setup and advertisement
Personal signing keys Separate access/refresh lineage keys for all 15 asymmetric profiles Device issuance and strict refresh live-tested
M7 Identity SDK 15 asymmetric profiles with explicit allowlist and compatible key resolution Updated source accepted; additional profiles require m7crypto; existing ZIPs unchanged
Post-quantum browser sessions ML-DSA with the current Web SDK token cookies Not ready; cookie/storage redesign required; device/native crypto paths accepted
UserInfo JSON, signed RS256, or signed RS512 Supported
Sender constraint RFC 9449 DPoP using ES256 Supported and advertised
Token state Confidential-client introspection Supported
Revocation Public and confidential client revocation with opaque HTTP 200 response Supported
Logout RP-initiated end-session flow with exact registered return URI Supported
Registration Authenticated Dynamic Client Registration Supported; resource audience assignment remains administrative
Rate limiting OAuth 429 response with Retry-After and rolling quiet-period recovery Supported
Mutual TLS RFC 8705 tls_client_auth, self_signed_tls_client_auth, dedicated endpoint aliases, and certificate-bound tokens Supported and advertised
OpenID certification Official conformance-suite result Pending; no certification claim

The RC4 provider profile lists every algorithm. Third-party integrations need support for the exact selected algorithm and key type. At 2026-09-15 21:49:24 UTC, both live metadata documents returned identical metadata advertising all 18 ID-token profiles, including HS256, HS384 and HS512. Public JWKS covered all 15 asymmetric profiles and contained no symmetric material. HMAC has no public key entry. Follow the verified discovery contract and live discovery when selecting algorithms.

Both discovery documents also advertise all ten response modes and JARM RS256/RS512 signing, verified at 2026-09-15 06:24 UTC. Each mode passed direct authorization, PAR and cancellation. Flexible web_message passed in both popup and iframe form. Iframe use requires provider-approved origins; fresh password sign-in passed, while remembered-session reuse and iframe MFA, email, federation and consent denial were not established by those checks. See response modes for client configuration and browser requirements. Updated SDK source supports these modes; existing downloads were not rebuilt for this increment.

Intentionally outside the current profile

  • implicit and hybrid flows;
  • PKCE plain;
  • JAR submitted to /par or configured through Dynamic Registration;
  • encrypted Request Objects and encrypted JARM responses;
  • JWE-encrypted ID tokens and UserInfo;
  • OAuth Token Exchange;
  • DPoP nonces;
  • public-client introspection; and
  • automatic Dynamic Registration authority packs.

For exact statuses, response shapes, algorithms, audience rules, DPoP challenges, and release limitations, use the full provider profile.