SEP 1380: Client Credential Manager

Title: MCP Client Credential Manager

Author(s): Nick Steele, nick.steele@agilebits.com

Status: Proposal

Type: Standards-Track

Base Spec Version: 2025‑08‑20

Abstract

This proposal defines a credential management service that provides an interface for an MCP agent and client to make and manage credentials. Currently, credentials and tokens that an agent might need are stored in a non-normative manner, and can potentially introduce additional risk through insecure storage and management. By introducing a specific profile for this service, users and enterprises can have more transparency and control over the credentials that need to be provided for an agent to access resources through OAuth or other authorization services.

Motivation

Issues with Management

While the Model Context Protocol specification describes how to handle authentication and authorization through OAuth2, there is little guidance on how best to manage the credentials and tokens that must be used by users and agents to establish access, authorization, and delegation. The current protocol leaves the management of credentials to the MCP Host to manage their lifecycle, but we’ve seen two large problems with this:

1. The MCP Host often has no attestable guarantees about the lifecycle of the credentials it needs.
2. In practice, both the host and client have access to the credentials that a client might need to connect to a server, and other services are potentially capable of requesting them from a client, again because there's no guarentees around management.

Issues with Scalability

Currently, MCP authentication and authorization favors OAuth as the primary means of establishing secure access to tools and resources, however this might not always be the case. Other types of credentials will eventually be used by agents for require credentials that aren't just for the web. These types of credentials, such as Verifiable Digital Credentials

Proposed Solution: Client Credential Manager

The service we wish to define is provided to the MCP Client through direct integration or through an API, and allows them to offset the management of access credentials needed by the agent to a storage layer that is trusted by the user and/or enterprise. While the invocation of the Credential Manager might not be in scope for the MCP specification, the initialization is relevant.

Initialization

This first part is fairly similar to what @dickhardt proposes in #SEP-1299 except

The credential manager would be assigned a key pair for the server

  {
  "kty": "OKP",
  "crv": "Ed25519",
  "x": "base64url-encoded-public-key",
  "d": "base64url-encoded-private-key"
  }

Simialr to 1299, we can leverage simialr patterns in SEP 1289 to better authenticate and authorize the credential manager for a relying party.

Clients SHOULD pass the following additional fields in the initialize request parameters:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    ...
    "clientInfo": {
      "name": "MCP Client",
      "title": "MCP Client Display Name",
      "version": "1.0.0"
    }
    // New fields 
    "credentialManager": {
        "name": "BotWarden",
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "base64url-encoded-public-key",
      }
  }
}

If these parameters are included the server SHOULD check the authenticity of the credential manager, using similar flows described by #1289 and #1299, or by responding with an endpoint to verify the public key which can then be cached.

Related Work

Related work for reference might look something like what’s available in Android through KeyStore or Apple through CryptoKit, and how they both provide and facilitate credential management today. When looking towards relevant specifications and standards, we might want to look towards WebAuthn and CTAP2, the two standards that make up the FIDO2 authentication framework, along with the Digital Credential API being developed in the Federated Identity WG of W3C.

Backward Compatibility

This change should be backwards compatible with the current state of OAuth usage in MCP and will not be a breaking change for any existing implementations of MCP clients.

Reference Implementation

Not available at this time

Security Implications
This proposal moves the attack surface and risk of credential misuse and exfiltration to a piece of software or hardware that is ideally designed to defend against these issues first and foremost. However, it’s worth noting that this proposal makes no guarantees about the security and architecture of the credential manager, leaving discretion to the user and/or their organization that wants more assurance around credential management.

Diagrams and Examples

Diagrams pending internal review