Identity boundary
Web Bot Auth authenticates a signed web request
Web Bot Auth builds on HTTP Message Signatures. A bot publishes or registers key information, signs selected request components, and sends Signature-Input, Signature, and Signature-Agent headers. A verifier checks the signature, key reference, creation and expiry window, and the components that were actually covered.
For agentic payments, the result can establish that a request came from a recognized bot operator or signing key and was not altered across the signed fields. It does not establish the human or organization represented by the bot, the mandate under which it acts, or the right to spend a particular credential.
| Claim | Representative evidence | Still required |
|---|---|---|
| Request integrity | HTTP message signature | Freshness and replay controls |
| Bot operator | Registered key directory and signature agent | Operator policy and current registration |
| Principal | Authenticated user or organization binding | Delegation from principal to agent |
| Payment authority | Mandate and deterministic policy decision | Exact order, amount, merchant, and expiry |
| Settlement | Rail-specific transaction evidence | Merchant fulfillment and recourse |
Sign the components that matter to the merchant decision
A signature is only as useful as its covered components. Bind the authority or host, method, path, relevant query, signature-agent reference, content digest where the path permits it, and short validity interval. If a payment offer or order identifier is carried in a header or body, ensure the application binds that same value into its authorization and transaction evidence.
Use a short expires value and an application-level nonce or request identifier where replay matters. Signature validity alone does not guarantee uniqueness. Infrastructure and origin services must agree which layer detects duplicates and how a retried request retrieves the prior result.
- Reject signatures that omit a component used in the authorization decision.
- Keep key rotation and revocation observable at the merchant boundary.
- Do not accept a verified operator as a substitute for principal authentication.
- Propagate verification results to the origin through a protected channel, not a client-set header.
Model the chain from website to operator to end user
A merchant often interacts with a platform-operated agent acting for many users. The signed request may identify the platform while the payment mandate belongs to one principal. Store both relationships and require a session-specific binding between them. Otherwise one recognized bot can become a confused deputy for another user's authority.
Recognition can support rate limits, bot access policy, or differentiated checkout handling. Merchant risk screening can still deny a recognized agent, and a valid mandate can still require a merchant to reject the transaction for product, fraud, sanctions, or availability reasons.
Compose request identity with mandate and rail evidence
At payment time, join the signed-request identifier to the agent identity, principal, mandate, order, credential request, payment attempt, and settlement receipt. The merchant should be able to explain which operator sent the call and which separate artifact authorized the financial effect.
Keep failure reasons precise. Invalid signature, unknown key, expired request, replay, mandate denial, credential failure, and unsettled payment require different recovery. Asking the model to retry every failure can amplify duplicates or turn an identity problem into an unauthorized rail switch.
Verified automation is easier to govern, but a verified bot is not automatically an authorized buyer.
Source discipline
Primary sources
Product status and protocol behavior are checked against maintainer documentation. Company sources establish what their organizations publish; they do not independently prove adoption or performance.