Discussion: AID and the IETF "Web Bot Auth" Draft — A Complementary Vision for Agent Trust

[nembal]

Hello everyone,

A new IETF draft, "Web Bot Auth", has been published, and it's highly relevant to our work on agent security. I wanted to start a discussion on how it relates to our Agent Interface Discovery (AID) specification.

My analysis is that AID and Web Bot Auth are not competing standards; they are highly complementary protocols that solve different problems at different layers of the agent interaction stack.

• AID answers: "Where is the agent and how do I talk to it?" (Discovery)
• Web Bot Auth answers: "Can I trust that this message truly came from that agent?" (Authentication)

Part 1: The Synergy Between AID and Web Bot Auth Today

First, let's look at how the two protocols can work together as they are currently specified.

What is Web Bot Auth (WBA)?
At its core, WBA is about authenticating individual HTTP requests. It uses the HTTP Message Signatures standard to allow an agent to cryptographically sign its requests. The key innovation is solving the public key distribution problem: it defines a .well-known URI where a domain can publish its public keys, allowing a server to dynamically fetch a key and verify a request's signature.

How They Fit Together
The synergy is elegant. AID provides the initial address, and WBA secures the conversation that follows. Here’s a typical flow:

1. Discovery (AID): A client starts with a domain, example.com. It performs an AID lookup on _agent.example.com and discovers the agent's MCP endpoint is https://api.example.com/mcp.
2. Connection: The client establishes a standard TLS connection to that endpoint.
3. Message Authentication (WBA): Now, for every sensitive request within the session (e.g., an MCP tools/call), the client signs the request using its private key and includes the Signature and Signature-Agent headers defined by WBA.
4. Message Verification (WBA): The server at api.example.com receives the signed request, uses the Signature-Agent header to fetch the client's public key, and cryptographically verifies the message before processing it.

This combination is already powerful. It gives us a decentralized discovery mechanism (AID) paired with a standardized, per-request authentication protocol (WBA).

Part 2: Enhancing the Model with the pka Proposal

While the above model is strong, there is still a subtle but critical trust gap. DNSSEC verifies the AID record, and WBA verifies the message, but how do we verify the endpoint itself? An attacker who compromises a web server or hijacks network traffic could potentially impersonate the agent endpoint, even if the DNS record is secure.

This is where a proposal I recently opened, Issue #36: Agent Identity Verification via a 'pka' (Public Key for Agent) key, comes in.

The pka proposal suggests adding an optional public key directly into the AID TXT record. This would enable a client to perform a one-time challenge-response handshake upon first connecting to the uri.

The "Even Stronger" Flow with pka:

The interaction flow would be enhanced with a crucial new step:

1. Discovery (AID): The client fetches the AID record for _agent.example.com and gets the uri and the new pka public key.
2. Record Verification (DNSSEC): The client verifies the authenticity of the AID record itself via DNSSEC.
3. Endpoint Verification (pka Handshake): The client connects to the uri and performs a challenge-response handshake. It sends a random nonce to the server, which signs it with its private key. The client then verifies this signature using the pka public key from the DNS record. This cryptographically proves the client is talking to the authentic agent.
4. Message Authentication (WBA): Now, with a verified endpoint, the client proceeds to send requests that are individually signed using the Web Bot Auth standard.

By adding the pka handshake, we create a complete, end-to-end chain of trust: from the domain owner (via DNSSEC), to the agent endpoint (via pka), to every single message (via WBA).

I believe this layered approach gives us the best of all worlds: AID for fast and simple discovery, the proposed pka key for robust endpoint verification, and WBA for standardized, per-request authentication.

I'm keen to hear the community's thoughts on this synergistic relationship and on the pka proposal as a way to complete our security model.

Relevant Links:

• AID Specification
• AID GitHub Repository
• IETF Web Bot Auth Draft