Network Working Group S. Nandakumar Internet-Draft C. Jennings Intended status: Informational Cisco Expires: 4 May 2027 31 October 2026 Agent SD-Card: Selective Disclosure of Agent Metadata for Discovery and Authentication draft-nandakumar-agent-sd-card-00 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights Nandakumar & Jennings Expires 4 May 2027 [Page 1] Internet-Draft Agent SD-Card October 2026 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 5 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 3. SD-Card Data Model . . . . . . . . . . . . . . . . . . . . . 6 3.1. Core Claims . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Common Claim Categories . . . . . . . . . . . . . . . . . 8 3.3. Selective Disclosure Processing . . . . . . . . . . . . . 9 4. SD-Card Issuance . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Registration Request . . . . . . . . . . . . . . . . . . 11 4.2. Registration Authentication . . . . . . . . . . . . . . . 12 4.3. Registration Response . . . . . . . . . . . . . . . . . . 13 4.4. Registration Example . . . . . . . . . . . . . . . . . . 13 5. Agent Discovery . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Well-Known URI Discovery . . . . . . . . . . . . . . . . 15 5.2. Registry Query . . . . . . . . . . . . . . . . . . . . . 16 5.3. Discovery Contexts . . . . . . . . . . . . . . . . . . . 17 5.4. Anonymous Authorization with Privacy Pass . . . . . . . . 17 6. Presentation and Verification . . . . . . . . . . . . . . . . 18 6.1. Presentation . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Key Binding JWT . . . . . . . . . . . . . . . . . . . . . 19 6.3. Verification . . . . . . . . . . . . . . . . . . . . . . 19 7. Use with OAuth and Workload Identity . . . . . . . . . . . . 19 7.1. OAuth Token Exchange . . . . . . . . . . . . . . . . . . 20 7.2. Workload Identity . . . . . . . . . . . . . . . . . . . . 21 8. Protocol Bindings . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Protocol Binding Requirements . . . . . . . . . . . . . . 21 8.2. MCP Binding . . . . . . . . . . . . . . . . . . . . . . . 22 8.2.1. Identifier and Source Document . . . . . . . . . . . 22 8.2.2. Claim Mapping . . . . . . . . . . . . . . . . . . . . 23 8.2.3. Discovery . . . . . . . . . . . . . . . . . . . . . . 24 8.2.4. Presentation . . . . . . . . . . . . . . . . . . . . 25 8.2.5. Consistency Rules . . . . . . . . . . . . . . . . . . 26 8.2.6. Backward Compatibility . . . . . . . . . . . . . . . 27 8.3. PAP Binding . . . . . . . . . . . . . . . . . . . . . . . 27 8.3.1. Identifier and Source Documents . . . . . . . . . . . 28 8.3.2. Company SD-Card Claim Mapping . . . . . . . . . . . . 28 8.3.3. Personal Agent SD-Card Claim Mapping . . . . . . . . 29 8.3.4. Discovery . . . . . . . . . . . . . . . . . . . . . . 30 8.3.5. SD-Card Extension . . . . . . . . . . . . . . . . . . 31 8.3.6. Consistency Rules . . . . . . . . . . . . . . . . . . 32 Nandakumar & Jennings Expires 4 May 2027 [Page 2] Internet-Draft Agent SD-Card October 2026 8.3.7. User Privacy . . . . . . . . . . . . . . . . . . . . 32 8.3.8. Backward Compatibility . . . . . . . . . . . . . . . 32 8.4. A2A Binding . . . . . . . . . . . . . . . . . . . . . . . 32 8.4.1. Identifier and Source Document . . . . . . . . . . . 32 8.4.2. Claim Mapping . . . . . . . . . . . . . . . . . . . . 33 8.4.3. Discovery . . . . . . . . . . . . . . . . . . . . . . 34 8.4.4. SD-Card Extension . . . . . . . . . . . . . . . . . . 34 8.4.5. Consistency and Backward Compatibility . . . . . . . 36 8.5. Relationship Between Bindings . . . . . . . . . . . . . . 36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 12.1. Normative References . . . . . . . . . . . . . . . . . . 37 12.2. Informative References . . . . . . . . . . . . . . . . . 39 Appendix A. Example Keys . . . . . . . . . . . . . . . . . . . . 40 Appendix B. MCP Binding Examples . . . . . . . . . . . . . . . . 42 Appendix C. PAP Binding Examples . . . . . . . . . . . . . . . . 48 C.1. Company SD-Card . . . . . . . . . . . . . . . . . . . . . 48 C.2. Personal Agent SD-Card . . . . . . . . . . . . . . . . . 53 Appendix D. A2A Binding Examples . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 1. 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) [MCP-SPEC] exposes server information and lists of tools, resources, and prompts for agent-to-tool interaction. The Personal Agent Protocol (PAP) [PAP-SPEC] has Companies publish a discovery document for the personal agents that act for their customers. The Agent2Agent (A2A) protocol [A2A-SPEC] 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. Nandakumar & Jennings Expires 4 May 2027 [Page 3] Internet-Draft Agent SD-Card October 2026 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 [RFC9901] 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 [RFC9576]. 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 (Section 4). The core of this document is independent of any agent protocol. It covers the architecture (Section 2), the SD-Card data model (Section 3), issuance (Section 4), discovery (Section 5), presentation and verification (Section 6), and use with OAuth and workload identity (Section 7). Protocol Bindings (Section 8) map the metadata document of a specific protocol onto the core. This document defines bindings for MCP (Section 8.2), PAP (Section 8.3), and A2A (Section 8.4); other specifications can define additional bindings following Section 8.1. 1.1. 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 [RFC2119] [RFC8174] 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. Nandakumar & Jennings Expires 4 May 2027 [Page 4] Internet-Draft Agent SD-Card October 2026 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 (Section 5.3). 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. 1.2. Notational Conventions This document follows SD-JWT [RFC9901] conventions: * Base64url encoding for binary data * JWS [RFC7515] 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: ~~...~~[] 2. 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: Nandakumar & Jennings Expires 4 May 2027 [Page 5] Internet-Draft Agent SD-Card October 2026 +------------------+ (1) Register +------------------+ | Agent Registry |<---------------------| Agent | | (Issuer) |--------------------->| (Holder) | +------------------+ (2) Issue SD-Card +------------------+ ^ | | (3) Discover | (4) Present | (registry query, or | selected | well-known URI of the agent) | disclosures | | + Key Binding | v | +------------------+ +--------------------------------| Verifier | +------------------+ Figure 1: SD-Card Roles and Flows 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 (Section 4). 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 (Section 5). 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 (Section 6). 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. 3. SD-Card Data Model An SD-Card is an SD-JWT VC [SD-JWT-VC], and therefore an SD-JWT [RFC9901], 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 [SD-JWT-VC]. Its payload contains: 1. Core Claims: Always disclosed claims, defined in Section 3.1, that establish the issuer, the agent's identity, the Protocol Binding in use, validity, and the confirmation key Nandakumar & Jennings Expires 4 May 2027 [Page 6] Internet-Draft Agent SD-Card October 2026 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 3.1. 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 [SD-JWT-VC], 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 (Section 7.2). 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::. These URNs identify a type; they cannot be dereferenced. A verifier that needs SD-JWT VC Type Metadata [SD-JWT-VC] 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 (Section 6.3). 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 Nandakumar & Jennings Expires 4 May 2027 [Page 7] Internet-Draft Agent SD-Card October 2026 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: { "iss": "https://registry.example.com", "sub": "agent:example-agent", "iat": 1767225600, "exp": 1798761599, "vct": "", "_sd_alg": "sha-256", "_sd": [ "" ], "name": "Example Agent", "description": "An example agent", "version": "1.0.0", "cnf": { "jwk": "" } } 3.2. 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 Section 5.3) can then be expressed per category and applied to an agent regardless of protocol. Nandakumar & Jennings Expires 4 May 2027 [Page 8] Internet-Draft Agent SD-Card October 2026 +=======================+======================================+ | 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 | +-----------------------+--------------------------------------+ Table 1: Claim Categories Claims in the Capabilities, Endpoints, Protocol Features, Security Requirements, and Provider categories are the main subjects of selective disclosure. 3.3. Selective Disclosure Processing Selectively disclosable binding claims are processed as defined in [RFC9901]. 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. Nandakumar & Jennings Expires 4 May 2027 [Page 9] Internet-Draft Agent SD-Card October 2026 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 [RFC9901] to hide the number of selectively disclosable claims or capabilities. 4. 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 [RFC6749] or a WIMSE Workload Identity Token [WIMSE-ARCH]), 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 (Section 4.1). 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 (Section 4.2). 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 (Section 7.2), an OAuth client_id [RFC6749], or a client identifier URL [I-D.ietf-oauth-client-id-metadata-document]. 3. The issuer MUST obtain the Native Metadata Document as the binding's Source Document retrieval rules specify (Section 8.1), 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 [I-D.ietf-oauth-client-id-metadata-document] at that origin; Nandakumar & Jennings Expires 4 May 2027 [Page 10] Internet-Draft Agent SD-Card October 2026 * a challenge, such as the ACME "http-01" or "dns-01" challenge [RFC8555], 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 (Section 4.3). 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. 4.1. Registration Request A registrant sends an HTTP POST request to the registry's registration endpoint over HTTPS [RFC9325]. 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 (Section 8.1). 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 Nandakumar & Jennings Expires 4 May 2027 [Page 11] Internet-Draft Agent SD-Card October 2026 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 [RFC7800] 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 (Section 5.3). 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 [SD-JWT-VC]: 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. 4.2. 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 [RFC9449] 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 [WIMSE-WPT] (Section 7.2). The issuer MUST reject the request if the key whose possession is proven is not the key in cnf. Nandakumar & Jennings Expires 4 May 2027 [Page 12] Internet-Draft Agent SD-Card October 2026 4.3. 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 [RFC9901], 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 (Section 5.2), 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. 4.4. 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: Nandakumar & Jennings Expires 4 May 2027 [Page 13] Internet-Draft Agent SD-Card October 2026 POST /agents/register HTTP/1.1 Host: registry.example.com Content-Type: application/json Authorization: DPoP 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"], Nandakumar & Jennings Expires 4 May 2027 [Page 14] Internet-Draft Agent SD-Card October 2026 ["capabilities"], ["provider"], ["securitySchemes"], ["securityRequirements"], ["documentationUrl"], ["iconUrl"] ] } ] } The registry grants all three contexts and returns the SD-Card (line breaks for display only): HTTP/1.1 200 OK Content-Type: application/json { "sd_card": "eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCJ9.. ~~~...~", "disclosure_contexts": [ ... as requested ... ] } 5. 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. 5.1. Well-Known URI Discovery This document defines a protocol-independent well-known URI [RFC8615] for retrieving SD-Cards: /.well-known/sd-card/{binding} where {binding} is the name of a Protocol Binding (Section 8.1). 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 [SD-JWT-VC], 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. Nandakumar & Jennings Expires 4 May 2027 [Page 15] Internet-Draft Agent SD-Card October 2026 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 (Section 6.3). 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 Section 8.4.3 for an example. An agent MAY return additional disclosures to clients that are authorized for a richer discovery context (Section 5.3). 5.2. 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: POST /agents/discover HTTP/1.1 Host: registry.example.com Content-Type: application/json Authorization: Bearer { "binding": "a2a", "query": { "skills": ["route-optimizer-traffic"], "capabilities": { "streaming": true } }, "context": "internal", "max_results": 10 } A query can instead use the claim categories of Section 3.2 (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. Nandakumar & Jennings Expires 4 May 2027 [Page 16] Internet-Draft Agent SD-Card October 2026 5.3. Discovery Contexts A discovery context determines which claims a presentation discloses. Contexts are expressed in terms of the claim categories of Section 3.2, so that a policy applies to agents of every binding. This document uses the following contexts; deployments MAY define others: +============+=================+==============================+ | Context | Intended for | Disclosed Categories | +============+=================+==============================+ | public | Any client | Core claims, selected | | | | Capabilities, public | | | | Endpoints, Content Modes | +------------+-----------------+------------------------------+ | internal | Clients in the | All public + remaining | | | operator's | Capabilities and Endpoints, | | | organization | Protocol Features, Provider, | | | | Security Requirements | +------------+-----------------+------------------------------+ | diagnostic | Operators | All internal + Documentation | | | troubleshooting | | | | the agent | | +------------+-----------------+------------------------------+ | federation | Partner | As set by the federation | | | organizations | agreement | +------------+-----------------+------------------------------+ Table 2: Discovery Contexts 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 (Section 5.4), whether the requester is authorized for the context, and MUST NOT return disclosures of a context the requester is not authorized for. 5.4. 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 [RFC9576] 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, Nandakumar & Jennings Expires 4 May 2027 [Page 17] Internet-Draft Agent SD-Card October 2026 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 [RFC9577]: HTTP/1.1 401 Unauthorized WWW-Authenticate: PrivateToken challenge="", token-key="" and the client presents it on the discovery request: GET /.well-known/sd-card/a2a HTTP/1.1 Host: agent.example.com Accept: application/dc+sd-jwt Authorization: PrivateToken token="" 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 [RFC9578]. 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 Section 5.2, 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. 6. Presentation and Verification An agent proves that it holds an SD-Card by adding a Key Binding JWT [RFC9901] 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. Appendix D gives a complete example. 6.1. Presentation The agent presents its SD-Card as an SD-JWT [RFC9901], in the serialization of Section 1.2, containing the issuer-signed JWT, the disclosures for the context, and a Key Binding JWT. Nandakumar & Jennings Expires 4 May 2027 [Page 18] Internet-Draft Agent SD-Card October 2026 6.2. Key Binding JWT The Key Binding JWT is as defined in [RFC9901]: 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. 6.3. 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 (Section 3.1). 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. 7. Use with OAuth and Workload Identity Nandakumar & Jennings Expires 4 May 2027 [Page 19] Internet-Draft Agent SD-Card October 2026 7.1. 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 [RFC8693] 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: POST /token HTTP/1.1 Host: auth.example.com Content-Type: application/x-www-form-urlencoded grant_type=urn:ietf:params:oauth:grant-type:token-exchange &subject_token= &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 [RFC9449]. The authorization server: 1. Validates the subject token as [RFC8693] requires. 2. Verifies the actor token as described in Section 6, 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. Nandakumar & Jennings Expires 4 May 2027 [Page 20] Internet-Draft Agent SD-Card October 2026 7.2. Workload Identity WIMSE [WIMSE-ARCH] gives a workload, including an agent [WIMSE-AIMS], an identifier [WIMSE-ID] 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 [WIMSE-WPT]. 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 [WIMSE-AIMS] 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 Section 7.1 lets an agent's attested metadata inform authorization decisions. 8. Protocol Bindings This section defines Protocol Bindings for MCP, PAP, and A2A. Each binding follows the requirements of Section 8.1. 8.1. Protocol Binding Requirements A Protocol Binding MUST specify: Nandakumar & Jennings Expires 4 May 2027 [Page 21] Internet-Draft Agent SD-Card October 2026 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 (Section 4.1), 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 Section 3.2, 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. 8.2. MCP Binding 8.2.1. 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 Nandakumar & Jennings Expires 4 May 2027 [Page 22] Internet-Draft Agent SD-Card October 2026 2026-07-28 of [MCP-SPEC]: 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 [RFC9728] 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). 8.2.2. 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 |url |Endpoints | Always, | |endpoint | | | when | | | | | present | +----------------------+-----------------+-------------+------------+ |capabilities |capabilities |Protocol | Selective | | | |Features | | +----------------------+-----------------+-------------+------------+ |tools/list entries |tools |Capabilities | Selective, | | | | | per tool | +----------------------+-----------------+-------------+------------+ |resources/list entries|resources |Capabilities | Selective, | | | | | per | | | | | resource | Nandakumar & Jennings Expires 4 May 2027 [Page 23] Internet-Draft Agent SD-Card October 2026 +----------------------+-----------------+-------------+------------+ |prompts/list entries |prompts |Capabilities | Selective, | | | | | per prompt | +----------------------+-----------------+-------------+------------+ |instructions |instructions |Documentation| Selective | +----------------------+-----------------+-------------+------------+ |serverInfo.title, |title, |Documentation| Selective | |websiteUrl, icons |websiteUrl, icons| | | +----------------------+-----------------+-------------+------------+ |Protected Resource |authorization |Security | Selective | |Metadata | |Requirements | | +----------------------+-----------------+-------------+------------+ |(operator) |provider |Provider | Selective | +----------------------+-----------------+-------------+------------+ Table 3: MCP Server Metadata to SD-Card Claim Mapping 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 [RFC9728]. 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. Appendix B gives an example. 8.2.3. Discovery SD-Cards for MCP servers are retrieved from the SD-Card well-known URI (Section 5.1) 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: Nandakumar & Jennings Expires 4 May 2027 [Page 24] Internet-Draft Agent SD-Card October 2026 GET /.well-known/sd-card/mcp?resource=https%3A%2F%2Fgeodata.example .com%2Fmcp HTTP/1.1 Host: geodata.example.com Accept: application/dc+sd-jwt 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 (Section 5) using "binding": "mcp" and tool, resource, or prompt names as query terms, or retrieved from a URL configured in the MCP client. 8.2.4. 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 (Section 6.2). org.ietf.sd-card/audience: REQUIRED. The identifier of the client, used as the aud value of the Key Binding JWT. { "jsonrpc": "2.0", "id": "discover-1", "method": "server/discover", "params": { "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28", "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" }, "io.modelcontextprotocol/clientCapabilities": {}, "org.ietf.sd-card/nonce": "tZignsnFbp8tC2rXq0VhGw", "org.ietf.sd-card/audience": "https://client.example.com" } } } Nandakumar & Jennings Expires 4 May 2027 [Page 25] Internet-Draft Agent SD-Card October 2026 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: { "jsonrpc": "2.0", "id": "discover-1", "result": { "resultType": "complete", "supportedVersions": ["2026-07-28"], "capabilities": { "tools": { "listChanged": true }, "extensions": { "org.ietf/sd-card": {} } }, "_meta": { "io.modelcontextprotocol/serverInfo": { "name": "geodata-server", "version": "3.4.1" }, "org.ietf.sd-card/presentation": "eyJhbGci...~eyJ..." }, "ttlMs": 0, "cacheScope": "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. 8.2.5. Consistency Rules The integrity of tool definitions is a primary benefit of this binding. After verifying a presentation, an MCP client: Nandakumar & Jennings Expires 4 May 2027 [Page 26] Internet-Draft Agent SD-Card October 2026 * 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. 8.2.6. 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. 8.3. PAP Binding The Personal Agent Protocol (PAP, also called Poppy) [PAP-SPEC] 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 [I-D.ietf-oauth-client-id-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 Nandakumar & Jennings Expires 4 May 2027 [Page 27] Internet-Draft Agent SD-Card October 2026 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. 8.3.1. 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 [PAP-SPEC]. 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. 8.3.2. 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 |Selective,| | | |Requirements |per scope | +---------------------+------------------+-------------+----------+ | auth.scope_hints | scope_hints |Security |Selective,| | | |Requirements |per scope | +---------------------+------------------+-------------+----------+ | web | web |Endpoints |Selective | Nandakumar & Jennings Expires 4 May 2027 [Page 28] Internet-Draft Agent SD-Card October 2026 +---------------------+------------------+-------------+----------+ | feedback, | feedback, |Documentation|Selective | | excluded_tasks | excluded_tasks | | | +---------------------+------------------+-------------+----------+ | extensions | extensions |Protocol |Selective | | | |Features | | +---------------------+------------------+-------------+----------+ Table 4: poppy.json to Company SD-Card Claim Mapping 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. 8.3.3. 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 | Selective | | | | Features | | +-------------+---------------------+---------------+--------------+ | (attested) | provider | Provider | Selective | +-------------+---------------------+---------------+--------------+ | (attested) | security_properties | Security | Selective, | | | | Requirements | per property | +-------------+---------------------+---------------+--------------+ | (attested) | certifications | Security | Selective, | | | | Requirements | per element | +-------------+---------------------+---------------+--------------+ Table 5: Personal Agent SD-Card Claim Mapping Nandakumar & Jennings Expires 4 May 2027 [Page 29] Internet-Draft Agent SD-Card October 2026 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 [PAP-SPEC]. 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 [PAP-SPEC] 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. Appendix C gives an example of each SD-Card type. 8.3.4. Discovery A Company serves its SD-Card at the SD-Card well-known URI (Section 5.1) 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: GET /.well-known/sd-card/pap?aud=https%3A%2F%2Fagent.example %2Fagent.json&nonce=Rk3vQ9wLx2bT7hNcYp0eAg HTTP/1.1 Host: example.com Accept: application/dc+sd-jwt A Personal Agent SD-Card is not discovered. The Personal Agent presents it to each Company as described below. Nandakumar & Jennings Expires 4 May 2027 [Page 30] Internet-Draft Agent SD-Card October 2026 8.3.5. SD-Card Extension This binding defines a PAP extension named ietf.org/sd-card, version "1", following Section 3.3 of [PAP-SPEC]. A Company that accepts Personal Agent SD-Cards lists the extension in its poppy.json: "extensions": { "ietf.org/sd-card": { "version": "1", "endpoint": "https://api.example.com/poppy/sd-card", "issuers": ["https://registry.example.com"], "requested_claims": ["provider", "security_properties"] } } 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: POST /poppy/sd-card HTTP/1.1 Host: api.example.com Content-Type: application/json Poppy-Session: eyJ0eXAiOiJwb3BweS1zZXNzaW9uK2p3dCIs... { "presentation": "eyJhbGciOiJFUzI1NiIs...~WyJ...~eyJ..." } Appendix C.2 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. Nandakumar & Jennings Expires 4 May 2027 [Page 31] Internet-Draft Agent SD-Card October 2026 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. 8.3.6. Consistency Rules A Personal Agent verifying a Company SD-Card MUST first complete the discovery checks of Section 3 of [PAP-SPEC], 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 [PAP-SPEC] describes. Disclosed extensions MUST match the client metadata document. 8.3.7. 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 (Section 5.4) instead of the SD-Card. 8.3.8. 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. 8.4. A2A Binding 8.4.1. 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 Nandakumar & Jennings Expires 4 May 2027 [Page 32] Internet-Draft Agent SD-Card October 2026 version 1.0 of [A2A-SPEC]. 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. 8.4.2. Claim Mapping Agent Card fields are carried as SD-Card claims with the same names: +============================+===============+===============+ | Agent Card field | Category | Disclosure | +============================+===============+===============+ | name, description, version | Core | Always | +----------------------------+---------------+---------------+ | supportedInterfaces | Endpoints | Selective, | | | | per interface | +----------------------------+---------------+---------------+ | skills | Capabilities | Selective, | | | | per skill | +----------------------------+---------------+---------------+ | capabilities | Protocol | Selective | | | Features | | +----------------------------+---------------+---------------+ | securitySchemes | Security | Selective | | | Requirements | | +----------------------------+---------------+---------------+ | securityRequirements | Security | Selective | | | Requirements | | +----------------------------+---------------+---------------+ | provider | Provider | Selective | +----------------------------+---------------+---------------+ | defaultInputModes, | Content Modes | Selective | | defaultOutputModes | | | +----------------------------+---------------+---------------+ | documentationUrl, iconUrl | Documentation | Selective | +----------------------------+---------------+---------------+ | signatures | (none) | Not carried | +----------------------------+---------------+---------------+ Table 6: A2A Agent Card to SD-Card Claim Mapping Nandakumar & Jennings Expires 4 May 2027 [Page 33] Internet-Draft Agent SD-Card October 2026 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. Appendix D gives an example. 8.4.3. 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: GET /.well-known/agent-card.json HTTP/1.1 Host: georoute-agent.example.com Accept: application/dc+sd-jwt The application/dc+sd-jwt media type [SD-JWT-VC] 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 (Section 5.1), no Key Binding JWT. Appendix D gives an example. An A2A agent MAY also serve its SD-Card at the protocol-independent location /.well-known/sd-card/a2a (Section 5.1). 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. 8.4.4. 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: Nandakumar & Jennings Expires 4 May 2027 [Page 34] Internet-Draft Agent SD-Card October 2026 { "uri": "urn:ietf:params:sd-card:a2a", "description": "SD-Card key-bound presentation", "required": false } 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 (Section 6.2). 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 (Section 5.3). { "messageId": "9f2c4a1e-7b3d-4c55-a0e2-5d1f8b6c3e90", "role": "ROLE_USER", "parts": [ { "text": "Plan a route from SJC to SFO" } ], "extensions": [ "urn:ietf:params:sd-card:a2a" ], "metadata": { "urn:ietf:params:sd-card:a2a": { "nonce": "8xk2Nq4ZpR0vWm3TfL7cHg", "aud": "https://client.example.com" } } } 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. Nandakumar & Jennings Expires 4 May 2027 [Page 35] Internet-Draft Agent SD-Card October 2026 { "metadata": { "urn:ietf:params:sd-card:a2a": { "presentation": "eyJhbGciOiJFUzI1NiIs...~eyJ..." } } } 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. 8.4.5. 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. 8.5. 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 Nandakumar & Jennings Expires 4 May 2027 [Page 36] Internet-Draft Agent SD-Card October 2026 +------------------------------------------------------+ | Application Layer | | (Agent Business Logic, Task Orchestration) | +------------------------------------------------------+ | MCP Protocol | PAP | A2A Protocol | | (Agent to | (Personal | (Agent to | | Tool) | Agent to | Agent) | | | Company) | | +------------------------------------------------------+ | SD-Card MCP | SD-Card PAP | SD-Card A2A | | Binding | Binding | Binding | +------------------------------------------------------+ | SD-Card Core (Data Model, Issuance, | | Discovery, Key-Bound Presentation) | +------------------------------------------------------+ | HTTP over TLS, or local transport | +------------------------------------------------------+ Figure 2: 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 Section 8.2 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. 9. IANA Considerations TODO 10. Security Considerations TODO 11. Privacy Considerations TODO 12. References 12.1. Normative References Nandakumar & Jennings Expires 4 May 2027 [Page 37] Internet-Draft Agent SD-Card October 2026 [A2A-SPEC] Foundation), A. P. (Linux., "Agent2Agent (A2A) Protocol Specification", Version 1.0, 2025, . [I-D.ietf-oauth-client-id-metadata-document] Parecki, A. and E. Smith, "OAuth Client ID Metadata Document", Work in Progress, Internet-Draft, draft-ietf- oauth-client-id-metadata-document-02, 6 July 2026, . [MCP-SPEC] Foundation), M. P. (Linux., "Model Context Protocol Specification", Version 2026-07-28, 28 July 2026, . [PAP-SPEC] Project, P. A. P., "Personal Agent Protocol", Version 0.3 (draft), 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, . Nandakumar & Jennings Expires 4 May 2027 [Page 38] Internet-Draft Agent SD-Card October 2026 [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . [RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, . [RFC9901] Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens", RFC 9901, DOI 10.17487/RFC9901, November 2025, . [SD-JWT-VC] Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based Verifiable Digital Credentials (SD-JWT VC)", Work in Progress, Internet-Draft, draft-ietf-oauth-sd-jwt-vc-22, 27 October 2026, . 12.2. Informative References [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9576] Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June 2024, . Nandakumar & Jennings Expires 4 May 2027 [Page 39] Internet-Draft Agent SD-Card October 2026 [RFC9577] Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass HTTP Authentication Scheme", RFC 9577, DOI 10.17487/RFC9577, June 2024, . [RFC9578] Celi, S., Davidson, A., Valdez, S., and C. A. Wood, "Privacy Pass Issuance Protocols", RFC 9578, DOI 10.17487/RFC9578, June 2024, . [WIMSE-AIMS] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf- wimse-aims-00, 15 September 2026, . [WIMSE-ARCH] Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-08, 6 July 2026, . [WIMSE-ID] Rosomakho, Y. and J. A. Salowey, "Workload Identifier", Work in Progress, Internet-Draft, draft-ietf-wimse- identifier-04, 23 October 2026, . [WIMSE-WPT] Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof Token", Work in Progress, Internet-Draft, draft-ietf- wimse-wpt-02, 27 August 2026, . Appendix A. 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 [RFC6979]. Agent Registry (issuer), label "sd-card example key: issuer": Nandakumar & Jennings Expires 4 May 2027 [Page 40] Internet-Draft Agent SD-Card October 2026 { "kty": "EC", "crv": "P-256", "x": "1YXC3H1FyjPwvaVOypzsgpkrmoXprmUXM7uJ_YVXuC0", "y": "kM_wSEMicXPAjvwQpyInsrj9VNphUQMhhhtGzeyCi80", "d": "LyTUa1hoawWFmddhQwISghJtbpQS5R9MjFvqBBpcvH8" } MCP server, label "sd-card example key: mcp server": { "kty": "EC", "crv": "P-256", "x": "BgKmUuTJ5FmMccQI_uK61N7QxIpg0D5U6jJ0qsOYeOs", "y": "xMYIsKsTuXdYFJvPsp5OY5UTSer1ng0r4Phm0Smi3Hc", "d": "QI_Ku9pGPpfkpj-Yhj6lQrbFVajayDSwmhtV4-yYZA4" } PAP Company, label "sd-card example key: pap company": { "kty": "EC", "crv": "P-256", "x": "7t0MSqKqUlkUTxPmIr8sDsRN4RTXQyKQGMGljtwKIwo", "y": "L1-V5oSxn3hkpJ-KtQq-dEyk-MqLRyMRtuKRO7CJNVc", "d": "7Ga8rGsq0p2qwy9vtfXqCYTuC3F2GbmNXWUJbmKFUMc" } PAP Personal Agent, label "sd-card example key: pap personal agent": { "kty": "EC", "crv": "P-256", "x": "rcb61_FGgWZhmA2QjsS3vkcei7Jk0DzjL8VHIKgsmms", "y": "48ZSN62KUwUpeiFONBkLb41MGbFF1HR0LWneXqWXav4", "d": "q0DCeKny5wdmzhjogUurilFJ73lV-7FF5APymbDeXog" } A2A agent, label "sd-card example key: a2a agent": { "kty": "EC", "crv": "P-256", "x": "NRV8L0GsHzQL4auGECf1EuQAAbWQDnZPp_rY1Iopvn0", "y": "uTOlnJ2S83z6DM7r0_pvVemMtsefFm-Lk4oiwHNbF5o", "d": "zRqIpNug6AjghmoepMnQy9zQ6ZxLwzCocHTmCb6iYus" } Nandakumar & Jennings Expires 4 May 2027 [Page 41] Internet-Draft Agent SD-Card October 2026 Appendix B. 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: { "iss": "https://registry.example.com", "sub": "mcp:geodata-server", "iat": 1767225600, "exp": 1798761599, "vct": "urn:ietf:params:sd-card:mcp:agent-card", "_sd_alg": "sha-256", "_sd": [ "9T01sZq1MQeHYeQfiNIW9x8lr5YbaZRXliFySZqgiUI", "H5UiatV4O4nvn7c4mdYJGIG3H7e8YzXs0r8u03LjpiY" ], "supportedVersions": [ "2026-07-28" ], "name": "geodata-server", "description": "Geospatial lookup tools", "version": "3.4.1", "url": "https://geodata.example.com/mcp", "tools": [ { "...": "ECzck2UInTxdsL64l-VrQAaqAuQ6bjlIzo-vYfcyZIY" }, { "...": "CNiYf-7UFxpMuXHIVBc6EVFL76C9wXbexReG0V13dGk" }, { "...": "64Drz-WmaH2sFqRF1Bk5ti9wjmk-GLIYnVQiao0N0fg" } ], "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "BgKmUuTJ5FmMccQI_uK61N7QxIpg0D5U6jJ0qsOYeOs", "y": "xMYIsKsTuXdYFJvPsp5OY5UTSer1ng0r4Phm0Smi3Hc" } } } Disclosure for the get_elevation tool: Nandakumar & Jennings Expires 4 May 2027 [Page 42] Internet-Draft Agent SD-Card October 2026 [ "43JWoTP34Li7cZEM0zIc1A", { "name": "get_elevation", "description": "Ground elevation in meters at a point", "inputSchema": { "type": "object", "properties": { "lat": { "type": "number" }, "lng": { "type": "number" } }, "required": [ "lat", "lng" ] } } ] Encoded: WyI0M0pXb1RQMzRMaTdjWkVNMHpJYzFBIix7Im5hbWUiOiJnZXRfZWxldmF0aW9uIiwi ZGVzY3JpcHRpb24iOiJHcm91bmQgZWxldmF0aW9uIGluIG1ldGVycyBhdCBhIHBvaW50 IiwiaW5wdXRTY2hlbWEiOnsidHlwZSI6Im9iamVjdCIsInByb3BlcnRpZXMiOnsibGF0 Ijp7InR5cGUiOiJudW1iZXIifSwibG5nIjp7InR5cGUiOiJudW1iZXIifX0sInJlcXVp cmVkIjpbImxhdCIsImxuZyJdfX1d SHA-256 digest: ECzck2UInTxdsL64l-VrQAaqAuQ6bjlIzo-vYfcyZIY Disclosure for the geocode_address tool: Nandakumar & Jennings Expires 4 May 2027 [Page 43] Internet-Draft Agent SD-Card October 2026 [ "ZusE9QIszhpVw4IGKtW1Gg", { "name": "geocode_address", "description": "Converts an address to coordinates", "inputSchema": { "type": "object", "properties": { "address": { "type": "string" } }, "required": [ "address" ] } } ] Encoded: WyJadXNFOVFJc3pocFZ3NElHS3RXMUdnIix7Im5hbWUiOiJnZW9jb2RlX2FkZHJlc3Mi LCJkZXNjcmlwdGlvbiI6IkNvbnZlcnRzIGFuIGFkZHJlc3MgdG8gY29vcmRpbmF0ZXMi LCJpbnB1dFNjaGVtYSI6eyJ0eXBlIjoib2JqZWN0IiwicHJvcGVydGllcyI6eyJhZGRy ZXNzIjp7InR5cGUiOiJzdHJpbmcifX0sInJlcXVpcmVkIjpbImFkZHJlc3MiXX19XQ SHA-256 digest: CNiYf-7UFxpMuXHIVBc6EVFL76C9wXbexReG0V13dGk Disclosure for the export_parcel_owners tool: Nandakumar & Jennings Expires 4 May 2027 [Page 44] Internet-Draft Agent SD-Card October 2026 [ "dyGRVreURWLjCNCZr3bX-A", { "name": "export_parcel_owners", "description": "Exports parcel ownership records", "inputSchema": { "type": "object", "properties": { "bbox": { "type": "array", "items": { "type": "number" }, "minItems": 4, "maxItems": 4 } }, "required": [ "bbox" ] }, "annotations": { "readOnlyHint": true, "openWorldHint": false } } ] Encoded: WyJkeUdSVnJlVVJXTGpDTkNacjNiWC1BIix7Im5hbWUiOiJleHBvcnRfcGFyY2VsX293 bmVycyIsImRlc2NyaXB0aW9uIjoiRXhwb3J0cyBwYXJjZWwgb3duZXJzaGlwIHJlY29y ZHMiLCJpbnB1dFNjaGVtYSI6eyJ0eXBlIjoib2JqZWN0IiwicHJvcGVydGllcyI6eyJi Ym94Ijp7InR5cGUiOiJhcnJheSIsIml0ZW1zIjp7InR5cGUiOiJudW1iZXIifSwibWlu SXRlbXMiOjQsIm1heEl0ZW1zIjo0fX0sInJlcXVpcmVkIjpbImJib3giXX0sImFubm90 YXRpb25zIjp7InJlYWRPbmx5SGludCI6dHJ1ZSwib3BlbldvcmxkSGludCI6ZmFsc2V9 fV0 SHA-256 digest: 64Drz-WmaH2sFqRF1Bk5ti9wjmk-GLIYnVQiao0N0fg Disclosure for capabilities: Nandakumar & Jennings Expires 4 May 2027 [Page 45] Internet-Draft Agent SD-Card October 2026 [ "kB0vLABzESqNhFlrJGL2Rw", "capabilities", { "tools": { "listChanged": true }, "resources": { "subscribe": true, "listChanged": false }, "extensions": { "org.ietf/sd-card": {} } } ] Encoded: WyJrQjB2TEFCekVTcU5oRmxySkdMMlJ3IiwiY2FwYWJpbGl0aWVzIix7InRvb2xzIjp7 Imxpc3RDaGFuZ2VkIjp0cnVlfSwicmVzb3VyY2VzIjp7InN1YnNjcmliZSI6dHJ1ZSwi bGlzdENoYW5nZWQiOmZhbHNlfSwiZXh0ZW5zaW9ucyI6eyJvcmcuaWV0Zi9zZC1jYXJk Ijp7fX19XQ SHA-256 digest: 9T01sZq1MQeHYeQfiNIW9x8lr5YbaZRXliFySZqgiUI Disclosure for authorization: [ "xzZ6lxCbqYrjd6_gDSl0RQ", "authorization", { "resource": "https://geodata.example.com/mcp", "authorization_servers": [ "https://auth.example.com" ], "scopes_supported": [ "geo.read", "parcel.read" ] } ] Nandakumar & Jennings Expires 4 May 2027 [Page 46] Internet-Draft Agent SD-Card October 2026 Encoded: WyJ4elo2bHhDYnFZcmpkNl9nRFNsMFJRIiwiYXV0aG9yaXphdGlvbiIseyJyZXNvdXJj ZSI6Imh0dHBzOi8vZ2VvZGF0YS5leGFtcGxlLmNvbS9tY3AiLCJhdXRob3JpemF0aW9u X3NlcnZlcnMiOlsiaHR0cHM6Ly9hdXRoLmV4YW1wbGUuY29tIl0sInNjb3Blc19zdXBw b3J0ZWQiOlsiZ2VvLnJlYWQiLCJwYXJjZWwucmVhZCJdfV0 SHA-256 digest: H5UiatV4O4nvn7c4mdYJGIG3H7e8YzXs0r8u03LjpiY In the server/discover exchange of Section 8.2.4, 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: { "iat": 1767226000, "aud": "https://client.example.com", "nonce": "tZignsnFbp8tC2rXq0VhGw", "sd_hash": "Y4xmzvUM-DlG6qA3DD7g8kc8YSokzPeJE-XJt7kfEio" } The presentation in compact serialization (line breaks for display only) is: Nandakumar & Jennings Expires 4 May 2027 [Page 47] Internet-Draft Agent SD-Card October 2026 eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCJ9.eyJpc3MiOiJodHRwczovL3J lZ2lzdHJ5LmV4YW1wbGUuY29tIiwic3ViIjoibWNwOmdlb2RhdGEtc2VydmVyIiwiaWF 0IjoxNzY3MjI1NjAwLCJleHAiOjE3OTg3NjE1OTksInZjdCI6InVybjppZXRmOnBhcmF tczpzZC1jYXJkOm1jcDphZ2VudC1jYXJkIiwiX3NkX2FsZyI6InNoYS0yNTYiLCJfc2Q iOlsiOVQwMXNacTFNUWVIWWVRZmlOSVc5eDhscjVZYmFaUlhsaUZ5U1pxZ2lVSSIsIkg 1VWlhdFY0TzRudm43YzRtZFlKR0lHM0g3ZThZelhzMHI4dTAzTGpwaVkiXSwic3VwcG9 ydGVkVmVyc2lvbnMiOlsiMjAyNi0wNy0yOCJdLCJuYW1lIjoiZ2VvZGF0YS1zZXJ2ZXI iLCJkZXNjcmlwdGlvbiI6Ikdlb3NwYXRpYWwgbG9va3VwIHRvb2xzIiwidmVyc2lvbiI 6IjMuNC4xIiwidXJsIjoiaHR0cHM6Ly9nZW9kYXRhLmV4YW1wbGUuY29tL21jcCIsInR vb2xzIjpbeyIuLi4iOiJFQ3pjazJVSW5UeGRzTDY0bC1WclFBYXFBdVE2YmpsSXpvLXZ ZZmN5WklZIn0seyIuLi4iOiJDTmlZZi03VUZ4cE11WEhJVkJjNkVWRkw3NkM5d1hiZXh SZUcwVjEzZEdrIn0seyIuLi4iOiI2NERyei1XbWFIMnNGcVJGMUJrNXRpOXdqbWstR0x JWW5WUWlhbzBOMGZnIn1dLCJjbmYiOnsiandrIjp7Imt0eSI6IkVDIiwiY3J2IjoiUC0 yNTYiLCJ4IjoiQmdLbVV1VEo1Rm1NY2NRSV91SzYxTjdReElwZzBENVU2akowcXNPWWV PcyIsInkiOiJ4TVlJc0tzVHVYZFlGSnZQc3A1T1k1VVRTZXIxbmcwcjRQaG0wU21pM0h jIn19fQ.SiYev_dmT3yIoXPR0vlbOJASGsrs2MuJeHfQAXW-iNVPA_IBYMehKnuM3QjD Ud2ymBzq4mL6nP2q2ku8b1PzYQ~WyI0M0pXb1RQMzRMaTdjWkVNMHpJYzFBIix7Im5hb WUiOiJnZXRfZWxldmF0aW9uIiwiZGVzY3JpcHRpb24iOiJHcm91bmQgZWxldmF0aW9uI GluIG1ldGVycyBhdCBhIHBvaW50IiwiaW5wdXRTY2hlbWEiOnsidHlwZSI6Im9iamVjd CIsInByb3BlcnRpZXMiOnsibGF0Ijp7InR5cGUiOiJudW1iZXIifSwibG5nIjp7InR5c GUiOiJudW1iZXIifX0sInJlcXVpcmVkIjpbImxhdCIsImxuZyJdfX1d~WyJadXNFOVFJ c3pocFZ3NElHS3RXMUdnIix7Im5hbWUiOiJnZW9jb2RlX2FkZHJlc3MiLCJkZXNjcmlw dGlvbiI6IkNvbnZlcnRzIGFuIGFkZHJlc3MgdG8gY29vcmRpbmF0ZXMiLCJpbnB1dFNj aGVtYSI6eyJ0eXBlIjoib2JqZWN0IiwicHJvcGVydGllcyI6eyJhZGRyZXNzIjp7InR5 cGUiOiJzdHJpbmcifX0sInJlcXVpcmVkIjpbImFkZHJlc3MiXX19XQ~eyJhbGciOiJFU zI1NiIsInR5cCI6ImtiK2p3dCJ9.eyJpYXQiOjE3NjcyMjYwMDAsImF1ZCI6Imh0dHBz Oi8vY2xpZW50LmV4YW1wbGUuY29tIiwibm9uY2UiOiJ0WmlnbnNuRmJwOHRDMnJYcTBW aEd3Iiwic2RfaGFzaCI6Ilk0eG16dlVNLURsRzZxQTNERDdnOGtjOFlTb2t6UGVKRS1Y SnQ3a2ZFaW8ifQ.QpIDTDfw2SQ_wz-RHkFZu4joXbSU4l7lf9EYO2vnhPS9gieCOR_yv -omJgmC08Y5ViZPqgzvAc1VIOecj9LBjw Appendix C. PAP Binding Examples C.1. 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: Nandakumar & Jennings Expires 4 May 2027 [Page 48] Internet-Draft Agent SD-Card October 2026 { "iss": "https://registry.example.com", "sub": "https://auth.example.com", "iat": 1767225600, "exp": 1798761599, "vct": "urn:ietf:params:sd-card:pap:company-card", "_sd_alg": "sha-256", "_sd": [ "aJzNGL_UcOnRSGSvrkDEAMQL21Qh1h6CyzTP4KHCGWc", "sg-qP1wAbCVS9KJJsYkf-yuMDWNCpKpFP_l-hDyfhXU" ], "protocol_version": "0.3", "name": "Example Company", "domain": "example.com", "apis": [ { "...": "w_MX6wqpXNIBS_UtmOdpC3lOmq4mgDHJhfR52QW1mSg" }, { "...": "IafpGvOvRsjNL6PxNKTM6cxqMuEtxypTANDmPCNx1T4" } ], "scope_hints": { "_sd": [ "2Kg8ZWdLfcFdB4oXEvOT4BgSQ7QNL9fLk1H3-6POSWE", "vRmNRX7z-XbXqeyq2Q1x7y-xczk-rPf9UUWv8NmCHaQ" ] }, "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "7t0MSqKqUlkUTxPmIr8sDsRN4RTXQyKQGMGljtwKIwo", "y": "L1-V5oSxn3hkpJ-KtQq-dEyk-MqLRyMRtuKRO7CJNVc" } } } Disclosure for the openapi API: [ "qwZMxiDVer23D3BZozXQhg", { "type": "openapi", "url": "https://api.example.com/openapi.json", "description": "Orders, returns, and exchanges" } ] Nandakumar & Jennings Expires 4 May 2027 [Page 49] Internet-Draft Agent SD-Card October 2026 Encoded: WyJxd1pNeGlEVmVyMjNEM0Jab3pYUWhnIix7InR5cGUiOiJvcGVuYXBpIiwidXJsIjoi aHR0cHM6Ly9hcGkuZXhhbXBsZS5jb20vb3BlbmFwaS5qc29uIiwiZGVzY3JpcHRpb24i OiJPcmRlcnMsIHJldHVybnMsIGFuZCBleGNoYW5nZXMifV0 SHA-256 digest: w_MX6wqpXNIBS_UtmOdpC3lOmq4mgDHJhfR52QW1mSg Disclosure for the partner mcp API: [ "F4WpND3NNijo7QFlBGi7cw", { "type": "mcp", "url": "https://partners.example.com/mcp", "description": "Partner inventory and allocation" } ] Encoded: WyJGNFdwTkQzTk5pam83UUZsQkdpN2N3Iix7InR5cGUiOiJtY3AiLCJ1cmwiOiJodHRw czovL3BhcnRuZXJzLmV4YW1wbGUuY29tL21jcCIsImRlc2NyaXB0aW9uIjoiUGFydG5l ciBpbnZlbnRvcnkgYW5kIGFsbG9jYXRpb24ifV0 SHA-256 digest: IafpGvOvRsjNL6PxNKTM6cxqMuEtxypTANDmPCNx1T4 Disclosure for the orders:read scope hint: [ "h2ccxMjDltejtmbOURrwuQ", "orders:read", { "changes": "none", "personal_data": true } ] Encoded: WyJoMmNjeE1qRGx0ZWp0bWJPVVJyd3VRIiwib3JkZXJzOnJlYWQiLHsiY2hhbmdlcyI6 Im5vbmUiLCJwZXJzb25hbF9kYXRhIjp0cnVlfV0 SHA-256 digest: 2Kg8ZWdLfcFdB4oXEvOT4BgSQ7QNL9fLk1H3-6POSWE Disclosure for the orders:write scope hint: Nandakumar & Jennings Expires 4 May 2027 [Page 50] Internet-Draft Agent SD-Card October 2026 [ "cdVQTJ7Nbz0EfJBGqkaNrQ", "orders:write", { "changes": "irreversible", "personal_data": true } ] Encoded: WyJjZFZRVEo3TmJ6MEVmSkJHcWthTnJRIiwib3JkZXJzOndyaXRlIix7ImNoYW5nZXMi OiJpcnJldmVyc2libGUiLCJwZXJzb25hbF9kYXRhIjp0cnVlfV0 SHA-256 digest: vRmNRX7z-XbXqeyq2Q1x7y-xczk-rPf9UUWv8NmCHaQ Disclosure for agent: [ "jy8iZYGgKZyDEQbDtIEZog", "agent", { "protocols": [ { "type": "poppy", "endpoint": "https://api.example.com/poppy/conversations" } ] } ] Encoded: WyJqeThpWllHZ0taeURFUWJEdElFWm9nIiwiYWdlbnQiLHsicHJvdG9jb2xzIjpbeyJ0 eXBlIjoicG9wcHkiLCJlbmRwb2ludCI6Imh0dHBzOi8vYXBpLmV4YW1wbGUuY29tL3Bv cHB5L2NvbnZlcnNhdGlvbnMifV19XQ SHA-256 digest: sg-qP1wAbCVS9KJJsYkf-yuMDWNCpKpFP_l-hDyfhXU Disclosure for extensions: Nandakumar & Jennings Expires 4 May 2027 [Page 51] Internet-Draft Agent SD-Card October 2026 [ "p_r-pHAgK_c-1wO1LS7iAg", "extensions", { "ietf.org/sd-card": { "version": "1", "endpoint": "https://api.example.com/poppy/sd-card", "issuers": [ "https://registry.example.com" ], "requested_claims": [ "provider", "security_properties" ] } } ] Encoded: WyJwX3ItcEhBZ0tfYy0xd08xTFM3aUFnIiwiZXh0ZW5zaW9ucyIseyJpZXRmLm9yZy9z ZC1jYXJkIjp7InZlcnNpb24iOiIxIiwiZW5kcG9pbnQiOiJodHRwczovL2FwaS5leGFt cGxlLmNvbS9wb3BweS9zZC1jYXJkIiwiaXNzdWVycyI6WyJodHRwczovL3JlZ2lzdHJ5 LmV4YW1wbGUuY29tIl0sInJlcXVlc3RlZF9jbGFpbXMiOlsicHJvdmlkZXIiLCJzZWN1 cml0eV9wcm9wZXJ0aWVzIl19fV0 SHA-256 digest: aJzNGL_UcOnRSGSvrkDEAMQL21Qh1h6CyzTP4KHCGWc In response to the well-known URI request of Section 8.3.4, 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: { "iat": 1767226000, "aud": "https://agent.example/agent.json", "nonce": "Rk3vQ9wLx2bT7hNcYp0eAg", "sd_hash": "FKMauTf98FDbNMh781J3lgF9xyYGckbq6lXBFvPoE1U" } The presentation in compact serialization (line breaks for display only) is: Nandakumar & Jennings Expires 4 May 2027 [Page 52] Internet-Draft Agent SD-Card October 2026 eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCJ9.eyJpc3MiOiJodHRwczovL3J lZ2lzdHJ5LmV4YW1wbGUuY29tIiwic3ViIjoiaHR0cHM6Ly9hdXRoLmV4YW1wbGUuY29 tIiwiaWF0IjoxNzY3MjI1NjAwLCJleHAiOjE3OTg3NjE1OTksInZjdCI6InVybjppZXR mOnBhcmFtczpzZC1jYXJkOnBhcDpjb21wYW55LWNhcmQiLCJfc2RfYWxnIjoic2hhLTI 1NiIsIl9zZCI6WyJhSnpOR0xfVWNPblJTR1N2cmtERUFNUUwyMVFoMWg2Q3l6VFA0S0h DR1djIiwic2ctcVAxd0FiQ1ZTOUtKSnNZa2YteXVNRFdOQ3BLcEZQX2wtaER5ZmhYVSJ dLCJwcm90b2NvbF92ZXJzaW9uIjoiMC4zIiwibmFtZSI6IkV4YW1wbGUgQ29tcGFueSI sImRvbWFpbiI6ImV4YW1wbGUuY29tIiwiYXBpcyI6W3siLi4uIjoid19NWDZ3cXBYTkl CU19VdG1PZHBDM2xPbXE0bWdESEpoZlI1MlFXMW1TZyJ9LHsiLi4uIjoiSWFmcEd2T3Z Sc2pOTDZQeE5LVE02Y3hxTXVFdHh5cFRBTkRtUENOeDFUNCJ9XSwic2NvcGVfaGludHM iOnsiX3NkIjpbIjJLZzhaV2RMZmNGZEI0b1hFdk9UNEJnU1E3UU5MOWZMazFIMy02UE9 TV0UiLCJ2Um1OUlg3ei1YYlhxZXlxMlExeDd5LXhjemstclBmOVVVV3Y4Tm1DSGFRIl1 9LCJjbmYiOnsiandrIjp7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjoiN3QwTVN xS3FVbGtVVHhQbUlyOHNEc1JONFJUWFF5S1FHTUdsanR3S0l3byIsInkiOiJMMS1WNW9 TeG4zaGtwSi1LdFFxLWRFeWstTXFMUnlNUnR1S1JPN0NKTlZjIn19fQ.366IbF-FHT7C 3Rer8fJFAJjol9kYUqrr5IpJW3wCgf5u96TmoHBDAYWV_lWvs7GdFKFkTFsQW-QEXsGl FZS16A~WyJxd1pNeGlEVmVyMjNEM0Jab3pYUWhnIix7InR5cGUiOiJvcGVuYXBpIiwid XJsIjoiaHR0cHM6Ly9hcGkuZXhhbXBsZS5jb20vb3BlbmFwaS5qc29uIiwiZGVzY3Jpc HRpb24iOiJPcmRlcnMsIHJldHVybnMsIGFuZCBleGNoYW5nZXMifV0~WyJoMmNjeE1qR Gx0ZWp0bWJPVVJyd3VRIiwib3JkZXJzOnJlYWQiLHsiY2hhbmdlcyI6Im5vbmUiLCJwZ XJzb25hbF9kYXRhIjp0cnVlfV0~WyJjZFZRVEo3TmJ6MEVmSkJHcWthTnJRIiwib3JkZ XJzOndyaXRlIix7ImNoYW5nZXMiOiJpcnJldmVyc2libGUiLCJwZXJzb25hbF9kYXRhI jp0cnVlfV0~WyJqeThpWllHZ0taeURFUWJEdElFWm9nIiwiYWdlbnQiLHsicHJvdG9jb 2xzIjpbeyJ0eXBlIjoicG9wcHkiLCJlbmRwb2ludCI6Imh0dHBzOi8vYXBpLmV4YW1wb GUuY29tL3BvcHB5L2NvbnZlcnNhdGlvbnMifV19XQ~WyJwX3ItcEhBZ0tfYy0xd08xTF M3aUFnIiwiZXh0ZW5zaW9ucyIseyJpZXRmLm9yZy9zZC1jYXJkIjp7InZlcnNpb24iOi IxIiwiZW5kcG9pbnQiOiJodHRwczovL2FwaS5leGFtcGxlLmNvbS9wb3BweS9zZC1jYX JkIiwiaXNzdWVycyI6WyJodHRwczovL3JlZ2lzdHJ5LmV4YW1wbGUuY29tIl0sInJlcX Vlc3RlZF9jbGFpbXMiOlsicHJvdmlkZXIiLCJzZWN1cml0eV9wcm9wZXJ0aWVzIl19fV 0~eyJhbGciOiJFUzI1NiIsInR5cCI6ImtiK2p3dCJ9.eyJpYXQiOjE3NjcyMjYwMDAsI mF1ZCI6Imh0dHBzOi8vYWdlbnQuZXhhbXBsZS9hZ2VudC5qc29uIiwibm9uY2UiOiJSa zN2UTl3THgyYlQ3aE5jWXAwZUFnIiwic2RfaGFzaCI6IkZLTWF1VGY5OEZEYk5NaDc4M UozbGdGOXh5WUdja2JxNmxYQkZ2UG9FMVUifQ.3lgUcbQOVSyrl6kxxKYzJWFDb5fgau hYXslpaBcqUvgbkxE4UJT2Dmrd8HzukC_X9njPItfA8ZrF-0uNX6gReQ C.2. 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: Nandakumar & Jennings Expires 4 May 2027 [Page 53] Internet-Draft Agent SD-Card October 2026 { "iss": "https://registry.example.com", "sub": "https://agent.example/agent.json", "iat": 1767225600, "exp": 1798761599, "vct": "urn:ietf:params:sd-card:pap:agent-card", "_sd_alg": "sha-256", "_sd": [ "6GH6iySztz_L0xpX5ce1nEY8yPrcxdIyaz26LjJAHvE", "IJcMSmlhJnlyBEhT7dK_XkipF2bVnwCAED96nvCMUhU", "Z3k4HY1r2Gs4jbFwgpY7-RqfU1SHs6DSaciAfxm25eM" ], "name": "Example Agent", "jwks_uri": "https://agent.example/jwks.json", "security_properties": { "_sd": [ "3c8QcgcCSVQz_T-AOADYnO1AKRePLuHRgzElBF8nJQo", "FDol_qww2o5PoREm36vRo_zBlg6-g5Xjrv7OA_sXAuQ", "g17S5l2qGRploiJEjPKaRRD8PAIW4TT-lJPd0I--iOE" ] }, "certifications": [ { "...": "9KbSANcu1LgcE_XauEaZspHMoASVMg8iz6bM-mBxYQM" } ], "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "rcb61_FGgWZhmA2QjsS3vkcei7Jk0DzjL8VHIKgsmms", "y": "48ZSN62KUwUpeiFONBkLb41MGbFF1HR0LWneXqWXav4" } } } Disclosure for blind_signing: [ "4Gg1rgvbL66FGIj2VN_aKQ", "blind_signing", false ] Nandakumar & Jennings Expires 4 May 2027 [Page 54] Internet-Draft Agent SD-Card October 2026 Encoded: WyI0R2cxcmd2Ykw2NkZHSWoyVk5fYUtRIiwiYmxpbmRfc2lnbmluZyIsZmFsc2Vd SHA-256 digest: 3c8QcgcCSVQz_T-AOADYnO1AKRePLuHRgzElBF8nJQo Disclosure for delegated_keys_on_device: [ "eQnWZvK4tybxYY2FYGwBBg", "delegated_keys_on_device", true ] Encoded: WyJlUW5XWnZLNHR5YnhZWTJGWUd3QkJnIiwiZGVsZWdhdGVkX2tleXNfb25fZGV2aWNl Iix0cnVlXQ SHA-256 digest: g17S5l2qGRploiJEjPKaRRD8PAIW4TT-lJPd0I--iOE Disclosure for model_isolated_secrets: [ "HChNKl55M2gT582qrg3LjQ", "model_isolated_secrets", true ] Encoded: WyJIQ2hOS2w1NU0yZ1Q1ODJxcmczTGpRIiwibW9kZWxfaXNvbGF0ZWRfc2VjcmV0cyIs dHJ1ZV0 SHA-256 digest: FDol_qww2o5PoREm36vRo_zBlg6-g5Xjrv7OA_sXAuQ Disclosure for the certification: [ "Nu6kNUoGQZRGk8yOqTwiQA", { "scheme": "https://certs.example/agent-security", "id": "cert-2026-0042" } ] Nandakumar & Jennings Expires 4 May 2027 [Page 55] Internet-Draft Agent SD-Card October 2026 Encoded: WyJOdTZrTlVvR1FaUkdrOHlPcVR3aVFBIix7InNjaGVtZSI6Imh0dHBzOi8vY2VydHMu ZXhhbXBsZS9hZ2VudC1zZWN1cml0eSIsImlkIjoiY2VydC0yMDI2LTAwNDIifV0 SHA-256 digest: 9KbSANcu1LgcE_XauEaZspHMoASVMg8iz6bM-mBxYQM Disclosure for provider: [ "CtM3U1ZlCBQiG1_K4Ox2sA", "provider", { "organization": "Example Agent Co.", "url": "https://agent.example" } ] Encoded: WyJDdE0zVTFabENCUWlHMV9LNE94MnNBIiwicHJvdmlkZXIiLHsib3JnYW5pemF0aW9u IjoiRXhhbXBsZSBBZ2VudCBDby4iLCJ1cmwiOiJodHRwczovL2FnZW50LmV4YW1wbGUi fV0 SHA-256 digest: Z3k4HY1r2Gs4jbFwgpY7-RqfU1SHs6DSaciAfxm25eM Disclosure for logo_uri: [ "u7baxWrx0KJuH9BJvjfOwA", "logo_uri", "https://agent.example/logo.png" ] Encoded: WyJ1N2JheFdyeDBLSnVIOUJKdmpmT3dBIiwibG9nb191cmkiLCJodHRwczovL2FnZW50 LmV4YW1wbGUvbG9nby5wbmciXQ SHA-256 digest: 6GH6iySztz_L0xpX5ce1nEY8yPrcxdIyaz26LjJAHvE Disclosure for extensions: Nandakumar & Jennings Expires 4 May 2027 [Page 56] Internet-Draft Agent SD-Card October 2026 [ "5n-80cLz7bLHvbjwYKu82w", "extensions", { "ietf.org/sd-card": { "version": "1" } } ] Encoded: WyI1bi04MGNMejdiTEh2Ymp3WUt1ODJ3IiwiZXh0ZW5zaW9ucyIseyJpZXRmLm9yZy9z ZC1jYXJkIjp7InZlcnNpb24iOiIxIn19XQ SHA-256 digest: IJcMSmlhJnlyBEhT7dK_XkipF2bVnwCAED96nvCMUhU In the request of Section 8.3.5, 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: { "iat": 1767226000, "aud": "https://auth.example.com", "nonce": "e1j3V_bKic8-LAEBq7Rw2g", "sd_hash": "8skcG11PG2LRWQap36R1YbRuA5pXcel7SGEOy1ti8b8" } The presentation in compact serialization (line breaks for display only) is: Nandakumar & Jennings Expires 4 May 2027 [Page 57] Internet-Draft Agent SD-Card October 2026 eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCJ9.eyJpc3MiOiJodHRwczovL3J lZ2lzdHJ5LmV4YW1wbGUuY29tIiwic3ViIjoiaHR0cHM6Ly9hZ2VudC5leGFtcGxlL2F nZW50Lmpzb24iLCJpYXQiOjE3NjcyMjU2MDAsImV4cCI6MTc5ODc2MTU5OSwidmN0Ijo idXJuOmlldGY6cGFyYW1zOnNkLWNhcmQ6cGFwOmFnZW50LWNhcmQiLCJfc2RfYWxnIjo ic2hhLTI1NiIsIl9zZCI6WyI2R0g2aXlTenR6X0wweHBYNWNlMW5FWTh5UHJjeGRJeWF 6MjZMakpBSHZFIiwiSUpjTVNtbGhKbmx5QkVoVDdkS19Ya2lwRjJiVm53Q0FFRDk2bnZ DTVVoVSIsIlozazRIWTFyMkdzNGpiRndncFk3LVJxZlUxU0hzNkRTYWNpQWZ4bTI1ZU0 iXSwibmFtZSI6IkV4YW1wbGUgQWdlbnQiLCJqd2tzX3VyaSI6Imh0dHBzOi8vYWdlbnQ uZXhhbXBsZS9qd2tzLmpzb24iLCJzZWN1cml0eV9wcm9wZXJ0aWVzIjp7Il9zZCI6WyI zYzhRY2djQ1NWUXpfVC1BT0FEWW5PMUFLUmVQTHVIUmd6RWxCRjhuSlFvIiwiRkRvbF9 xd3cybzVQb1JFbTM2dlJvX3pCbGc2LWc1WGpydjdPQV9zWEF1USIsImcxN1M1bDJxR1J wbG9pSkVqUEthUlJEOFBBSVc0VFQtbEpQZDBJLS1pT0UiXX0sImNlcnRpZmljYXRpb25 zIjpbeyIuLi4iOiI5S2JTQU5jdTFMZ2NFX1hhdUVhWnNwSE1vQVNWTWc4aXo2Yk0tbUJ 4WVFNIn1dLCJjbmYiOnsiandrIjp7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4Ijo icmNiNjFfRkdnV1pobUEyUWpzUzN2a2NlaTdKazBEempMOFZISUtnc21tcyIsInkiOiI 0OFpTTjYyS1V3VXBlaUZPTkJrTGI0MU1HYkZGMUhSMExXbmVYcVdYYXY0In19fQ.OgpT _UvOg4nC-vfvDQcCs-ffY3U3ty40FyXZJKnTo35xAF4oKbBFvFPoJ3DKFrssFmM-bnXv 7KttSIwwy3jpQw~WyJDdE0zVTFabENCUWlHMV9LNE94MnNBIiwicHJvdmlkZXIiLHsib 3JnYW5pemF0aW9uIjoiRXhhbXBsZSBBZ2VudCBDby4iLCJ1cmwiOiJodHRwczovL2FnZ W50LmV4YW1wbGUifV0~WyI0R2cxcmd2Ykw2NkZHSWoyVk5fYUtRIiwiYmxpbmRfc2lnb mluZyIsZmFsc2Vd~WyJIQ2hOS2w1NU0yZ1Q1ODJxcmczTGpRIiwibW9kZWxfaXNvbGF0 ZWRfc2VjcmV0cyIsdHJ1ZV0~eyJhbGciOiJFUzI1NiIsInR5cCI6ImtiK2p3dCJ9.eyJ pYXQiOjE3NjcyMjYwMDAsImF1ZCI6Imh0dHBzOi8vYXV0aC5leGFtcGxlLmNvbSIsIm5 vbmNlIjoiZTFqM1ZfYktpYzgtTEFFQnE3UncyZyIsInNkX2hhc2giOiI4c2tjRzExUEc yTFJXUWFwMzZSMVliUnVBNXBYY2VsN1NHRU95MXRpOGI4In0.Pvjl6-08FHeQRsuZuE5 AUrxJaqNOZ_oU5xfQseay0IhCvWijlZzA0X_hDZdBGwDE993eC6XBu1IddZIkwFuSWw Appendix D. A2A Binding Examples The examples in this appendix are for an agent with the following native Agent Card (the signatures member is omitted): { "name": "GeoSpatial Route Planner Agent", "description": "Route planning and traffic analysis", "version": "1.2.0", "supportedInterfaces": [ { "url": "https://georoute-agent.example.com/a2a/v1", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" }, { "url": "https://georoute-agent.example.com/a2a/grpc", "protocolBinding": "GRPC", "protocolVersion": "1.0" }, { Nandakumar & Jennings Expires 4 May 2027 [Page 58] Internet-Draft Agent SD-Card October 2026 "url": "https://georoute-agent.example.com/a2a/json", "protocolBinding": "HTTP+JSON", "protocolVersion": "1.0" } ], "skills": [ { "id": "route-optimizer-traffic", "name": "Traffic-Aware Route Optimizer", "description": "Optimal driving routes with live traffic", "tags": [ "maps", "routing", "navigation", "traffic" ], "examples": [ "Plan a route from Mountain View to SFO avoiding tolls." ], "inputModes": [ "application/json", "text/plain" ], "outputModes": [ "application/json", "application/vnd.geo+json" ] }, { "id": "custom-map-generator", "name": "Personalized Map Generator", "description": "Custom map images from points of interest", "tags": [ "maps", "customization", "visualization" ], "examples": [ "Generate a map of my road trip with all stops marked." ], "inputModes": [ "application/json" ], "outputModes": [ "image/png", "image/jpeg" ] } Nandakumar & Jennings Expires 4 May 2027 [Page 59] Internet-Draft Agent SD-Card October 2026 ], "capabilities": { "streaming": true, "pushNotifications": true, "extendedAgentCard": true, "extensions": [ { "uri": "urn:ietf:params:sd-card:a2a", "description": "SD-Card key-bound presentation", "required": false } ] }, "securitySchemes": { "bearer": { "httpAuthSecurityScheme": { "scheme": "Bearer", "bearerFormat": "JWT" } }, "apiKey": { "apiKeySecurityScheme": { "location": "header", "name": "X-API-Key" } } }, "securityRequirements": [ { "schemes": { "bearer": { "list": [ "route.read" ] } } }, { "schemes": { "apiKey": { "list": [] } } } ], "provider": { "organization": "Example Geo Services Inc.", "url": "https://www.examplegeoservices.com" Nandakumar & Jennings Expires 4 May 2027 [Page 60] Internet-Draft Agent SD-Card October 2026 }, "defaultInputModes": [ "application/json", "text/plain" ], "defaultOutputModes": [ "application/json", "image/png" ], "documentationUrl": "https://docs.example.com/georoute/api", "iconUrl": "https://georoute-agent.example.com/icon.png" } Its SD-Card has the following issuer-signed JWT payload. The digests in the top-level _sd array are sorted, as recommended by [RFC9901], 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: { "iss": "https://registry.example.com", "sub": "agent:georoute-planner-v1", "iat": 1767225600, "exp": 1798761599, "vct": "urn:ietf:params:sd-card:a2a:agent-card", "_sd_alg": "sha-256", "_sd": [ "AWAL2ayXi0cd7csdXv_sXidFYqlhZX9be5iomHYHkec", "BOvhArNcCssa1U0_6YWQGqA2DYYLI8bFNfhmMBQ55Fo", "EZd-DNHuqQD0bRRxnL7TIEIfTIHgD-hPaKVChtlRT4M", "FgbvYfB6JqdEjNxyF05bfsrWSCH7mkWxAi28QD9iIqw", "GMNvMxuapmwYAyFC-WKO6WxBZbM5sEDEx_2oKKzpNvY", "STPLV1FuTajpbbKxf8BzKcl5VqNbr_qr97txspH5Jg0", "xBKXSxbl8v-6sqqcLTWyepSa_IAWsan4tLVM26NWhe4", "zqQAwSfFlKrkTIJBUv_CHBIB2_6iR4nv4ZC_tCvpPnU" ], "name": "GeoSpatial Route Planner Agent", "description": "Route planning and traffic analysis", "version": "1.2.0", "supportedInterfaces": [ { "...": "W7W2L92tnRYd4koIzVIhlAPfSzhLEAUAGl3hF93fQgg" }, { "...": "oKwVkXTM0mZZESMbDqCK4vym2r9QNCtUL_6ml88gdtw" }, { "...": "WFN8IW9crHJ7CfZzH6CtP43gRzqMeVTgbhGSU883XNg" Nandakumar & Jennings Expires 4 May 2027 [Page 61] Internet-Draft Agent SD-Card October 2026 } ], "skills": [ { "...": "1AHkDy9GmVjWbXthKSb9jpPWjfMWi9BACM07gTRI4DY" }, { "...": "YtdzrPs6Jh2f-75QXW2FCNFSxUr9RajZ-W3MvH2W3GY" } ], "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "NRV8L0GsHzQL4auGECf1EuQAAbWQDnZPp_rY1Iopvn0", "y": "uTOlnJ2S83z6DM7r0_pvVemMtsefFm-Lk4oiwHNbF5o" } } } Disclosure for the JSONRPC interface: [ "WTNDgkT7wkj4FrdZrh8NVQ", { "url": "https://georoute-agent.example.com/a2a/v1", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" } ] Encoded: WyJXVE5EZ2tUN3drajRGcmRacmg4TlZRIix7InVybCI6Imh0dHBzOi8vZ2Vvcm91dGUt YWdlbnQuZXhhbXBsZS5jb20vYTJhL3YxIiwicHJvdG9jb2xCaW5kaW5nIjoiSlNPTlJQ QyIsInByb3RvY29sVmVyc2lvbiI6IjEuMCJ9XQ SHA-256 digest: W7W2L92tnRYd4koIzVIhlAPfSzhLEAUAGl3hF93fQgg Disclosure for the GRPC interface: Nandakumar & Jennings Expires 4 May 2027 [Page 62] Internet-Draft Agent SD-Card October 2026 [ "kgioGea_nc4e26NCTOXodw", { "url": "https://georoute-agent.example.com/a2a/grpc", "protocolBinding": "GRPC", "protocolVersion": "1.0" } ] Encoded: WyJrZ2lvR2VhX25jNGUyNk5DVE9Yb2R3Iix7InVybCI6Imh0dHBzOi8vZ2Vvcm91dGUt YWdlbnQuZXhhbXBsZS5jb20vYTJhL2dycGMiLCJwcm90b2NvbEJpbmRpbmciOiJHUlBD IiwicHJvdG9jb2xWZXJzaW9uIjoiMS4wIn1d SHA-256 digest: oKwVkXTM0mZZESMbDqCK4vym2r9QNCtUL_6ml88gdtw Disclosure for the HTTP+JSON interface: [ "BHsoR5aBrcLKwndvjlZJ3g", { "url": "https://georoute-agent.example.com/a2a/json", "protocolBinding": "HTTP+JSON", "protocolVersion": "1.0" } ] Encoded: WyJCSHNvUjVhQnJjTEt3bmR2amxaSjNnIix7InVybCI6Imh0dHBzOi8vZ2Vvcm91dGUt YWdlbnQuZXhhbXBsZS5jb20vYTJhL2pzb24iLCJwcm90b2NvbEJpbmRpbmciOiJIVFRQ K0pTT04iLCJwcm90b2NvbFZlcnNpb24iOiIxLjAifV0 SHA-256 digest: WFN8IW9crHJ7CfZzH6CtP43gRzqMeVTgbhGSU883XNg Disclosure for the route-optimizer-traffic skill: Nandakumar & Jennings Expires 4 May 2027 [Page 63] Internet-Draft Agent SD-Card October 2026 [ "JcXyRSV5CQSPZ9IJkklUow", { "id": "route-optimizer-traffic", "name": "Traffic-Aware Route Optimizer", "description": "Optimal driving routes with live traffic", "tags": [ "maps", "routing", "navigation", "traffic" ], "examples": [ "Plan a route from Mountain View to SFO avoiding tolls." ], "inputModes": [ "application/json", "text/plain" ], "outputModes": [ "application/json", "application/vnd.geo+json" ] } ] Encoded: WyJKY1h5UlNWNUNRU1BaOUlKa2tsVW93Iix7ImlkIjoicm91dGUtb3B0aW1pemVyLXRy YWZmaWMiLCJuYW1lIjoiVHJhZmZpYy1Bd2FyZSBSb3V0ZSBPcHRpbWl6ZXIiLCJkZXNj cmlwdGlvbiI6Ik9wdGltYWwgZHJpdmluZyByb3V0ZXMgd2l0aCBsaXZlIHRyYWZmaWMi LCJ0YWdzIjpbIm1hcHMiLCJyb3V0aW5nIiwibmF2aWdhdGlvbiIsInRyYWZmaWMiXSwi ZXhhbXBsZXMiOlsiUGxhbiBhIHJvdXRlIGZyb20gTW91bnRhaW4gVmlldyB0byBTRk8g YXZvaWRpbmcgdG9sbHMuIl0sImlucHV0TW9kZXMiOlsiYXBwbGljYXRpb24vanNvbiIs InRleHQvcGxhaW4iXSwib3V0cHV0TW9kZXMiOlsiYXBwbGljYXRpb24vanNvbiIsImFw cGxpY2F0aW9uL3ZuZC5nZW8ranNvbiJdfV0 SHA-256 digest: 1AHkDy9GmVjWbXthKSb9jpPWjfMWi9BACM07gTRI4DY Disclosure for the custom-map-generator skill: Nandakumar & Jennings Expires 4 May 2027 [Page 64] Internet-Draft Agent SD-Card October 2026 [ "p5CehwGx-qdqIB__xjYklg", { "id": "custom-map-generator", "name": "Personalized Map Generator", "description": "Custom map images from points of interest", "tags": [ "maps", "customization", "visualization" ], "examples": [ "Generate a map of my road trip with all stops marked." ], "inputModes": [ "application/json" ], "outputModes": [ "image/png", "image/jpeg" ] } ] Encoded: WyJwNUNlaHdHeC1xZHFJQl9feGpZa2xnIix7ImlkIjoiY3VzdG9tLW1hcC1nZW5lcmF0 b3IiLCJuYW1lIjoiUGVyc29uYWxpemVkIE1hcCBHZW5lcmF0b3IiLCJkZXNjcmlwdGlv biI6IkN1c3RvbSBtYXAgaW1hZ2VzIGZyb20gcG9pbnRzIG9mIGludGVyZXN0IiwidGFn cyI6WyJtYXBzIiwiY3VzdG9taXphdGlvbiIsInZpc3VhbGl6YXRpb24iXSwiZXhhbXBs ZXMiOlsiR2VuZXJhdGUgYSBtYXAgb2YgbXkgcm9hZCB0cmlwIHdpdGggYWxsIHN0b3Bz IG1hcmtlZC4iXSwiaW5wdXRNb2RlcyI6WyJhcHBsaWNhdGlvbi9qc29uIl0sIm91dHB1 dE1vZGVzIjpbImltYWdlL3BuZyIsImltYWdlL2pwZWciXX1d SHA-256 digest: YtdzrPs6Jh2f-75QXW2FCNFSxUr9RajZ-W3MvH2W3GY Disclosure for capabilities: Nandakumar & Jennings Expires 4 May 2027 [Page 65] Internet-Draft Agent SD-Card October 2026 [ "aizVNSQQSkX9N88wd6a0ng", "capabilities", { "streaming": true, "pushNotifications": true, "extendedAgentCard": true, "extensions": [ { "uri": "urn:ietf:params:sd-card:a2a", "description": "SD-Card key-bound presentation", "required": false } ] } ] Encoded: WyJhaXpWTlNRUVNrWDlOODh3ZDZhMG5nIiwiY2FwYWJpbGl0aWVzIix7InN0cmVhbWlu ZyI6dHJ1ZSwicHVzaE5vdGlmaWNhdGlvbnMiOnRydWUsImV4dGVuZGVkQWdlbnRDYXJk Ijp0cnVlLCJleHRlbnNpb25zIjpbeyJ1cmkiOiJ1cm46aWV0ZjpwYXJhbXM6c2QtY2Fy ZDphMmEiLCJkZXNjcmlwdGlvbiI6IlNELUNhcmQga2V5LWJvdW5kIHByZXNlbnRhdGlv biIsInJlcXVpcmVkIjpmYWxzZX1dfV0 SHA-256 digest: EZd-DNHuqQD0bRRxnL7TIEIfTIHgD-hPaKVChtlRT4M Disclosure for securitySchemes: [ "ATmAiwGeb2dopQumqW3EyQ", "securitySchemes", { "bearer": { "httpAuthSecurityScheme": { "scheme": "Bearer", "bearerFormat": "JWT" } }, "apiKey": { "apiKeySecurityScheme": { "location": "header", "name": "X-API-Key" } } } ] Nandakumar & Jennings Expires 4 May 2027 [Page 66] Internet-Draft Agent SD-Card October 2026 Encoded: WyJBVG1BaXdHZWIyZG9wUXVtcVczRXlRIiwic2VjdXJpdHlTY2hlbWVzIix7ImJlYXJl ciI6eyJodHRwQXV0aFNlY3VyaXR5U2NoZW1lIjp7InNjaGVtZSI6IkJlYXJlciIsImJl YXJlckZvcm1hdCI6IkpXVCJ9fSwiYXBpS2V5Ijp7ImFwaUtleVNlY3VyaXR5U2NoZW1l Ijp7ImxvY2F0aW9uIjoiaGVhZGVyIiwibmFtZSI6IlgtQVBJLUtleSJ9fX1d SHA-256 digest: zqQAwSfFlKrkTIJBUv_CHBIB2_6iR4nv4ZC_tCvpPnU Disclosure for securityRequirements: [ "72KzFibaBhxIEEO_BfkUBQ", "securityRequirements", [ { "schemes": { "bearer": { "list": [ "route.read" ] } } }, { "schemes": { "apiKey": { "list": [] } } } ] ] Encoded: WyI3Mkt6RmliYUJoeElFRU9fQmZrVUJRIiwic2VjdXJpdHlSZXF1aXJlbWVudHMiLFt7 InNjaGVtZXMiOnsiYmVhcmVyIjp7Imxpc3QiOlsicm91dGUucmVhZCJdfX19LHsic2No ZW1lcyI6eyJhcGlLZXkiOnsibGlzdCI6W119fX1dXQ SHA-256 digest: FgbvYfB6JqdEjNxyF05bfsrWSCH7mkWxAi28QD9iIqw Disclosure for provider: Nandakumar & Jennings Expires 4 May 2027 [Page 67] Internet-Draft Agent SD-Card October 2026 [ "DlLAMK9B5fBfGXBAtzkXcw", "provider", { "organization": "Example Geo Services Inc.", "url": "https://www.examplegeoservices.com" } ] Encoded: WyJEbExBTUs5QjVmQmZHWEJBdHprWGN3IiwicHJvdmlkZXIiLHsib3JnYW5pemF0aW9u IjoiRXhhbXBsZSBHZW8gU2VydmljZXMgSW5jLiIsInVybCI6Imh0dHBzOi8vd3d3LmV4 YW1wbGVnZW9zZXJ2aWNlcy5jb20ifV0 SHA-256 digest: AWAL2ayXi0cd7csdXv_sXidFYqlhZX9be5iomHYHkec Disclosure for defaultInputModes: [ "skk6w1xqLNRjlbApRHf4ZQ", "defaultInputModes", [ "application/json", "text/plain" ] ] Encoded: WyJza2s2dzF4cUxOUmpsYkFwUkhmNFpRIiwiZGVmYXVsdElucHV0TW9kZXMiLFsiYXBw bGljYXRpb24vanNvbiIsInRleHQvcGxhaW4iXV0 SHA-256 digest: BOvhArNcCssa1U0_6YWQGqA2DYYLI8bFNfhmMBQ55Fo Disclosure for defaultOutputModes: [ "bZn5ISqDUwQ74wv61Uj7hw", "defaultOutputModes", [ "application/json", "image/png" ] ] Nandakumar & Jennings Expires 4 May 2027 [Page 68] Internet-Draft Agent SD-Card October 2026 Encoded: WyJiWm41SVNxRFV3UTc0d3Y2MVVqN2h3IiwiZGVmYXVsdE91dHB1dE1vZGVzIixbImFw cGxpY2F0aW9uL2pzb24iLCJpbWFnZS9wbmciXV0 SHA-256 digest: STPLV1FuTajpbbKxf8BzKcl5VqNbr_qr97txspH5Jg0 Disclosure for documentationUrl: [ "E2M7EMPjNPenCRdFr6yTsg", "documentationUrl", "https://docs.example.com/georoute/api" ] Encoded: WyJFMk03RU1Qak5QZW5DUmRGcjZ5VHNnIiwiZG9jdW1lbnRhdGlvblVybCIsImh0dHBz Oi8vZG9jcy5leGFtcGxlLmNvbS9nZW9yb3V0ZS9hcGkiXQ SHA-256 digest: GMNvMxuapmwYAyFC-WKO6WxBZbM5sEDEx_2oKKzpNvY Disclosure for iconUrl: [ "of-8J5G2jl1VX7yRAPITzA", "iconUrl", "https://georoute-agent.example.com/icon.png" ] Encoded: WyJvZi04SjVHMmpsMVZYN3lSQVBJVHpBIiwiaWNvblVybCIsImh0dHBzOi8vZ2Vvcm91 dGUtYWdlbnQuZXhhbXBsZS5jb20vaWNvbi5wbmciXQ SHA-256 digest: xBKXSxbl8v-6sqqcLTWyepSa_IAWsan4tLVM26NWhe4 For the public context of the registration example (Section 4.4), the agent discloses its first interface and skill and its default input and output modes. Responding to the activation of the SD-Card extension (Section 8.4.4), it adds a Key Binding JWT. The Key Binding JWT has the header {"alg": "ES256", "typ": "kb+jwt"} and the following payload: Nandakumar & Jennings Expires 4 May 2027 [Page 69] Internet-Draft Agent SD-Card October 2026 { "iat": 1767226000, "aud": "https://client.example.com", "nonce": "8xk2Nq4ZpR0vWm3TfL7cHg", "sd_hash": "8i7sLfsLeUks8T61y4AGtJT0Yn1CfPGCXnW5XUiZRb8", "interaction_id": "12345678-1234-1234-1234-123456789abc" } The presentation in compact serialization (line breaks for display only) is: Nandakumar & Jennings Expires 4 May 2027 [Page 70] Internet-Draft Agent SD-Card October 2026 eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCJ9.eyJpc3MiOiJodHRwczovL3J lZ2lzdHJ5LmV4YW1wbGUuY29tIiwic3ViIjoiYWdlbnQ6Z2Vvcm91dGUtcGxhbm5lci1 2MSIsImlhdCI6MTc2NzIyNTYwMCwiZXhwIjoxNzk4NzYxNTk5LCJ2Y3QiOiJ1cm46aWV 0ZjpwYXJhbXM6c2QtY2FyZDphMmE6YWdlbnQtY2FyZCIsIl9zZF9hbGciOiJzaGEtMjU 2IiwiX3NkIjpbIkFXQUwyYXlYaTBjZDdjc2RYdl9zWGlkRllxbGhaWDliZTVpb21IWUh rZWMiLCJCT3ZoQXJOY0Nzc2ExVTBfNllXUUdxQTJEWVlMSThiRk5maG1NQlE1NUZvIiw iRVpkLUROSHVxUUQwYlJSeG5MN1RJRUlmVElIZ0QtaFBhS1ZDaHRsUlQ0TSIsIkZnYnZ ZZkI2SnFkRWpOeHlGMDViZnNyV1NDSDdta1d4QWkyOFFEOWlJcXciLCJHTU52TXh1YXB td1lBeUZDLVdLTzZXeEJaYk01c0VERXhfMm9LS3pwTnZZIiwiU1RQTFYxRnVUYWpwYmJ LeGY4QnpLY2w1VnFOYnJfcXI5N3R4c3BINUpnMCIsInhCS1hTeGJsOHYtNnNxcWNMVFd 5ZXBTYV9JQVdzYW40dExWTTI2TldoZTQiLCJ6cVFBd1NmRmxLcmtUSUpCVXZfQ0hCSUI yXzZpUjRudjRaQ190Q3ZwUG5VIl0sIm5hbWUiOiJHZW9TcGF0aWFsIFJvdXRlIFBsYW5 uZXIgQWdlbnQiLCJkZXNjcmlwdGlvbiI6IlJvdXRlIHBsYW5uaW5nIGFuZCB0cmFmZml jIGFuYWx5c2lzIiwidmVyc2lvbiI6IjEuMi4wIiwic3VwcG9ydGVkSW50ZXJmYWNlcyI 6W3siLi4uIjoiVzdXMkw5MnRuUllkNGtvSXpWSWhsQVBmU3poTEVBVUFHbDNoRjkzZlF nZyJ9LHsiLi4uIjoib0t3VmtYVE0wbVpaRVNNYkRxQ0s0dnltMnI5UU5DdFVMXzZtbDg 4Z2R0dyJ9LHsiLi4uIjoiV0ZOOElXOWNySEo3Q2Zaekg2Q3RQNDNnUnpxTWVWVGdiaEd TVTg4M1hOZyJ9XSwic2tpbGxzIjpbeyIuLi4iOiIxQUhrRHk5R21WaldiWHRoS1NiOWp wUFdqZk1XaTlCQUNNMDdnVFJJNERZIn0seyIuLi4iOiJZdGR6clBzNkpoMmYtNzVRWFc yRkNORlN4VXI5UmFqWi1XM012SDJXM0dZIn1dLCJjbmYiOnsiandrIjp7Imt0eSI6IkV DIiwiY3J2IjoiUC0yNTYiLCJ4IjoiTlJWOEwwR3NIelFMNGF1R0VDZjFFdVFBQWJXUUR uWlBwX3JZMUlvcHZuMCIsInkiOiJ1VE9sbkoyUzgzejZETTdyMF9wdlZlbU10c2VmRm0 tTGs0b2l3SE5iRjVvIn19fQ.O7TMP6ZKTDIdBAIREumTIn9tBCo350YE-7oHzVuqrC6J JwLdXoB7cSDpx_Ug7SpIw0u75BA996X4B7gCxTb3nQ~WyJXVE5EZ2tUN3drajRGcmRac mg4TlZRIix7InVybCI6Imh0dHBzOi8vZ2Vvcm91dGUtYWdlbnQuZXhhbXBsZS5jb20vY TJhL3YxIiwicHJvdG9jb2xCaW5kaW5nIjoiSlNPTlJQQyIsInByb3RvY29sVmVyc2lvb iI6IjEuMCJ9XQ~WyJKY1h5UlNWNUNRU1BaOUlKa2tsVW93Iix7ImlkIjoicm91dGUtb3 B0aW1pemVyLXRyYWZmaWMiLCJuYW1lIjoiVHJhZmZpYy1Bd2FyZSBSb3V0ZSBPcHRpbW l6ZXIiLCJkZXNjcmlwdGlvbiI6Ik9wdGltYWwgZHJpdmluZyByb3V0ZXMgd2l0aCBsaX ZlIHRyYWZmaWMiLCJ0YWdzIjpbIm1hcHMiLCJyb3V0aW5nIiwibmF2aWdhdGlvbiIsIn RyYWZmaWMiXSwiZXhhbXBsZXMiOlsiUGxhbiBhIHJvdXRlIGZyb20gTW91bnRhaW4gVm lldyB0byBTRk8gYXZvaWRpbmcgdG9sbHMuIl0sImlucHV0TW9kZXMiOlsiYXBwbGljYX Rpb24vanNvbiIsInRleHQvcGxhaW4iXSwib3V0cHV0TW9kZXMiOlsiYXBwbGljYXRpb2 4vanNvbiIsImFwcGxpY2F0aW9uL3ZuZC5nZW8ranNvbiJdfV0~WyJza2s2dzF4cUxOUm psYkFwUkhmNFpRIiwiZGVmYXVsdElucHV0TW9kZXMiLFsiYXBwbGljYXRpb24vanNvbi IsInRleHQvcGxhaW4iXV0~WyJiWm41SVNxRFV3UTc0d3Y2MVVqN2h3IiwiZGVmYXVsdE 91dHB1dE1vZGVzIixbImFwcGxpY2F0aW9uL2pzb24iLCJpbWFnZS9wbmciXV0~eyJhbG ciOiJFUzI1NiIsInR5cCI6ImtiK2p3dCJ9.eyJpYXQiOjE3NjcyMjYwMDAsImF1ZCI6I mh0dHBzOi8vY2xpZW50LmV4YW1wbGUuY29tIiwibm9uY2UiOiI4eGsyTnE0WnBSMHZXb TNUZkw3Y0hnIiwic2RfaGFzaCI6IjhpN3NMZnNMZVVrczhUNjF5NEFHdEpUMFluMUNmU EdDWG5XNVhVaVpSYjgiLCJpbnRlcmFjdGlvbl9pZCI6IjEyMzQ1Njc4LTEyMzQtMTIzN C0xMjM0LTEyMzQ1Njc4OWFiYyJ9.m-TXiQsDv7y9a-hYnklQSNKFwiLrvUHrP1kbBeSW 4sMQt8VSIhmE6kPbZyUFPrEyg8hljxKa0J0S6g4n8RDW2A The discovery response of Section 8.4.3 carries the same presentation without the Key Binding JWT, ending at the last ~. Nandakumar & Jennings Expires 4 May 2027 [Page 71] Internet-Draft Agent SD-Card October 2026 Authors' Addresses Suhas Nandakumar Cisco Email: snandaku@cisco.com Cullen Jennings Cisco Email: flufy@cisco.com Nandakumar & Jennings Expires 4 May 2027 [Page 72]