Skip to content

docs(building): explain why bearer tokens are prohibited for financial operations#5822

Open
aleksUIX wants to merge 2 commits into
adcontextprotocol:mainfrom
aleksUIX:docs/why-signed-requests-financial-ops
Open

docs(building): explain why bearer tokens are prohibited for financial operations#5822
aleksUIX wants to merge 2 commits into
adcontextprotocol:mainfrom
aleksUIX:docs/why-signed-requests-financial-ops

Conversation

@aleksUIX

@aleksUIX aleksUIX commented Jul 6, 2026

Copy link
Copy Markdown

Summary

Closes #5789 (critical knowledge gap: signed requests vs bearer tokens).

The Authentication Method table in docs/building/by-layer/L2/authentication.mdx states that static credentials are prohibited for mutating and financial operations from 3.1, but never says why. The question keeps coming up (the issue captures a Slack thread where a human expert had to supply the rationale). This PR writes the rationale into the doc where the question is asked.

Change

New "Why bearer tokens are prohibited for financial operations" subsection, placed directly after the mechanism table and the 3.0-floor warning:

  • Bearer tokens authenticate whoever presents them; anyone who obtains the token can originate spend commitments indistinguishable from the legitimate agent's.
  • What signing buys for spend-bearing calls: proof of possession (key never travels), payload integrity (the signature binds the RFC 9421 covered components already listed later in the page), replay resistance (timestamp window plus nonce), and accountability (provable origination, which is what lowers fraud and dispute cost).
  • Points implementers at the L1 verifier checklist and reference SDKs rather than hand-rolled cryptography.

Explanatory only: no new requirements, no changes to the normative table, consistent with the covered components and parameters specified in the L1 security reference. Docs only, outside docs/reference/; no changeset per the protocol-scope policy.

Verification

  • Claims cross-checked against the mechanism table in the same file and docs/building/by-layer/L1/security.mdx (request-signing section: covered components, ±60 s window, nonce)
  • Internal link resolves

…l 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 adcontextprotocol#5789.

@aao-release-bot aao-release-bot Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Argus review could not complete

The automated review encountered an issue (possibly reached max turns, timed out, or failed to post the final gh pr review). A human reviewer should take this PR.

View workflow run

This is an automated message from the Argus AI review workflow.

@aao-release-bot aao-release-bot Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Argus review could not complete

The automated review encountered an issue (possibly reached max turns, timed out, or failed to post the final gh pr review). A human reviewer should take this PR.

View workflow run

This is an automated message from the Argus AI review workflow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

docs: knowledge gap (critical) — Authentication Method - Signed Requests vs. Bearer Tokens

1 participant