.agent.agent Community

Bootstrapping ARDP via AID: A Non-Normative Interop Mapping

·Balazs Nemethi
#aid#ardp#dns#discovery#interoperability#ietf#agent-protocols
View Source

AID and ARDP solve different problems at different layers. AID answers a static question via DNS: given a domain, where is the agent endpoint and what protocol does it speak? ARDP answers dynamic questions at the control plane: registration refresh, presence, capability queries, scoped discovery, and federation.

These layers compose naturally. This post documents an optional, non-normative mapping for using AID as a DNS bootstrap into ARDP, so that deployments where the ARDP authority is a DNS name get a simple onboarding path without modifying either protocol.

Try it live: ardp-demo.agentcommunity.org runs the full bootstrap flow in your browser --- DNS lookup via DoH, ARDP metadata fetch, and agent resolution, with each step visualized. Source: github.com/agentcommunity/ardp-aid-demo.

The layering

┌─────────────────────────────────────┐
│  Application Protocols              │
│  (MCP, A2A, OpenAPI, gRPC, ...)     │
├─────────────────────────────────────┤
│  ARDP Control Plane                 │
│  Registration, resolution,          │
│  presence, capabilities,            │
│  scoped discovery, federation       │
├─────────────────────────────────────┤
│  AID DNS Bootstrap                  │
│  _agent.<domain> TXT record         │
│  Static endpoint discovery          │
└─────────────────────────────────────┘

This aligns with the layering framework emerging in the IETF agent2agent discussions: discovery ("who is reachable and where") sits below the control plane, which sits below the application protocols. Each layer is independently replaceable.

DNS record format

A domain advertising an ARDP resolver or registrar via AID publishes a TXT record. The protocol-specific subdomain form is preferred:

_agent._ardp.example.com. 300 IN TXT "v=aid1;p=openapi;u=https://example.com/.well-known/ardp/meta;s=ARDP resolver"

A base record works as fallback:

_agent.example.com. 300 IN TXT "v=aid1;p=openapi;u=https://example.com/.well-known/ardp/meta;s=ARDP resolver"

We use plain TXT records because they work today with every DNS provider, registrar, and managed DNS service. No SVCB support required, no provider upgrade path, no feature gates. Any domain owner who can edit a TXT record can publish an AID record right now.

Key fields:

KeyValueNotes
vaid1AID version (required)
popenapiProtocol token --- ARDP exposes REST/JSON endpoints (required; see note below)
uHTTPS URIPoints to ARDP metadata resource (required)
sFree textHuman-readable description (optional)
aAuth hintAuthentication method hint (optional)

Why p=openapi instead of p=ardp? The AID SDK currently validates the p field against a fixed set of recognized protocol tokens. Since ARDP's /.well-known/ardp/* endpoints are REST/JSON, openapi is the correct semantic fit today. The protocol-specific subdomain (_agent._ardp.<domain>) still uses ardp to differentiate the DNS lookup path. Once the ardp token is registered in the AID protocol registry, records can be updated to p=ardp without changing the subdomain structure.

Client flow

Given an agent identifier whose authority component is a DNS name:

  1. Canonicalize the domain (lowercase, IDNA2008 if applicable).
  2. Query the protocol-specific record: _agent._ardp.<domain>. On NXDOMAIN or no valid AID record, proceed to step 3.
  3. Query the base record: _agent.<domain>. Accept if p=openapi (or p=ardp once registered). If no valid record, bootstrap fails and the client may fall back to other discovery mechanisms per the ARDP spec.
  4. Validate transport: confirm the discovered URI uses HTTPS. Perform standard TLS certificate validation.
  5. Fetch ARDP metadata: retrieve the ARDP metadata resource at the discovered URI. Parse TTL bounds, supported authentication profiles, and operational parameters.
  6. Proceed with ARDP operations: execute RESOLVE, REGISTER, or other ARDP operations subject to ARDP's authorization model.

What this does not change

This bootstrap is optional. It does not modify ARDP's identity proof requirements (proof-of-control for registration), authorization model, or protocol semantics. It provides one possible onboarding path. ARDP deployments that use non-DNS authorities or have their own discovery mechanisms are unaffected.

AID's security requirements apply to the bootstrap phase: mandatory HTTPS for remote URIs, optional DNSSEC validation, optional PKA (Ed25519 endpoint proof via RFC 9421 HTTP Message Signatures). Once the ARDP metadata endpoint is resolved, ARDP's own security model governs everything from that point forward.

Live demo

The full bootstrap flow runs at ardp-demo.agentcommunity.org. It executes three steps live in the browser:

  1. AID DNS Discovery --- calls discover("ardp-demo.agentcommunity.org", { protocol: "ardp" }) from @agentcommunity/aid, which performs a DNS-over-HTTPS query for _agent._ardp.ardp-demo.agentcommunity.org and parses the AID record
  2. ARDP Metadata Fetch --- fetches /.well-known/ardp/meta from the URI in the AID record, returning server capabilities, supported auth, and feature list
  3. ARDP Resolve --- queries /.well-known/ardp/resolve?aid=agent:demo@ardp-demo.agentcommunity.org to resolve an agent identifier to its MCP endpoint

Each step shows the DNS query or HTTP request/response as it happens. The ARDP endpoints are mock implementations of three resources from draft-pioli-agent-discovery-01 (meta, resolve, nonce), deployed as Vercel serverless functions.

Source and deployment instructions: github.com/agentcommunity/ardp-aid-demo.

Protocol token registration

The ardp protocol token will be registered in the AID protocol token registry once ARDP's identifier terminology stabilizes. In the meantime, deployments should use p=openapi (ARDP endpoints are REST/JSON) while using the _ardp protocol-specific subdomain for DNS lookup differentiation. Once registered, updating the p value in the TXT record is a one-line change with no client-side impact.

References