AID v2 is live
Agent Identity & Discovery v2 makes AID the 0-th hop for agent discovery: a DNS-first endpoint and key anchor with sharper PKA, updated SDKs, and a cleaner migration path.
AID v2 is live
Agent Identity & Discovery v2 is live.
The short version:
AID is the 0-th hop for agent discovery. Given a domain, it tells a client where the agent entry point is, which protocol to speak, and, when key material is published, how the endpoint proves it controls that DNS-published key.
This matters because agents often start from ordinary names, not from clean API base URLs. A user says "work with example.com." A partner agent claims to represent acme.com. An enterprise workflow starts with a domain, not a connector registry entry. In those cases, the client should not guess between a marketing site, a dashboard, an API host, an MCP server, a docs page, or a marketplace listing.
AID lets the domain answer first.
_agent.example.com. 300 IN TXT "v=aid2;p=mcp;u=https://api.example.com/mcp;k=ebVWLo_mVPlAeLES6K..."That record is intentionally small. It is not a registry. It is not an authorization server. It is not a capability graph. It is the first domain-owned hint that gets the client to the right protocol and endpoint.
What changed in v2
v2 cleans up the parts of AID that need to be precise before independent implementations can trust the wire format.
The record version is now v=aid2. New records default to v2, while clients keep aid1 compatibility during the migration window.
PKA is sharper. The v2 k field carries the unpadded base64url Ed25519 JWK x value. Clients derive the HTTP Message Signature keyid from the RFC 7638 JWK thumbprint. v2 records do not publish a separate DNS kid or i value for key identity.
The endpoint proof handshake is now explicit: RFC 9421 HTTP Message Signatures, Ed25519, a verifier nonce, created and expires, Cache-Control: no-store, and the aid-pka-v2 tag. The signed components bind the request method, target URI, authority, and response status.
Clients also partition records by version before ambiguity checks. That makes side-by-side aid1 and aid2 publication practical during migration.
The docs, workbench, conformance fixtures, aid-doctor, and SDKs were updated together so the spec is not just prose. TypeScript, Python, Go, Rust, Java, and .NET all implement the v2 record and PKA behavior, with legacy aid1 compatibility kept where it belongs.
What PKA proves
PKA is deliberately narrow.
It proves that the endpoint reached at the discovered URI controls the private key corresponding to the public key currently published in the selected AID record.
It does not prove user authorization. It does not prove legal authority. It does not prove delegation, reputation, workload identity, or enterprise policy approval. Those layers still belong in OAuth, auth.md, SPIFFE, WIMSE, registries, IAM systems, contracts, and audit.
That boundary is a feature. The first hop should stay small enough to deploy and verify. Richer metadata and authorization should stay above it.
Try it
Install the TypeScript SDK:
npm install @agentcommunity/aidUse the doctor to inspect a domain:
npx @agentcommunity/aid-doctor check example.comInstall the Python SDK:
pip install aid-discoveryRead the v2 spec:
Why this shape
DNS is not the whole agent-discovery stack. It should not try to be.
The useful split is staged:
| Stage | Question | Good home |
|---|---|---|
| First hop | Given a domain, where should an agent client start? | AID DNS record |
| Endpoint proof | Did this endpoint prove control of the DNS-published key? | AID PKA |
| Description | What can this agent do? | Agent cards, manifests, registries, docs |
| Authorization | What may this agent do for this user or organization? | OAuth, auth.md, IAM, policy systems |
| Governance | Who is accountable over time? | Registries, compliance, audit, contracts |
That is also why AID stays TXT-first today. SVCB and richer DNS service-binding models are interesting and worth exploring. DNS-AID and adjacent drafts are pushing on that direction. AID v2 chooses the smaller thing that domain owners can publish now and clients can verify now: one _agent.<domain> TXT record, one endpoint, one protocol hint, and optional endpoint proof key material.
The agentic web needs discovery, identity, authorization, governance, and commerce to compose. AID v2 gives the stack a clearer 0-th hop.