| Internet-Draft | adp-agent-discovery | June 2026 |
| Lian | Expires 20 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 20 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¶
following SvcParamKeys¶
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¶
reference to DNS-AID [I-D.mozleywilliams-dnsop-dnsaid]. The¶
original TXT+SRV scheme is retained as a documented fallback¶
endpoint authentication.¶
key-verified → peer-verified.¶
application/vnd.adp+json (see Section 9.4).¶
of 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.¶
user and an automated client via JSON-LD embedding.¶
Ed25519 signatures authenticate messages end-to-end.¶
domain name, capable of being discovered through DNS-AID + ADP and¶
interacting via standard Web protocols.¶
identifier for an Agent. The Agent URI scheme is¶
agent:{domain}.¶
identity, capabilities, and endpoints.¶
without padding and prefixed with ed25519:.¶
for inter-agent communication after discovery.¶
[I-D.mozleywilliams-dnsop-dnsaid], which serves as ADP's¶
normative Layer 1.¶
The Agent Discovery Protocol defines a three-layer discovery and¶
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 | +-----------------------------------------------------+
*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>
)
Agents SHOULD include the relevant Agent protocol identifier¶
(e.g., a2a) alongside standard HTTP protocol IDs (h2, h3).¶
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).¶
Clients MUST resolve this against¶
https://{target}/.well-known/{well-known}. If absent, the¶
default path /.well-known/agent.json is used.¶
Agents SHOULD publish this as a URL to their capability document.¶
publishing. Allows a Discovery Client to verify that the¶
capability document has not changed without re-fetching.¶
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
)
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-based TLS¶
endpoint authentication.¶
_443._tcp.alice.example.com. 3600 IN TLSA 3 1 1 <cert-sha256>
[RFC9364], to prevent downgrade attacks.¶
type 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"
public key, encoded in base64url without padding.¶
255 octets MAY be split across multiple TXT records at the same¶
owner name. Reassembly concatenates RDATA in returned order.¶
_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.¶
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).¶
GET https://{domain}/.well-known/agent.json
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.¶
The JSON document contains the following top-level members¶
ADP/1.1.¶
The identity block MUST contain¶
agent:{domain}.¶
base64url without padding, prefixed with ed25519:.¶
At minimum, the wellKnown endpoint MUST be present. Additional¶
endpoints provide entry points for different interaction modes¶
Each capability is an object with¶
"file"]`).¶
["chat", "api"]).¶
model (free, per_use, subscription) and optional¶
details.¶
MUST support pubkey. MAY also support bearer_token.¶
requestsPerMinute and burstSize for rate limiting.¶
{
"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"],
"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"
}
}
}
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.¶
The domain root (GET /) MUST return an HTML page suitable for both¶
human browsing and machine parsing.¶
The page MUST embed a <script type="application/ld+json"> block¶
containing the Agent's full metadata (equivalent to the Well-Known¶
JSON content).¶
The page SHOULD include the following meta tags¶
<meta name="agent-id" content="agent:{domain}">
<meta name="agent-protocol" content="ADP/1.1">
Agent landing pages SHOULD use semantic HTML elements and custom¶
elements (e.g., <agent-card>) to describe capabilities and enable¶
human interaction. An example landing page structure is provided¶
in Appendix A.¶
AGP is a WebSocket-based messaging protocol that enables real-time¶
communication between Agents after discovery. It uses JSON as the¶
message framing format, with Ed25519 signatures for per-message¶
authentication.¶
A Discovery Client establishes an AGP connection as follows¶
Resolve the Agent's chat endpoint from the Well-Known metadata¶
(endpoints.chat).¶
Open a WebSocket connection to the resolved URL using WSS¶
(WebSocket Secure).¶
The connecting Agent sends a hello message containing its¶
Agent URI and public key fingerprint.¶
The receiving Agent responds with its own hello message.¶
Both sides verify the counterparty's public key fingerprint¶
against the value obtained from the Well-Known metadata.¶
Subsequent messages are signed and verified using Ed25519.¶
Each AGP message is a single JSON object with the following¶
structure¶
{
"id": "<message-uuid>",
"from": "agent:alice.example.com",
"to": "agent:bob.example.com",
"type": "chat|task|system|ack",
"timestamp": "2026-06-18T10:00:00Z",
"signature": "ed25519:<base64url-signature>",
"body": {
"content": "<message content>",
"contentType": "text/plain|text/html|application/json",
"replyTo": "<optional-message-id>"
}
}
The signature covers the following fields, concatenated with¶
newlines¶
{id}\n{from}\n{to}\n{type}\n{timestamp}\n{body.content}
The signature is computed using Ed25519 [RFC8032] and encoded as¶
base64url without padding, prefixed with ed25519:.¶
POST /agent/tasks
Content-Type: application/json
{
"task": "code-review",
"input": { "code": "...", "language": "python" },
"callback": "https://requester.example.com/agent/webhook"
}
The server responds with 202 Accepted and a task status URL.¶
Results are delivered to the callback endpoint when complete.¶
POST /agent/swarm/join
Content-Type: application/json
{
"agent": "agent:alice.example.com",
"task": "collaborative-analysis",
"role": "participant"
}
ADP defines a progressive trust model¶
fingerprint in the DNS record (SVCB bap or TXT pk) has been¶
retrieved. No cryptographic verification has been performed.¶
DNSSEC-signed TLSA record. The transport channel is¶
authenticated at the DANE level.¶
been verified to match the fingerprint from the DNS record. The¶
key is cryptographically bound to the domain.¶
communication partner's identity is fully authenticated.¶
Each AGP message includes a timestamp. Receivers MUST reject¶
messages with timestamps more than 300 seconds in the past or more¶
than 60 seconds in the future (relative to the receiver's clock),¶
with appropriate clock skew tolerance.¶
Implementations SHOULD track recently seen message IDs to detect¶
replay attempts within the validity window.¶
Discovery Clients MUST verify that the SHA-256 hash of the full¶
Ed25519 public key obtained from the Well-Known metadata matches the¶
fingerprint published in the DNS record (SVCB or TXT). If the¶
fingerprints do not match, the connection MUST be terminated and the¶
Agent MUST NOT be trusted.¶
All endpoints (Well-Known, WebSocket, REST) MUST be served over¶
TLS 1.3 or later. Certificates MUST be valid and chain to a trusted¶
root CA. Self-signed certificates are NOT acceptable for production¶
deployments, except in local development environments.¶
When TLSA records are published (Section 4.2), Discovery Clients SHOULD¶
perform DANE verification in addition to standard PKI validation.¶
Agents that do not wish to be publicly discoverable may¶
_agent DNS records.¶
A private Agent may distribute invitations containing the¶
information normally obtained through DNS discovery¶
{
"protocol": "ADP/1.1",
"invite": {
"code": "a1b2c3d4",
"agent": "agent:alice.example.com",
"wellKnown": "https://alice.example.com/.well-known/agent.json",
"pubkey": "ed25519:<fingerprint>",
"expires": "2026-12-31T00:00:00Z"
}
}
IANA has denied registration of the "agent" Well-Known URI¶
[RFC8615] in case #1453939 (2026-06). This document therefore¶
specifies the URI path /.well-known/agent.json as a de facto¶
convention pending future availability of the Well-Known URI registry¶
slot. Implementers should be aware that this path has not been¶
formally registered.¶
The SvcParamKeys used by ADP (bap, cap, cap-sha256, well-known) are¶
registered through the DNS-AID specification¶
[I-D.mozleywilliams-dnsop-dnsaid]. ADP does not independently¶
request these registrations.¶
ADP uses the service name _agent for SRV records. Formal service¶
name registration with IANA is pending.¶
This document requests the registration of the following media type¶
in the vendor tree¶
than 998 octets and arbitrary octet sequences within string¶
values. Per [RFC6838] Section 4.8, binary encoding is¶
appropriate.¶
The protocol field determines the schema version; clients¶
MUST check it before processing.¶
and agent gateway implementations.¶
is not recommended for use in email or other non-HTTP contexts.¶
Magic number(s): N/A (JSON)¶
File extension(s): N/A¶
Macintosh file type code(s): N/A¶
OID(s): N/A¶
A reference implementation of ADP is available at¶
[https://github.com/harrylian8766/adp-protocol](https://github.com/harrylian8766/adp-protocol).¶
The reference implementation includes¶
ADP v1.1 is backward compatible with ADP v1.0 at the Well-Known¶
metadata layer. v1.1 adds the dns block and dane auth method to¶
the schema; v1.0 clients that ignore unknown fields will function¶
correctly with v1.1 metadata.¶
The fallback TXT+SRV discovery mechanism (Section 5) is identical to¶
the ADP v1.0 Layer 1, ensuring that pre-v1.1 Discovery Clients can¶
still locate Agents that have migrated to SVCB-based discovery.¶
The ADP protocol design draws on WebFinger [RFC7033], the¶
.well-known URI pattern [RFC8615], and the DNS-AID specification¶
as primary DNS mechanism.¶
support. Defined trust escalation model. Updated protocol¶
version to ADP/1.1.¶
registration to vendor tree (application/vnd.adp+json). Noted¶
Well-Known URI registration denial. Added Private Agents and¶
Invitation Format sections.¶
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="agent-id" content="agent:alice.example.com">
<meta name="agent-protocol" content="ADP/1.1">
<title>Alice's Agent</title>
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"protocol": "ADP/1.1",
"identity": {
"id": "agent:alice.example.com",
"domain": "alice.example.com",
"name": "Alice's Agent",
"publicKey": {
"algorithm": "ed25519",
"fingerprint": "ed25519:dGhpcyBpcyBhIHRlc3Q..."
}
},
"endpoints": {
"wellKnown": "https://alice.example.com/.well-known/agent.json",
"chat": "wss://alice.example.com/agent/chat"
},
"capabilities": [
{
"id": "chat",
"name": "Conversational Chat",
"description": "General-purpose conversational AI",
"input": ["text", "image", "file"],
"output": ["text", "html"],
"interfaces": ["chat", "api"],
"languages": ["en", "zh"],
"pricing": { "model": "free" }
}
]
}
</script>
</head>
<body>
<agent-card>
<h1>Alice's Agent</h1>
<p>General-purpose conversational AI agent.</p>
<capability-list>
<capability name="Chat" status="available"></capability>
</capability-list>
<connect-form action="/agent/connect">
<input name="from" placeholder="Your Agent ID (agent:...)">
<button type="submit">Connect</button>
</connect-form>
</agent-card>
</body>
</html>
Bin Lian aipair.ai Email: TBD