SEP: Support software_statement and jwks_uri in Dynamic Client Registration for MCP

[knguyen-figma]

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

Loading

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.

[localden]

This might be superseded by #991? @aaronpk @pcarleton

[pcarleton]

@localden a short-lived, signed statement would still be useful for localhost clients, e.g. #991 might want to incorporate a software statement into it as well

[jaredhanson]

Is it true that the jwks_uri in the registration request contains the keys used to verify the software statement?

I had always assumed that the jwks_uri was the client's set of of keys. The software statement is signed by the vendor, which has a completely independent set of keys, which would be resolved by following metadata from the iss value in the software statement itself.

The DCR specification does not provide a lot of detailed guidance around software statements, so I think there a lot of details that need clarification.

[aaronpk]

There's definitely a lot of dots to connect to get this right. One other building block in OAuth is this in progress draft:

https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/

I am planning on writing up a description of how to connect the dots between a client's keys (whether from DCR or a CIMD) to the attestation backend to solve this.

[jaredhanson]

Thanks @aaronpk! Let me know if you want to collaborate on the writeup. I'm looking to prototype an implementation, and could feed back learnings from that process.

[JohnBergant]

Since this Software Statement is essentially a Bearer Token it would allow any running process on localhost to present itself as a legitimate client. It is a common risk in all these flows when dealing with localhost.