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 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) 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" : [ , ... ], "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, . [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, DOI 10.17487/RFC4001, March 2005, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, DOI 10.17487/RFC5986, September 2010, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . 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, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [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, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, . [RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, . 12.2. Informative References [A2A-v1.0] "What's New in A2A Protocol v1.0", March 2026, . [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, . [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 2013, . 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, . [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, . [RFC9901] Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens", RFC 9901, DOI 10.17487/RFC9901, November 2025, . [SD-CARD] "SD Agent: Selective Disclosure for Agent Discovery and Identity Management", n.d., . [SPIFFE] "Secure Production Identity Framework for Everyone (SPIFFE)", n.d., . [WebTransport] "WebTransport", n.d., . 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: .. 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": [ "" ] } 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]