Network Working Group Bin. Lian Internet-Draft aipair.ai Intended status: Informational 18 June 2026 Expires: 20 December 2026 Agent Discovery Protocol (ADP) v1.1 — Well-Known Metadata and Interaction Layer draft-pro-adp-agent-discovery-02 Abstract This document defines the Agent Discovery Protocol (ADP) v1.1, a layered protocol for discovering, verifying, and interacting with AI Agents on the Internet. ADP delegates DNS discovery to DNS-AID (SVCB records) and defines a Well-Known JSON metadata format, an Ed25519-based identity model, and the Agent Gateway Protocol (AGP) for real-time WebSocket messaging. The protocol is designed to be decentralized, standards-based, and incremental — clients escalate from DNS to HTTP to WebSocket only as needed. 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 20 December 2026. Lian Expires 20 December 2026 [Page 1] Internet-Draft adp-agent-discovery June 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Relationship to DNS-AID . . . . . . . . . . . . . . . . . 4 1.3. Changes from -00 . . . . . . . . . . . . . . . . . . . . 4 1.4. Design Goals . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Layer 1: DNS Discovery (DNS-AID) . . . . . . . . . . . . . . 8 4.1. SVCB Record (RECOMMENDED) . . . . . . . . . . . . . . . . 8 4.1.1. SvcParamKey Usage in ADP . . . . . . . . . . . . . . 8 4.1.2. Hosted Agents (TargetName) . . . . . . . . . . . . . 9 4.1.3. Organization Index (AliasMode) . . . . . . . . . . . 9 4.2. TLSA Record (RECOMMENDED with DNSSEC) . . . . . . . . . . 9 4.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Fallback Discovery: TXT + SRV . . . . . . . . . . . . . . . . 10 5.1. TXT Record . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. SRV Record . . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Fallback Procedure . . . . . . . . . . . . . . . . . . . 11 6. Layer 2: Well-Known Metadata . . . . . . . . . . . . . . . . 11 6.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Content Type . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3.1. Top-Level Members . . . . . . . . . . . . . . . . . . 12 6.3.2. Identity Block . . . . . . . . . . . . . . . . . . . 12 6.3.3. Endpoints Block . . . . . . . . . . . . . . . . . . . 13 6.3.4. Capabilities Block . . . . . . . . . . . . . . . . . 13 6.3.5. Security Block . . . . . . . . . . . . . . . . . . . 14 6.3.6. Example . . . . . . . . . . . . . . . . . . . . . . . 14 6.4. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Layer 3: Interaction Endpoints . . . . . . . . . . . . . . . 16 7.1. HTML Landing Page . . . . . . . . . . . . . . . . . . . . 16 7.1.1. JSON-LD Embedding . . . . . . . . . . . . . . . . . . 16 7.1.2. HTML Meta Tags . . . . . . . . . . . . . . . . . . . 16 7.1.3. Semantic HTML . . . . . . . . . . . . . . . . . . . . 16 7.2. Agent Gateway Protocol (AGP) . . . . . . . . . . . . . . 16 Lian Expires 20 December 2026 [Page 2] Internet-Draft adp-agent-discovery June 2026 7.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 16 7.2.2. Connection Handshake . . . . . . . . . . . . . . . . 17 7.2.3. Message Format . . . . . . . . . . . . . . . . . . . 17 7.2.4. Message Types . . . . . . . . . . . . . . . . . . . . 18 7.2.5. Signature Computation . . . . . . . . . . . . . . . . 18 7.3. HTTP Endpoints . . . . . . . . . . . . . . . . . . . . . 18 7.3.1. Task Endpoint . . . . . . . . . . . . . . . . . . . . 18 7.3.2. Swarm Endpoint . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8.1. Trust Escalation Model . . . . . . . . . . . . . . . . . 19 8.1.1. Freshness and Replay Protection . . . . . . . . . . . 19 8.1.2. Fingerprint Verification . . . . . . . . . . . . . . 20 8.2. TLS Requirements . . . . . . . . . . . . . . . . . . . . 20 8.3. Private Agents . . . . . . . . . . . . . . . . . . . . . 20 8.3.1. Invitation Format . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9.1. Well-Known URI Registration . . . . . . . . . . . . . . . 21 9.2. SvcParamKey Registration (via DNS-AID) . . . . . . . . . 21 9.3. Service Name Registration . . . . . . . . . . . . . . . . 21 9.4. Media Type Registration . . . . . . . . . . . . . . . . . 22 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 10.1. Reference Implementation . . . . . . . . . . . . . . . . 23 10.2. Backward Compatibility . . . . . . . . . . . . . . . . . 23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 12. Version History . . . . . . . . . . . . . . . . . . . . . . . 24 13. Normative References . . . . . . . . . . . . . . . . . . . . 24 14. Informative References . . . . . . . . . . . . . . . . . . . 26 Appendix A. Appendix: HTML Landing Page Example . . . . . . . . 26 Appendix B. Author's Address . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction 1.1. Background AI Agents are evolving from chatbot plugins into autonomous, internet-native entities. Each platform (OpenAI, Dify, Coze) provides its own directory and identity system, but there is no universal discovery mechanism: an Agent on one platform cannot natively discover an Agent on another without a bridging registry. The Web solved an analogous problem decades ago: any resource can be discovered through a combination of DNS names, well-known ports, and Lian Expires 20 December 2026 [Page 3] Internet-Draft adp-agent-discovery June 2026 HTML interlinking. ADP applies the same principle to Agents, adding what the Web assumes but Agents require: structured capability descriptions, cryptographic identity binding, and real-time communication primitives. 1.2. Relationship to DNS-AID DNS-AID [I-D.mozleywilliams-dnsop-dnsaid] defines the DNS discovery layer for Agents using SVCB records [RFC9460]. It registers the *following SvcParamKeys* * bap: Bulk Agent Protocol identifier (e.g., a2a, mcp). * cap: URI or URN of the Agent's capability descriptor. * cap-sha256: SHA-256 digest of the capability descriptor. * well-known: Path relative to /.well-known/ for the Agent's metadata document. ADP v1.1 adopts DNS-AID as its normative DNS discovery mechanism. The ADP Well-Known JSON schema (Section 6) serves as the content format pointed to by the well-known SvcParamKey. If DNS-AID is unavailable (the DNS resolver does not support SVCB, or the authoritative server has not published SVCB records), ADP provides a fallback path using TXT [RFC1035] and SRV [RFC2782] records as documented in Section 5. 1.3. Changes from -00 * Layer 1 (DNS): Replaced TXT+SRV as the primary mechanism with reference to DNS-AID [I-D.mozleywilliams-dnsop-dnsaid]. The original TXT+SRV scheme is retained as a documented fallback Lian Expires 20 December 2026 [Page 4] Internet-Draft adp-agent-discovery June 2026 (Section 5). * Added TLSA [RFC6698] + DNSSEC [RFC9364] for DANE-style TLS endpoint authentication. * Defined a trust escalation chain: dns-verified → dane-verified → key-verified → peer-verified. * Protocol version string updated from ADP/1.0 to ADP/1.1. * Updated Well-Known schema with dns block and dane auth method. * Added implementation guidance for SVCB-first discovery clients. * Updated IANA media type registration to vendor tree: application/vnd.adp+json (see Section 9.4). 1.4. Design Goals * *Decentralized*: No central registry; domain ownership is the root of identity. * *Layered and incremental*: SVCB answers connectivity in one round trip; Well-Known provides full metadata; WebSocket enables real-time chat. Do not escalate to a heavier layer when a lighter one suffices. * *Standards-based*: Built on SVCB [RFC9460], TLSA [RFC6698], DNSSEC [RFC9364], Well-Known URIs [RFC8615], WebSocket [RFC6455], and Ed25519 [RFC8032]. * *Aligned with IETF work*: DNS layer defers to DNS-AID [I-D.mozleywilliams-dnsop-dnsaid]. ADP focuses on what happens after discovery. * *Human-and-machine readable*: The root URL serves both a browser Lian Expires 20 December 2026 [Page 5] Internet-Draft adp-agent-discovery June 2026 user and an automated client via JSON-LD embedding. * *Secure by default*: DNS-AID + TLSA/DANE anchors the TLS endpoint; Ed25519 signatures authenticate messages end-to-end. 2. Terminology Agent An autonomous or semi-autonomous software entity identified by a domain name, capable of being discovered through DNS-AID + ADP and interacting via standard Web protocols. Agent Domain A fully qualified domain name (FQDN) that serves as the canonical identifier for an Agent. The Agent URI scheme is agent:{domain}. Discovery Client Software that performs discovery to locate and verify an Agent's identity, capabilities, and endpoints. Fingerprint The SHA-256 hash of an Ed25519 public key, encoded in base64url without padding and prefixed with ed25519:. AGP (Agent Gateway Protocol) The WebSocket-based messaging protocol defined in Section 7.2, used for inter-agent communication after discovery. DNS-AID The DNS-based Agent Identity and Discovery mechanism defined in [I-D.mozleywilliams-dnsop-dnsaid], which serves as ADP's normative Layer 1. 3. Protocol Overview The Agent Discovery Protocol defines a three-layer discovery and Lian Expires 20 December 2026 [Page 6] Internet-Draft adp-agent-discovery June 2026 *interaction stack* *Layer 1 — DNS Discovery (delegated to DNS-AID):* A single SVCB query at the Agent's domain name returns the target, port, IP hints, ALPN protocol list, Agent protocol identifier (bap), capability descriptor URI (cap), its SHA-256 digest (cap-sha256), and the Well-Known URI path (well-known). TLSA records enable DANE-based TLS endpoint authentication. TXT+SRV records serve as fallback. *Layer 2 — Well-Known Metadata (this document):* A GET request to the Well-Known URI (default /.well-known/agent.json) returns a JSON document containing the Agent's identity, capabilities, relationships, security policies, and endpoint map. *Layer 3 — Interaction Endpoints (this document):* An HTML landing page at the domain root provides human-readable discovery with embedded JSON-LD structured data. WebSocket endpoints using the Agent Gateway Protocol (AGP) enable real-time inter-agent communication with Ed25519 signature authentication. +-----------------------------------------------------+ | Agent Discovery Stack | +-----------------------------------------------------+ | Layer 1: DNS-AID | Layer 2+3: ADP | | (SVCB + TLSA) | (Well-Known + AGP) | +-----------------------------------------------------+ | IETF dnsop WG | This Document | +-----------------------------------------------------+ Figure 1 *Core principle*: If SVCB answers your question, do not issue an HTTP Lian Expires 20 December 2026 [Page 7] Internet-Draft adp-agent-discovery June 2026 request. If Well-Known suffices, do not open a WebSocket. 4. Layer 1: DNS Discovery (DNS-AID) ADP v1.1 delegates its DNS discovery layer to DNS-AID [I-D.mozleywilliams-dnsop-dnsaid]. This section summarizes the integration points; the normative specification resides in that document. 4.1. SVCB Record (RECOMMENDED) An ADP-compliant Agent SHOULD publish a SVCB record at its domain name. alice.example.com. 3600 IN SVCB 1 . ( alpn="a2a,h2,h3" port=443 ipv4hint=192.0.2.1 ipv6hint=2001:db8::1 bap=a2a well-known=agent.json cap=https://alice.example.com/capabilities/a2a.json cap-sha256= ) Figure 2 4.1.1. SvcParamKey Usage in ADP alpn The application-layer protocol negotiation IDs [RFC7301]. ADP Agents SHOULD include the relevant Agent protocol identifier (e.g., a2a) alongside standard HTTP protocol IDs (h2, h3). bap Bulk Agent Protocol identifier. Separated from alpn so that policy engines can match on Agent-level protocol without parsing transport protocol negotiation. ADP v1.1 defines the protocol identifier a2a for the AGP messaging protocol (Section 7.2). well-known Path relative to the Well-Known URI namespace. Discovery Lian Expires 20 December 2026 [Page 8] Internet-Draft adp-agent-discovery June 2026 Clients MUST resolve this against https://{target}/.well-known/{well-known}. If absent, the default path /.well-known/agent.json is used. cap URI or URN identifying the Agent's capability descriptor. ADP Agents SHOULD publish this as a URL to their capability document. cap-sha256 SHA-256 digest of the capability descriptor at the time of DNS publishing. Allows a Discovery Client to verify that the capability document has not changed without re-fetching. 4.1.2. Hosted Agents (TargetName) When an Agent is hosted by a third-party provider, the SVCB TargetName field points to the provider's domain. alice.example.com. 3600 IN SVCB 1 provider.example.com. ( alpn="a2a,h2" port=443 bap=a2a well-known=agent.json ) Figure 3 4.1.3. Organization Index (AliasMode) Organizations MAY publish an index of their Agents using AliasMode. _agents.example.com. 3600 IN SVCB 0 alice.example.com. _agents.example.com. 3600 IN SVCB 0 bob.example.com. Figure 4 4.2. TLSA Record (RECOMMENDED with DNSSEC) ADP Agents SHOULD publish a TLSA record to enable DANE-based TLS endpoint authentication. _443._tcp.alice.example.com. 3600 IN TLSA 3 1 1 Lian Expires 20 December 2026 [Page 9] Internet-Draft adp-agent-discovery June 2026 Figure 5 * TLSA records are only valid when the DNS zone is DNSSEC-signed [RFC9364], to prevent downgrade attacks. * The RECOMMENDED usage is DANE-EE (3), selector SPKI (1), matching type SHA-256 (1). * A Discovery Client that receives both a valid TLSA record and a certificate that does not match MUST terminate the connection. 4.3. DNSSEC All DNS records used for Agent discovery SHOULD be DNSSEC-signed. TLSA records MUST be DNSSEC-signed to be trusted. 5. Fallback Discovery: TXT + SRV When the DNS resolver or authoritative server does not support SVCB queries (returns NODATA or NXDOMAIN for a SVCB query), Discovery Clients SHOULD fall back to the following mechanism. This section preserves the Layer 1 from ADP v1.0 (-00) as a backward-compatible alternative. 5.1. TXT Record _agent.{domain}. IN TXT "v=ADP1.1; pk=ed25519:; wk=; alpn=a2a" Figure 6 v (REQUIRED) Protocol version. MUST be ADP1, ADP1.0, or ADP1.1. pk (REQUIRED) Public key fingerprint. Computed as SHA-256 of the raw Ed25519 public key, encoded in base64url without padding. wk (REQUIRED) Full HTTPS URL to the Well-Known agent metadata endpoint. Lian Expires 20 December 2026 [Page 10] Internet-Draft adp-agent-discovery June 2026 alpn (OPTIONAL in fallback) Application protocol identifier (e.g., a2a). port (OPTIONAL) Service port number. Default: 443. bap (OPTIONAL) Agent protocol identifier. Multi-record TXT: Values exceeding 255 octets MAY be split across multiple TXT records at the same owner name. Reassembly concatenates RDATA in returned order. 5.2. SRV Record _agent._tcp.{domain}. IN SRV Figure 7 If no SRV record is published, Discovery Clients SHOULD connect to {domain} on TCP port 443. 5.3. Fallback Procedure Query SVCB at {domain}. If NODATA or NXDOMAIN, proceed to fallback. Query TXT at _agent.{domain}. Parse v, pk, wk fields. Query SRV at _agent._tcp.{domain} to locate host:port. Proceed to Layer 2 (Section 6) using the resolved URL and host. Discovery Clients that successfully use the fallback path SHOULD indicate this in their user agent or log, as the security properties of fallback discovery are weaker than SVCB-based discovery (no DANE support, weaker path validation). 6. Layer 2: Well-Known Metadata 6.1. Endpoint Lian Expires 20 December 2026 [Page 11] Internet-Draft adp-agent-discovery June 2026 GET https://{domain}/.well-known/agent.json Figure 8 6.2. Content Type *The server MUST respond with Content-Type* application/vnd.adp+json (vendor-tree media type registered per Section 9.4). Prior to formal registration, servers MAY use application/json as a transitional content type. 6.3. Schema 6.3.1. Top-Level Members *The JSON document contains the following top-level members* protocol REQUIRED. Protocol version string. MUST be ADP/1.1. identity REQUIRED. Identity block (Section 6.3.2). endpoints REQUIRED. Endpoints block (Section 6.3.3). capabilities REQUIRED. Capabilities block (Section 6.3.4). security RECOMMENDED. Security block (Section 6.3.5). policies OPTIONAL. Privacy, terms, and data handling policies. availability OPTIONAL. Status and uptime information. meta OPTIONAL. Generator, version, and documentation references. 6.3.2. Identity Block *The identity block MUST contain* id Agent URI in the form agent:{domain}. domain The Agent's FQDN. name Human-readable Agent name. publicKey Object containing: Lian Expires 20 December 2026 [Page 12] Internet-Draft adp-agent-discovery June 2026 * algorithm: MUST be ed25519. * fingerprint: SHA-256 of the Ed25519 public key, encoded in base64url without padding, prefixed with ed25519:. * full: PEM-encoded Ed25519 public key (if verification needed). * proof: OPTIONAL. Self-signature proving key possession. 6.3.3. Endpoints Block At minimum, the wellKnown endpoint MUST be present. Additional *endpoints provide entry points for different interaction modes* wellKnown URL of this document (self-referential). discovery HTML landing page URL. chat WebSocket URL for AGP real-time messaging. tasks REST endpoint for asynchronous task submission. swarm REST endpoint for multi-agent swarm coordination. webhook REST endpoint for external event callbacks. 6.3.4. Capabilities Block *Each capability is an object with* id Unique capability identifier. name Human-readable name. description Free-text description. input Array of accepted MIME types or tokens (e.g., `["text", "image", "file"]`). output Array of produced MIME types or tokens. interfaces Array of supported interface modes (e.g., ["chat", "api"]). languages Array of BCP 47 language tags. Lian Expires 20 December 2026 [Page 13] Internet-Draft adp-agent-discovery June 2026 pricing Object with model (free, per_use, subscription) and optional details. 6.3.5. Security Block tlsRequired MUST be true per Section 8.2. minProtocolVersion Minimum ADP protocol version accepted. authMethods Array of supported authentication methods. All implementations MUST support pubkey. MAY also support bearer_token. rateLimit Object with requestsPerMinute and burstSize for rate limiting. 6.3.6. Example { "protocol": "ADP/1.1", "identity": { "id": "agent:alice.example.com", "domain": "alice.example.com", "name": "Alice's Agent", "publicKey": { "algorithm": "ed25519", "fingerprint": "ed25519:dGhpcyBpcyBhIHRlc3QgcHVibGljIGtleQ", "full": "-----BEGIN PUBLIC KEY-----\nMCowBQYDK2VwAyE...\n-----END PUBLIC KEY-----" } }, "endpoints": { "wellKnown": "https://alice.example.com/.well-known/agent.json", "discovery": "https://alice.example.com/", "chat": "wss://alice.example.com/agent/chat", "tasks": "https://alice.example.com/agent/tasks", "swarm": "https://alice.example.com/agent/swarm" }, "capabilities": [ { "id": "chat", "name": "Conversational Chat", "description": "General-purpose conversational AI", "input": ["text", "image", "file"], "output": ["text", "html"], "interfaces": ["chat", "api"], "languages": ["en", "zh"], Lian Expires 20 December 2026 [Page 14] Internet-Draft adp-agent-discovery June 2026 "pricing": { "model": "free" } } ], "security": { "tlsRequired": true, "minProtocolVersion": "ADP/1.1", "authMethods": ["pubkey"], "rateLimit": { "requestsPerMinute": 60, "burstSize": 10 } }, "dns": { "svcbVerified": true, "dnssecSigned": true, "dane": { "supported": true, "usage": "DANE-EE", "selector": "SPKI", "matchingType": "SHA-256" } } } Figure 9 6.4. Caching Discovery Clients SHOULD cache Well-Known metadata with respect to the HTTP Cache-Control headers returned by the server. If no explicit cache directives are present, clients SHOULD apply a default TTL of 3600 seconds. Clients MAY use the cap-sha256 SvcParamKey from DNS-AID to detect changes to the capability descriptor without re-fetching the full document. Lian Expires 20 December 2026 [Page 15] Internet-Draft adp-agent-discovery June 2026 7. Layer 3: Interaction Endpoints 7.1. HTML Landing Page The domain root (GET /) MUST return an HTML page suitable for both human browsing and machine parsing. 7.1.1. JSON-LD Embedding The page MUST embed a

Alice's Agent

General-purpose conversational AI agent.

 Figure 16 Appendix B. Author's Address Bin Lian aipair.ai Email: TBD Figure 17 Author's Address Bin Lian aipair.ai Email: TBD Lian Expires 20 December 2026 [Page 27]