Preamble

Title: Support software_statement and jwks_uri in Dynamic Client Registration for MCP
Author: Khanh Nguyen (@knguyen-figma)
Status: Proposal
Type: Standards Track
Created: 2025-07-22

Abstract

This SEP proposes an enhancement to the MCP Dynamic Client Registration (DCR) flow by recommending support for two fields defined in RFC 7591: software_statement and jwks_uri. This change introduces a standardized, cryptographic mechanism for identifying and verifying client software during registration, which would improve trust, accountability, and vendor-specific policy enforcement across the MCP ecosystem.

Motivation

The current DCR mechanism in MCP lacks a reliable way to verify the authenticity of registering clients. This leads to several operational and security challenges:

• Authorization servers cannot distinguish between legitimate and malicious MCP clients.
• There's no cryptographic way to verify that a client was created by a trusted vendor.
• It is difficult to audit or group clients by software origin.
• Vendor-specific controls such as rate limiting, allowlisting, or feature gating are hard to implement reliably.

Introducing signed software_statements and jwks_uri fields addresses these gaps by creating a verifiable chain of trust back to the software vendor.

Specification

MCP clients and authorization servers SHOULD support software_statement and jwks_uri fields during DCR, as defined in RFC 7591 Section 3.1.1.

• software_statement is a signed JWT (RFC 7519) containing client metadata, software ID/version, and expiration.
• jwks_uri is a URL to a JSON Web Key Set (RFC 7517) that provides the public keys needed to verify the JWT.

DCR Flow:

sequenceDiagram
    participant C as MCP Client
    participant CB as Software Vendor Server
    participant A as Authorization Server

    Note over C,CB: Software Statement Preparation
    C->>CB: Request software_statement JWT
    Note over CB: Generate JWT with claims:<br/>- client metadata<br/>- software ID<br/>- software version<br/>- expiration
    CB-->>C: Signed software_statement JWT

    Note over C,A: Dynamic Registration
    C->>A: POST /register<br/>software_statement + jwks_uri
    A->>CB: GET /mcp/jwks.json
    CB-->>A: JWKS document
    Note over A: 1. Validate software_statement<br/>2. Verify JWT signature using JWKS<br/>3. Check issuer trust<br/>4. Validate claims & expiry
    A-->>C: Client credentials

Rationale

Adding support for software statements:

• Promotes consistent client identification: Allows grouping of registrations by software vendor or product.
• Enables trust and auditing: Vendors can assert their identity cryptographically and servers can audit which clients are in use.
• Facilitates vendor-specific policies: Rate limits, feature flags, or security controls can be applied more effectively.

Other approaches considered:

• Manual allowlisting or pre-registration: Higher operational cost, less scalable.
• Client-side fingerprinting or static identifiers: Unreliable and insecure.

This proposal uses well-established standards (JWT, JWKS) and is compatible with existing OAuth DCR workflows.

Backward Compatibility

This is a non-breaking, opt-in enhancement. Clients and servers that do not support the fields will continue to function as before. There is no requirement to reject clients who omit software_statement or jwks_uri.

Reference Implementation

Reference server implementation: mcp-auth-server-software-statement

Tested via updated @modelcontextprotocol/inspector to generate software statements and host JWKS endpoints.

PR with spec updates: #883

Security Implications

This enhancement improves security posture by:

• Preventing unauthorized client registrations via cryptographic verification.
• Allowing trusted vendors to sign and attest to the origin of client software.
• Enabling detection of impersonation or unauthorized forks.

Authorization servers must ensure:

• Trusted management of jwks_uri allowlists.
• Proper validation of JWT signatures and claims.