The Missing First Hop

draft-klrc-aiagent-auth states, in §1, that one of its goals is "identifying gaps and clarifying where extensions or profiles of existing standards are needed." This post is a response to that sentence.

Short version: §10.9 names three discovery mechanisms: OAuth 2.0 Authorization Server Metadata (RFC 8414), OAuth 2.0 Protected Resource Metadata (RFC 9728), and Client ID Metadata Documents. All three answer the same kind of question: given a URL, what can it do? None of them answers the question that comes first: given a domain, what's the URL?

That first-hop discovery is the gap. It's a DNS question, and there's already a spec that fills it: draft-nemethi-aid-agent-identity-discovery.

What §10.9 covers, and what it doesn't

The three §10.9 mechanisms are well-chosen for what they do. If an agent already knows https://auth.example.com is the authorization server for some resource, it can fetch /.well-known/oauth-authorization-server and learn the issuer identifier, supported grant types, jwks_uri, and the rest. Same pattern for Protected Resource Metadata. Same pattern for Client ID Metadata Documents. This is good capability discovery.

But each mechanism starts from an HTTPS URL. An agent operating across organizational boundaries (the scenario §10.5 is written for) does not always have that URL preconfigured. It has a domain. It knows it needs to talk to something at example.com, but it doesn't know whether that something lives at api.example.com/mcp, agents.example.com/a2a, or gateway.example.net/something-else.

The mapping from domain to URL is first-hop discovery. It's a DNS question, not an HTTP one. HTTPS metadata endpoints describe what a host can do once you're already talking to it. They don't tell you which host to talk to.

The closest analogue in existing DNS practice is DKIM. DKIM publishes a public key at selector._domainkey.<domain>, and receiving servers use it to verify that mail claiming to be from the domain is legitimately signed. DKIM isn't about routing (MX handles that). It's cryptographic identity for a domain, published in DNS, verifiable without prior enrollment. AID does the same thing for agents.

What AID does

AID defines a single DNS TXT record at _agent.<domain>:

_agent.example.com. 300 IN TXT "v=aid1;p=mcp;u=https://api.example.com/mcp;a=oauth2_code"

The record carries a protocol token (mcp, a2a, openapi, grpc, graphql, websocket, local, zeroconf), an absolute https:// URL for remote agents, and an optional authentication hint. If the provider wants cryptographic endpoint proof, the record can also publish an Ed25519 public key (k=) and a key rotation id (i=). Clients verify the endpoint via a challenge-response handshake using HTTP Message Signatures (RFC 9421). That is the same primitive klrc §9.2.2 already uses through the WIMSE HTTP Signatures profile.

A client resolves _agent.<domain>, parses the TXT record, and from there has an HTTPS URL. Whatever comes next stays the same: capability discovery, OAuth flows, WIMSE credentials, mTLS.

AID has been stable since July 2025, runs in production, has SDKs in TypeScript, Python, Go, Rust, .NET, and Java, and was submitted to the IETF as draft-nemethi-aid-agent-identity-discovery-00 in March 2026.

How it composes with klrc

The two specs cover different hops. Together they form a clean chain.

The most useful overlap is hop 3. klrc's §9.2.2 points at RFC 9421 via the WIMSE HTTP Signatures profile. AID's optional PKA uses the same RFC for its challenge-response handshake. Any client that implements klrc's application-layer authentication already has the cryptographic machinery needed to verify an AID record. The composition is free.

A proposed §10.9.0

Here is a drop-in subsection written in klrc's house style. Treat it as a sketch to edit. The shape matters more than the specific wording.

10.9.0. Domain-Based First-Hop Discovery

Before an Agent can use the HTTP-based discovery mechanisms in the subsections below, it MUST know the base URL of the counterparty's Authorization Server, Protected Resource, or Agent endpoint. In deployments where this URL is not preconfigured, Agents MAY resolve it from a domain name using DNS-based discovery.

The Agent Identity and Discovery specification [AID] defines a DNS TXT record at _agent.<domain> containing a protocol token, an absolute endpoint URL, and optional cryptographic proof-of-control material. Once the endpoint URL has been resolved, the discovery mechanisms in Sections 10.9.1 through 10.9.3 apply unchanged.

[AID] draft-nemethi-aid-agent-identity-discovery, Agent Identity and Discovery (AID), Work in Progress.

Two small consequences. First, klrc §16 currently says "This document has no IANA actions." With an informative reference to AID, the draft transitively gets a published IANA anchor for agent service discovery: the _agent underscored node name under RFC 8552, which is the request in draft-nemethi-aid §7.1. No additional filing on klrc's part. Second, AID is being discussed on dnsop@ietf.org; klrc lives on oauth@ietf.org and near WIMSE. A reference would connect two working-group conversations currently running in parallel on the same underlying problem.

What this doesn't try to solve

A few gaps in klrc I'm not touching here:

• §14 Security Considerations is currently "TODO Security." Domain impersonation and the first-contact adversary belong in that section, and DNS-based discovery changes what the threat model looks like. That's a separate conversation.
• Kieran Sweeney's critique of multi-hop delegation on oauth@ietf.org (msg25761) and the parallel AgentID draft (msg25768) are live on the same list. They sit at hops beyond discovery, not underneath it.
• The broader question of whether SPIFFE URIs, DIDs, or DNS names are the right cross-organizational identity anchor is a longer essay. An earlier version is already on this blog, as PKA as External Trust Anchor.

All of that can wait. The concrete ask here is one informative subsection.

What happens next

I'd like to take this proposal to oauth@ietf.org, and I'm happy to discuss directly with any of the authors of klrc-aiagent-auth. The AID I-D is at draft-nemethi-aid-agent-identity-discovery. Spec, SDKs, and a CLI validator are at aid.agentcommunity.org.

klrc-aiagent-auth is a good framework. This post isn't a complaint. It's an ask for a single informative reference that slots DNS discovery into the layer where it belongs, and it costs the draft no new IANA actions.

Draft: draft-klrc-aiagent-auth-01. AID I-D: draft-nemethi-aid-agent-identity-discovery-00. Spec: AID v1.2. Code: github.com/agentcommunity/agent-identity-discovery.