Agent SD-Card: Selective Disclosure of Agent Metadata for Discovery and Authentication
draft-nandakumar-agent-sd-card-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Suhas Nandakumar , Cullen Fluffy Jennings | ||
| Last updated | 2026-10-31 | ||
| Replaces | draft-nandakumar-agent-sd-jwt | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-nandakumar-agent-sd-card-00
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:
<Issuer-signed JWT>~<Disclosure 1>~...~<Disclosure N>~[<KB-JWT>]
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:<binding>:<type>. 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": "<binding-defined value>",
"_sd_alg": "sha-256",
"_sd": [ "<digests of selectively disclosable binding claims>" ],
"name": "Example Agent",
"description": "An example agent",
"version": "1.0.0",
"cnf": { "jwk": "<the agent's public key>" }
}
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 <access_token>
DPoP: <DPoP proof signed with the cnf key>
{
"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.<payload>.
<signature>~<disclosure 1>~<disclosure 2>~...~",
"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 <registry_access_token>
{
"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="<challenge>",
token-key="<internal-context-issuer-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="<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=<access_token_received_from_upstream>
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&actor_token=<sd_card_presentation>
&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,
<https://a2a-protocol.org/latest/>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
client-id-metadata-document-02>.
[MCP-SPEC] Foundation), M. P. (Linux., "Model Context Protocol
Specification", Version 2026-07-28, 28 July 2026,
<https://modelcontextprotocol.io/
specification/2026-07-28>.
[PAP-SPEC] Project, P. A. P., "Personal Agent Protocol", Version 0.3
(draft), 2026,
<https://personalagentprotocol.org/docs/0.3>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[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,
<https://www.rfc-editor.org/rfc/rfc7800>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[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, <https://www.rfc-editor.org/rfc/rfc9325>.
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, <https://www.rfc-editor.org/rfc/rfc9449>.
[RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0
Protected Resource Metadata", RFC 9728,
DOI 10.17487/RFC9728, April 2025,
<https://www.rfc-editor.org/rfc/rfc9728>.
[RFC9901] Fett, D., Yasuda, K., and B. Campbell, "Selective
Disclosure for JSON Web Tokens", RFC 9901,
DOI 10.17487/RFC9901, November 2025,
<https://www.rfc-editor.org/rfc/rfc9901>.
[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, <https://datatracker.ietf.org/doc/html/
draft-ietf-oauth-sd-jwt-vc-22>.
12.2. Informative References
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[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, <https://www.rfc-editor.org/rfc/rfc6979>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/rfc/rfc8555>.
[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,
<https://www.rfc-editor.org/rfc/rfc8693>.
[RFC9576] Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy
Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June
2024, <https://www.rfc-editor.org/rfc/rfc9576>.
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,
<https://www.rfc-editor.org/rfc/rfc9577>.
[RFC9578] Celi, S., Davidson, A., Valdez, S., and C. A. Wood,
"Privacy Pass Issuance Protocols", RFC 9578,
DOI 10.17487/RFC9578, June 2024,
<https://www.rfc-editor.org/rfc/rfc9578>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
aims-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
arch-08>.
[WIMSE-ID] Rosomakho, Y. and J. A. Salowey, "Workload Identifier",
Work in Progress, Internet-Draft, draft-ietf-wimse-
identifier-04, 23 October 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
identifier-04>.
[WIMSE-WPT]
Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof
Token", Work in Progress, Internet-Draft, draft-ietf-
wimse-wpt-02, 27 August 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
wpt-02>.
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]