From 44047e98399d36ef3f888941961af342c46f1fb3 Mon Sep 17 00:00:00 2001 From: Aleksander Sekowski Date: Sun, 5 Jul 2026 18:29:14 -0700 Subject: [PATCH 1/2] docs(building): explain why bearer tokens are prohibited for financial operations The authentication method table states the 3.1+ prohibition but not the rationale, and the question keeps coming up. Add a subsection covering proof of possession versus token theft, payload integrity via the signed covered components, replay resistance, and the accountability anchor that lowers fraud and dispute cost, with a pointer to the L1 verifier checklist instead of hand-rolled cryptography. Closes #5789. --- docs/building/by-layer/L2/authentication.mdx | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/docs/building/by-layer/L2/authentication.mdx b/docs/building/by-layer/L2/authentication.mdx index 7e6bcbd6fe..6b5999db01 100644 --- a/docs/building/by-layer/L2/authentication.mdx +++ b/docs/building/by-layer/L2/authentication.mdx @@ -53,6 +53,19 @@ AdCP supports three authentication mechanisms for authenticated operations. The **3.0 mutating-operation floor.** Until 3.1 lands, static Authorization-header credentials over TLS are the effective floor for mutating operations. Operators handling spend commitments SHOULD ship RFC 9421 request signing before the 3.1 deprecation date to avoid a forced cutover. +### Why bearer tokens are prohibited for financial operations + +A bearer token authenticates whoever presents it. Any party that obtains the token (a leaked log line, a compromised proxy, a captured request, a misconfigured relay) can originate spend commitments indistinguishable from the legitimate agent's, and the seller cannot tell the difference after the fact. For read and discovery operations that risk is bounded; for operations that move money it is not. + +Signed requests replace possession of a string with proof of possession of a private key: + +- **Proof of possession.** The signature proves the caller holds the signing key. The key never travels on the wire, so the theft surface shrinks from every system a token passes through to the signer's key storage. +- **Payload integrity.** The signature binds `@method`, `@target-uri`, `@authority`, `content-type`, and `content-digest`, so tampering with a budget figure, account reference, or target endpoint invalidates the request. TLS protects bytes in transit but not through intermediaries, relays, or logs; the signature protects the transaction end to end. +- **Replay resistance.** The ±60 s timestamp window and nonce prevent a captured request from being resubmitted as a new transaction. +- **Accountability.** Both parties can prove after the fact who originated a transaction and exactly what was requested. That audit anchor is what lowers fraud and dispute cost in financial workflows; with a shared secret, origination is unprovable once the token may have leaked. + +This is why the 3.1+ conformance floor prohibits static credentials for mutating and financial operations while continuing to permit them for read and discovery. Key discovery, covered components, and the full verifier checklist are defined in the [implementation security reference](/docs/building/by-layer/L1/security#request-signing); build on those (or a reference SDK) rather than hand-rolling the cryptography. + ### Static Authorization credentials (3.0 baseline) ``` From 8a0ca73bbd45c31bd79f5f4f955e5fca7c8594e6 Mon Sep 17 00:00:00 2001 From: Aleksander Sekowski Date: Sun, 5 Jul 2026 18:39:00 -0700 Subject: [PATCH 2/2] chore: retrigger Argus review