Independent Submission                                           H. Lian
Internet-Draft                                                   AI Pair
Intended status: Informational                               9 June 2026
Expires: 11 December 2026


                     Agent Discovery Protocol (ADP)
                    draft-pro-adp-agent-discovery-00

Abstract

   This document specifies the Agent Discovery Protocol (ADP), a three-
   layer discovery mechanism for AI Agents that leverages existing
   Internet infrastructure: DNS TXT and SRV records for lightweight
   service discovery (Layer 1), Well-Known URIs for machine-readable
   metadata (Layer 2), and HTML landing pages with WebSocket channels
   for human interaction and inter-agent communication (Layer 3).  ADP
   enables any domain owner to make their AI Agent discoverable without
   relying on centralized registries, using the Domain Name System as
   the decentralized trust anchor.

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 11 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.  Code Components



Lian                    Expires 11 December 2026                [Page 1]

Internet-Draft             adp-agent-discovery                 June 2026


   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Layer 1: DNS Discovery  . . . . . . . . . . . . . . . . . . .   4
     4.1.  TXT Record (REQUIRED) . . . . . . . . . . . . . . . . . .   4
       4.1.1.  Record Format . . . . . . . . . . . . . . . . . . . .   4
       4.1.2.  Fields  . . . . . . . . . . . . . . . . . . . . . . .   4
       4.1.3.  Multi-Record TXT  . . . . . . . . . . . . . . . . . .   5
       4.1.4.  Discovery Procedure . . . . . . . . . . . . . . . . .   5
     4.2.  SRV Record (RECOMMENDED)  . . . . . . . . . . . . . . . .   5
   5.  Layer 2: Well-Known Metadata  . . . . . . . . . . . . . . . .   5
     5.1.  Endpoint  . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.2.  Content Type  . . . . . . . . . . . . . . . . . . . . . .   5
     5.3.  Schema  . . . . . . . . . . . . . . . . . . . . . . . . .   6
       5.3.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Layer 3: Interaction Endpoints  . . . . . . . . . . . . . . .   8
     6.1.  HTML Landing Page . . . . . . . . . . . . . . . . . . . .   8
       6.1.1.  JSON-LD Embedding . . . . . . . . . . . . . . . . . .   8
       6.1.2.  HTML Meta Tags  . . . . . . . . . . . . . . . . . . .   8
     6.2.  WebSocket Communication . . . . . . . . . . . . . . . . .   8
       6.2.1.  Endpoint  . . . . . . . . . . . . . . . . . . . . . .   8
       6.2.2.  Connection Handshake  . . . . . . . . . . . . . . . .   8
       6.2.3.  Message Format  . . . . . . . . . . . . . . . . . . .   9
   7.  Security Model  . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Trust Chain . . . . . . . . . . . . . . . . . . . . . . .   9
     7.2.  Trust Levels  . . . . . . . . . . . . . . . . . . . . . .   9
     7.3.  Threat Mitigations  . . . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Well-Known URI Registration . . . . . . . . . . . . . . .  10
     8.2.  SRV Service Name Registration . . . . . . . . . . . . . .  10
     8.3.  Media Type Registration . . . . . . . . . . . . . . . . .  11
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     9.1.  DNSSEC Dependency . . . . . . . . . . . . . . . . . . . .  11
     9.2.  Key Management  . . . . . . . . . . . . . . . . . . . . .  11
     9.3.  Denial of Service . . . . . . . . . . . . . . . . . . . .  11
     9.4.  Privacy Considerations  . . . . . . . . . . . . . . . . .  12
   10. Operational Considerations  . . . . . . . . . . . . . . . . .  12
     10.1.  DNS Caching  . . . . . . . . . . . . . . . . . . . . . .  12
     10.2.  Well-Known Caching . . . . . . . . . . . . . . . . . . .  12
     10.3.  Version Negotiation  . . . . . . . . . . . . . . . . . .  12



Lian                    Expires 11 December 2026                [Page 2]

Internet-Draft             adp-agent-discovery                 June 2026


     10.4.  Backwards Compatibility  . . . . . . . . . . . . . . . .  12
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   12. Sample TXT Record . . . . . . . . . . . . . . . . . . . . . .  13
   13. Sample SRV Record . . . . . . . . . . . . . . . . . . . . . .  13
   14. Reference Implementations . . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

1.1.  Background

   AI Agents are rapidly evolving from chatbot plugins into autonomous
   internet-native entities.  Yet the ecosystem lacks a universal
   discovery mechanism: agents are locked inside proprietary platforms
   (OpenAI, Dify, Coze), each with its own directory and identity
   system.  An agent on one platform cannot natively discover an agent
   on another.

   The Web solved an analogous problem 40 years ago: any resource can be
   discovered through a combination of DNS names, well-known ports, and
   HTML document interlinking.  This specification applies the same
   principle to Agents.

1.2.  Design Goals

   *  *Decentralized*: No central registry required; domain ownership is
      the root of identity.
   *  *Incremental discovery*: Solve at the lowest possible layer; only
      escalate to heavier mechanisms when needed.
   *  *Web-native*: Build on existing IETF standards (DNS, TLS, Well-
      Known URIs, WebSocket) rather than invent new protocols.
   *  *Human-and-machine readable*: The same endpoint serves both a
      browser user and an automated agent.
   *  *Secure by default*: Public key fingerprint bound to the DNS
      record provides first-meeting trust without pre-shared keys or
      PKI.

2.  Terminology

   {::boilerplate bcp14-tagged}

   Agent:  An autonomous or semi-autonomous software entity identified
      by a domain name, capable of being discovered through 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 ADP discovery to locate and



Lian                    Expires 11 December 2026                [Page 3]

Internet-Draft             adp-agent-discovery                 June 2026


      verify an Agent's identity, capabilities, and endpoints.
   Fingerprint:  The SHA-256 hash of an Ed25519 public key, encoded in
      base64url and prefixed with ed25519:.

3.  Protocol Overview

   The Agent Discovery Protocol defines a three-layer discovery and
   interaction stack:

   1.  *Layer 1 — DNS Discovery:* A TXT record at _agent.{domain}
       carries the protocol version, a public key fingerprint, and the
       Well-Known URI.  An optional SRV record at _agent._tcp.{domain}
       locates the Agent's service endpoints.

   2.  *Layer 2 — Well-Known Metadata:* GET /.well-known/agent.json
       returns a JSON document containing the Agent's full identity,
       capabilities, relationship graph, security policies, and endpoint
       map.

   3.  *Layer 3 — Interaction Endpoints:* An HTML landing page at the
       domain root provides human-readable discovery with embedded JSON-
       LD structured data.  WebSocket endpoints enable real-time inter-
       agent communication with Ed25519 signature authentication.

   *Core principle*: Solve at the lowest possible layer.  If DNS records
   suffice, do not issue an HTTP request.  If Well-Known metadata
   suffices, do not open a WebSocket.

4.  Layer 1: DNS Discovery

4.1.  TXT Record (REQUIRED)

   Every ADP-compliant Agent MUST publish a DNS TXT record at
   _agent.{domain} containing semicolon-delimited key-value pairs.

4.1.1.  Record Format

_agent.{domain}.  IN  TXT  "v=ADP1; pk=<fingerprint>; wk=<well-known-uri>"

4.1.2.  Fields

   v:  Protocol version.  Current value: ADP1.  REQUIRED.
   pk:  Public key fingerprint in the format ed25519:<base64url-sha256>.
      Computed as the SHA-256 hash of the raw 32-byte Ed25519 public
      key, encoded in base64url without padding (Section 5 of
      {{!RFC4648}}).  REQUIRED.
   wk:  Full URL to the Well-Known agent metadata endpoint.  MUST use
      HTTPS.  REQUIRED.



Lian                    Expires 11 December 2026                [Page 4]

Internet-Draft             adp-agent-discovery                 June 2026


   rel:  Optional comma-separated list of relationship tags.  Defined
      values include self, parent, and cluster:{name}.
   note:  Optional human-readable description, maximum 64 octets.

4.1.3.  Multi-Record TXT

   When the combined key-value string exceeds 255 octets (a single TXT
   resource record limit), it SHOULD be split across multiple TXT
   records at the same owner name.  Reassembly is performed by
   concatenating the RDATA value of each TXT record in the order
   returned by the DNS resolver.

4.1.4.  Discovery Procedure

   1.  Query IN TXT _agent.{domain} using a DNSSEC-validating resolver.
   2.  Parse semicolon-delimited fields from the concatenated TXT data.
   3.  Verify v=ADP1 is present.
   4.  Extract the pk fingerprint and wk Well-Known URL.
   5.  Optionally cache the fingerprint for subsequent signature
       verification.

4.2.  SRV Record (RECOMMENDED)

   Agents that operate their own service endpoints SHOULD publish a DNS
   SRV record {{!RFC2782}}:

   _agent._tcp.{domain}.  IN  SRV  <priority> <weight> <port> <target>

   The target field MUST resolve to a host providing ADP-compliant
   service endpoints.  If no SRV record is published, Discovery Clients
   SHOULD fall back to connecting to {domain} on TCP port 443 (HTTPS).

5.  Layer 2: Well-Known Metadata

5.1.  Endpoint

   Every ADP-compliant Agent MUST serve a JSON document at:

   /.well-known/agent.json

   As defined in {{!RFC8615}}, this URI suffix is registered under the
   /.well-known/ namespace.

5.2.  Content Type

   The response MUST include Content-Type: application/json.  The
   document MUST be valid JSON {{!RFC8259}}.




Lian                    Expires 11 December 2026                [Page 5]

Internet-Draft             adp-agent-discovery                 June 2026


5.3.  Schema

   The root object contains the following top-level members:

   protocol (string, REQUIRED):  Protocol version string, e.g.
      "ADP/1.0".

   identity (object, REQUIRED):  Agent identity block.

      *  id (string): Agent URI in the format agent:{domain}.
      *  domain (string): Canonical FQDN.
      *  name (string): Human-readable Agent name.
      *  owner (string): Display name of the entity operating the Agent.
      *  created (string): ISO 8601 creation timestamp.
      *  publicKey (object): Contains algorithm ("ed25519"), fingerprint
         (string), and optional full (base64url-encoded full public
         key).

   endpoints (object, REQUIRED):  Map of logical endpoint names to
      absolute URLs.

      *  discovery: Landing page URL.
      *  wellKnown: Canonical Well-Known URL.
      *  chat: WebSocket Secure URL for real-time chat.
      *  tasks: HTTPS URL for asynchronous task submission.
      *  swarm: HTTPS URL for multi-agent coordination.

   capabilities (array, REQUIRED):  Array of capability objects, each
      describing a skill the Agent offers: id, name, description, input
      (array of MIME types), output (array of MIME types), interfaces
      (array of chat/api/webhook), languages (array of BCP 47 tags), and
      pricing (object with model and optional details).

   interfaces (object, OPTIONAL):  Map of interface type to URL.

   relationships (array, OPTIONAL):  Known peer Agents.  Each entry
      contains type (peer/child/parent), id (Agent URI), name, optional
      trust level, and optional since timestamp.

   security (object, REQUIRED):  Security configuration.  Contains
      tlsRequired (boolean), minProtocolVersion, authMethods (array,
      e.g. ["pubkey"]), and optional rateLimit object.

   policies (object, OPTIONAL):  Links to privacy policy, terms of
      service, data retention policy, and third-party data sharing
      declaration.

   availability (object, REQUIRED):  Current status (online/offline/



Lian                    Expires 11 December 2026                [Page 6]

Internet-Draft             adp-agent-discovery                 June 2026


      maintenance), uptime commitment, optional maintenance window.

   meta (object, OPTIONAL):  Document metadata: updated timestamp,
      version, generator string.

5.3.1.  Example

   {
     "protocol": "ADP/1.0",
     "identity": {
       "id": "agent:alice.agent",
       "domain": "alice.agent",
       "name": "Alice's Agent",
       "owner": "Alice",
       "created": "2026-01-01T00:00:00Z",
       "publicKey": {
         "algorithm": "ed25519",
         "fingerprint": "ed25519:abc123..."
       }
     },
     "endpoints": {
       "discovery": "https://alice.agent/",
       "wellKnown": "https://alice.agent/.well-known/agent.json",
       "chat": "wss://alice.agent/agent/chat",
       "tasks": "https://alice.agent/agent/tasks"
     },
     "capabilities": [
       {
         "id": "chat",
         "name": "Conversation",
         "description": "General-purpose conversational AI",
         "input": ["text", "image"],
         "output": ["text", "html"],
         "interfaces": ["chat", "api"],
         "languages": ["en", "zh"],
         "pricing": { "model": "free" }
       }
     ],
     "security": {
       "tlsRequired": true,
       "minProtocolVersion": "ADP/1.0",
       "authMethods": ["pubkey"],
       "rateLimit": { "requestsPerMinute": 60 }
     },
     "availability": {
       "status": "online"
     }
   }



Lian                    Expires 11 December 2026                [Page 7]

Internet-Draft             adp-agent-discovery                 June 2026


6.  Layer 3: Interaction Endpoints

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

6.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.  This
   allows automated discovery from a single HTTP GET request.

6.1.2.  HTML Meta Tags

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

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

6.2.  WebSocket Communication

6.2.1.  Endpoint

   The Agent's WebSocket endpoint (published in the Well-Known JSON
   under endpoints.chat) provides a real-time, bidirectional
   communication channel between Agents.

6.2.2.  Connection Handshake

   Upon connection, the client MUST send an adp_handshake message
   containing:

   {
     "type": "adp_handshake",
     "protocol": "ADP/1.0",
     "agent_id": "agent:caller.domain",
     "public_key": "<base64url-encoded Ed25519 public key>",
     "nonce": "<random hex string>"
   }

   The server responds with its own handshake message, and subsequent
   messages are authenticated with Ed25519 signatures.





Lian                    Expires 11 December 2026                [Page 8]

Internet-Draft             adp-agent-discovery                 June 2026


6.2.3.  Message Format

   All messages after handshake MUST be JSON objects with type, id,
   timestamp, and signature fields:

   {
     "type": "message",
     "id": "<uuid>",
     "timestamp": "<ISO 8601>",
     "from": "agent:caller.domain",
     "to": "agent:target.domain",
     "payload": { ... },
     "signature": "<base64url Ed25519 signature>"
   }

   The signature covers the concatenation of type, id, timestamp, from,
   to, and the canonical JSON serialization of payload.

7.  Security Model

7.1.  Trust Chain

   ADP establishes a trust chain anchored in DNSSEC and the domain
   registration system:

   DNSSEC-validated TXT record
     → fingerprint (embed in DNS)
       → Well-Known agent.json (verify fingerprint matches)
         → full public key (publish in JSON)
           → Ed25519 signatures (verify every message)

7.2.  Trust Levels

   Discovery Clients assign one of four trust levels:

   1.  *unverified* — DNS resolved but no verification performed.
   2.  *dns-verified* — TXT record was validated via DNSSEC.
   3.  *key-verified* — Public key fingerprint from DNS matches the
       Agent's Well-Known document and the Agent successfully signed a
       challenge.
   4.  *peer-verified* — Mutual verification between known peers,
       tracked in the relationships array with a trust value of
       verified.








Lian                    Expires 11 December 2026                [Page 9]

Internet-Draft             adp-agent-discovery                 June 2026


7.3.  Threat Mitigations

   *Domain hijacking*: DNSSEC validation prevents DNS cache poisoning.
   Even without DNSSEC, the fingerprint comparison between DNS TXT and
   Well-Known JSON provides a second factor.

   *Man-in-the-middle*: TLS 1.3 is REQUIRED for all HTTP and WebSocket
   endpoints.  The DNS-anchored fingerprint allows detection of TLS
   termination attacks.

   *Impersonation*: An attacker who controls a different domain cannot
   claim another Agent's identity because the domain IS the identity.
   No certificate authority can issue a valid certificate for another
   domain without compromising that domain's DNS or the CA itself.

   *Key rotation*: Agents SHOULD publish a previousFingerprint field in
   their Well-Known document during key rotation.  Discovery Clients
   SHOULD accept the new key if it can be validated through the old
   key's signature over a key rotation message.

8.  IANA Considerations

8.1.  Well-Known URI Registration

   This document requests registration of the "agent" Well-Known URI in
   the "Well-Known URIs" registry established by {{!RFC8615}}.

   *  URI suffix: agent
   *  Change controller: IETF
   *  Specification document(s): This document
   *  Related information: Agent metadata is served in JSON format at
      /.well-known/agent.json

8.2.  SRV Service Name Registration

   This document requests registration of the "_agent" service name in
   the "Service Name and Transport Protocol Port Number Registry" for
   TCP.

   *  Service Name: agent
   *  Transport Protocol: TCP
   *  Assignee: IETF (IESG)
   *  Contact: Harry Lian harry@aipair.ai (mailto:harry@aipair.ai)
   *  Description: AI Agent Discovery Protocol service endpoint
   *  Reference: This document
   *  Port Number: None (uses SRV-defined port)





Lian                    Expires 11 December 2026               [Page 10]

Internet-Draft             adp-agent-discovery                 June 2026


8.3.  Media Type Registration

   This document requests registration of the media type application/
   adp+json in the "Media Types" registry.

   *  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: ADP-compliant Agent hosts
      and discovery clients
   *  Additional information:
      -  Deprecated alias names for this type: N/A
      -  Magic number(s): N/A
      -  File extension(s): N/A
      -  Macintosh file type code(s): N/A

9.  Security Considerations

9.1.  DNSSEC Dependency

   The security of the trust chain depends on DNSSEC validation.
   Discovery Clients SHOULD use DNSSEC-validating resolvers and MUST
   treat non-validated DNS responses as unverified trust level.  In
   environments where DNSSEC is unavailable, the fingerprint comparison
   between DNS TXT and Well-Known JSON provides defense-in-depth but
   does not constitute full verification.

9.2.  Key Management

   Agents MUST protect their Ed25519 private key with the same care as a
   TLS private key.  Compromise of the private key allows an attacker to
   impersonate the Agent across all communication channels.  Key
   rotation SHOULD be performed by publishing a new fingerprint in DNS
   TXT, updating the Well-Known document, and (optionally) signing a
   rotation message with the previous key.

9.3.  Denial of Service

   The Well-Known endpoint is a JSON document typically under 16 KiB and
   is cacheable.  Rate limiting at the application layer (published in
   security.rateLimit) and standard HTTP caching headers SHOULD be
   employed to prevent abuse.



Lian                    Expires 11 December 2026               [Page 11]

Internet-Draft             adp-agent-discovery                 June 2026


9.4.  Privacy Considerations

   Agent discovery is inherently public: any party that knows a domain
   name can discover the associated Agent's capabilities and endpoints.
   Agents SHOULD NOT include personally identifiable information in
   their Well-Known documents.  The policies.privacy URL provides a
   mechanism for Agents to declare their data handling practices.

10.  Operational Considerations

10.1.  DNS Caching

   Discovery Clients SHOULD cache DNS TXT and SRV query results for the
   TTL specified in the DNS response, up to a maximum of 3600 seconds.

10.2.  Well-Known Caching

   The Well-Known JSON document SHOULD be served with appropriate HTTP
   caching headers (Cache-Control, ETag).  Discovery Clients SHOULD
   honor these headers and MAY use conditional requests.

10.3.  Version Negotiation

   The protocol version is carried in DNS TXT (v field) and echoed in
   the Well-Known JSON (protocol field).  If a Discovery Client
   encounters a version it does not support, it SHOULD abort discovery
   and report the incompatibility.  New protocol versions MUST increment
   the version string (e.g., ADP2).

10.4.  Backwards Compatibility

   ADP/1.0 is the initial protocol version.  Future versions SHOULD be
   backwards-compatible in their discovery layers (TXT record format,
   Well-Known schema additions are non-breaking if unknown fields are
   ignored).

   --- back

11.  Acknowledgments

   This protocol was conceived through discussions between Harry Lian
   and Pro on the nature of the Agent Internet, with the shared
   conviction that Agents should inherit the Web's proven infrastructure
   rather than reinventing it.







Lian                    Expires 11 December 2026               [Page 12]

Internet-Draft             adp-agent-discovery                 June 2026


12.  Sample TXT Record

_agent.alice.agent.  3600  IN  TXT  "v=ADP1; pk=ed25519:dGhpcyBpcyBhIHRlc3Q; wk=https://alice.agent/.well-known/agent.json"

13.  Sample SRV Record

   _agent._tcp.alice.agent.  3600  IN  SRV  10 5 443 alice.agent.

14.  Reference Implementations

   *  Node.js SDK: https://github.com/harrylian8766/adp-protocol
      (https://github.com/harrylian8766/adp-protocol)
   *  Protocol registry: https://agent-discovery.org (https://agent-
      discovery.org)

Author's Address

   Harry Lian
   AI Pair
   Email: harrylian8766@gmail.com































Lian                    Expires 11 December 2026               [Page 13]