{
 "acronym": "AID",
 "adoption": {
  "by": null,
  "level": "observed",
  "probe_run": null
 },
 "aliases": [],
 "analog": "a DNS SRV/TXT record for agents, with a TLS-certificate-like endpoint proof bolted on",
 "collisions": [
  "DNS-AID (unrelated IETF dnsop draft that solves the same problem with SVCB instead of TXT)",
  "AID also collides with generic 'agent ID' usage elsewhere"
 ],
 "discovery": {
  "mechanism": "DNS TXT record at a fixed base name, with an HTTPS well-known fallback",
  "path": "_agent.<domain> (DNS TXT); /.well-known/agent (HTTP fallback)"
 },
 "dispute": {
  "claims": [
   "AID: _agent.<domain> TXT record, agentcommunity.org, community-governed",
   "DNS-AID: SVCB records at agent + _index._agents labels, IETF dnsop draft, Infoblox/Deutsche Telekom/Amazon"
  ],
  "summary": "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."
 },
 "evidence": [
  {
   "claim": "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.",
   "date": "2026-06-01",
   "label": "VERIFIED",
   "url": "https://raw.githubusercontent.com/agentcommunity/agent-identity-discovery/main/packages/docs/specification.md"
  },
  {
   "claim": "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.",
   "date": "2026-09-06",
   "label": "VERIFIED",
   "url": "https://github.com/agentcommunity/agent-identity-discovery"
  }
 ],
 "form": "dns-record",
 "governance": "Agent Community open-source project; editor listed as 'Agent Community'; no formal standards body, though the spec discusses composing with IETF-track work (RFC 9421, RFC 7638, RFC 9728, RFC 8414)",
 "group": null,
 "history": [
  {
   "date": "2026-09-05",
   "note": "seeded from Exa Agent research run"
  },
  {
   "date": "2026-09-06",
   "note": "verified against AID v2.1.0 spec text via raw.githubusercontent.com"
  },
  {
   "date": "2026-09-06",
   "note": "fix round 1: added second evidence entry (agentcommunity GitHub repo, fetched directly) showing real published multi-language packages; upgraded implementation unknown -> shipping and adoption unmeasured -> observed on that basis"
  }
 ],
 "id": "aid",
 "implementation": "shipping",
 "last_verified": "2026-09-06",
 "name": "Agent Identity and Discovery",
 "native_status": "Current normative specification",
 "origin": {
  "date": "2026-06-01",
  "org": "Agent Community (agentcommunity.org)"
 },
 "part_of": null,
 "parties": [
  "agent-site",
  "agent-agent"
 ],
 "phase": "living",
 "probe": {
  "method": "GET",
  "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",
  "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",
  "path": "https://{origin}/.well-known/agent"
 },
 "question": "Given a domain, where is the agent and which protocol should I speak, with cryptographic proof the endpoint controls the matching key?",
 "scope": "general",
 "spec_url": "https://raw.githubusercontent.com/agentcommunity/agent-identity-discovery/main/packages/docs/specification.md",
 "step": "discover",
 "summary_md": "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.\n\nThe 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].\n\nAID 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].\n\nThe 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].\n\nWhat 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.",
 "track": "community",
 "version": {
  "date": "2026-06-01",
  "label": "v2.1.0 (aid2 wire format; aid1 legacy)"
 }
}