agenticweb.wiki

Agent Identity and Discovery AID

Discover Agent Identity & Discovery (AID) answers "given a domain, where is the agent and which protocol should I speak?" using a single DNS TXT record published at the fixed base name _agent.<domain> [1]. It is deliberately minimal: after AID resolves an endpoint and protocol token, richer protocols (MCP, A2A, OpenAPI, OAuth) take over for the actual interaction [1]. It is maintained by "Agent Community" as an open-source project (agentcommunity/agent-identity-discovery on GitHub) rather than through any formal standards body.

Overview

The current wire format is v2 (aid2), current since 1 June 2026, which supersedes a legacy aid1 format kept only for backward compatibility during a migration window [1]. A record is a semicolon-delimited key=value string with required version/uri/proto (or their single-letter aliases v/u/p), and optional fields for auth hints, description, docs link, deprecation date, and an Ed25519 public key (pka/k) used for endpoint proof [1]. When a key is present, an AID client performs a PKA (Public-Key-for-Agent) handshake -- HTTP Message Signatures (RFC 9421) over a nonce challenge, keyed by an RFC 7638 JWK thumbprint -- to verify the endpoint controls the corresponding private key [1]. A newer "domain-binding" profile (Appendix B.7) lets the endpoint additionally attest that it consents to serve the specific queried domain, closing a gap where any domain could otherwise publish another party's endpoint and key without that endpoint's consent [1].

AID is explicit about what it does not do: it does not issue credentials, grant authorization, prove human approval, define SPIFFE/WIMSE trust-domain federation, or manage cryptographic key rotation -- a key change is simply a key change, with no DNS-level provenance chain [1]. Discovery is exact-host only; clients must not walk up to parent domains, though CNAME delegation lets child hosts share a record explicitly [1]. A .well-known/agent HTTP fallback exists for environments (some managed DNS panels) where TXT record creation is restricted, but that path's trust rests on TLS rather than DNS, and cannot satisfy a dnssec=require policy [1].

The project's own GitHub repository (47 stars, 8 forks, fetched 2026-09-06) shows real shipped code: published npm (@agentcommunity/aid) and PyPI (aid-discovery) packages, source-available Go/Rust/.NET/Java libraries, an aid-doctor CLI, a live interactive workbench, and at least one documented live showcase domain (supabase.agentcommunity.org) [2] -- so implementation is recorded as shipping. No independent count of AID-publishing domains beyond that one showcase example was located, so adoption is recorded as observed rather than measured. The specification's own roadmap flags that a future major version (aid3) is expected to make domain-binding mandatory rather than optional-with-default, once adoption is broad enough that the switching cost is low [1].

What is disputed: AID's DNS-TXT approach and the separately-authored, IETF-track DNS-AID specification (see dns-aid) solve the identical "resolve a domain to an agent endpoint" problem with incompatible record shapes (TXT vs. SVCB), and no evidence of coordination between the two efforts was found in the texts read for this verification.

Discovery and probe

DNS TXT record at a fixed base name, with an HTTPS well-known fallback · _agent.<domain> (DNS TXT); /.well-known/agent (HTTP fallback)

GET https://{origin}/.well-known/agent
parse:     200 response is JSON mirroring the v2 TXT record keys (version, uri, proto, auth, ...); trustSource is reported as well-known-tls rather than dns for this path
on absent: No well-known fallback; query DNS TXT at _agent.{domain} directly (not curl-executable) -- absence of both means the domain does not publish AID

Live check run by the MCP probe: GET /.well-known/agent. The AID well-known document mirrors the DNS TXT record, including uri.

{
 "path": "/.well-known/agent",
 "expect": {
  "content_type": "json",
  "json_keys": [
   "uri"
  ]
 },
 "note": "The AID well-known document mirrors the DNS TXT record, including uri."
}

History

Instances

Every instance with its source is listed on the instances page.

See also

References

  1. AID v2.1.0 (1 June 2026, agentcommunity.org) defines a DNS TXT record at the canonical base name _agent.<domain> with required keys v/u/p (version/uri/proto), an optional Ed25519 endpoint-proof key (pka/k), and a JSON .well-known/agent HTTP fallback for environments where DNS TXT record creation is restricted. — https://raw.githubusercontent.com/agentcommunity/agent-identity-discovery/main/packages/docs/specification.md (2026-06-01) VERIFIED
  2. The agentcommunity/agent-identity-discovery GitHub repository (47 stars, 8 forks, 5 contributors, fetched 2026-09-06) shows AID v2 shipped as published packages -- npm @agentcommunity/aid, PyPI aid-discovery, plus source-available Go/Rust/.NET/Java libraries -- an official aid-doctor CLI, a live interactive workbench at aid.agentcommunity.org, and a documented live showcase domain (supabase.agentcommunity.org) used in the README's own Go example, i.e. a real, multi-language, actively maintained implementation exists beyond the specification text alone. — https://github.com/agentcommunity/agent-identity-discovery (2026-09-06) VERIFIED

Disputed: AID (agentcommunity.org) and DNS-AID (IETF dnsop draft-mozleywilliams) both answer 'given a domain, where is the agent and which protocol' but chose incompatible DNS shapes -- a single TXT record with key=value pairs, versus an SVCB RRset with SvcParamKeys and a separate _index._agents label. No evidence either project references or coordinates with the other in the text fetched for this record.

JSON · Markdown