Network Working Group H. Lian Internet-Draft AI Pair Intended status: Informational 17 June 2026 Expires: 19 December 2026 Agent Discovery Protocol (ADP) v1.1 — Well-Known Metadata and Interaction Layer draft-pro-adp-agent-discovery-01 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 19 December 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. Lian Expires 19 December 2026 [Page 1] Internet-Draft adp-agent-discovery June 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Layer 1: DNS Discovery (DNS-AID) . . . . . . . . . . . . . . 7 4.1. SVCB Record (RECOMMENDED) . . . . . . . . . . . . . . . . 7 4.1.1. SvcParamKey Usage in ADP . . . . . . . . . . . . . . 8 4.1.2. Hosted Agents (TargetName) . . . . . . . . . . . . . 8 4.1.3. Organization Index (AliasMode) . . . . . . . . . . . 8 4.2. TLSA Record (RECOMMENDED with DNSSEC) . . . . . . . . . . 9 4.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Fallback Discovery: TXT + SRV . . . . . . . . . . . . . . . . 9 5.1. TXT Record . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. SRV Record . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Fallback Procedure . . . . . . . . . . . . . . . . . . . 10 6. Layer 2: Well-Known Metadata . . . . . . . . . . . . . . . . 11 6.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Content Type . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.3.1. Top-Level Members . . . . . . . . . . . . . . . . . . 11 6.3.2. Identity Block . . . . . . . . . . . . . . . . . . . 12 6.3.3. Endpoints Block . . . . . . . . . . . . . . . . . . . 12 6.3.4. Capabilities Block . . . . . . . . . . . . . . . . . 13 6.3.5. Security Block . . . . . . . . . . . . . . . . . . . 13 6.3.6. Example . . . . . . . . . . . . . . . . . . . . . . . 13 6.4. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Layer 3: Interaction Endpoints . . . . . . . . . . . . . . . 15 7.1. HTML Landing Page . . . . . . . . . . . . . . . . . . . . 15 7.1.1. JSON-LD Embedding . . . . . . . . . . . . . . . . . . 15 7.1.2. HTML Meta Tags . . . . . . . . . . . . . . . . . . . 15 7.1.3. Semantic HTML . . . . . . . . . . . . . . . . . . . . 15 7.2. Agent Gateway Protocol (AGP) . . . . . . . . . . . . . . 15 7.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 16 7.2.2. Connection Handshake . . . . . . . . . . . . . . . . 16 7.2.3. Message Format . . . . . . . . . . . . . . . . . . . 16 7.2.4. Message Types . . . . . . . . . . . . . . . . . . . . 17 7.2.5. Signature Computation . . . . . . . . . . . . . . . . 17 7.3. HTTP Endpoints . . . . . . . . . . . . . . . . . . . . . 17 7.3.1. Task Endpoint . . . . . . . . . . . . . . . . . . . . 17 7.3.2. Swarm Endpoint . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8.1. Trust Escalation Model . . . . . . . . . . . . . . . . . 18 8.1.1. Freshness and Replay Protection . . . . . . . . . . . 18 Lian Expires 19 December 2026 [Page 2] Internet-Draft adp-agent-discovery June 2026 8.1.2. Fingerprint Verification . . . . . . . . . . . . . . 19 8.2. TLS Requirements . . . . . . . . . . . . . . . . . . . . 19 8.3. Private Agents . . . . . . . . . . . . . . . . . . . . . 19 8.3.1. Invitation Format . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9.1. Well-Known URI Registration . . . . . . . . . . . . . . . 20 9.2. SvcParamKey Registration (via DNS-AID) . . . . . . . . . 20 9.3. Service Name Registration . . . . . . . . . . . . . . . . 20 9.4. Media Type Registration . . . . . . . . . . . . . . . . . 20 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 10.1. Reference Implementation . . . . . . . . . . . . . . . . 21 10.2. Backward Compatibility . . . . . . . . . . . . . . . . . 21 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 12. Version History . . . . . . . . . . . . . . . . . . . . . . . 22 13. Normative References . . . . . . . . . . . . . . . . . . . . 22 14. Informative References . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 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 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. Lian Expires 19 December 2026 [Page 3] Internet-Draft adp-agent-discovery June 2026 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 * 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 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 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 (Section 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. Lian Expires 19 December 2026 [Page 4] Internet-Draft adp-agent-discovery June 2026 * Updated Well-Known schema with dns block and dane auth method. * Added implementation guidance for SVCB-first discovery clients. 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 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 interactingvia 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}. Lian Expires 19 December 2026 [Page 5] Internet-Draft adp-agent-discovery June 2026 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 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 normativeLayer 1. 3. Protocol Overview The Agent Discovery Protocol defines a three-layer discovery and interaction stack 1. *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. 2. *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. 3. *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 Lian Expires 19 December 2026 [Page 6] Internet-Draft adp-agent-discovery June 2026 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 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 Lian Expires 19 December 2026 [Page 7] Internet-Draft adp-agent-discovery June 2026 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 transportprotocol negotiation. ADP v1.1 defines the protocol identifier a2a forthe AGP messaging protocol (Section Section 7.2). well-known Path relative to the Well-Known URI namespace. Discovery Clients MUST resolve this against https://{target}/.well- known/{well-known}. Ifabsent, 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 capabilitydocument 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 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 Lian Expires 19 December 2026 [Page 8] Internet-Draft adp-agent-discovery June 2026 4.2. TLSA Record (RECOMMENDED with DNSSEC) ADP Agents SHOULD publish a TLSA record to enable DANE _443._tcp.alice.example.com. 3600 IN TLSA 3 1 1 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. Lian Expires 19 December 2026 [Page 9] Internet-Draft adp-agent-discovery June 2026 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. 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 acrossmultiple TXT records at the same owner name. Reassembly concatenatesRDATA 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 1. Query SVCB at {domain}. 2. If NODATA or NXDOMAIN, proceed to fallback. 3. Query TXT at _agent.{domain}. 4. Parse v, pk, wk fields. 5. Query SRV at _agent._tcp.{domain} to locate host:port. 6. Proceed to Layer 2 (Section 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 Lian Expires 19 December 2026 [Page 10] Internet-Draft adp-agent-discovery June 2026 mode differ from SVCB-mode (no ALPN validation, no capability digest, no IP hints). 6. Layer 2: Well-Known Metadata 6.1. Endpoint Every ADP-compliant Agent MUST serve a JSON document at the path /.well-known/agent.json Figure 8 As defined in [RFC8615], this URI suffix is registered under the /.well-known/ namespace. 6.2. Content Type The response MUST include Content-Type: application/json. The document MUST be valid JSON [RFC8259] and SHOULD include a $schema field pointing to the ADP schema resource. 6.3. Schema 6.3.1. Top-Level Members $schema (string, OPTIONAL) URI of the JSON Schema for this document, e.g. "https://raw.githubusercontent.com/harrylian8766/adp- protocol/main/schemas/v1.1/agent.json". protocol (string, REQUIRED) Protocol version string. For this document, MUST be "ADP/1.1". identity (object, REQUIRED) Agent identity block (Section Section 6.3.2). endpoints (object, REQUIRED) Map of endpoint names to absolute URLs (Section Section 6.3.3). capabilities (array, REQUIRED) Array of capability objects (Section Section 6.3.4). Lian Expires 19 December 2026 [Page 11] Internet-Draft adp-agent-discovery June 2026 interfaces (object, OPTIONAL) Map of interface type to URL, e.g. html, api, chat. relationships (array, OPTIONAL) Known peer Agents. Each entry contains type, id, name, optional trust level, and optional since timestamp. security (object, REQUIRED) Security configuration (Section Section 6.3.5). dns (object, OPTIONAL) DNS record references for verification: * svcbRecord (string): The domain at which the SVCB record was queried. * tlsaRecord (string): The TLSA record query name. * dnssec (boolean): Whether the zone is DNSSEC-signed. policies (object, OPTIONAL) Links to privacy policy, terms of service, data retention policy. availability (object, REQUIRED) Current operational status. meta (object, OPTIONAL) Document metadata: updated, version, generator, documentation. 6.3.2. Identity Block * id (REQUIRED): Agent URI agent:{domain}. * domain (REQUIRED): Canonical FQDN. * name (REQUIRED): Human-readable Agent name. * owner (REQUIRED): Display name of the entity operating the Agent. * created (REQUIRED): ISO 8601 creation timestamp. * publicKey (REQUIRED): Object with: * algorithm (REQUIRED): "ed25519". * fingerprint (REQUIRED): ed25519: as defined in DNS-AID and the fallback TXT record. * full (OPTIONAL): Base64url-encoded full 32-byte Ed25519 public key. * proof (OPTIONAL): A signature over agent:{domain} made with the corresponding private key, encoded as signature:. 6.3.3. Endpoints Block * discovery: Landing page URL (HTTPS). * wellKnown: Canonical Well-Known URL (HTTPS). Lian Expires 19 December 2026 [Page 12] Internet-Draft adp-agent-discovery June 2026 * chat: WebSocket Secure URL for AGP messaging (Section Section 7.2). * tasks: HTTPS URL for asynchronous task submission. * swarm: HTTPS URL for multi-agent coordination. * webhook: HTTPS URL for outbound event callbacks. 6.3.4. Capabilities Block * id (REQUIRED): Unique capability identifier (e.g., chat, code- review). * name (REQUIRED): Human-readable name. * description (REQUIRED): Short natural-language summary. * input (array): Accepted MIME types and modalities (e.g., text, image, file). * output (array): Produced MIME types and modalities. * interfaces (array): Which interfaces expose this capability (chat, api, webhook). * languages (array): BCP 47 language tags the Agent supports. * pricing (object): model (free, subscription, per-use, enterprise) and optional details. 6.3.5. Security Block * tlsRequired (boolean): Whether TLS is required for all endpoints. * minProtocolVersion (string): Minimum ADP protocol version required. * authMethods (array): Supported authentication methods. ADP v1.1 adds the value dane to indicate DANE-based TLS authentication (Section Section 4.2). * rateLimit (object): requestsPerMinute and burstSize. 6.3.6. Example { "$schema": "https://raw.githubusercontent.com/harrylian8766/adp-protocol/main/schemas/v1.1/agent.json", "protocol": "ADP/1.1", "identity": { "id": "agent:alice.example.com", "domain": "alice.example.com", "name": "Alice's Agent", "owner": "Alice", "created": "2026-01-15T00:00:00Z", "publicKey": { "algorithm": "ed25519", Lian Expires 19 December 2026 [Page 13] Internet-Draft adp-agent-discovery June 2026 "fingerprint": "ed25519:dGhpcyBpcyBhIHRlc3Qg..." } }, "endpoints": { "discovery": "https://alice.example.com/", "wellKnown": "https://alice.example.com/.well-known/agent.json", "chat": "wss://alice.example.com/agent/chat", "tasks": "https://alice.example.com/agent/tasks" }, "capabilities": [ { "id": "chat", "name": "Conversation", "description": "General-purpose conversational AI", "input": ["text", "image", "file"], "output": ["text", "html", "chart"], "interfaces": ["chat", "api"], "languages": ["en", "zh"], "pricing": { "model": "free" } } ], "security": { "tlsRequired": true, "minProtocolVersion": "ADP/1.1", "authMethods": ["pubkey", "dane"], "rateLimit": { "requestsPerMinute": 60, "burstSize": 10 } }, "dns": { "svcbRecord": "alice.example.com", "tlsaRecord": "_443._tcp.alice.example.com", "dnssec": true }, "availability": { "status": "online", "uptime": "99.9%" } } Figure 9 6.4. Caching Discovery Clients MAY cache the Well-Known JSON. The RECOMMENDED TTL is the DNS TTL of the SVCB record or 3600 seconds, whichever is shorter. Clients SHOULD revalidate using the cap-sha256 digest from the SVCB Lian Expires 19 December 2026 [Page 14] Internet-Draft adp-agent-discovery June 2026 record when available. 7. Layer 3: Interaction Endpoints 7.1. HTML Landing Page The domain root (/) SHOULD return an HTML document suitable for browser rendering. The page serves as the human-facing Agent card and MUST embed structured data for machine consumption. 7.1.1. JSON-LD Embedding The page MUST include a