Skip to content

fetch: drive the per-call escalation challenge (AAuth-Requirement) for escalate/irreversible operations #19

Description

@dickhardt

Live test 2026-08-14: a granted gmail.users.messages.send was answered by the proxy with 401 {"error":"escalation_required","operationId":"gmail.users.messages.send","sensitivity":"irreversible"} — correct per the sensitivity ladder (send/delete/merge always step up even with a standing grant). The 401 carries an AAuth-Requirement header with the full per-call proposal (built by aauth-proxy buildEscalationChallenge: operation, path, query, body digest as hash+excerpt).

@aauth/fetch prints the error body and exits — it does not follow the per-call leg (present the proposal to the PS, await the person's approval of THIS call, retry with the per-call credential). The proxy side is fully covered by its component suite (proposal → approval → retry, parameter enforcement, non-replay); the wallet side verifies per-call fields. The CLI is the only party that does not speak it.

Related: dickhardt/AAuth#92 (202 deferred pattern for per-call).

🤖 Generated with Claude Code

https://claude.ai/code/session_01TQ2FCHHAnuJWF5TJB3838S

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions