Agent Capability Advertisement Protocol (ACAP)
draft-zahed-acap-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 | Zaheduzzaman Sarker , Tirumaleswar Reddy.K | ||
| Last updated | 2026-06-25 | ||
| 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-zahed-acap-00
xxxxx Z. Sarker
Internet-Draft T. Reddy
Intended status: Standards Track Nokia
Expires: 27 December 2026 25 June 2026
Agent Capability Advertisement Protocol (ACAP)
draft-zahed-acap-00
Abstract
This document specifies the Agent Capability Advertisement Protocol
(ACAP), a REST-like protocol built on HTTP/3 that defines a
structured registry and exchange format for Agent Capability
Documents (ACDs). ACAP enables the discovery of AI agents deployed
across different administrative domains on the Internet. Each agent
exposes an ACAP endpoint, hosted at a well-known URI, that serves
ACDs describing the capabilities, authentication requirements, and
operational metadata for agents within that domain. ACAP supports
three core operations: retrieval, registration, and capability-based
search. In deployments where multiple agent operators share hosting
infrastructure, ACDs are cryptographically signed to enable secure,
decentralized agent discovery.
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 27 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Sarker & Reddy Expires 27 December 2026 [Page 1]
Internet-Draft ACAP June 2026
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
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. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Model 1: Domain-Hosted Internal Agents . . . . . . . . . 6
5.2. Model 2: Operator-Hosted Third-Party Agents . . . . . . . 6
6. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Obtaining the Locator . . . . . . . . . . . . . . . . . . 7
6.2. Network-Based Agent Discovery . . . . . . . . . . . . . . 8
7. Agent Capability Document (ACD) Format . . . . . . . . . . . 8
7.1. Capability Descriptor . . . . . . . . . . . . . . . . . . 10
7.2. Authentication Configuration . . . . . . . . . . . . . . 11
7.3. Transport Configuration . . . . . . . . . . . . . . . . . 11
8. ACAP Operations . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. GET — Retrieve an Agent Capability Document . . . . . . . 12
8.2. PUT — Register or Update an Agent Capability Document . . 12
8.3. POST — Query Agents by Capability . . . . . . . . . . . . 13
8.3.1. Query Request Fields . . . . . . . . . . . . . . . . 13
8.3.2. Query Response Fields . . . . . . . . . . . . . . . . 13
9. ACD Signing and Verification . . . . . . . . . . . . . . . . 14
9.1. JWS Protected Header . . . . . . . . . . . . . . . . . . 14
9.2. Signing Procedure . . . . . . . . . . . . . . . . . . . . 14
9.3. Verification Procedure . . . . . . . . . . . . . . . . . 14
9.4. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10.1. Transport Security . . . . . . . . . . . . . . . . . . . 15
10.2. Validity Period and Freshness . . . . . . . . . . . . . 15
10.3. Cross-Domain Trust . . . . . . . . . . . . . . . . . . . 16
10.4. Key Fetch Security . . . . . . . . . . . . . . . . . . . 16
10.5. Privacy Considerations . . . . . . . . . . . . . . . . . 16
10.6. Denial of Service . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11.1. Well-Known URI Registration . . . . . . . . . . . . . . 16
11.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Sarker & Reddy Expires 27 December 2026 [Page 2]
Internet-Draft ACAP June 2026
12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Appendix A — Example ACD (JWT) . . . . . . . . . . . 19
Appendix B. Appendix B — Relationship to Existing Protocols . . 20
Appendix C. Appendix C — Example Discovery Flow . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
The proliferation of AI agents deployed across heterogeneous
administrative domains on the Internet creates a fundamental
interoperability challenge: how can an agent or orchestration system
discover the capabilities of agents it has never previously
encountered, without relying on centralized registries or out-of-band
coordination?
This document specifies the Agent Capability Advertisement Protocol
(ACAP), a structured discovery protocol that fills this gap. ACAP is
inspired by RFC 8615 (Well-Known URIs) [RFC8615] and the WebFinger
protocol [RFC7033] and provides richer capability advertisement than
DNS-SD TXT records.
ACAP defines:
* A well-known URI scheme for locating ACAP endpoints.
* An Agent Capability Document (ACD) format encoded as JSON,
optionally carried as the payload of a JWT [RFC7519] when signing
is required.
* Three HTTP/3 [RFC9114] operations: GET (retrieve), PUT (register/
update), and POST (query by capability).
* A signing mechanism based on JSON Web Signature (JWS) [RFC7515] to
ensure ACD integrity and agent operator authenticity.
A key motivation for ACD signatures is the multi-tenant deployment
model, where multiple agent operators share the same hosting
infrastructure. In such environments, the TLS end-entity certificate
belongs to the infrastructure provider, not the agent operator. ACD
signatures allow the agent operator to bind their identity directly
to the ACD content, independent of the hosting infrastructure.
Sarker & Reddy Expires 27 December 2026 [Page 3]
Internet-Draft ACAP June 2026
Note: A future revision of this document will provide a formal CDDL
[RFC8610] representation covering both JSON and CBOR encodings,
enabling the same ACD content to be represented in either encoding.
When CBOR encoding is supported, COSE [RFC9052] will be used for
signing in place of JWS. Clients and servers will negotiate the
encoding using the Accept and Content-Type headers.
1.1. Requirements Language
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.
2. Terminology
Agent: An autonomous software entity capable of performing tasks on
behalf of a principal, potentially communicating with other
agents.
Agent Capability Document (ACD): A structured JSON document that
describes an agent's identity, capabilities, and authentication
requirements. In Model 2, an ACD MUST be carried as the payload
of a JWT [RFC7519]. In Model 1, an ACD MAY be carried as plain
JSON.
ACAP Endpoint: An HTTP/3 server exposing ACD resources at well-known
URIs.
Trust Domain: An administrative domain that operates one or more
ACAP endpoints and issues or validates agent identities within
that domain.
Capability Descriptor: A structured record within an ACD that
describes a single capability offered by the agent.
Agent Operator: The entity responsible for deploying and managing an
agent, which holds the private key used to sign the ACD.
3. Motivation
When the domain of an agent operator is already known, the DNS
provides what is needed to connect to it. Service Binding (SVCB)
records [RFC9460] convey connection parameters such as the supported
application protocols, port, and IP addresses in a single cached
lookup, before any connection is established. ACAP does not
duplicate this connection-layer information.
Sarker & Reddy Expires 27 December 2026 [Page 4]
Internet-Draft ACAP June 2026
What the DNS does not provide is a way to learn what an agent can do.
Agent capability information is structured and evolving: each
capability has its own input and output types, performance
characteristics, and authentication requirements, and discovery
includes searching for agents by capability, not only resolving a
known name. This is not a connection hint; it is capability data,
and querying it is an application-layer operation. Encoding such
data in the DNS is also a poor fit: capability data is far larger
than a connection hint, and packing it into DNS records inflates
response sizes and risks fragmentation and fallback to TCP.
ACAP therefore addresses a different concern than connection
bootstrap. It defines the Agent Capability Document, its retrieval,
and capability-based search, served over HTTPS at well-known URIs.
Placing capability description at the application layer lets the
protocol carry rich and extensible structure, be queried, and be
signed by the agent operator independently of the infrastructure that
hosts it (Section 5). Because the format is an application-layer
document, new capabilities and fields can be introduced in future
revisions without defining new DNS record types or registering new
parameters. DNS-based connection discovery and ACAP are
complementary: the former locates and connects to a known domain,
while ACAP describes the capabilities of the agents within it and
enables discovery across them.
4. Protocol Overview
ACAP operates as follows:
1. An agent operator registers an ACD at their ACAP endpoint by
issuing a PUT request to the well-known URI for that agent.
2. A discovering party retrieves an ACD by issuing a GET request to
the agent's well-known URI, or discovers agents by capability by
issuing a POST query to the domain-level query endpoint.
3. Upon receipt of a signed ACD, the recipient MUST verify the JWS
signature and check that the ACD has not expired.
The following diagram illustrates the basic discovery flow:
Sarker & Reddy Expires 27 December 2026 [Page 5]
Internet-Draft ACAP June 2026
Requester ACAP Endpoint
| |
|--- GET https://{domain}/.well-known/ --->|
| agents[/{agent-local-id}]/acap |
| |
|<------- 200 OK {JWT or JSON ACD} ------------------ |
| |
| [If signed: Verify JWS signature] |
| [If signed: Check exp claim] |
| |
|-- Connect to agent endpoint (QUIC/WebTransport) --->|
Figure 1: Basic ACAP Discovery Flow
5. Deployment Models
This section describes two common deployment models. Other
deployment models are possible and may be defined in future revisions
of this document.
5.1. Model 1: Domain-Hosted Internal Agents
In this model, an organization deploys agents within its own domain
for internal use. The domain operator and agent operator are the
same entity. For example, example.com may deploy multiple internal
agents, a scheduling agent, a document processing agent, and a
customer support agent, all hosted within its own infrastructure:
https://example.com/.well-known/agents/scheduler/acap
https://example.com/.well-known/agents/docproc/acap
https://example.com/.well-known/agents/support/acap
Since the domain operator and agent operator are the same entity, TLS
authentication of the ACAP endpoint is sufficient to establish trust
in the ACD content. ACD signatures are OPTIONAL in this model. The
{agent-local-id} path component MUST be present when multiple agents
are deployed within the same domain.
5.2. Model 2: Operator-Hosted Third-Party Agents
In this model, the hosting infrastructure is operated independently
from the agent operator. For example, example.com may deploy
multiple agents on a third-party hosting platform, where the TLS
certificate belongs to the hosting provider rather than example.com.
The ACD is discovered at https://{agent-domain}/.well-known/
agents[/{agent-local-id}]/acap and the ACAP endpoint URI is conveyed
within the ACD content. The {agent-local-id} path component MUST be
present when multiple agents are deployed within the same domain.
Sarker & Reddy Expires 27 December 2026 [Page 6]
Internet-Draft ACAP June 2026
While TLS authenticates the hosting infrastructure, it cannot
guarantee the integrity of the ACD content, a compromised host could
tamper with the advertised capabilities. Agent operators MUST
therefore sign their ACD as described in Section 9.
6. Well-Known URIs
ACAP endpoints MUST be accessible at the following well-known URI
([RFC8615]):
https://{domain}/.well-known/agents[/{agent-local-id}]/acap
where {domain} is the fully qualified domain name of the agent
operator and {agent-local-id} is a domain-local identifier for the
agent, which MUST be URL-safe and MUST NOT contain path separator
characters. {agent-local-id} MUST be present when multiple agents are
deployed within the same domain.
A domain-level index of all agents available within a domain MUST be
accessible at:
https://{domain}/.well-known/agents
The domain index resource SHOULD return a JSON array of ACDs
available within that domain.
A domain-level capability query endpoint MUST be accessible at:
https://{domain}/.well-known/agents/_query
ACAP endpoints MUST be served over HTTPS with a valid TLS
certificate. Servers MUST support HTTP/3 [RFC9114].
NOTE : Support for HTTP/2 as a fallback MAY need to be considered.
6.1. Obtaining the Locator
Before retrieving an ACD, a discovering party needs the domain at
which to issue the first request. The locator may be obtained in
several ways:
* it is configured or otherwise known to the client;
* it is learned from the network as the access network domain name
(see Section 6.2);
* it is provided by from another agent; or
Sarker & Reddy Expires 27 December 2026 [Page 7]
Internet-Draft ACAP June 2026
* it is resolved through DNS-based agent discovery.
Once the domain is known, the client constructs the well-known URI
(Section 6) and proceeds with the operations in Section 8.
6.2. Network-Based Agent Discovery
ACAP's well-known URI scheme enables network-based agent discovery.
An endpoint that has joined a network can obtain the access network
domain name provisioned by the network operator via DHCP, DHCPv4
option 213 (OPTION_V4_ACCESS_DOMAIN) or DHCPv6 option 57
(OPTION_V6_ACCESS_DOMAIN) as defined in [RFC5986], and use it to
construct the ACAP discovery URI:
https://{access-network-domain}/.well-known/agents
This allows the endpoint to discover agents offered by the network
operator without any out-of-band configuration.
7. Agent Capability Document (ACD) Format
ACDs are JSON objects. In Model 2 (Section 5), ACDs MUST be carried
as the payload of a JWT [RFC7519], signed using JWS Compact
Serialization [RFC7515] as described in Section 9. In Model 1, ACDs
MAY be signed.
The JWT payload for a signed ACD contains the following fields. The
JWT registered claims [RFC7519] MUST be present:
iss: The agent operator's domain URI (e.g., "https://example.com").
iat: The time at which the ACD was signed, as a NumericDate value
(seconds since the Unix epoch) per [RFC7519].
exp: The expiration time of the ACD, as a NumericDate value per
[RFC7519]. Recipients MUST NOT use an ACD whose exp time has
passed.
The JWT registered claims iss, iat, and exp are defined by [RFC7519]
and are included here to clarify their specific semantics and
requirements within the ACAP context. Implementations MUST follow
[RFC7519] for encoding and processing these claims.
The following ACD-specific fields MUST also be present in the JWT
payload:
Sarker & Reddy Expires 27 December 2026 [Page 8]
Internet-Draft ACAP June 2026
{
"iss" : string, ; Agent operator domain URI (JWT)
"iat" : integer, ; Signing time NumericDate (JWT)
"exp" : integer, ; Expiration time NumericDate (JWT)
"id" : string, ; Agent Identifier URN
"version" : string, ; Framework version (e.g., "1.0")
"domain" : string, ; Agent operator domain name
"name" : string, ; Human-readable agent name (UTF-8)
"description" : string, ; Short description (UTF-8)
"endpoint" : string, ; Primary QUIC/WebTransport endpoint URI
"alt_endpoints": [string], ; Alternate endpoints
"capabilities" : { ; Capability taxonomy map
string => CapabilityDescriptor
},
"auth" : AuthConfig, ; Authentication and authorization config
"transport" : TransportConfig, ; Transport configuration
"context" : ContextConfig, ; Context and session parameters
"jwks_uri" : string, ; URI of the agent operator's JWK Set
}
Field definitions:
id: A URN uniquely identifying the agent.
version: The IETF protocol suite version to which this ACD conforms
(e.g., "1.0").
domain: The fully qualified domain name of the agent operator (e.g.,
"example.com"). MUST match the domain portion of the well-known
URI from which this ACD was served.
name: A human-readable display name for the agent. MUST be encoded
as UTF-8.
description: A short, human-readable description of the agent's
capabilities and intended use. MUST be encoded as UTF-8.
endpoint: The URI of the agent's primary QUIC or WebTransport
endpoint to which connections SHOULD be established after
discovery.
alt_endpoints: An array of alternative endpoint URIs for load
balancing or failover. MAY be empty.
capabilities: A map from capability name strings to
CapabilityDescriptor objects (see Section 7.1).
auth: An AuthConfig object describing supported authentication and
Sarker & Reddy Expires 27 December 2026 [Page 9]
Internet-Draft ACAP June 2026
authorization schemes (see Section 7.2).
transport: A TransportConfig object describing the agent endpoint's
transport configuration (see Section 7.3).
context: A ContextConfig object describing session and context
parameters. The structure of ContextConfig is left to the IETF
agentic protocol suite profile specification.
jwks_uri: A URI at which the agent operator's JSON Web Key Set
[RFC7517] MAY be retrieved. Used by recipients to obtain the
public key for JWS signature verification. MUST be present in
Model 2 (Section 5).
7.1. Capability Descriptor
CapabilityDescriptor = {
"id" : string, ; Capability URN
"version" : string, ; Capability version
"input_type" : [string], ; Accepted input modalities/formats
"output_type": [string], ; Produced output modalities/formats
"latency_ms" : integer, ; Expected p50 latency in milliseconds
? "rate_limit": integer, ; Requests per second limit (optional)
? "cost_unit" : string, ; Pricing unit, informational (optional)
}
id: A URN identifying the capability.
version: The version of this capability's interface.
input_type: An array of MIME types or modality identifiers accepted
as input.
output_type: An array of MIME types or modality identifiers produced
as output.
latency_ms: The expected p50 (median) end-to-end latency for this
capability in milliseconds, under normal operating conditions.
rate_limit: If present, the maximum number of requests per second
this agent will accept for this capability.
cost_unit: If present, a human-readable string describing the
pricing unit for invoking this capability (e.g., "USD per 1K
tokens"). This field is informational only and does not
constitute a binding pricing commitment.
Sarker & Reddy Expires 27 December 2026 [Page 10]
Internet-Draft ACAP June 2026
7.2. Authentication Configuration
The auth field contains an OAuth 2.0 Protected Resource Metadata
object as defined in [RFC9728]. Clients MUST use the
authorization_servers field to discover the Authorization Server and
obtain access tokens. Only fields not defined in [RFC9728] are
described below.
AuthConfig = {
"schemes" : [string], ; e.g., ["spiffe", "oauth2", "mtls"]
"authorization_servers" : [string], ; OAuth 2.0 AS URIs (per RFC9728)
"scopes_supported" : [string], ; OAuth 2.0 scopes (per RFC9728)
}
schemes: An array of supported authentication scheme identifiers.
Defined values include "spiffe", "oauth2", and "mtls". Additional
values MAY be defined by IETF agentic protocol suite profile
specifications.
7.3. Transport Configuration
The transport field carries transport configuration for the agent
endpoint. The specific parameters conveyed are to be defined in a
future revision of this document.
TransportConfig = {
"modalities" : [string], ; Supported modalities
"protocols" : [string], ; Supported transport protocols
"pref_add" : [string], ; reachable IP addresses
}
modalities: An array of modality identifiers (e.g., "text", "image",
"audio", "video") indicating what input and output types the agent
can process.
protocols: An array of transport protocols supported by the agent
(e.g., "quic", "moq").
pref_add: Preferred reachable IP addresses. The presentation value
will be a comma-separated list of one or more IP addresses of the
appropriate family in standard textual format [RFC5952]}
[RFC4001].
Sarker & Reddy Expires 27 December 2026 [Page 11]
Internet-Draft ACAP June 2026
8. ACAP Operations
ACAP defines three operations over HTTP/3. Requests and responses
carrying signed ACDs MUST use Content-Type: application/jwt.
Requests and responses carrying unsigned ACDs MUST use Content-Type:
application/json.
8.1. GET — Retrieve an Agent Capability Document
A discovering party retrieves a specific agent's ACD with an HTTP
GET:
GET https://{domain}/.well-known/agents[/{agent-local-id}]/acap HTTP/3
Accept: application/jwt, application/json
200 OK
Content-Type: application/jwt (Model 2) or application/json (Model 1)
Cache-Control: max-age=300
<JWT or JSON>
Servers MUST set Cache-Control: max-age to a value no greater than
the number of seconds remaining until the ACD's exp time. Servers
MUST return 404 Not Found if no ACD exists for the requested agent-
local-id.
8.2. PUT — Register or Update an Agent Capability Document
An agent operator registers or updates an ACD with an HTTP PUT:
PUT https://{domain}/.well-known/agents[/{agent-local-id}]/acap HTTP/3
Content-Type: application/jwt (Model 2) or application/json (Model 1)
<JWT or JSON>
204 No Content
If the ACD is signed, the server MUST verify the JWS signature of the
ACD payload as specified in Section 9. A successful signature
verification constitutes proof of possession of the agent operator's
private key and is sufficient to authenticate the request. Servers
MUST return 400 Bad Request if verification fails.
Authorization policy for agent registration is a matter of local
policy and is out of scope for this document.
Sarker & Reddy Expires 27 December 2026 [Page 12]
Internet-Draft ACAP June 2026
8.3. POST — Query Agents by Capability
A discovering party searches for agents matching specific criteria
using an HTTP POST to the domain-level query endpoint:
POST https://{domain}/.well-known/agents/_query HTTP/3
Content-Type: application/json
{
"capability" : "urn:ietf:cap:translate",
"modalities" : ["text"],
"domain_hint" : "*.example.com",
"max_latency_ms": 500
}
200 OK
Content-Type: application/json
{
"results" : [ <JWT or JSON ACD>, ... ],
"next_cursor": "string"
}
8.3.1. Query Request Fields
capability: REQUIRED. The capability URN to search for. Agents
whose ACD includes a CapabilityDescriptor with a matching id MUST
be included in results.
modalities: OPTIONAL. An array of required modalities. If present,
only agents supporting all listed modalities MUST be returned.
domain_hint: OPTIONAL. A glob pattern or exact domain name
restricting results to agents within matching domains.
max_latency_ms: OPTIONAL. If present, only agents whose relevant
CapabilityDescriptor latency_ms value is less than or equal to
this value MUST be returned.
8.3.2. Query Response Fields
results: An array of JWT or JSON ACDs matching the query criteria.
MAY be empty if no matching agents are found.
next_cursor: If present, the response is paginated. The client MUST
include this cursor value as a cursor field in a subsequent query
request to retrieve the next page of results.
Sarker & Reddy Expires 27 December 2026 [Page 13]
Internet-Draft ACAP June 2026
9. ACD Signing and Verification
ACDs are signed using JWS Compact Serialization [RFC7515]. The
signed ACD is represented as:
Base64url(JWS Protected Header)
|| '.'
|| Base64url(JWT Payload)
|| '.'
|| Base64url(Signature)
9.1. JWS Protected Header
The JWS Protected Header MUST contain:
alg: The signature algorithm. Algorithm requirements will be
specified in a future version of this document.
kid: The key identifier of the agent operator's signing key,
referencing an entry in the JWK Set at the jwks_uri field of the
ACD.
9.2. Signing Procedure
1. Construct the JWT payload as a JSON object containing the JWT
registered claims (iss, iat, exp) and all ACD-specific fields as
defined in Section 7.
2. Serialize the JWT payload to JSON and base64url-encode the result
to form the JWS Payload.
3. Sign using the agent operator's private key to produce the JWT.
9.3. Verification Procedure
Recipients MUST perform the following steps before acting on any
signed ACD:
1. Parse the JWT to extract the Protected Header, Payload, and
Signature.
2. Decode the Protected Header to obtain alg and kid. Fetch the
agent operator's JWK Set from jwks_uri in the decoded payload and
locate the key matching kid.
3. Verify the JWS signature. If verification fails, the ACD MUST be
rejected.
Sarker & Reddy Expires 27 December 2026 [Page 14]
Internet-Draft ACAP June 2026
4. Check the exp claim. If the current time exceeds exp, the ACD
MUST be rejected as expired.
9.4. Freshness
Agent operators SHOULD re-sign and re-publish their ACDs well before
the exp time to ensure continuous discoverability.
10. Security Considerations
ACAP endpoints are served over HTTPS, which protects the
confidentiality and integrity of ACDs in transit and authenticates
the server hosting the ACAP endpoint. However, TLS alone is not
sufficient to establish trust in the content of an ACD.
As discussed in Section 5, in the multi-tenant deployment model the
TLS certificate belongs to the infrastructure provider, not the agent
operator. The ACD signature addresses this gap. By signing the ACD
with a private key under the agent operator's control, separate from
the hosting platform's TLS key, the agent operator binds their
identity directly to the content of the ACD, including the endpoint
URI. Without signature verification, a compromised or malicious
hosting platform could redirect connecting agents to a fraudulent
endpoint. A recipient that verifies the signature can confirm that
the agent operator, not just the hosting infrastructure, authorized
that specific ACD.
Recipients MUST verify ACD signatures before acting on any signed ACD
content, regardless of whether the ACD was retrieved directly from
the ACAP endpoint or obtained through a registry or other
intermediary.
10.1. Transport Security
All ACAP traffic MUST be carried over HTTPS (TLS 1.3 or later) with
server certificate validation. ACAP servers MUST NOT operate over
unencrypted HTTP.
10.2. Validity Period and Freshness
Short validity periods reduce the window in which a compromised or
revoked ACD remains in circulation. Operators SHOULD set exp to a
value appropriate to their operational context. Very long validity
periods SHOULD be avoided for agents whose capabilities or endpoints
may change.
Sarker & Reddy Expires 27 December 2026 [Page 15]
Internet-Draft ACAP June 2026
10.3. Cross-Domain Trust
ACAP does not itself define a cross-domain trust hierarchy. Trust in
an ACD is derived from: (a) TLS server certificate validation of the
ACAP endpoint, and (b) JWS signature verification using the agent
operator's public key obtained from jwks_uri.
Operators SHOULD establish explicit trust relationships with foreign
domains before relying on ACDs served by those domains.
10.4. Key Fetch Security
The security of ACD signature verification depends on the integrity
of the jwks_uri endpoint. Recipients MUST perform PKIX validation of
the TLS certificate of the jwks_uri host before trusting any key
material retrieved from it. The security considerations of [RFC7517]
apply.
10.5. Privacy Considerations
ACDs are publicly accessible capability advertisements by design.
Operators SHOULD avoid including personally identifiable information
or sensitive operational details in ACDs. Capability descriptors and
latency metadata SHOULD be expressed at a level of granularity that
does not reveal implementation internals.
10.6. Denial of Service
ACAP endpoints are public-facing HTTP/3 services and are subject to
denial-of-service attacks. Implementations SHOULD apply rate
limiting to all ACAP operations, particularly the query endpoint
(Section 8.3). The PUT operation (Section 8.2) MUST require
authentication to prevent unauthorised registration.
11. IANA Considerations
11.1. Well-Known URI Registration
This document requests IANA to register the following well-known URI
prefix in the "Well-Known URIs" registry established by [RFC8615]:
URI suffix: agents
Change controller: IETF
Specification document(s): This document
Status: Permanent
Sarker & Reddy Expires 27 December 2026 [Page 16]
Internet-Draft ACAP June 2026
11.2. Media Type
This document uses the application/jwt media type for signed ACD
payloads and application/json for unsigned ACD payloads.
12. References
12.1. Normative References
[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>.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, DOI 10.17487/RFC4001, March 2005,
<https://www.rfc-editor.org/rfc/rfc4001>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/rfc/rfc5952>.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986,
DOI 10.17487/RFC5986, September 2010,
<https://www.rfc-editor.org/rfc/rfc5986>.
[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>.
[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>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/rfc/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
Sarker & Reddy Expires 27 December 2026 [Page 17]
Internet-Draft ACAP June 2026
[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>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/rfc/rfc8414>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.
[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>.
12.2. Informative References
[A2A-v1.0] "What's New in A2A Protocol v1.0", March 2026,
<https://a2a-protocol.org/latest/whats-new-v1/>.
[I-D.farrel-dawn-terminology]
Farrel, A., Yao, K., Schott, R., and N. Williams,
"Terminology for the Discovery of Agents, Workloads, and
Named Entities (DAWN)", Work in Progress, Internet-Draft,
draft-farrel-dawn-terminology-02, 4 June 2026,
<https://datatracker.ietf.org/doc/html/draft-farrel-dawn-
terminology-02>.
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
"WebFinger", RFC 7033, DOI 10.17487/RFC7033, September
2013, <https://www.rfc-editor.org/rfc/rfc7033>.
Sarker & Reddy Expires 27 December 2026 [Page 18]
Internet-Draft ACAP June 2026
[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>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.
[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-CARD] "SD Agent: Selective Disclosure for Agent Discovery and
Identity Management", n.d.,
<https://datatracker.ietf.org/doc/draft-nandakumar-agent-
sd-jwt/>.
[SPIFFE] "Secure Production Identity Framework for Everyone
(SPIFFE)", n.d.,
<https://spiffe.io/docs/latest/spiffe-about/overview/>.
[WebTransport]
"WebTransport", n.d.,
<https://www.w3.org/TR/webtransport/>.
Appendix A. Appendix A — Example ACD (JWT)
The following is a non-normative example of a signed ACD.
The JWS Protected Header is:
{
"alg": "ES256",
"kid": "operator-key-1"
}
The JWT Payload is:
Sarker & Reddy Expires 27 December 2026 [Page 19]
Internet-Draft ACAP June 2026
{
"iss": "https://example.com",
"iat": 1744887600,
"exp": 1744891200,
"id": "urn:ietf:agent:example.com:translator-v1",
"version": "1.0",
"domain": "example.com",
"name": "Example Translation Agent",
"description": "Translates text between supported language pairs",
"endpoint": "https://agent.example.com:4433/translator",
"alt_endpoints": ["https://agent2.example.com:4433/translator"],
"capabilities": {
"translate": {
"id": "urn:ietf:cap:translate",
"version": "1.0",
"input_type": ["text/plain"],
"output_type": ["text/plain"],
"latency_ms": 350,
"rate_limit": 100,
"cost_unit": "USD per 1M characters"
}
},
"auth": {
"schemes": ["oauth2", "mtls"],
"authorization_servers": ["https://auth.example.com"],
"scopes_supported": ["agent:invoke"],
},
"transport": {
"modalities": ["text"],
"protocols": ["quic"],
"pref_add": ["192.0.2.10"]
},
"jwks_uri": "https://agent.example.com/.well-known/jwks.json"
}
The complete signed ACD is the JWT:
<Base64url(Header)>.<Base64url(Payload)>.<Base64url(Signature)>
Appendix B. Appendix B — Relationship to Existing Protocols
ACAP is designed to complement, rather than replace, existing
discovery and identity protocols:
* *WebFinger (RFC 7033)*: WebFinger provides lightweight identity
lookup tied to email-like identifiers. ACAP provides richer,
capability- oriented discovery tied to HTTPS well-known URIs.
Sarker & Reddy Expires 27 December 2026 [Page 20]
Internet-Draft ACAP June 2026
* *DNS-SD / mDNS*: Suitable for local network discovery; does not
scale to Internet-wide agent discovery or carry semantic
capability metadata.
* *OAuth 2.0 (RFC 6749)*: ACAP references OAuth 2.0 for access token
issuance but does not specify authorisation flows; those are left
to IETF agentic protocol suite profile specifications.
* *A2A Agent Cards*: The Agent2Agent Protocol uses a similar well-
known URI pattern for agent discovery. ACAP differs in its richer
ACD schema, its three-operation model including capability search,
and its HTTP/3 transport mandate.
* *SD-Card ([SD-CARD])*: SD-Card applies SD-JWT [RFC9901] to A2A
Agent Cards to enable selective disclosure of agent capabilities
in privacy-sensitive contexts. ACAP differs in that ACDs are
publicly accessible capability advertisements served from well-
known URIs; selective disclosure is not applicable to ACAP's
design. Access control to specific capabilities is enforced at
invocation time through the auth and scopes_supported fields in
the ACD, not at discovery time.
* *DAWN ([I-D.farrel-dawn-terminology])*: The Discovery of Agents,
Workloads, and Named Entities (DAWN) effort treats discovery as
locating an entity to communicate with, and explicitly places
capability exposure and capability exchange out of scope while
noting they are essential to agent selection and operation. ACAP
provides that function: an ACD is a capability card in DAWN's
terms, and ACAP's retrieval, registration, and query operations
are how an agent's capabilities are exposed and exchanged.
Appendix C. Appendix C — Example Discovery Flow
This example walks through a complete discovery of the translation
agent from Appendix A, hosted at example.com.
1. Obtain the domain. The discovering party knows the domain
example.com, for example from configuration (see the methods in
Section 6)
2. Find the agent. The party queries the domain for agents offering
the translation capability:
Sarker & Reddy Expires 27 December 2026 [Page 21]
Internet-Draft ACAP June 2026
POST https://example.com/.well-known/agents/_query
Content-Type: application/json
{ "capability": "urn:ietf:cap:translate" }
200 OK
Content-Type: application/json
{
"results": [ "<signed ACD for translator-v1; see Appendix A>" ]
}
1. Verify the ACD. The party fetches the JWK Set from the jwks_uri
in the ACD, verifies the JWS signature using the key matching
kid, and checks that the exp time has not passed.
2. Connect. Having confirmed the agent operator signed the ACD, the
party connects to the endpoint (https://agent.example.com:4433/
translator) and uses the agent's translation capability.
Acknowledgements
Thanks to Mohamed Boucadair for the review and suggestions.
Authors' Addresses
Zaheduzzaman Sarker
Nokia
Email: zaheduzzaman.sarker@nokia.com
Tirumaleswar Reddy
Nokia
Email: k.tirumaleswar_reddy@nokia.com
Sarker & Reddy Expires 27 December 2026 [Page 22]