Agent SD-Card: Selective Disclosure of Agent Metadata for Discovery and Authentication

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.¶

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>]

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 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.¶

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.¶

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.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 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.¶

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:¶

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"],
        ["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.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.¶

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.¶

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:¶

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, 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.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.¶

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.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.¶

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.1. Protocol Binding Requirements

A Protocol Binding MUST specify:¶

1. Identifier: A short binding name and the vct value or values that SD-Cards for this binding carry. A binding whose protocol has more than one kind of holder defines a vct value for each.¶

2. Source Document: The Native Metadata Document, the protocol version or versions it applies to, how an issuer retrieves it given the metadata_url of a registration request (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

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

{
  "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"
    }
  }
}

{
  "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"
  }
}

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 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.¶

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

"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"]
  }
}

POST /poppy/sd-card HTTP/1.1
Host: api.example.com
Content-Type: application/json
Poppy-Session: eyJ0eXAiOiJwb3BweS1zZXNzaW9uK2p3dCIs...

{ "presentation": "eyJhbGciOiJFUzI1NiIs...~WyJ...~eyJ..." }

8.4. A2A Binding

GET /.well-known/agent-card.json HTTP/1.1
Host: georoute-agent.example.com
Accept: application/dc+sd-jwt

{
  "uri": "urn:ietf:params:sd-card:a2a",
  "description": "SD-Card key-bound presentation",
  "required": false
}

{
  "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"
    }
  }
}

{
  "metadata": {
    "urn:ietf:params:sd-card:a2a": {
      "presentation": "eyJhbGciOiJFUzI1NiIs...~eyJ..."
    }
  }
}

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¶

+------------------------------------------------------+
|                  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          |
+------------------------------------------------------+

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.¶

12.1. Normative References

[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>.

[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>.

[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>.

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:¶

{
  "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"
  }
]

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:¶

[
  "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:¶

[
  "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:¶

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:¶

{
  "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
]

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"
  }
]

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:¶

[
  "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:¶

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