Web Bot Auth and Visa TAP: Where Agent Names Fit
An agent arrives at a merchant's site with a signed request. The signature checks out. The merchant can recognize the signing service.
But which named agent is using that service? Who operates it, and where can a customer find its official information?
A headless domain can connect an agent's public identity to the signing service or key directory used to authenticate its traffic. That connection needs verifiable evidence and support in the receiving application. Publishing a name or a link alone doesn't establish it.
Web Bot Auth, Visa's Trusted Agent Protocol and MPP's identity features make this a practical design question. They already provide identity mechanisms. The opportunity for Headless Domains is to help connect those mechanisms to the service people and other agents recognize.
What a signed request actually proves
RFC 9421, HTTP Message Signatures, defines how to sign selected components of an HTTP message and verify that signature. A verifier needs the appropriate key, a valid signature and a policy for deciding what to accept.
The word “selected” matters. A signature protects the components it covers. It doesn't automatically protect every header, the request body or the meaning of a purchase. Freshness and replay checks also depend on the protocol profile and implementation.
That gives us a useful distinction: verifying a signature establishes a specific cryptographic fact. Deciding which business or named service that fact represents requires a trusted connection to that identity.
Web Bot Auth already provides a persistent identifier
The current Web Bot Auth working-group draft uses Signature-Agent to support signing-key discovery. Its identifier is the resolved HTTPS URL associated with the keys that verify the request. The URL can remain stable while the keys rotate.
So an agent doesn't need a new domain extension just to have continuity across signed requests.
The draft also draws a boundary: successful verification doesn't establish the operator's real-world identity, good behavior or permission to perform an action. Those decisions belong to the receiving service.
If you've followed an older link to draft-meunier-http-message-signatures-directory-03, follow the replacement history before implementing it. As of September 10, 2026, the active document is draft-ietf-webbotauth-httpsig-protocol-00, published September 1. It remains an Internet-Draft, not a finalized RFC. The Datatracker status page tracks its progress.
Visa TAP adds recognition for commerce agents
Visa's Trusted Agent Protocol specifications describe how merchants can recognize approved agents arriving with browsing or payment intent. Its agent-recognition signature builds on HTTP Message Signatures, with keys obtained from trusted sources.
The broader protocol also describes linked consumer-recognition and payment objects. That makes TAP more than a bot's name in a header.
Visa's implementation connects recognition to participation in its commerce program. Registering a headless domain, publishing your own public key or generating a valid signature does not enroll an agent in that program. Merchants still apply their acceptance policies.
A public name can identify the service using an approved provider. It cannot manufacture that provider's approval.
MPP brings request identity into the payment flow
MPP's August 12, 2026 mppx identity announcement documents support for Web Bot Auth and Trusted Agent Protocol. When configured, the SDK signs the initial request and automatic paid retries. Servers can verify the attestations before handling the payment challenge or credential.
This is useful because an agent may make several attempts to complete one paid interaction. Its request identity needs to travel with those attempts.
The current MPP identity guide separates request attestation from the identity authorizing payment. A request signer might represent an automated client or agent provider. The payment credential identifies the key authorizing the payment. Neither should be casually treated as proof of the end user's identity.
The guide also makes key resolution an application responsibility. Its Web Bot Auth verifier does not blindly fetch a caller-supplied directory URL. The application supplies keys according to its trust policy. That's a concrete place where a verified association with a public agent identity could become useful.
Connect the name to the signer in both directions
Suppose a company operates procurement.agent, a conceptual name for an agent that finds suppliers and prepares purchase requests. Customers know it by that name. Its outbound traffic uses a signing service.
The operator could publish the signing service's identity URL in documentation linked from the agent's public record. That gives a reader somewhere to start. It still leaves the signing service's side of the relationship unproven.
A stronger integration would require the operator or provider to substantiate the association through a mechanism the verifier trusts. For example, an application could maintain an authenticated enrollment record connecting the public name to an approved signing identity. A cryptographic attestation could serve that purpose where an agreed format and trusted issuer exist.
This is a proposed integration pattern, not a claim that Headless Domains currently implements a Web Bot Auth or TAP binding service.
For a controlled pilot, the connection would have four parts:
- Publish the public reference. Identify the agent's operator and link to documentation for its signing service through records the operator maintains.
- Establish the association. Have the receiving application verify and approve the relationship between the public name and signing identity. A self-declared link is insufficient.
- Verify incoming traffic. Validate requests using the selected signature profile and approved key source. Attribute them to the named agent only when the approved association supports that conclusion.
- Enforce the requested action separately. Apply access, spending and purchase-approval rules. Recognition alone doesn't permit a purchase.
There is one easy mistake here. A provider may sign traffic for many agents. If the signature identifies only that provider, it doesn't distinguish procurement.agent from another customer using the same service. Attribution to an individual agent needs additional authenticated context or a suitably distinct signing identity. A public profile cannot fill in missing evidence.
Use an HTTPS identity the verifier can reach
The Headless Domains name and the HTTPS address used by a signature implementation can coexist. The name can point to public documentation describing the signing identity, while the protocol uses its supported HTTPS interface.
Don't replace a working directory URL with https://procurement.agent and assume every merchant can resolve it or validate its TLS connection. Use an address that the participating clients and verifiers actually support.
Headless Domains supplies public naming and discovery records. Its API contract describes a read-only resolver; it does not authorize or proxy the discovered actions. The signing infrastructure, key management and receiving application's verification logic remain separate work.
The benefit is having a public identity that can refer to these technical systems without pretending to replace them. Our agent identity graph guide covers the wider relationships between public records and services.
AP2 handles the buyer's authority
Recognizing our procurement agent still doesn't establish that its user approved an order.
The AP2 specification addresses agent-performed purchases through checkout and payment mandates, receipts and verification duties. Its autonomous flow binds open mandates to an agent key.
That authorization evidence is distinct from recognizing the client sending an HTTP request. An implementation may use both, but it must explicitly connect the relevant identities and transaction context. Publishing the same agent name in two places doesn't make the protocols interoperable.
For payment-system selection, use our x402, AP2 and MPP comparison.
The case for a name gets more specific
These developments support a practical part of the Headless Domains argument: agents benefit when others can inspect who they represent and connect that public information to their working interfaces. They don't establish that every agent needs a headless domain.
Our opportunity is to make a named service easier to recognize across those interfaces, with evidence behind the connections. A customer can return to its public name. A receiving application can check its signing identity. A payment system can evaluate the authority for the transaction.
Start with the agent you already operate. Describe its purpose, publish its official interfaces and identify the signing infrastructure it actually uses. Add verified connections as the relevant integrations become available.
Give your agent the Headless Domains skill file and ask it to explain how to register a public name and maintain its records before taking action.
Sources checked September 10, 2026. The Headless Domains integration described here is a proposed architecture, not an announcement of Visa approval, native TAP support or automatic Web Bot Auth compatibility.