| Internet-Draft | adp-agent-discovery | June 2026 |
| Lian | Expires 19 December 2026 | [Page] |
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.¶
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 (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.¶
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.¶
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¶
to DNS-AID [I-D.mozleywilliams-dnsop-dnsaid]. The original TXT+SRV¶
scheme is retained as a documented fallback (Section Section 5).¶
endpoint authentication.¶
key-verified → peer-verified.¶
identity.¶
trip; Well-Known provides full metadata; WebSocket enables real-time¶
chat. Do not escalate to a heavier layer when a lighter one suffices.¶
DNSSEC [RFC9364], Well-Known URIs [RFC8615], WebSocket¶
[RFC6455], and Ed25519 [RFC8032].¶
[I-D.mozleywilliams-dnsop-dnsaid]. ADP focuses on what happens after¶
discovery.¶
and an automated client via JSON-LD embedding.¶
Ed25519 signatures authenticate messages end-to-end.¶
agent:{domain}.¶
ed25519:.¶
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¶
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 | +-----------------------------------------------------+
Core principle: If SVCB answers your question, do not issue an HTTP¶
request. If Well-Known suffices, do not open a WebSocket.¶
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.¶
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=<sha256-digest>
)
alpna2a)alongside standard HTTP protocol IDs (h2, h3).¶
bapalpn 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-knownhttps://{target}/.well-known/{well-known}. Ifabsent, the default path /.well-known/agent.json is used.¶
capcap-sha256When 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
)
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.
ADP Agents SHOULD publish a TLSA record to enable DANE¶
_443._tcp.alice.example.com. 3600 IN TLSA 3 1 1 <cert-sha256>
[RFC9364], to prevent downgrade attacks.¶
SHA-256 (1).¶
certificate that does not match MUST terminate the connection.¶
All DNS records used for Agent discovery SHOULD be DNSSEC-signed. TLSA¶
records MUST be DNSSEC-signed to be trusted.¶
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.¶
_agent.{domain}. IN TXT "v=ADP1.1; pk=ed25519:<fp>; wk=<url>; alpn=a2a"
v (REQUIRED)ADP1, ADP1.0, or ADP1.1.¶
pk (REQUIRED)wk (REQUIRED)alpn (OPTIONAL in fallback)a2a).¶
port (OPTIONAL)bap (OPTIONAL)
_agent._tcp.{domain}. IN SRV <priority> <weight> <port> <target>
If no SRV record is published, Discovery Clients SHOULD connect to¶
{domain} on TCP port 443.¶
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¶
mode differ from SVCB-mode (no ALPN validation, no capability digest, no¶
IP hints).¶
Every ADP-compliant Agent MUST serve a JSON document at the path¶
/.well-known/agent.json
As defined in [RFC8615], this URI suffix is registered under the¶
/.well-known/ namespace.¶
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.¶
$schema (string, OPTIONAL)"https://raw.githubusercontent.com/harrylian8766/adp-protocol/main/schemas/v1.1/agent.json".¶
protocol (string, REQUIRED)"ADP/1.1".¶
identity (object, REQUIRED)endpoints (object, REQUIRED)capabilities (array, REQUIRED)interfaces (object, OPTIONAL)html, api, chat.¶
relationships (array, OPTIONAL)type, id, name, optional trust level, and optional since timestamp.¶
security (object, REQUIRED)dns (object, OPTIONAL)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)availability (object, REQUIRED)meta (object, OPTIONAL)updated, version, generator, documentation.¶
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:<base64url-sha256> 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:<base64>.¶
discovery: Landing page URL (HTTPS).¶
wellKnown: Canonical Well-Known URL (HTTPS).¶
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.¶
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.¶
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¶
rateLimit (object): requestsPerMinute and burstSize.¶
{
"$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",
"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%"
}
}
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¶
record when available.¶
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.¶
The page MUST include a <script type="application/ld+json"> block¶
containing the complete Agent metadata as a JSON-LD document, using the¶
context URI https://raw.githubusercontent.com/harrylian8766/adp-protocol/main/schemas/v1.1.¶
The page SHOULD include the following <meta> elements in the document¶
To enable browser-based agent interaction without JavaScript, Agents MAY¶
AGP is a JSON-based messaging protocol over WebSocket [RFC6455] that¶
enables real-time, bidirectional communication between Agents after¶
discovery.¶
{
"id": "<uuid>",
"type": "adp_handshake",
"protocol": "ADP/1.1",
"agent_id": "agent:caller.example.com",
"public_key": "<base64url-encoded Ed25519 public key>",
"nonce": "<random hex>"
}
The server MUST respond with its own adp_handshake frame. Both parties¶
validate the other's public key fingerprint against the one obtained¶
during discovery (DNS-AID SVCB record or fallback TXT).¶
All messages after handshake MUST be JSON objects (one per WebSocket¶
{
"id": "<uuid>",
"from": "agent:sender.example.com",
"to": "agent:recipient.example.com",
"type": "<message-type>",
"timestamp": "<ISO 8601>",
"signature": "ed25519:<base64-signature>",
"body": {
"content": "<payload>",
"contentType": "text/plain|text/html|application/json",
"replyTo": "<message-id>"
},
"attachments": []
}
The signature field contains an Ed25519 signature over the¶
canonical JSON representation of the message without the signature¶
field. The canonical form follows the JCS (JSON Canonicalization Scheme)¶
Discovery Clients MUST verify the signature against the public key¶
obtained during discovery. Messages with invalid signatures MUST be¶
discarded.¶
POST /agent/tasks
Content-Type: application/json
{
"callback": "https://caller.example.com/agent/webhook",
"body": {
"type": "code-review",
"content": "..."
}
}
Response: 202 Accepted with a Location header pointing to the task¶
status resource.¶
POST /agent/swarm/join
Content-Type: application/json
{
"agent_id": "agent:joiner.example.com",
"swarm_id": "<uuid>",
"role": "worker"
}
Level 1: dns-verified ├── DNSSEC-validated SVCB response ├── Public key fingerprint obtained └── No connection established yet Level 2: dane-verified ├── TLSA record retrieved and validated ├── TLS certificate matches TLSA binding └── Endpoint identity cryptographically confirmed Level 3: key-verified ├── Well-Known JSON fetched ├── identity.publicKey.fingerprint == SVCB fingerprint └── Public key ownership confirmed Level 4: peer-verified ├── Bidirectional AGP handshake with valid signatures ├── Human confirmation (for first meeting) └── Ongoing message-level signature verification
AGP messages include a nonce (during handshake) and timestamp (in¶
every message). Receiving Agents SHOULD maintain a sliding window of¶
recent message IDs to detect replays.¶
The fingerprint published in the DNS-AID SVCB record (or fallback TXT)¶
MUST match the identity.publicKey.fingerprint in the Well-Known JSON.¶
If they do not match, the Discovery Client MUST abort and MUST NOT¶
proceed to message exchange.¶
[RFC6698] SHOULD be preferred over CA validation.¶
MUST NOT be used for public-facing Agents.¶
Agent's domain and public key fingerprint.¶
{
"protocol": "ADP/1.1",
"invite": {
"code": "<random>",
"expires": "<ISO 8601>",
"agent": "agent:alice.example.com",
"wellKnown": "https://alice.example.com/.well-known/agent.json?invite=<code>",
"pubkey": "ed25519:<fingerprint>"
}
}
IANA is requested to register the following Well-Known URI suffix in the¶
The SvcParamKeys bap, cap, cap-sha256, and well-known are¶
registered through DNS-AID [I-D.mozleywilliams-dnsop-dnsaid]. This¶
document does not request independent registration of these keys.¶
IANA has registered the following service name in the "Service Name and¶
application¶
adp+json¶
A reference implementation in Node.js/TypeScript is available at¶
https://github.com/harrylian8766/adp-protocol. It includes:¶
ADP v1.1 Discovery Clients MUST support fallback to TXT+SRV discovery¶
(Section Section 5) to interoperate with ADP v1.0 Agents.¶
ADP v1.0 Discovery Clients will not benefit from SVCB-based discovery or¶
DANE authentication, but can discover v1.1 Agents through the fallback¶
path.¶
The author thanks Ross for the suggestion to adopt a SVCB-first approach¶
and for pointing to DNS-AID as an emerging standard for Agent DNS¶
discovery. The DNS-AID authors (Richard Mozley et al.) provided a clean¶
SvcParamKey registration base that ADP builds upon.¶
The three-layer architecture and the principle of "solving at the lowest¶
possible layer" were inspired by discussions with Pro about the¶
relationship between domain identity, DNS discovery, and Web-native Agent¶
interaction.¶
fallback preservation for backward compatibility.¶
service name registration (ai-adp).¶