Internet-Draft adp-agent-discovery June 2026
Lian Expires 19 December 2026 [Page]
Workgroup:
Network Working Group
Published:
Intended Status:
Informational
Expires:
Author:
H. Lian
AI Pair

Agent Discovery Protocol (ADP) v1.1 — Well-Known Metadata and Interaction Layer

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.

▲

Table of Contents

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.

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

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.

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.

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

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.

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

ADP Agents SHOULD publish a TLSA record to enable DANE

_443._tcp.alice.example.com.  3600  IN  TLSA  3  1  1  <cert-sha256>
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:<fp>; wk=<url>; 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.
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  <priority> <weight> <port> <target>
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

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

6.3.3. Endpoints Block

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

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

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

7.1.2. HTML Meta Tags

The page SHOULD include the following <meta> elements in the document

  • <meta name="agent-id" content="agent:{domain}">
  • <meta name="agent-protocol" content="ADP/1.1">
  • <meta name="agent-fingerprint" content="ed25519:...">

7.1.3. Semantic HTML

To enable browser-based agent interaction without JavaScript, Agents MAY

  • <agent-card>: Root element for the Agent profile.
  • <capability-list>: Container for capability entries.
  • <capability>: Individual capability with name and status attributes.
  • <connect-form>: Form with action pointing to a connection endpoint.

7.2. Agent Gateway Protocol (AGP)

7.2.1. Overview

AGP is a JSON-based messaging protocol over WebSocket [RFC6455] that

enables real-time, bidirectional communication between Agents after

discovery.

7.2.2. Connection Handshake 

{
  "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>"
}
Figure 10

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

7.2.3. Message Format

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": []
}
Figure 11

7.2.4. Message Types

  • chat: Conversational message between Agents.
  • task: Task submission or status update.
  • swarm: Multi-agent coordination message (join, leave, vote).
  • system: Protocol-level control message (ping, pong, error).

7.2.5. Signature Computation

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)

[RFC8785].

Discovery Clients MUST verify the signature against the public key

obtained during discovery. Messages with invalid signatures MUST be

discarded.

7.3. HTTP Endpoints

7.3.1. Task Endpoint 

POST /agent/tasks
Content-Type: application/json

{
  "callback": "https://caller.example.com/agent/webhook",
  "body": {
    "type": "code-review",
    "content": "..."
  }
}
Figure 12

Response: 202 Accepted with a Location header pointing to the task

status resource.

7.3.2. Swarm Endpoint 

POST /agent/swarm/join
Content-Type: application/json

{
  "agent_id": "agent:joiner.example.com",
  "swarm_id": "<uuid>",
  "role": "worker"
}
Figure 13

8. Security Considerations

8.1. Trust Escalation Model 

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
Figure 14

8.1.1. Freshness and Replay Protection

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.

8.1.2. Fingerprint Verification

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.

8.2. TLS Requirements

  • All endpoints MUST use TLS 1.3 [RFC8446].
  • Certificates SHOULD be issued by a publicly trusted CA.
  • When both TLSA records and DNSSEC are available, DANE verification

[RFC6698] SHOULD be preferred over CA validation.

  • Self-signed certificates are acceptable only for local development and

MUST NOT be used for public-facing Agents.

8.3. Private Agents

  • Method A: Do not publish SVCB or TXT records.
  • Method B: Return HTTP 403 from the Well-Known endpoint.
  • Method C: Require an invitation code (out of band) that includes the

Agent's domain and public key fingerprint.

8.3.1. Invitation Format 

{
  "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>"
  }
}
Figure 15

9. IANA Considerations

9.1. Well-Known URI Registration

IANA is requested to register the following Well-Known URI suffix in the

  • URI suffix: agent
  • Change controller: IETF
  • Specification document(s): This document
  • Related information: See also DNS-AID

[I-D.mozleywilliams-dnsop-dnsaid]

9.2. SvcParamKey Registration (via DNS-AID)

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.

9.3. Service Name Registration

IANA has registered the following service name in the "Service Name and

  • Service Name: ai-adp
  • Transport Protocol: TCP
  • Description: AI Agent Discovery Protocol (ADP)
  • Assignee: [Harry_Lian]
  • Contact: [Harry_Lian]
  • Registration Date: 2026-06-12
  • Reference: [draft-pro-adp-agent-discovery-00]

9.4. Media Type Registration

  • Type name: application
  • Subtype name: adp+json
  • Required parameters: N/A
  • Optional parameters: N/A
  • Encoding considerations: binary (UTF-8 JSON)
  • Security considerations: See Security Considerations of this document
  • Interoperability considerations: N/A
  • Published specification: This document
  • Applications that use this media type: AI Agent discovery and interop
  • Fragment identifier considerations: N/A

10. Implementation Status

10.1. Reference Implementation

A reference implementation in Node.js/TypeScript is available at

https://github.com/harrylian8766/adp-protocol. It includes:

  • SVCB and fallback DNS record generation and parsing.
  • TLSA record verification.
  • Well-Known JSON schema validation.
  • HTML landing page generation.
  • AGP WebSocket server and client with Ed25519 signing.
  • Full Discovery Client implementing the three-layer discovery procedure.

10.2. Backward Compatibility

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.

11. Acknowledgments

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.

12. Version History

  • -00: Initial version with TXT+SRV DNS discovery.
  • -01: SVCB-first via DNS-AID; TLSA+DANE; trust escalation model;

fallback preservation for backward compatibility.

  • -01 (2026-06-13): Updated IANA Considerations to reflect completed

service name registration (ai-adp).

13. Normative References

[RFC9460]
Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, , <https://www.rfc-editor.org/rfc/rfc9460>.
[RFC6698]
Hoffman, P. and J. Schlyter, "DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, , <https://www.rfc-editor.org/rfc/rfc6698>.
[RFC9364]
Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, , <https://www.rfc-editor.org/rfc/rfc9364>.
[RFC8615]
Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, , <https://www.rfc-editor.org/rfc/rfc8615>.
[RFC6455]
Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, , <https://www.rfc-editor.org/rfc/rfc6455>.
[RFC8032]
Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, , <https://www.rfc-editor.org/rfc/rfc8032>.
[RFC1035]
Mockapetris, P., "Domain Names — Implementation and Specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, , <https://www.rfc-editor.org/rfc/rfc1035>.
[RFC2782]
Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for Specifying the Location of Services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, , <https://www.rfc-editor.org/rfc/rfc2782>.
[RFC7301]
Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, , <https://www.rfc-editor.org/rfc/rfc7301>.
[RFC8259]
Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/rfc/rfc8259>.
[RFC7464]
Williams, N., "JavaScript Object Notation (JSON) Text Sequences", RFC 7464, DOI 10.17487/RFC7464, , <https://www.rfc-editor.org/rfc/rfc7464>.
[RFC8785]
Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, , <https://www.rfc-editor.org/rfc/rfc8785>.
[RFC8446]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/rfc/rfc8446>.

14. Informative References

[I-D.mozleywilliams-dnsop-dnsaid]
Mozley, R., Guðmundsson, O., Pusateri, T., and J. Damick, "DNS for AI Discovery", Work in Progress, Internet-Draft, draft-mozleywilliams-dnsop-dnsaid-02, , <https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/>.

Author's Address

Harry Lian
AI Pair