ARD finds the agent. AID proves it.

Where Agent Identity & Discovery sits relative to Google, Microsoft, and Hugging Face's new Agentic Resource Discovery spec, and why the identity question is the one search cannot answer for you.

Date: 24 June 2026

---

Agentic Resource Discovery (ARD) shipped in May as a v0.9 draft, with contributors from Google, Microsoft, and Hugging Face and a long list of launch partners. It solves a real problem. Once there are thousands or millions of agents, no client can hold every tool description in its context window, and nobody is going to hardcode each one by hand. ARD moves selection out of the model and into a search service: publishers host a catalog, registries crawl and index those catalogs, and a client asks "find me an agent that can book a flight" instead of pre-installing anything.

Google framed the launch around three questions an agent has to answer: where does the right capability live, which one should it use, and how does it verify the thing is safe to connect to. ARD is built for the first two. The third is where AID lives, and it is why these are not competing specs.

§Discovery is ARD's job. Trust is the part it leaves open.

AID calls itself the zero-th hop of agent discovery, and on its own that is a fair description: given a domain, it resolves the one endpoint that is its agent. But stand it next to ARD and the emphasis moves. ARD already does discovery, at a scale a single DNS record never will. When a search result hands you a catalog entry, you already have the endpoint URL. What you do not have is any proof that the URL is really that domain's agent. Closing that gap is the reason to keep AID in the stack.

So in this setting AID is less a second way to find things than the trust layer underneath the first one. And trust and discovery are not separable here the way ARD makes them. ARD splits them: discovery is the search layer, trust is an optional manifest you attach afterward. AID fuses them. The channel it discovers through, the domain's DNS zone, is the same channel that anchors the proof, so finding the key and trusting the key are one act. That fusion is what a zero-th hop is for. It is not a small discovery step before the real ones. It is where trust for the whole chain gets set, before anything else runs.

ARD had to separate the two to search across millions of agents. AID can fuse them because it only ever answers about one domain at a time. Neither can be the other. The mistake is letting the search layer quietly stand in for the trust layer, because a ranked result feels authoritative and a catalog is easy to publish. Ranking is not proof. Presence in an index is not consent.

§The real difference is trust topology, not file format

It is tempting to make this about DNS versus JSON. That argument does not hold, and it is worth being honest about why. At a single host, a file served over valid TLS and a DNS record are anchored to roughly the same authority, and DNS is often run by a different team than the one shipping the service, which can leave a stale key in place. File format is not the axis.

The axis is who you trust when you connect. ARD is search-first by design, so the client gets its answer from a registry that crawled and re-served someone else's catalog. At that point you are not reading the source. You are trusting the registry's copy, and the weakest registry in the federation sets the floor. ARD is candid about this: its trustManifest is optional, its signature is optional, the algorithm is unpinned, the relevance score is explicitly not a trust rating, and trust "comes from the curation of the registry, not from the protocol."

AID keeps the path direct. Go to the source, get one answer, and make the endpoint prove, live and right now, that it holds the private key the domain published for it. No intermediary's stored claim sits in that path.

That property is the part search cannot absorb without ceasing to be search. A signature field is easy to copy. A live proof done by the client directly against the endpoint cuts against the whole reason ARD exists, which is to move selection off the client and into the index. If ARD ever does require that direct live proof, it has adopted the bootstrap model. Either way the distinction is real and structural.

§PKA is a first-contact identity anchor, not a signature bolt-on

AID's endpoint proof is called PKA, Public Key for Agent. It is Ed25519 keys and RFC 9421 HTTP Message Signatures, the same primitives as Web Bot Auth. The domain publishes a public key. The endpoint signs a fresh client challenge and proves it holds the matching private key. In v2 the client also sends the domain it queried, and a cooperating endpoint signs over that value, so it can state that it consents to serve as the agent for that specific domain.

The reason this matters more than "a mandatory signature" is what it does at first contact. When an agent from one organization meets an agent from another with no prior relationship, ARD's identity options do not help. Its trustManifest accepts SPIFFE and DID, and both are private namespaces that assume enrollment or federation you already have. A SPIFFE ID from one company means nothing to a stranger. PKA is the one anchor in that set that works cold, with no prior arrangement, because it is rooted in globally resolvable DNS zone control rather than in a certificate authority or an identity provider you both had to join first.

One subtlety decides whether any of this holds. The live proof is the same wherever the key sits. What matters is that the key is published on a channel independent of the endpoint it vouches for. DNS is that independent channel: compromising the endpoint's web host does not let an attacker forge a key that lives in the zone. A key sitting at the same origin as the endpoint it certifies is the endpoint vouching for itself, which collapses back to plain TLS trust. External anchor versus self anchor. That is the whole game, and it is what what makes a trust anchor external works through in full.

§Where each one is simply the right tool

When you already know the domain, a ranked list is the wrong answer. You do not want ten candidates and a relevance number you were told not to trust. You want one endpoint, tied to the name you asked about, that you can verify belongs to it. That is AID.

When you do not know the domain and you are shopping the whole field by capability, cryptographic endpoint proof is not the question yet. You want reach, ranking, and a federated index. That is ARD.

The layers stack cleanly. ARD indexes the field. AID collapses a known domain to one proven endpoint. The protocol layer, MCP or A2A or OpenAPI, does the actual work once identity is settled.

§What we are actually proposing

We are not asking anyone to bolt our record onto their spec. The useful thing AID brings is finished work on the hard parts: the domain-binding profile that closes the unauthorized-association gap, six language SDKs already at parity, conformance fixtures, and the edge cases of endpoint proof that take months to get right. ARD's own DNS discovery mechanism is under-specified today. Pointing it at a worked-out endpoint-proof profile beats rebuilding one.

There is one small divergence worth naming early rather than late. ARD's DNS option uses the plural label form, _catalog._agents and _search._agents. AID uses the singular _agent. The clean split is the natural one: a singular bootstrap record for the agent at an exact name, and catalog or search records for the index a domain offers. We would rather align that story than fork it.

AID is community-governed and vendor-neutral, which is worth something for an identity layer specifically. The organization that owns the anchor should not be one of the parties whose agents it certifies. If you are building on ARD and you care about the difference between "this matched your query" and "this is verifiably who it claims to be," that difference is the reason AID exists. We would like to help close it.

---

More on the identity layer AID adds: What makes a trust anchor external, on the anchor independence that makes the proof mean anything, and PKA as an external trust anchor, on why first contact needs a public anchor at all.