Summary
- The first individual AAuth-R3 Internet-Draft, submitted on 28 September 2026, proposes that a resource may execute a truly consequence-free held call before asking a person to approve release of its result. It is not an RFC, IETF endorsement or evidence of deployment.
- The approval screen must state that the operation already ran. The resource can describe the fixed result's actual size and sensitive field categories; consent now governs disclosure to the agent, not the earlier execution.
- If execution is itself audited, metered, billed, rate-counted or triggers another party, the proposal says approval must come first. A method named “read-only” does not prove that running it has no external effect.
The decision after the answer exists
Suppose an agent requests a table of employee records. Before displaying a consent screen, the resource executes the query and finds 214 rows, including compensation and home addresses. The resource retains the result; the agent has not received it. The person's decision is now more concrete than approval of an abstract SELECT statement: it is whether to release this already computed collection. AAuth-R3's new individual draft uses exactly this distinction in §10.4.
The mechanism matters because query text does not reliably disclose the consequence of disclosure. The resource knows the actual row count and categories of fields. It can put a description in the per-call proposal and may withhold or redact material it judges unsuitable to release. The issuer and the person see only the result description that the resource elects to provide, not the result itself. The proposal's result member is optional and appears only when execution has already happened. The person's display must say so; a screen that suggests the person is still deciding whether the query may run would misstate the control.
This is not a general “execute first, ask later” rule. The draft requires the early path to have no side effects. It says that if running the operation itself is what an access log records, a meter or rate limit counts, a bill charges, or another party is contacted, approval must precede execution. The useful test is not whether the API calls itself a read. It is whether anything outside the retained answer changes at execution time. A read that creates a charge is consequential before a single byte is disclosed to the agent.
What binds the later release
The Datatracker record lists revision -00 as an individual Internet-Draft with I-D Exists state. Its intended Standards Track label is a proposal, not approval. The text describes a content-addressed proposal for one call: concrete operation and parameters, a reference by r3_uri and r3_s256, and a human display. In the held-call 202 flow the resource retains the invocation; the agent does not reconstruct its parameters after approval. For ordinary 401 retry, however, the resource must compare the retried parameters with the approved proposal, including byte-identical values where a digest represented a sensitive parameter. One per-call token cannot execute two invocations.
When the qualifying call was run before approval, the result is already fixed. The approval is therefore for releasing that result, not for a later execution that might return different rows. The draft says this avoids parameter drift for that path. Yet fixed bytes do not settle the privacy question by themselves. The resource determines the result description sent to the person-facing service and which output to release; a disclosure choice made on an incomplete description remains a governance problem, even if the token and digest bind the call correctly.
No production deployment or interoperability test is demonstrated by the source. This is a specification proposal with a conditional control design. BTW's adjacent AAuth budget coverage concerns aggregate spending across tokens, and its event-delivery coverage concerns an intermediary's receipt versus agent delivery. Here the disputed moment is the human decision after a single result exists but before the agent receives it.
Sources
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance

