SD Agent: Selective Disclosure for Agent Discovery and Identity Management

Introduction The Agent-to-Agent (A2A) specification defines protocols for autonomous agent discovery and interaction through standardized Agent Cards. Current A2A implementations have following limitations:

Information Leakage: Agent Cards expose all capabilities during discovery
Weak Authentication: No cryptographic verification of agent identity
Static Disclosure: No context-based capability filtering
Linkability: Identical presentations enable cross-context tracking

This document specifies SD-Card, an SD-JWT encoding of Agent Cards that addresses these limitations through:

Selective Disclosure: Context-specific capability revelation
Cryptographic Authentication: Key-bound agent identity verification
Unlinkable Presentations: Privacy-preserving multi-context interactions
Backward Compatibility: Interoperability with existing A2A implementations

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Agent Card: A JSON metadata document describing an agent's capabilities, identity, and interaction requirements as defined in . SD-Card: An Agent Card encoded as an SD-JWT that enables selective disclosure of agent metadata. Agent Registry: A trusted service that issues and manages SD-Cards for agents within a domain or federation. Discovery Context: A named security context (e.g., "public", "internal", "diagnostic") that determines which claims are disclosed in an SD-Card presentation. Capability Disclosure: The selective revelation of specific agent capabilities based on the requesting entity's authorization and context. 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. SD-JWT Media Type: The application/vnd.sd-jwt+json media type is used to indicate content that contains Selective Disclosure JWT data within JSON structures. This vendor-specific media type distinguishes SD-JWT presentations from standard JSON content and signals that the receiver should process the content using SD-JWT parsing and verification procedures.

Notational Conventions This document follows SD-JWT conventions:

Base64url encoding for binary data
JWS format for signed tokens
SHA-256 hashing for selective disclosure
Tilde (~) separator for SD-JWT serialization:

~~~... ]]>

Overview of SD-Card Architecture and Benefits SD-Card enhances Agent-to-Agent (A2A) interactions by providing privacy-preserving agent discovery and cryptographically verifiable agent authentication. SD-Card enables selective disclosure of agent capabilities, skills, and endpoints based on requester authorization and discovery context, unlinkable agent interactions across different contexts, cryptographic integrity of agent metadata, and key binding for authentication that complements transport-layer security.

System Architecture The SD-Card architecture involves four primary components: Agent Registries that issue credentials, Agents that hold and present SD-Cards, Services that agents interact with, and Clients that discover and invoke agents. The following diagram illustrates these relationships and the flow of SD-Card issuance and presentation:

SD-Card System Architecture | | +------------------+ (2) Issue SD-Card +------------------+ | | | | | (3) Publish | (4) Present | Discovery | SD-Card | Metadata | (Selective) v v +------------------+ +------------------+ | | (5) Discover | | | Client |--------------------->| Service | | (Verifier) | | (Verifier) | | |<---------------------| | +------------------+ (6) Agent Info +------------------+ | ^ | | +-----------------------------------------+ (7) Invoke Agent via Service (with Key Binding proof) ]]> The architecture operates as follows:

Registration: An Agent registers with an Agent Registry, providing its capabilities, skills, and public key material for key binding.
SD-Card Issuance: The Registry issues an SD-Card (SD-JWT) containing the agent's metadata with selectively disclosable claims. The SD-Card includes the agent's confirmation key (cnf claim) for holder binding.
Discovery Publication: The Registry may publish non-sensitive discovery metadata to enable clients to locate agents matching their requirements.
Selective Presentation: When interacting with Services, the Agent presents its SD-Card with only the disclosures relevant to the interaction context. Different contexts receive different subsets of claims.
Client Discovery: Clients query the Registry or Services to discover agents with specific capabilities. The discovery response contains only claims appropriate for the discovery context.
Agent Information: The discovered agent information is returned to the client, enabling informed decisions about which agent to invoke.
Agent Invocation: The Client invokes the Agent through the Service, with the Agent providing a Key Binding JWT to prove possession of the private key corresponding to its SD-Card.

This architecture enables privacy-preserving agent discovery while maintaining cryptographic verifiability. Agents control what information they reveal in each context, and verifiers can trust that presented claims are authentic and unmodified.

Challenges with Traditional Agent Discovery Traditional agent discovery in Agent-to-Agent protocol faces several challenges:

Information Leakage:: Agent Cards expose all capabilities to any entity performing discovery, potentially revealing sensitive operational details.
Linkability:: Identical capabilities presented to different verifiers enable tracking across contexts.
Authenticity:: Without cryptographic verification, Agent Cards can be forged or tampered with during transmission.
Capability Enumeration:: Attackers can enumerate all agent capabilities by performing discovery, potentially identifying attack vectors.
Context Insensitivity:: Agents cannot adapt capability disclosure based on the requesting entity's authorization level or intended use case.

Allowing agents to selectively disclose their capabilities addresses these challenges through:

Selective Capability Disclosure:: Agents reveal only capabilities relevant to the specific discovery context or requester authorization level.
Unlinkable Presentations:: Different presentations of the same agent to different verifiers cannot be linked, enhancing privacy.
Flexible Authentication:: Key binding enables strong agent authentication without relying solely on transport security.
Batch Credential Issuance:: Multiple context-specific credentials can be issued to the same agent for different use cases.

SD-Card Agent Card This specification defienes "SD-Card". An SD-Card is an Agent Card encoded as an SD-JWT.

Agent Card Structure The base Agent Card structure follows the A2A specification but is extended to support selective disclosure. The card consists of three main components:

Base Claims: Always disclosed information that establishes the agent's identity, protocol version, and basic metadata
Selective Disclosure Claims: A2A-specific information that can be selectively revealed based on the discovery context including skills, interfaces, and provider details
Cryptographic Binding: Keys and signatures that ensure authenticity and enable secure agent interactions

The Agent Card is represented as a Selective Disclosure JSON Web Token (SD-JWT) that contains both standard A2A Agent Card fields and selective disclosure metadata : The following claims are permanently disclosed in the SD-Card:

iss:: The issuer of the Agent Card (typically an Agent Registry). This establishes the trust anchor for the credential and enables signature verification. The issuer MUST be a resolvable URI that provides access to the issuer's public key material.
sub:: The unique identifier of the agent within the issuer's namespace. This identifier MUST be stable across different Agent Card issuances for the same logical agent, enabling correlation when authorized while supporting unlinkable presentations through different salt values.
iat:: The time at which the Agent Card was issued (Unix timestamp).
exp:: The expiration time of the Agent Card (Unix timestamp).
vct:: The verifiable credential type, identifying this as an SD-Card Agent Card. This value MUST be "urn:ietf:params:oauth:token-type:sd-agent-card" for compliance with this specification.
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.
cnf:: The confirmation key for agent authentication. This public key enables key binding and ensures that only the legitimate agent can present the Agent Card. The key MUST be in JSON Web Key (JWK) format.

Selective Disclosure Claims The following claims are selectively disclosed based on the discovery context:

Skills and Capabilities The skills claim contains an array of A2A AgentSkill objects that the agent can perform. Each skill definition follows the A2A specification and includes input/output modes, examples, and metadata for proper integration.

Original Skills JSON Object:

SD-JWT Transformation Process: When converting the skills claim to selective disclosure, the Agent Registry performs the following transformation: Step 1: Generate Salt Value A cryptographically secure random salt is generated for the skills claim: Step 2: Create Disclosure Array The skills claim is packaged into a disclosure array format: Step 3: Base64url Encode Disclosure The disclosure array is JSON-serialized and base64url-encoded: Step 4: Calculate SHA-256 Digest A SHA-256 hash is computed over the base64url-encoded disclosure: Step 5: Include Digest in SD-JWT The digest is included in the _sd array of the Issuer-signed JWT payload: Step 6: Selective Disclosure When presenting the agent card, the skills disclosure is included only if authorized: ~~~ ]]> During verification, the verifier:

Decodes the skills disclosure from base64url
Calculates SHA-256 hash of the decoded disclosure
Confirms the hash matches the digest in the _sd array
Extracts the skills claim value for use

Additional Agent Interfaces The additionalInterfaces claim defines alternative transport mechanisms and endpoints for A2A communication as specified in the AgentInterface object structure.

Original values The original additionalInterfaces claim in the agent metadata contains:

SD-JWT Transformation Process: When converting the additionalInterfaces claim to selective disclosure, the Agent Registry performs the following transformation: Step 1: Generate Salt Value A cryptographically secure random salt is generated for the additionalInterfaces claim: Step 2: Create Disclosure Array The additionalInterfaces claim is packaged into a disclosure array format: Step 3: Base64url Encode Disclosure The disclosure array is JSON-serialized and base64url-encoded: Step 4: Calculate SHA-256 Digest A SHA-256 hash is computed over the base64url-encoded disclosure: Step 5: Include Digest in SD-JWT The digest is included in the _sd array of the Issuer-signed JWT payload:

Agent Capabilities The capabilities claim provides information about the agent's A2A protocol feature support as defined in the AgentCapabilities object.

Original values The original capabilities claim in the agent metadata contains:

SD-JWT Transformation Process: When converting the capabilities claim to selective disclosure, the Agent Registry performs the following transformation: Step 1: Generate Salt Value A cryptographically secure random salt is generated for the capabilities claim: Step 2: Create Disclosure Array The capabilities claim is packaged into a disclosure array format: Step 3: Base64url Encode Disclosure The disclosure array is JSON-serialized and base64url-encoded: Step 4: Calculate SHA-256 Digest A SHA-256 hash is computed over the base64url-encoded disclosure: Step 5: Include Digest in SD-JWT The digest is included in the _sd array of the Issuer-signed JWT payload:

Security Schemes and Authentication The securitySchemes claim defines authentication requirements following A2A SecurityScheme format.

Original values The original securitySchemes claim in the agent metadata contains:

SD-JWT Transformation Process: When converting the securitySchemes claim to selective disclosure, the Agent Registry performs the following transformation: Step 1: Generate Salt Value A cryptographically secure random salt is generated for the securitySchemes claim: Step 2: Create Disclosure Array The securitySchemes claim is packaged into a disclosure array format: Step 3: Base64url Encode Disclosure The disclosure array is JSON-serialized and base64url-encoded: Step 4: Calculate SHA-256 Digest A SHA-256 hash is computed over the base64url-encoded disclosure: Step 5: Include Digest in SD-JWT The digest is included in the _sd array of the Issuer-signed JWT payload:

Provider Information The provider claim contains A2A AgentProvider information about the organization that operates the agent.

Original values The original provider claim in the agent metadata contains:

SD-JWT Transformation Process: When converting the provider claim to selective disclosure, the Agent Registry performs the following transformation: Step 1: Generate Salt Value A cryptographically secure random salt is generated for the provider claim: Step 2: Create Disclosure Array The provider claim is packaged into a disclosure array format: Step 3: Base64url Encode Disclosure The disclosure array is JSON-serialized and base64url-encoded: Step 4: Calculate SHA-256 Digest A SHA-256 hash is computed over the base64url-encoded disclosure: Step 5: Include Digest in SD-JWT The digest is included in the _sd array of the Issuer-signed JWT payload:

Input and Output Modes The defaultInputModes and defaultOutputModes claims specify supported content types for A2A message interactions.

Original values The original defaultInputModes and defaultOutputModes claims in the agent metadata contain:

SD-JWT Transformation Process: When converting the defaultInputModes and defaultOutputModes claims to selective disclosure, the Agent Registry performs the following transformation: Step 1: Generate Salt Value A cryptographically secure random salt is generated for the input/output modes claims: Step 2: Create Disclosure Arrays Each claim is packaged into separate disclosure array formats:

Disclosure for defaultInputModes:

Disclosure for defaultOutputModes: Step 3: Base64url Encode Disclosures The disclosure arrays are JSON-serialized and base64url-encoded:

defaultInputModes encoded:

defaultOutputModes encoded: Step 4: Calculate SHA-256 Digests SHA-256 hashes are computed over the base64url-encoded disclosures: Step 5: Include Digests in SD-JWT The digests are included in the _sd array of the Issuer-signed JWT payload:

Documentation and Support Additional A2A Agent Card metadata for documentation and extended capabilities.

Agent Card Issuance Agent Cards are issued by trusted Agent Registries, the details of the which are out of scope of this specification

Issuance Process Overview

Agent Registration: The agent registers with the Agent Registry, providing its capabilities, endpoints, and authentication information. This includes submitting detailed metadata about the agent's functions, operational requirements, and security capabilities.
Identity Verification: The Agent Registry verifies the agent's identity and authorization to claim the specified capabilities.
Agent Card Creation: The Agent Registry creates an SD-JWT Agent Card containing the agent's metadata with appropriate claims marked for selective disclosure. The registry determines which claims should be selectively disclosable based on authorization, privacy policies and security requirements.
Batch Issuance: Multiple Agent Cards with different disclosure configurations may be issued for different discovery contexts. This enables the same agent to interact in various contexts while maintaining privacy and unlinkability.

Example issuance request based on HTTP POST method with bearing token is shown below: { "agent_id": "ai-assistant-v2", "name": "AI Assistant Agent", "description": "General purpose AI assistant", "version": "2.1.0", "public_key": { "kty": "EC", "crv": "P-256", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" }, "disclosure_contexts": [ { "context": "public", "disclose": ["skills", "endpoints", "operational_info"] }, { "context": "internal", "disclose": ["skills", "endpoints", "operational_info", "provider", "security_context"] }, { "context": "diagnostic", "disclose": ["operational_info", "provider"] } ] } ]]>

Agent Discovery Protocols with Privacy Protection This section describes the protocols and mechanisms for discovering agents:

Well-Known URI Discovery The well-known URI discovery mechanism is extended to support SD-JWT Agent Cards: The application/vnd.sd-jwt+json media type indicates that the client accepts responses containing Selective Disclosure JWT data formatted as JSON. In the examples below, the "agent_card" field contains an SD-JWT formatted according to the Agent Card Structure defined in . The response contains an SD-JWT Agent Card with context-appropriate disclosures. For privacy-sensitive discovery, the agent MAY require authentication before revealing the Agent Card: Accept: application/vnd.sd-jwt+json ]]>

Registry-Based Discovery Agent Registries support discovery with context-based selective disclosure. In the example below, an agent is discovered based on the skill "route-optimizer-traffic". { "query": { "skills": ["route-optimizer-traffic"], "availability": "24/7" }, "context": "public", "max_results": 10 } ]]>

Contextual Discovery Discovery can be performed with different contexts to control the level of information disclosure:

Public Context:: Minimal information suitable for public discovery, including basic skills and public endpoints.
Internal Context:: Additional operational details for internal organizational use.
Diagnostic Context:: Detailed technical information for troubleshooting and monitoring.
Federation Context:: Inter-organizational discovery with appropriate trust relationships.

The same agent may present different Agent Cards for different contexts while maintaining unlinkability between presentations.

Integration with Model Context Protocol The A2A protocol and SD-Card operate at the agent-to-agent communication layer, while Model Context Protocol (MCP) addresses agent-to-tool interactions. These protocols are complementary:

A2A/SD-Card: Agent discovery, identity, and capability negotiation
MCP: Tool discovery, invocation, and context management

When an agent discovered via SD-Card utilizes MCP for tool access, the following security considerations apply:

The SD-Card's security context does not automatically propagate to MCP tool invocations
Separate authorization may be required for tool access
Audit logs SHOULD correlate A2A interaction IDs with MCP sessions

Protocol Layering SD-Card enables secure agent discovery and authentication, after which agents may use MCP for accessing tools and external resources. The interaction_id from the Key Binding JWT SHOULD be included in MCP requests for audit correlation.

Cryptographic Authentication and Capability-Based Authorization SD-Card provides enhanced authentication and authorization mechanisms through SD-JWT integration with cryptographic key binding. This section details the complete authentication flow, key binding mechanisms, and capability-based authorization processes that ensure secure agent interactions.

SD-JWT with Key Binding Selective Disclosure JWT (SD-JWT) with Key Binding is a security mechanism that enables privacy-preserving authentication. An SD-JWT consists of three main parts separated by tildes (~):

Issuer-Signed JWT: Contains the base claims and selective disclosure metadata
Disclosure Arrays: Base64url-encoded arrays containing the salt and claim data
Key Binding JWT (KB-JWT): Proves possession of the confirmation key

~~~...~ ]]> Key binding cryptographically proves that the presenter of an SD-JWT possesses the private key corresponding to the public key specified in the cnf (confirmation) claim of the SD-JWT. This mechanism:

Selective Disclosure: Only relevant claims are revealed to the verifier
Cryptographic Binding: Proof of possession of a private key
Unlinkable Presentations: Different interactions cannot be correlated
Replay Protection: Each presentation is unique and time-bound

Agent Authentication Process The agent authentication process involves multiple cryptographic steps to ensure secure and verifiable identity establishment:

Step 1: Agent Card Presentation The agent presents its SD-JWT Agent Card with context-appropriate selective disclosures. The "agent_card" field contains an SD-JWT generated from the following raw input structure: Raw Input Structure: The agent_card field is generated from the following base agent information: Selective Disclosures:

skills: ["salt1","skills",[{"name":"text-generation"}]]
endpoints: ["salt2","endpoints",[{"name":"primary"}]]

Resulting SD-JWT Presentation:

Step 2: Key Binding JWT Creation The agent creates a Key Binding JWT (KB-JWT) to prove possession of the private key. The KB-JWT structure includes: KB-JWT Header: KB-JWT Payload: where,

iat: Issued at time - prevents replay attacks
aud: Audience - identifies the intended recipient
sd_hash: Hash of the SD-JWT presentation (binds KB-JWT to specific presentation)
interaction_id: Unique interaction identifier - prevents cross-session attacks
nonce: Optional random value - adds additional replay protection

Step 3: Cryptographic Verification The client performs comprehensive verification:

Agent Card Signature Verification: Validates the issuer's signature
Disclosure Verification: Confirms disclosed claims match their digests
Key Binding Verification: Validates the KB-JWT signature using the agent's public key
Temporal Validation: Checks expiration and freshness of timestamps
Audience Validation: Ensures the KB-JWT is intended for this client

Advanced Authorization Flows

Capability-Based Discovery Verifiers can query for agents based on required capabilities: { "query": { "skills": ["route-optimizer-traffic"], "capabilities": { "streaming": true } }, "context": "internal", "requester_claims": { "organization": "example.com", "roles": ["service-account"] } } ]]>

Role-Based Disclosure The Agent Registry MAY implement role-based disclosure policies:

Context	Disclosed Claims
public	name, description, skills (names only)
internal	All public + endpoints, capabilities, provider
diagnostic	All internal + securitySchemes, version details
federation	Context-dependent based on federation agreement

Token Exchange for Sub-Agent Delegation When a client agent needs to delegate to a discovered agent, it MAY use OAuth 2.0 Token Exchange : &subject_token_type=urn:ietf:params:oauth:token-type:access_token &requested_token_type=urn:ietf:params:oauth:token-type:access_token &audience=agent:georoute-planner-v1 &scope=route-optimizer-traffic ]]> The authorization server validates the subject token, applies any scope restrictions, and returns a new token bound to the target agent.

IANA Considerations

Media Type Registration This specification registers the following media type with IANA:

Type name:: application
Subtype name:: vnd.sd-jwt+json
Required parameters:: N/A
Optional parameters:: N/A
Encoding considerations:: binary (JSON)
Security considerations:: See Security Considerations section of this document
Interoperability considerations:: N/A
Published specification:: This document
Applications that use this media type:: A2A agent discovery systems, agent registries, and agent clients that support selective disclosure of agent capabilities
Fragment identifier considerations:: N/A

Verifiable Credential Type Registration This specification registers the following verifiable credential type in the "OAuth URI" registry:

URI:: urn:ietf:params:oauth:token-type:sd-agent-card
Description:: SD-JWT Agent Card for A2A protocol
Reference:: This document

JSON Web Token Claims Registration This specification does not define new JWT claims but uses existing claims as defined in and standard JWT claims from

Security Considerations

Token Binding and Replay Prevention SD-Card implementations MUST implement token binding mechanisms to prevent stolen credential misuse. Implementations SHOULD support DPoP for application-level proof-of-possession when presenting SD-Cards outside the key binding JWT mechanism. The Key Binding JWT already provides replay protection through:

iat (issued-at) timestamps with short validity windows
aud (audience) binding to specific verifiers
sd_hash binding to specific SD-JWT presentations
Optional nonce values for additional freshness

Verifiers MUST reject Key Binding JWTs with:

iat timestamps more than 5 minutes in the past
Missing or incorrect aud claims
Mismatched sd_hash values

Agent Identity Verification In multi-agent workflows, identity verification becomes critical. The architecture aligns with WIMSE principles for workload identity:

Agent Attestation: The cnf claim provides cryptographic proof that the presenter possesses the corresponding private key
Issuer Trust: The Agent Registry's signature establishes a trust anchor. Verifiers MUST validate the issuer's signature using pre-established trust relationships
Claim Integrity: Selective disclosure digests ensure that disclosed claims have not been modified since issuance

Delegation and Multi-Agent Scenarios When agents delegate tasks to sub-agents, the following security properties MUST be maintained:

Delegation Chains: Use OAuth 2.0 Token Exchange to create constrained tokens for sub-agents with reduced scope
Audit Trail: Each delegation SHOULD include an interaction_id that enables tracing across agent invocations
Scope Limitation: Sub-agents MUST NOT receive broader permissions than the delegating agent possesses
Human Oversight: For sensitive operations, delegation chains SHOULD support human-in-the-loop approval mechanisms

Privacy Considerations

Correlation Prevention SD-Card's selective disclosure mechanism prevents unwanted correlation:

Different salt values per disclosure create unique hashes
Verifiers cannot correlate presentations across contexts without access to the original disclosures
Batch issuance enables multiple unlinkable SD-Cards for the same agent

Minimal Disclosure Principle Following NIST AI RMF principles for trustworthy AI:

Agents SHOULD request only the disclosures necessary for the interaction context
Discovery contexts (public, internal, diagnostic, federation) enable appropriate disclosure levels
Verifiers SHOULD NOT request more claims than required for authorization decisions

Data Minimization in Agent Cards Agent operators SHOULD:

Avoid including PII in selectively disclosable claims when possible
Use capability descriptions rather than detailed implementation details
Rotate SD-Cards periodically to limit temporal correlation
Consider using different SD-Cards for different trust domains

Transport Security SD-Card provides application-layer security that complements, but does not replace, transport-layer security:

TLS Required: All SD-Card exchanges MUST occur over TLS 1.3 or later as recommended in
Defense in Depth: Key binding provides protection even if transport security is compromised
Channel Binding: Implementations MAY bind presentations to the TLS session for additional protection against token export attacks

Issuer Security Agent Registries (issuers) have significant security responsibilities:

Key Protection: Issuer signing keys MUST be protected using hardware security modules (HSMs) or equivalent protection
Revocation: Issuers SHOULD implement revocation mechanisms for compromised SD-Cards. This MAY include:
- Short-lived credentials requiring frequent renewal
- Status list endpoints for revocation checking
- Push-based revocation notifications
Audit Logging: Issuers MUST maintain audit logs of all SD-Card issuances including agent identity, disclosed claims, and issuance timestamps

Cryptographic Agility This specification mandates support for:

ES256 (ECDSA with P-256 and SHA-256) as the minimum required algorithm
SHA-256 for selective disclosure hashing

Implementations SHOULD be prepared to support additional algorithms as they become standardized. Post-quantum cryptographic algorithms for JOSE/COSE are under active development and implementations SHOULD plan for migration paths. {backmatter}