]> Cisco

snandaku@cisco.com

Cisco

flufy@cisco.com

Security agent-to-agent model context protocol personal agent protocol selective disclosure JWT privacy identity management This document defines SD-Card, an SD-JWT encoding of AI agent metadata that lets an agent reveal to each verifier only the capabilities, endpoints, and security requirements it is authorized to see, while the verifier can check that they are authentic and issuer-attested. SD-Card keeps agent metadata confidential; it does not make agents anonymous. The document specifies the SD-Card data model, issuance, discovery, and key-bound presentation, and defines bindings for the Model Context Protocol (MCP), the Personal Agent Protocol (PAP), and the Agent2Agent (A2A) protocol.

Introduction Agent ecosystems publish machine-readable metadata so that clients can discover what an agent or service does and how to reach it. The Model Context Protocol (MCP) exposes server information and lists of tools, resources, and prompts for agent-to-tool interaction. The Personal Agent Protocol (PAP) has Companies publish a discovery document for the personal agents that act for their customers. The Agent2Agent (A2A) protocol defines Agent Cards for agent-to-agent interaction. Other agent frameworks and registries define similar documents. These documents have the following limitations:

1. Information Leakage: A metadata document reveals all of an agent's capabilities, endpoints, and security requirements to anyone who retrieves it, which also lets attackers enumerate them.
2. Limited Authentication: Signing of metadata is optional (A2A) or absent (MCP), covers the whole document so it cannot be combined with selective disclosure, does not prove that the presenter holds the signing key, and conveys no third-party attestation beyond control of a domain. Nothing prevents an MCP server from changing tool descriptions after a client has approved them.
3. Static Disclosure: Every client receives the same document; an agent cannot vary what it reveals with the client's authorization.
4. Requester Exposure: Clients reveal which agents they are looking for to every server and registry they query.

This document specifies SD-Card, an SD-JWT encoding of agent metadata. An Agent Registry attests an agent's metadata once. The agent then reveals to each verifier only the claims that verifier is authorized to see, and proves possession of the key bound to the SD-Card. The verifier checks that each disclosed claim is attested by the issuer and unmodified. A client that only needs to show that it is authorized for a discovery context can do so without identifying itself, using Privacy Pass . Agents and clients that do not support SD-Card continue to use the native metadata documents. The privacy that SD-Card provides is confidentiality of agent metadata toward verifiers: each verifier learns only the claims disclosed to it. SD-Card does not hide the agent's identity, which is always disclosed, and presentations of the same SD-Card can be linked. Separate SD-Cards with different keys reduce this correlation (). The core of this document is independent of any agent protocol. It covers the architecture (), the SD-Card data model (), issuance (), discovery (), presentation and verification (), and use with OAuth and workload identity (). Protocol Bindings () map the metadata document of a specific protocol onto the core. This document defines bindings for MCP (), PAP (), and A2A (); other specifications can define additional bindings following .

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Agent: Software that acts autonomously on behalf of a user or organization and exposes an interface to clients. In this document the term also covers other holders of SD-Cards, such as MCP servers that expose tools to agents and PAP Companies. Native Metadata Document: The metadata document defined by an agent protocol to describe an agent, for example an A2A Agent Card or the server information and tool lists of an MCP server. SD-Card: An agent's metadata encoded as an SD-JWT VC, as defined in this document, that enables selective disclosure of that metadata. Protocol Binding: A specification that defines how the Native Metadata Document of a particular agent protocol is represented as an SD-Card, how it is discovered, and how it is presented within that protocol. Agent Registry: A trusted service that issues SD-Cards for agents within a domain or federation. Verifier: A party that receives and verifies an SD-Card presentation, such as a client, a PAP Company, or an authorization server. Discovery Context: A named level of authorization, such as "public" or "internal", that determines which claims an SD-Card presentation discloses (). Key Binding: Cryptographic proof that the presenter of an SD-Card possesses the private key corresponding to the public key in the SD-Card's cnf claim.

Notational Conventions This document follows SD-JWT conventions:

• Base64url encoding for binary data
• JWS for signed tokens
• SHA-256 as the default hash algorithm for selective disclosure
• Tilde (~) separator for SD-JWT serialization, where the Key Binding JWT is present only in key-bound presentations:

~~...~~[] ]]>

Architecture SD-Card involves three roles. An Agent Registry is the issuer, the agent is the holder, and a verifier is any party that relies on the agent's metadata:

SD-Card Roles and Flows | (Holder) | +------------------+ (2) Issue SD-Card +------------------+ ^ | | (3) Discover | (4) Present | (registry query, or | selected | well-known URI of the agent) | disclosures | | + Key Binding | v | +------------------+ +--------------------------------| Verifier | +------------------+ ]]>

1. Register: The agent gives the Agent Registry its Native Metadata Document and the public key it will use for key binding, and the registry verifies the agent's identity and its authority to claim the metadata ().
2. Issue: The registry issues an SD-Card that encodes the metadata according to the Protocol Binding, with the agent's key in cnf.
3. Discover: A verifier finds the agent through a registry query or the agent's well-known URI, and receives a presentation with the disclosures of the discovery context it is authorized for ().
4. Present: When the verifier interacts with the agent, the agent presents its SD-Card within the protocol with a Key Binding JWT for that verifier, and the verifier checks it ().

The architecture is the same for every Protocol Binding; bindings differ only in the claims carried and in how discovery and presentation are mapped onto the protocol.

SD-Card Data Model An SD-Card is an SD-JWT VC , and therefore an SD-JWT , whose payload carries an agent's metadata. The typ header parameter of its issuer-signed JWT MUST be dc+sd-jwt. In HTTP, an SD-Card presentation is carried in compact serialization with the application/dc+sd-jwt media type . Its payload contains:

1. Core Claims: Always disclosed claims, defined in , that establish the issuer, the agent's identity, the Protocol Binding in use, validity, and the confirmation key
2. Binding Claims: Claims defined by a Protocol Binding that carry the content of the Native Metadata Document. Each binding states which of these are always disclosed and which are selectively disclosable

Core Claims The following claims MUST be present and MUST NOT be selectively disclosable in any SD-Card:

iss:

The issuer of the SD-Card (typically an Agent Registry). This establishes the trust anchor for the credential and enables signature verification. The issuer MUST be an HTTPS URI, and verifiers obtain its public keys as described in , for example from its JWT VC Issuer Metadata.

sub:

The unique identifier of the agent within the issuer's namespace, or the agent's workload identifier (). This identifier MUST be stable across different SD-Card issuances for the same logical agent, so it is a correlation handle for every verifier that sees it.

iat:

The time at which the SD-Card was issued (Unix timestamp).

exp:

The expiration time of the SD-Card (Unix timestamp).

vct:

The verifiable credential type. Each Protocol Binding defines one or more vct values of its own, so this claim identifies both that the token is an SD-Card and which binding defines the remaining claims. Verifiers MUST reject an SD-Card whose vct value does not identify a binding they support. vct values are URNs of the form urn:ietf:params:sd-card:<binding>:<type>. These URNs identify a type; they cannot be dereferenced. A verifier that needs SD-JWT VC Type Metadata for a vct value obtains it out of band, for example from the binding specification or from a local cache.

cnf:

The confirmation key for agent authentication, in JSON Web Key (JWK) format. A presentation with a Key Binding JWT signed with this key shows that the presenter is the agent ().

The following claims SHOULD be present and, when present, MUST NOT be selectively disclosable. A binding maps them to the corresponding fields of its Native Metadata Document:

name:

The human-readable name of the agent.

description:

A brief description of the agent's purpose and primary function. This helps users understand the agent's role without revealing sensitive capability details.

version:

The version of the agent software.

The following example shows the core claims of an SD-Card. The binding claims, and the digests of the selectively disclosable ones in _sd, are defined by the binding named by vct: ", "_sd_alg": "sha-256", "_sd": [ "" ], "name": "Example Agent", "description": "An example agent", "version": "1.0.0", "cnf": { "jwk": "" } } ]]>

Common Claim Categories Agent protocols describe broadly the same kinds of information under different names. To keep disclosure policies portable across bindings, each binding assigns each of its claims to one of the following categories in its claim mapping table (for example, A2A skills, MCP tools, and PAP apis are all Capabilities). Policies (see ) can then be expressed per category and applied to an agent regardless of protocol. Claim Categories

Category	Describes
Capabilities	Operations the agent offers
Endpoints	Where and how the agent is reached
Protocol Features	Optional protocol features supported
Security Requirements	How clients authenticate, and attested security properties
Provider	The operating organization
Content Modes	Accepted and produced media types
Documentation	Human-oriented information

Claims in the Capabilities, Endpoints, Protocol Features, Security Requirements, and Provider categories are the main subjects of selective disclosure.

Selective Disclosure Processing Selectively disclosable binding claims are processed as defined in . For each such claim the issuer:

1. Generates a cryptographically secure random salt. A fresh salt MUST be used for every disclosure; salts MUST NOT be reused across claims or across SD-Cards.
2. Creates a disclosure array: [salt, claim name, claim value] for an object property, or [salt, value] for an array element.
3. Base64url-encodes the JSON serialization of the disclosure.
4. Computes the digest of the encoded disclosure using the hash algorithm named in _sd_alg.
5. Places the digest in the _sd array of the containing object, or, for an array element, replaces the element with {"...": digest}.

At presentation time, the holder includes only the disclosures permitted for the context.

Disclosure granularity:

Claims whose value is a list of capabilities (such as A2A skills or MCP tools) MAY be made selectively disclosable as a whole, or per element. Per-element disclosure allows an agent to reveal individual capabilities to a verifier and SHOULD be used when different contexts are expected to see different subsets of the list.

Decoy digests:

Issuers MAY add decoy digests as described in to hide the number of selectively disclosable claims or capabilities.

SD-Card Issuance Agent Registries issue SD-Cards. Before registration, an agent is provisioned by its operator or deployment platform with a key pair for cnf, a credential that identifies it to the registry (for example, an OAuth client credential or a WIMSE Workload Identity Token ), and its Native Metadata Document, published at an origin the operator controls. How these are provisioned, how a registrant discovers a registry's registration endpoint, and the registry's vetting policy are out of scope for this specification. The registrant requests an SD-Card with a registration request (). The issuer processes it as follows:

1. The issuer MUST verify that the registrant possesses the private key for the public key in the request's cnf member ().
2. The issuer MUST authenticate the registrant with its credential, of whatever type the issuer accepts, and derive sub from the identity that credential establishes: for example, a WIMSE identifier (), an OAuth client_id , or a client identifier URL .
3. The issuer MUST obtain the Native Metadata Document as the binding's Source Document retrieval rules specify (), and MUST verify that the registrant controls each origin whose endpoints the SD-Card will contain. Retrieving a document from an origin shows only that it is published there, not that the registrant published it. The issuer can verify control by:
   • an identity bound to the origin, such as a client identifier URL at that origin;
   • a challenge, such as the ACME "http-01" or "dns-01" challenge , in which the registrant publishes an issuer-supplied value at the origin or in its DNS zone; or
   • the Native Metadata Document at the origin containing the cnf key or the identity authenticated in step 2.
   The issuer MUST NOT include in an SD-Card endpoints at origins the registrant has not been shown to control.
4. The issuer creates the SD-Card according to the Protocol Binding named in the request, which MUST be one the issuer supports. It takes claim values only from the document obtained in step 3, as the binding's Claim Mapping specifies, and MUST NOT attest values the registrant supplies in any other way.
5. The issuer grants each requested discovery context only the disclosures that the binding's Claim Mapping makes selectively disclosable and that its own policy allows, and returns the SD-Card and the granted contexts ().

Each SD-Card has one cnf key. Issuing several SD-Cards with different keys, for example one per discovery context, reduces linkability only when each SD-Card is presented to one verifier; a registrant obtains them with one registration request per key. An agent that is reachable over more than one protocol (for example, an agent that offers an A2A interface and also operates an MCP server) registers once per binding and receives a separate SD-Card for each. Issuers MAY use the same sub value in those SD-Cards to allow authorized verifiers to correlate them, or different values to prevent such correlation.

Registration Request A registrant sends an HTTP POST request to the registry's registration endpoint over HTTPS . The request body is a JSON object with the media type application/json and the following members:

binding:

REQUIRED. The name of a Protocol Binding ().

vct:

OPTIONAL. The vct value of the requested SD-Card. REQUIRED when the binding defines more than one vct value.

metadata_url:

REQUIRED unless metadata is present. An HTTPS URL from which the issuer retrieves the Native Metadata Document. Its meaning is defined by the binding; for example, the A2A binding uses the URL of the Agent Card.

metadata:

OPTIONAL. The Native Metadata Document, supplied by value. A registrant MUST NOT use this member unless the binding permits it, and an issuer MUST reject it otherwise. Exactly one of metadata_url and metadata MUST be present.

cnf:

REQUIRED. A confirmation method as in containing a jwk member with the public key to be placed in the SD-Card's cnf claim.

disclosure_contexts:

REQUIRED. A non-empty array of JSON objects, each with the following members:

context:

REQUIRED. The name of a discovery context (). Each name MUST appear at most once.

disclose:

REQUIRED. An array of claim paths identifying the selectively disclosable claims that presentations for this context disclose. A claim path is a non-empty array as defined for claim metadata in : a string selects an object member, a non-negative integer selects an array element, and null selects all elements of an array. Paths use SD-Card claim names and index arrays in the order of the Native Metadata Document. Always disclosed claims are not listed.

The issuer MUST ignore members it does not understand.

Registration Authentication The registrant authenticates with any credential the issuer accepts, typically an OAuth access token in the Authorization header. It MUST also prove possession of the cnf key. With an OAuth access token, the registrant does so with a DPoP proof whose jwk header parameter is the cnf key, and the access token is bound to that key. Other credentials MAY use their own proof-of-possession mechanism; for example, a registrant that authenticates with a WIMSE Workload Identity Token whose confirmed key is the cnf key uses a WIMSE Proof Token (). The issuer MUST reject the request if the key whose possession is proven is not the key in cnf.

Registration Response On success, the issuer returns HTTP status 200 (OK) with a JSON object with the media type application/json and the following members:

sd_card:

REQUIRED. The SD-Card in compact serialization , with all of its disclosures and without a Key Binding JWT.

disclosure_contexts:

REQUIRED. The granted discovery contexts, in the format of the request member of the same name. A context or claim path that was requested but not granted is omitted.

The agent uses the granted disclosure_contexts to select the disclosures it presents in each context. When the registry also serves discovery requests for the agent (), it uses the same contexts. On failure, the issuer returns HTTP status 400 (Bad Request), 401 (Unauthorized), or 403 (Forbidden) with a JSON object containing an error member and, optionally, an error_description member with human-readable text. This document defines the following error values:

invalid_request:

The request is malformed or is missing a required member.

invalid_proof:

The registrant did not prove possession of the cnf key.

unsupported_binding:

The issuer does not support the binding or vct value.

invalid_metadata:

The issuer could not retrieve the Native Metadata Document, or the document is not the binding's Source Document.

origin_not_verified:

The issuer could not verify that the registrant controls an origin whose endpoints the SD-Card would contain.

Registration Example In the following example, an A2A agent authenticates with a DPoP-bound access token and asks the registry to retrieve its Agent Card. Public clients see only its first skill and first interface; internal and diagnostic clients see more: DPoP: { "binding": "a2a", "metadata_url": "https://georoute-agent.example.com/.well-known/agent-card.json", "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "NRV8L0GsHzQL4auGECf1EuQAAbWQDnZPp_rY1Iopvn0", "y": "uTOlnJ2S83z6DM7r0_pvVemMtsefFm-Lk4oiwHNbF5o" } }, "disclosure_contexts": [ { "context": "public", "disclose": [ ["skills", 0], ["supportedInterfaces", 0], ["defaultInputModes"], ["defaultOutputModes"] ] }, { "context": "internal", "disclose": [ ["skills", null], ["supportedInterfaces", null], ["defaultInputModes"], ["defaultOutputModes"], ["capabilities"], ["provider"], ["securitySchemes"], ["securityRequirements"] ] }, { "context": "diagnostic", "disclose": [ ["skills", null], ["supportedInterfaces", null], ["defaultInputModes"], ["defaultOutputModes"], ["capabilities"], ["provider"], ["securitySchemes"], ["securityRequirements"], ["documentationUrl"], ["iconUrl"] ] } ] } ]]> The registry grants all three contexts and returns the SD-Card (line breaks for display only): . ~~~...~", "disclosure_contexts": [ ... as requested ... ] } ]]>

Agent Discovery This section describes the protocol-independent mechanisms for discovering agents. Each binding defines the concrete well-known locations and query terms for its protocol.

Well-Known URI Discovery This document defines a protocol-independent well-known URI for retrieving SD-Cards: where {binding} is the name of a Protocol Binding (). A client retrieves the SD-Card of an agent at an origin with an HTTP GET request to this path, including application/dc+sd-jwt in the Accept header. A successful response has that media type , and its body is an SD-Card presentation in compact serialization with the disclosures appropriate for the requester. A binding MAY define query parameters that select among several agents hosted at the same origin. A client MAY include aud and nonce query parameters. When both are present, the presentation MUST include a Key Binding JWT whose aud and nonce claims equal them. Without them, the presentation carries no Key Binding JWT (). Where a protocol already defines a well-known URI for its Native Metadata Document, the binding MAY additionally specify that the SD-Card is returned from that URI through content negotiation: clients signal support by including application/dc+sd-jwt in the Accept header, and servers that do not support SD-Card return the Native Metadata Document. See for an example. An agent MAY return additional disclosures to clients that are authorized for a richer discovery context ().

Registry Query Agent Registries answer queries that name a binding and use the claim names of that binding. This document does not define a query protocol; the following illustrative query asks for A2A agents with the skill "route-optimizer-traffic" that support streaming: { "binding": "a2a", "query": { "skills": ["route-optimizer-traffic"], "capabilities": { "streaming": true } }, "context": "internal", "max_results": 10 } ]]> A query can instead use the claim categories of (for example, "categories": {"Capabilities": ["geocode"]}) to search across bindings. The registry returns an SD-Card presentation for each matching agent, with the disclosures of the requested context.

Discovery Contexts A discovery context determines which claims a presentation discloses. Contexts are expressed in terms of the claim categories of , so that a policy applies to agents of every binding. This document uses the following contexts; deployments MAY define others: Discovery Contexts

Context	Intended for	Disclosed Categories
public	Any client	Core claims, selected Capabilities, public Endpoints, Content Modes
internal	Clients in the operator's organization	All public + remaining Capabilities and Endpoints, Protocol Features, Provider, Security Requirements
diagnostic	Operators troubleshooting the agent	All internal + Documentation
federation	Partner organizations	As set by the federation agreement

A request, such as the context member of a registry query, names a context but does not prove that the requester may use it. The agent or registry MUST determine from the requester's credential, such as a bearer token or a Privacy Pass token (), whether the requester is authorized for the context, and MUST NOT return disclosures of a context the requester is not authorized for.

Anonymous Authorization with Privacy Pass Authorizing a requester for a discovery context usually means authenticating it, which tells the agent or registry which client is looking at which agents. Where the agent or registry only needs to know that the requester is authorized, it SHOULD use Privacy Pass instead of client authentication. In this deployment, the agent or Agent Registry acts as the Privacy Pass Origin, and each discovery context other than public has its own Privacy Pass Issuer key. An Attester admits a client to a context, for example by checking membership in the operator's organization or a federation agreement, and the Issuer then issues tokens for that context. Because the Issuer key identifies the context, the token conveys the context without identifying the client. The Origin requests a token with the PrivateToken HTTP authentication scheme : ", token-key="" ]]> and the client presents it on the discovery request: " ]]> An Origin MAY send one challenge for each context it supports, and returns the disclosures of the context whose token it receives. Tokens MAY be of the privately verifiable or publicly verifiable issuance protocol . The challenge SHOULD carry a fresh redemption context so that a token cannot be replayed to obtain disclosures elsewhere. The same exchange applies to the registry query of , with the PrivateToken scheme in place of the bearer token. Privacy Pass hides the identity of the requester from the Origin. It does not hide the agent from the requester: the SD-Card returned is still bound to the agent's sub and cnf key.

Presentation and Verification An agent proves that it holds an SD-Card by adding a Key Binding JWT to its presentation. The verifier supplies the audience and nonce for the Key Binding JWT; each binding specifies how they are supplied and where the presentation is carried in its protocol. gives a complete example.

Presentation The agent presents its SD-Card as an SD-JWT , in the serialization of , containing the issuer-signed JWT, the disclosures for the context, and a Key Binding JWT.

Key Binding JWT The Key Binding JWT is as defined in : its typ header parameter is kb+jwt, it is signed with the cnf key, and its payload contains iat, aud, nonce, and sd_hash. The verifier supplies aud and nonce. aud identifies the verifier. nonce MUST be a fresh random value with at least 128 bits of entropy, base64url-encoded, unless a binding takes it from an existing protocol value of equivalent freshness. This document additionally defines the OPTIONAL interaction_id claim. Its value is chosen by the agent and identifies the interaction, so that the agent and verifier can correlate the presentation with later requests for audit.

Verification The verifier:

1. Checks that typ is dc+sd-jwt, that vct identifies a binding it supports, that the issuer is trusted, through a pre-established trust relationship, for that binding, and validates the issuer's signature.
2. Checks that each disclosure's digest appears in the issuer-signed payload, and rejects the SD-Card if a disclosure carries the name of a core claim ().
3. Checks that the Key Binding JWT typ is kb+jwt, validates its signature with the cnf key, and checks sd_hash.
4. Checks exp of the SD-Card, and rejects the Key Binding JWT if its iat is outside a window the verifier sets, for example 5 minutes.
5. Checks that the Key Binding JWT aud identifies the verifier and that its nonce equals the value the verifier supplied.

A presentation without a Key Binding JWT, such as one retrieved from a well-known URI without aud and nonce, proves the integrity of the disclosed claims but not that the presenter is the agent, since anyone who obtained it can present it. Verifiers that rely on the agent's identity MUST require a Key Binding JWT.

Use with OAuth and Workload Identity

OAuth Token Exchange When an agent acting for a user or an upstream agent needs a token to call a discovered agent, it MAY use OAuth 2.0 Token Exchange and present its own SD-Card as the actor token. This document defines the token type identifier urn:ietf:params:oauth:token-type:sd-card for an SD-Card presentation that includes a Key Binding JWT: &subject_token_type=urn:ietf:params:oauth:token-type:access_token &actor_token= &actor_token_type=urn:ietf:params:oauth:token-type:sd-card &requested_token_type=urn:ietf:params:oauth:token-type:access_token &audience=agent:georoute-planner-v1 &scope=route-optimizer-traffic ]]> The Key Binding JWT of the actor token MUST have an aud equal to the issuer identifier of the authorization server, and a nonce supplied by the authorization server, for example as a DPoP server-provided nonce . The authorization server:

1. Validates the subject token as requires.
2. Verifies the actor token as described in , including that its issuer is trusted for the binding named by vct.
3. Applies its policy to the disclosed claims, for example accepting only actors whose disclosed provider or security properties meet its requirements. The actor discloses only the claims the authorization server needs.
4. Identifies the actor in the issued token with an act claim whose sub and iss are the sub and iss of the SD-Card.

If the request carries a DPoP proof, its key MUST be the SD-Card's cnf key, so that the issued token is bound to the same key that the actor proved possession of. The audience of the request MAY be the sub of the target agent's SD-Card, and the authorization server MAY restrict the requested scope to capabilities that the target agent's SD-Card discloses.

Workload Identity WIMSE gives a workload, including an agent , an identifier and a Workload Identity Token (WIT) issued by its trust domain, and lets it prove possession of the WIT key with a WIMSE Proof Token . A WIT says which workload a request comes from. An SD-Card says what that workload offers and is attested by an Agent Registry, which may be in a different trust domain. The two are complementary, and an agent MAY hold both. When an agent has a WIMSE identifier:

• The issuer SHOULD set the SD-Card's sub to that identifier, so that the SD-Card and the WIT name the same agent.
• The SD-Card's cnf key SHOULD be the key confirmed by the agent's WIT. A single proof of possession then authenticates the agent for both, and the verifier does not need to relate two keys.
• A verifier that receives both a WIT and an SD-Card for the same request MUST check that the sub claims are equal and, if the SD-Card's cnf key is the WIT key, that the Key Binding JWT and the WIMSE Proof Token are signed by the same key. It MUST NOT treat the WIT issuer as an issuer of SD-Card claims, or the SD-Card issuer as an issuer of workload identity.

A WIMSE identifier names the agent's trust domain, and as the sub of an SD-Card it is disclosed to every verifier. An issuer that does not want to reveal the trust domain to verifiers of the SD-Card uses an identifier in its own namespace instead. The agent identity management model of covers agent identifiers, credentials, authentication, and authorization, and uses OAuth metadata for discovery. SD-Card adds discovery of the agent's own capabilities with control over what each verifier sees, and the token exchange of lets an agent's attested metadata inform authorization decisions.

Protocol Bindings This section defines Protocol Bindings for MCP, PAP, and A2A. Each binding follows the requirements of .

Protocol Binding Requirements A Protocol Binding MUST specify:

1. Identifier: A short binding name and the vct value or values that SD-Cards for this binding carry. A binding whose protocol has more than one kind of holder defines a vct value for each.
2. Source Document: The Native Metadata Document, the protocol version or versions it applies to, how an issuer retrieves it given the metadata_url of a registration request (), and whether a registrant may instead supply it in metadata.
3. Claim Mapping: How each field of the Native Metadata Document maps to an SD-Card claim (bindings SHOULD reuse native field names), the claim category from , whether the claim is always disclosed or selectively disclosable, and the disclosure granularity.
4. Always Disclosed Binding Claims: Any binding claims, beyond the core claims, that MUST always be disclosed (for example, the protocol version needed to interoperate).
5. Discovery: How SD-Cards are discovered for the protocol, such as well-known URIs or registry query terms.
6. Presentation: How an SD-Card presentation and its Key Binding JWT are carried within the protocol, and how the verifier supplies the audience and nonce values.
7. Consistency Rules: How a verifier relates disclosed claims to metadata it later receives at runtime through the protocol itself.
8. Backward Compatibility: How a Native Metadata Document is reconstructed from a presentation for consumers that do not understand SD-Card.
9. Security Considerations specific to the binding.

MCP Binding

Identifier and Source Document

Binding name:

mcp

vct:

urn:ietf:params:sd-card:mcp:agent-card

Source document:

The metadata an MCP server exposes in version 2026-07-28 of : its server/discover result, including the server identity in the io.modelcontextprotocol/serverInfo member of its _meta, and the results of tools/list, resources/list, and prompts/list, together with the server's OAuth 2.0 Protected Resource Metadata when authorization is used.

Retrieval:

The metadata_url of a registration request is the server's Streamable HTTP endpoint. The issuer sends server/discover, tools/list, resources/list, and prompts/list to it as an MCP client, following each nextCursor to the end of the list, and retrieves the server's Protected Resource Metadata. A server that offers only the stdio transport has no URL; its registrant MAY instead supply in metadata a JSON object whose discover member is the server/discover result and whose tools, resources, and prompts members are the arrays returned by the corresponding list requests. Such metadata is asserted by the registrant alone, and issuers SHOULD verify it by other means, for example by running the published server package.

In this binding the holder of the SD-Card is the MCP server, and the verifier is the MCP client (typically an agent or host application).

Claim Mapping MCP Server Metadata to SD-Card Claim Mapping

MCP field	SD-Card claim	Category	Disclosure
serverInfo.name	name	Core	Always
serverInfo.version	version	Core	Always
serverInfo.description	description	Core	Always
supportedVersions	supportedVersions	(binding)	Always
Streamable HTTP endpoint	url	Endpoints	Always, when present
capabilities	capabilities	Protocol Features	Selective
tools/list entries	tools	Capabilities	Selective, per tool
resources/list entries	resources	Capabilities	Selective, per resource
prompts/list entries	prompts	Capabilities	Selective, per prompt
instructions	instructions	Documentation	Selective
serverInfo.title, websiteUrl, icons	title, websiteUrl, icons	Documentation	Selective
Protected Resource Metadata	authorization	Security Requirements	Selective
(operator)	provider	Provider	Selective

In the table, serverInfo is the Implementation object in the io.modelcontextprotocol/serverInfo member of the server/discover result's _meta, and supportedVersions, capabilities, and instructions are members of that result. The supportedVersions claim lists the MCP protocol versions for which the claims were produced. Each element of tools, resources, and prompts is the object returned by the corresponding list method. The authorization claim carries the members of the server's Protected Resource Metadata . The provider claim is an object with an organization name and a url, the same structure as the A2A AgentProvider object. MCP states that serverInfo is self-reported and that clients should not rely on it for security decisions. The name, version, and description claims of a verified SD-Card are attested by the issuer and can be relied on to the extent the issuer is trusted. The url claim is present only for servers reachable over the Streamable HTTP transport; an SD-Card for a server reached over stdio omits it. Tools, resources, and prompts MUST be selectively disclosable per element, so that a server can reveal individual tools to a client without exposing the remainder of its toolset. gives an example.

Discovery SD-Cards for MCP servers are retrieved from the SD-Card well-known URI () with the binding name mcp. Because an origin can host several MCP servers, this binding defines the resource query parameter, whose value is the URL of the MCP endpoint: When resource is absent, the server returns the SD-Card of its default MCP endpoint. SD-Cards for MCP servers can also be found through Agent Registries () using "binding": "mcp" and tool, resource, or prompt names as query terms, or retrieved from a URL configured in the MCP client.

Presentation This binding defines an MCP extension with the identifier org.ietf/sd-card and uses _meta keys with the prefix org.ietf.sd-card/. A server that holds an SD-Card declares the extension, with an empty settings object, in the extensions member of its capabilities. MCP has no session, so a presentation authenticates the server that returns it in response to one request. An MCP client that supports this binding requests a presentation by including the following keys in the _meta member of its server/discover request parameters, alongside the per-request protocol fields:

org.ietf.sd-card/nonce:

REQUIRED. The nonce value of the Key Binding JWT ().

org.ietf.sd-card/audience:

REQUIRED. The identifier of the client, used as the aud value of the Key Binding JWT.

A server that holds an SD-Card returns its presentation, with a Key Binding JWT whose nonce and aud claims equal the supplied values, in the _meta member of the server/discover result under the key org.ietf.sd-card/presentation. Because the presentation is specific to the request, the result MUST have a cacheScope of private: The same exchange applies to every MCP transport, including stdio. For a server reached over Streamable HTTP, the client MUST check that the SD-Card's url claim equals the endpoint to which it sent the request. Without this check, a server could forward the client's nonce and audience to another server and relay that server's presentation as its own. An SD-Card without a url claim MUST NOT be accepted over Streamable HTTP. A client MAY rely on a verified presentation for later requests to the same Streamable HTTP endpoint, or the same stdio server process, until the SD-Card expires or a shorter period that the client chooses ends, whichever comes first. After that, it requests a fresh presentation before relying on the server's identity again.

Consistency Rules The integrity of tool definitions is a primary benefit of this binding. After verifying a presentation, an MCP client:

• MUST compare each tool, resource, or prompt returned by the corresponding list method against the disclosed element with the same name (for resources, the same uri), and MUST NOT use an entry whose definition (including its description, inputSchema, and outputSchema) differs from the disclosed element.
• SHOULD treat entries that were not disclosed in the SD-Card as unverified, and SHOULD require explicit user or policy approval before using them.
• MUST repeat this comparison whenever it fetches a list again, for example when the list's ttlMs has elapsed or after a list-changed notification on a subscriptions/listen stream.

This prevents a server, or an attacker on the path, from silently altering tool descriptions after the client has approved them.

Backward Compatibility The SD-Card does not replace any MCP message. Clients that do not support this binding ignore the _meta member and continue to use the MCP list methods unchanged. A server that also supports MCP revisions that use an initialize handshake MAY accept the org.ietf.sd-card/nonce and org.ietf.sd-card/audience keys in the _meta of an initialize request and return its presentation in the _meta of the initialize result.

PAP Binding The Personal Agent Protocol (PAP, also called Poppy) defines how a Personal Agent, acting for one User, works with a Company on that User's behalf. Two parties publish metadata in PAP, so this binding defines two SD-Card types:

Company SD-Card:

Held by a Company and verified by Personal Agents. Its source document is the Company's poppy.json discovery document.

Personal Agent SD-Card:

Held by a Personal Agent and verified by Companies. Its source document is the Personal Agent's OAuth client metadata document , extended with claims attested by the issuer.

PAP already authenticates both parties: a Company through the link between its domain and its OAuth issuer, and a Personal Agent through private_key_jwt client assertions. It does not say how a Company decides which Personal Agents to accept, and it gives a Personal Agent no assurance about a Company beyond control of its domain. The two SD-Card types add third-party attestation from an Agent Registry to both directions, with the disclosed claims chosen for each counterpart.

Identifier and Source Documents

Binding name:

pap

vct (Company SD-Card):

urn:ietf:params:sd-card:pap:company-card

vct (Personal Agent SD-Card):

urn:ietf:params:sd-card:pap:agent-card

Source documents:

The poppy.json document and the client metadata document as defined in draft version 0.3 of .

Retrieval:

For a Company SD-Card, the metadata_url of a registration request is the URL of the Company's poppy.json document. For a Personal Agent SD-Card, it is the Personal Agent's client identifier URL, from which the issuer retrieves the client metadata document. The registration request MUST NOT use metadata.

Company SD-Card Claim Mapping poppy.json to Company SD-Card Claim Mapping

poppy.json field	SD-Card claim	Category	Disclosure
(OAuth issuer)	sub	Core	Always
organization.name	name	Core	Always
organization.domain	domain	Provider	Always
protocol_version	protocol_version	(binding)	Always
apis	apis	Capabilities	Selective, per API
agent	agent	Capabilities	Selective
auth.scopes	scopes	Security Requirements	Selective, per scope
auth.scope_hints	scope_hints	Security Requirements	Selective, per scope
web	web	Endpoints	Selective
feedback, excluded_tasks	feedback, excluded_tasks	Documentation	Selective
extensions	extensions	Protocol Features	Selective

The sub claim MUST be the Company's OAuth issuer identifier, which PAP uses to identify the Company. The scopes and scope_hints claims are objects keyed by scope name, and each member is a separately disclosable object property, so that a Company can describe sensitive scopes only to the Personal Agents it chooses. The public poppy.json remains authoritative for PAP. A Company MAY disclose in its SD-Card APIs, scopes, or extensions that it leaves out of its public poppy.json, such as partner APIs, and present them only to Personal Agents it chooses.

Personal Agent SD-Card Claim Mapping Personal Agent SD-Card Claim Mapping

Source	SD-Card claim	Category	Disclosure
client_id	sub	Core	Always
client_name	name	Core	Always
jwks_uri	jwks_uri	(binding)	Always
logo_uri	logo_uri	Documentation	Selective
extensions	extensions	Protocol Features	Selective
(attested)	provider	Provider	Selective
(attested)	security_properties	Security Requirements	Selective, per property
(attested)	certifications	Security Requirements	Selective, per element

The sub claim MUST equal the Personal Agent's client_id, and cnf.jwk MUST be one of the keys published at its jwks_uri. The provider claim has the same structure as in the MCP binding. The security_properties claim is an object whose members are separately disclosable. This binding defines the following members, each a boolean that the issuer has verified:

blind_signing:

The Personal Agent signs its client assertions and delegations blindly, as described in Section 10.7 of .

delegated_keys_on_device:

The Personal Agent's delegated keys never leave the User's device.

model_isolated_secrets:

The Personal Agent keeps the secrets listed in Section 10.2 of out of model context.

Issuers MAY define other members, whose names MUST start with a domain the issuer controls. The certifications claim is a list of objects, each with a scheme URI identifying a certification program and an id within it. A Personal Agent SD-Card describes the Personal Agent, never a User. It MUST NOT contain a User ID, an Agent ID, or anything about a User or the Companies a User works with, following the rule PAP sets for delegations. gives an example of each SD-Card type.

Discovery A Company serves its SD-Card at the SD-Card well-known URI () of its domain with the binding name pap, the same domain that serves its poppy.json. A Personal Agent asks for a key-bound presentation by supplying its client_id as aud and a fresh nonce: A Personal Agent SD-Card is not discovered. The Personal Agent presents it to each Company as described below.

SD-Card Extension This binding defines a PAP extension named ietf.org/sd-card, version "1", following Section 3.3 of . A Company that accepts Personal Agent SD-Cards lists the extension in its poppy.json:

endpoint:

REQUIRED. The HTTPS URL to which Personal Agents send their SD-Card presentations.

issuers:

OPTIONAL. The SD-Card issuers the Company trusts.

requested_claims:

OPTIONAL. The names of the claims the Company asks Personal Agents to disclose.

A Personal Agent that supports the extension lists it in the extensions member of its client metadata document. It presents its SD-Card by sending a POST request to endpoint. As for every endpoint a PAP extension defines, the request carries the Poppy-Session header. The Key Binding JWT's aud MUST be the Company's issuer, as PAP requires for client assertions and Session JWTs, and its nonce MUST be the jti of the Session JWT in the same request: shows such a presentation. The Company verifies the Session header as PAP requires and the presentation as this document requires, and checks that the SD-Card's sub equals the Session JWT's iss. It responds with HTTP 204 on success, or HTTP 400 with {"error": "invalid_sd_card"}. The Company MAY cache the result for the client_id until the SD-Card expires. A Company that requires a verified Personal Agent SD-Card MAY refuse other requests with the extension_required error of PAP. The cnf key of a Personal Agent SD-Card is a key from jwks_uri, so its Key Binding JWTs, like client assertions, name a Company. A Personal Agent that signs blindly MUST sign its Key Binding JWTs blindly as well, with PS384; its cnf key is then an RSA key.

Consistency Rules A Personal Agent verifying a Company SD-Card MUST first complete the discovery checks of Section 3 of , and then MUST check that the SD-Card's sub equals the issuer it verified and that domain equals organization.domain. Each disclosed API, scope, or extension that also appears in poppy.json MUST match it. Disclosed items that do not appear in poppy.json MAY be used, under the same issuer and token rules as items listed there. A Company verifying a Personal Agent SD-Card MUST check that sub equals the client_id, and that the JWK thumbprint of cnf.jwk matches a key in the jwks_uri it fetched as Section 5.3 of describes. Disclosed extensions MUST match the client metadata document.

User Privacy A Personal Agent acts for one User, so its sub and cnf key identify that User to every Company that verifies its SD-Card, and Companies can use them to link the User's activity. A Personal Agent SHOULD present its SD-Card only to Companies with which the User has, or is setting up, a relationship. Where a Company only needs to know that a request comes from an attested Personal Agent, for example to browse a catalog or check availability before the User decides to proceed, the Company SHOULD accept a Privacy Pass token () instead of the SD-Card.

Backward Compatibility Under PAP, both parties ignore extensions they don't support, so Personal Agents and Companies that don't implement this binding continue to work unchanged.

A2A Binding

Identifier and Source Document

Binding name:

a2a

vct:

urn:ietf:params:sd-card:a2a:agent-card

Source document:

The A2A Agent Card (AgentCard object) as defined in version 1.0 of .

Retrieval:

The metadata_url of a registration request is the URL of the Agent Card, typically at the A2A well-known location. A registration request MUST NOT use metadata.

Claim Mapping Agent Card fields are carried as SD-Card claims with the same names: A2A Agent Card to SD-Card Claim Mapping

Agent Card field	Category	Disclosure
name, description, version	Core	Always
supportedInterfaces	Endpoints	Selective, per interface
skills	Capabilities	Selective, per skill
capabilities	Protocol Features	Selective
securitySchemes	Security Requirements	Selective
securityRequirements	Security Requirements	Selective
provider	Provider	Selective
defaultInputModes, defaultOutputModes	Content Modes	Selective
documentationUrl, iconUrl	Documentation	Selective
signatures	(none)	Not carried

A2A 1.0 has no top-level endpoint field: each element of supportedInterfaces gives an endpoint URL, a protocol binding, and the A2A protocol version spoken there. Every presentation MUST therefore disclose at least one element of supportedInterfaces. Disclosing interfaces per element lets an agent, for example, reveal only its JSON-RPC endpoint to public clients and its gRPC endpoint to internal ones. Because securityRequirements refers to entries of securitySchemes by name, issuers SHOULD disclose the two claims together. The native Agent Card signatures member is not carried in the SD-Card; the issuer signature over the SD-JWT takes its place. gives an example.

Discovery An A2A agent that supports this binding returns an SD-Card from the A2A well-known Agent Card location when the client indicates support for SD-Card: The application/dc+sd-jwt media type indicates that the client accepts an SD-JWT VC. The response has that media type, and its body is an SD-Card presentation for this binding with the disclosures of the client's context and, unless the client supplied aud and nonce (), no Key Binding JWT. gives an example. An A2A agent MAY also serve its SD-Card at the protocol-independent location /.well-known/sd-card/a2a (). The A2A extended Agent Card maps naturally onto SD-Card: instead of returning a separate, larger Agent Card to authenticated clients, an agent that sets capabilities.extendedAgentCard MAY return the same SD-Card with additional disclosures from its extended Agent Card endpoint.

SD-Card Extension This binding defines an A2A extension, identified by the URI urn:ietf:params:sd-card:a2a, that carries key-bound SD-Card presentations in A2A messages. An agent that supports the extension declares it in the capabilities.extensions member of its Agent Card: A client that wants the agent to prove its identity activates the extension by listing its URI in the A2A-Extensions service parameter and in the extensions member of its Message. The Message metadata contains an object under the extension URI with the following members:

nonce:

REQUIRED. The nonce value of the Key Binding JWT ().

aud:

REQUIRED. The identifier of the client, used as the aud value of the Key Binding JWT.

context:

OPTIONAL. The discovery context the client requests. As for any context, the agent discloses only what the client's authorization for that context permits ().

The agent responds by including, in the metadata of the first Message or Task it returns in that context, an object under the extension URI whose presentation member is its SD-Card presentation with a Key Binding JWT. The Key Binding JWT nonce and aud claims MUST equal the values supplied by the client. When the response is a Message, the agent also lists the extension URI in its extensions member. An agent needs to present its SD-Card only once per contextId. A client that requires a presentation and does not receive one, or receives one that fails verification, MUST NOT continue the interaction on the basis of the agent's claimed identity.

Consistency and Backward Compatibility A client that receives an A2A Agent Card through other means (for example, the authenticated extended card endpoint) after verifying an SD-Card SHOULD verify that every field it relies on matches the corresponding disclosed SD-Card claim. A native Agent Card is reconstructed from a verified presentation by removing the SD-JWT specific claims (iss, sub, iat, exp, vct, cnf, _sd, _sd_alg) and inserting each disclosed claim. Fields that were not disclosed are absent from the reconstructed card. When they include fields that A2A 1.0 marks as required, the result is a partial Agent Card, and clients MUST NOT interpret a withheld field as empty. Agents MUST continue to serve the native Agent Card to clients that do not request application/dc+sd-jwt, subject to the agent's own access policy.

Relationship Between Bindings The three bindings address different parts of an agent system and are complementary:

• MCP binding: Tool discovery, integrity of tool definitions, and server identity between agents and tool servers
• PAP binding: Attested identity of Companies and Personal Agents, and per-counterpart disclosure of APIs, scopes, and security properties
• A2A binding: Agent discovery, identity, and capability negotiation between agents

SD-Card Bindings and Protocol Layering

A PAP Company lists its MCP servers in apis. Each of those servers MAY hold its own MCP SD-Card, which a Personal Agent verifies as described in in addition to the Company SD-Card. The security context established by one binding does not automatically propagate to another: an agent authenticated through its A2A SD-Card that then calls MCP tools needs separate authorization for that tool access. When an A2A Key Binding JWT carries an interaction_id, the agent SHOULD include it in the MCP requests it makes for that interaction, in the _meta key org.ietf.sd-card/interaction_id, for audit correlation.

IANA Considerations TODO

Security Considerations TODO

Privacy Considerations TODO

References Normative References JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. MATTR Authlete Inc. Ping Identity This specification describes data formats as well as validation and processing rules to express Verifiable Digital Credentials with JSON payloads with and without selective disclosure based on the SD-JWT format. Okta This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. Zscaler Palo Alto Networks This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in Workload Identity Credentials, including X.509 certificates and JWT-based tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. Ping Identity Defakto Security The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from basic deployments to complex multi-service, multi-cloud, multi-tenant systems. This document specifies the Workload Proof Token (WPT), a mechanism for workloads to prove possession of the private key associated with a Workload Identity Token (WIT). The WPT is a signed JWT that binds the workload's authentication to a specific HTTP request, providing application-layer proof of possession for workload-to-workload communication. This specification is designed to work alongside the WIT credential format defined in draft-ietf- wimse-workload-creds and can be combined with other WIMSE protocols in multi-hop call chains. Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms. It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model, to help ensure that the desired security and privacy goals are fulfilled. This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization. The authentication scheme specified in this document can be used by Clients to redeem Privacy Pass tokens with an Origin. It can also be used by Origins to challenge Clients to present Privacy Pass tokens. This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the Issuer Private Key and one that produces tokens that are publicly verifiable using the Issuer Public Key. Instances of "issuance protocol" and "issuance protocols" in the text of this document are used interchangeably to refer to the two variants of the Privacy Pass issuance protocol. Palo Alto Networks Zscaler University of the Bundeswehr Munich The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.

Example Keys The examples in this document use the following P-256 keys. They are for testing only and MUST NOT be used for any other purpose. Each private key is the SHA-256 hash of an ASCII label, reduced modulo the group order, so that the examples can be regenerated. ECDSA signatures in the examples use deterministic nonces . Agent Registry (issuer), label "sd-card example key: issuer": MCP server, label "sd-card example key: mcp server": PAP Company, label "sd-card example key: pap company": PAP Personal Agent, label "sd-card example key: pap personal agent": A2A agent, label "sd-card example key: a2a agent":

MCP Binding Examples The following SD-Card describes an MCP server with three tools, each a separately disclosable array element, and selectively disclosable capabilities and authorization claims. Its issuer-signed JWT has the following payload: Disclosure for the get_elevation tool: Disclosure for the geocode_address tool: Disclosure for the export_parcel_owners tool: Disclosure for capabilities: Disclosure for authorization: In the server/discover exchange of , the server presents its SD-Card to a public client, disclosing only the get_elevation and geocode_address tools. The client learns that a third tool exists but not what it is. To an authorized internal client the server would also disclose export_parcel_owners, capabilities, and authorization. The Key Binding JWT has the header {"alg": "ES256", "typ": "kb+jwt"} and the following payload: The presentation in compact serialization (line breaks for display only) is:

PAP Binding Examples

Company SD-Card The following Company SD-Card discloses its public OpenAPI description and, to selected Personal Agents, a partner MCP server that its public poppy.json does not list. Its issuer-signed JWT has the following payload: Disclosure for the openapi API: Disclosure for the partner mcp API: Disclosure for the orders:read scope hint: Disclosure for the orders:write scope hint: Disclosure for agent: Disclosure for extensions: In response to the well-known URI request of , the Company presents its SD-Card to a Personal Agent that is not a partner, withholding the partner MCP API. The Key Binding JWT has the header {"alg": "ES256", "typ": "kb+jwt"} and the following payload: The presentation in compact serialization (line breaks for display only) is:

Personal Agent SD-Card The following Personal Agent SD-Card carries three attested security properties and one certification. Its issuer-signed JWT has the following payload: Disclosure for blind_signing: Disclosure for delegated_keys_on_device: Disclosure for model_isolated_secrets: Disclosure for the certification: Disclosure for provider: Disclosure for logo_uri: Disclosure for extensions: In the request of , the Personal Agent presents its SD-Card to the Company, disclosing provider, blind_signing, and model_isolated_secrets. The nonce is the jti of the Session JWT in the same request. The Key Binding JWT has the header {"alg": "ES256", "typ": "kb+jwt"} and the following payload: The presentation in compact serialization (line breaks for display only) is:

A2A Binding Examples The examples in this appendix are for an agent with the following native Agent Card (the signatures member is omitted): Its SD-Card has the following issuer-signed JWT payload. The digests in the top-level _sd array are sorted, as recommended by , so that their order does not reveal claim names; the supportedInterfaces and skills arrays contain one digest per element, in the order of the native Agent Card: Disclosure for the JSONRPC interface: Disclosure for the GRPC interface: Disclosure for the HTTP+JSON interface: Disclosure for the route-optimizer-traffic skill: Disclosure for the custom-map-generator skill: Disclosure for capabilities: Disclosure for securitySchemes: Disclosure for securityRequirements: Disclosure for provider: Disclosure for defaultInputModes: Disclosure for defaultOutputModes: Disclosure for documentationUrl: Disclosure for iconUrl: For the public context of the registration example (), the agent discloses its first interface and skill and its default input and output modes. Responding to the activation of the SD-Card extension (), it adds a Key Binding JWT. The Key Binding JWT has the header {"alg": "ES256", "typ": "kb+jwt"} and the following payload: The presentation in compact serialization (line breaks for display only) is: The discovery response of carries the same presentation without the Key Binding JWT, ending at the last ~.