A Universal Discovery Layer for AP2: Agent Identity & Discovery (AID) Protocol

[nembal]

TL;DR
AID is a minimal, DNS-first discovery standard that lets any agent find and verify another agent by domain name. It solves the bootstrap problem for agentic systems so that shopping agents, credential providers, merchant agents, and others can discover each other without hardcoded allowlists or centralized registries. Read the full technical spec at: https://docs.agentcommunity.org/aid/specification

---

Problem

AP2 and related agent protocols solve secure payments and agent-to-agent messaging, but they do not solve discovery and initial trust. Right now agents often rely on hardcoded lists, proprietary registries, or one-off integrations. That creates central points of failure and prevents a truly open and competitive agent economy.

We need a simple way to answer three questions when starting any interaction:

1. Where is the agent?
2. How can I trust that agent is the authentic agent for that domain?
3. What protocol does the agent speak?

AID is the proposal to answer those questions in a simple, auditable, and deployable way.

more about AID at aid.agentcommunity.org

Proposal: Agent Identity & Discovery (AID)

AID uses a single DNS TXT record placed at a well-known subdomain _agent.<domain> to publish minimal discovery metadata. The record is a semicolon-delimited list of key=value pairs. Clients perform a DNS TXT lookup, parse the record, and optionally perform a public key attestation handshake to verify the endpoint.

Key properties

• Zero configuration for users and clients
• DNS-first and decentralized, no central registry required
• Protocol-agnostic: works with A2A, MCP, gRPC, OpenAPI, websocket, local execution tokens, etc.
• Optional cryptographic endpoint proof (Public Key Attestation, PKA) using HTTP Message Signatures with Ed25519

Learn the full normative details in the spec: https://docs.agentcommunity.org/aid/specification

Quick record format overview

• The record must be a single string of semicolon-delimited key=value pairs
• Keys have single-letter aliases. Clients must accept aliases and ignore unknown keys
• Keep records short. If DNS splits into 255-octet chunks, clients concatenate in order

Required keys for v1

• v = aid1 (version)
• u = https://... (agent endpoint URI or local package locator)
• p = protocol token (for example mcp, a2a, openapi)

Optional keys

• a = auth hint token (for example pat)
• d = docs URL
• s = short human description for UI (<= 60 bytes)
• k = multibase-encoded Ed25519 public key for PKA
• i = key id (kid) required when k is present
• e = ISO 8601 deprecation timestamp

Example: remote MCP agent

_agent.example.com. 300 IN TXT "v=aid1;u=https://api.example.com/mcp;p=mcp;a=pat;s=Example AI Gateway"

Example: remote MCP with PKA

_agent.example.com. 300 IN TXT "v=aid1;p=mcp;u=https://api.example.com/mcp;k=z7rW8rTq...;i=g1;d=https://docs.example.com/agent;e=2026-01-01T00:00:00Z;s=Secure AI Gateway"

Client discovery algorithm (summary)

1. Normalize domain. Convert IDNs to punycode A-label if needed.
2. Query DNS TXT for _agent.<domain>. If not found, optional .well-known/agent fallback.
3. Concatenate TXT chunks, parse semicolon key=value pairs, trim whitespace.
4. Validate required keys. If k (pka) is present, perform the PKA handshake (HTTP Message Signatures, Ed25519).
5. Respect TTLs and DNSSEC when available. Fail with explicit codes on error.

See spec for full algorithm, error codes, and appendix details.

Security considerations

• Providers should sign zones with DNSSEC when possible. Clients should validate RRSIG when advertised.
• Remote URIs must use https:// and clients must validate TLS certificates.
• The TXT record must not contain secrets.
• If pka is present, providers must publish kid. Clients must perform an HTTP Message Signature handshake to verify control of the private key.
• Local execution (proto=local) requires explicit user consent, fingerprinting, sandboxing, and strict no-shell-interpretation rules.
• Clients must not follow cross-origin redirects automatically. Cross-origin redirects must require explicit confirmation or fail with a security error.

How this enables AP2

Workflow example

1. User says: "Buy me shoes from cool-kicks.com."
2. Shopping Agent resolves _agent.cool-kicks.com and discovers u=https://api.cool-kicks.com/agent and p=a2a.
3. If k is present, the agent verifies the endpoint with PKA. Now the agent has a trusted channel.
4. Hand off to A2A and AP2 flows: IntentMandate, CartMandate, PaymentMandate proceed over the verified channel.
5. Merchant, credential provider, and networks can reason over signed mandates for liability, authorization, and dispute evidence.

This removes the need for preconfigured allowlists and allows any compliant agent to interact with any compliant merchant by domain name.

Questions for the community

• Does this fit the long-term vision for discoverability in AP2 and related protocols?
• What additional security checks should clients perform on discovery? For example, should clients treat removal of pka as an explicit downgrade and require user confirmation?
• Do we need stricter default TTL guidance or caching rules for specific deployments?
• Should AID push for an early IANA service name registration, or keep adoption community-led for now?
• Any objections to the single TXT record approach versus a multi-record or SVCB first approach?

Next steps and how to help

• Read the full technical specification: https://docs.agentcommunity.org/aid/specification
• Try publishing a _agent TXT record for a test domain and exercise a reference client. The spec includes quickstart and an aid-doctor CLI for validation.
• Open issues or PRs on the spec repo: https://github.com/agentcommunity/agent-interface-discovery
• Join this discussion and leave feedback on security, tokens, protocol registry, and governance

---

Appendix: links

• Spec: docs.agentcommunity.org/aid/specification
• AID repo: github.com/agentcommunity/agent-interface-discovery
• Reference implementation and tooling: see the workbench at aid.agentcommunity.org/workbench