]> Nokia

zaheduzzaman.sarker@nokia.com

Nokia

k.tirumaleswar_reddy@nokia.com

xxxxxx xxxxx AI agents capability advertisement agent discovery QUIC WebTransport 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.

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) and the WebFinger protocol 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 when signing is required.
• Three HTTP/3 operations: GET (retrieve), PUT (register/update), and POST (query by capability).
• A signing mechanism based on JSON Web Signature (JWS) 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. Note: A future revision of this document will provide a formal CDDL representation covering both JSON and CBOR encodings, enabling the same ACD content to be represented in either encoding. When CBOR encoding is supported, COSE will be used for signing in place of JWS. Clients and servers will negotiate the encoding using the Accept and Content-Type headers.

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 when, and only when, they appear in all capitals, as shown here.

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

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 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. 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 (). 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.

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:

Basic ACAP Discovery Flow | | 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) --->| ]]>

Deployment Models This section describes two common deployment models. Other deployment models are possible and may be defined in future revisions of this document.

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

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

Well-Known URIs ACAP endpoints MUST be accessible at the following well-known URI (): 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: 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: ACAP endpoints MUST be served over HTTPS with a valid TLS certificate. Servers MUST support HTTP/3 . NOTE : Support for HTTP/2 as a fallback MAY need to be considered.

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 );
• it is provided by from another agent; or
• it is resolved through DNS-based agent discovery.

Once the domain is known, the client constructs the well-known URI () and proceeds with the operations in .

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 , and use it to construct the ACAP discovery URI: This allows the endpoint to discover agents offered by the network operator without any out-of-band configuration.

Agent Capability Document (ACD) Format ACDs are JSON objects. In Model 2 (), ACDs MUST be carried as the payload of a JWT , signed using JWS Compact Serialization as described in . In Model 1, ACDs MAY be signed. The JWT payload for a signed ACD contains the following fields. The JWT registered claims 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 .

exp:

The expiration time of the ACD, as a NumericDate value per . Recipients MUST NOT use an ACD whose exp time has passed.

The JWT registered claims iss, iat, and exp are defined by and are included here to clarify their specific semantics and requirements within the ACAP context. Implementations MUST follow for encoding and processing these claims. The following ACD-specific fields MUST also be present in the JWT payload: 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 ).

auth:

An AuthConfig object describing supported authentication and authorization schemes (see ).

transport:

A TransportConfig object describing the agent endpoint's transport configuration (see ).

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 MAY be retrieved. Used by recipients to obtain the public key for JWS signature verification. MUST be present in Model 2 ().

Capability Descriptor

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.

Authentication Configuration The auth field contains an OAuth 2.0 Protected Resource Metadata object as defined in . Clients MUST use the authorization_servers field to discover the Authorization Server and obtain access tokens. Only fields not defined in are described below.

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.

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.

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

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.

GET — Retrieve an Agent Capability Document A discovering party retrieves a specific agent's ACD with an HTTP GET: ]]> 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.

PUT — Register or Update an Agent Capability Document An agent operator registers or updates an ACD with an HTTP PUT: 204 No Content ]]> If the ACD is signed, the server MUST verify the JWS signature of the ACD payload as specified in . 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.

POST — Query Agents by Capability A discovering party searches for agents matching specific criteria using an HTTP POST to the domain-level query endpoint: , ... ], "next_cursor": "string" } ]]>

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.

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.

ACD Signing and Verification ACDs are signed using JWS Compact Serialization . The signed ACD is represented as:

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.

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

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.
4. Check the exp claim. If the current time exceeds exp, the ACD MUST be rejected as expired.

Freshness Agent operators SHOULD re-sign and re-publish their ACDs well before the exp time to ensure continuous discoverability.

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

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.

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.

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.

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

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.

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 (). The PUT operation () MUST require authentication to prevent unauthorised registration.

IANA Considerations

Well-Known URI Registration This document requests IANA to register the following well-known URI prefix in the "Well-Known URIs" registry established by :

URI suffix:

agents

Change controller:

IETF

Specification document(s):

This document

Status:

Permanent

Media Type This document uses the application/jwt media type for signed ACD payloads and application/json for unsigned ACD payloads.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. Discovery of the correct Location Information Server (LIS) in the local access network is necessary for Devices that wish to acquire location information from the network. A method is described for the discovery of a LIS in the access network serving a Device. Dynamic Host Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name. This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process. [STANDARDS-TRACK] As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK] Informative References This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Old Dog Consulting China Mobile Deutsche Telekom Infoblox The proliferation of distributed systems, Artificial Intelligence (AI) agents, cloud workloads, and network services has created a need for interoperable mechanisms to discover entities. Entities may include AI agents, software services, compute workloads, and other named resources that need to be found and characterised before interaction can begin. This document defines terminology for Discovery of Agents, Workloads, and Named Entities (DAWN). The intention is that this common set of terms can be used by other documents related to DAWN and so achieve consistency of meaning across the space. n.d. n.d. n.d.

Appendix A — Example ACD (JWT) The following is a non-normative example of a signed ACD. The JWS Protected Header is: The JWT Payload is: The complete signed ACD is the JWT: .. ]]>

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.
• 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 applies SD-JWT 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 (): 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 — 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 )
2. Find the agent. The party queries the domain for agents offering the translation capability:

" ] } ]]>

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.