Hello everyone,
I am new here, but thought if I could voice a though on this:
The scope sentence here looks right to me, and I think there is one
useful way to make the grant-layer / execution-layer boundary more
testable without proposing another mechanism.
Issues #11 and #15 already cover the need for execution-time evidence
and action-specific binding, so I would not add another artifact format
here. The gap I think is still worth making explicit is a *conformance /
falsification boundary*:
*Successful grant establishment MUST NOT itself satisfy any requirement
for approval or admission of a specific consequential action. Where
execution-layer binding is required, the execution endpoint must
independently verify that the concrete action, its material parameters,
actor/resource context, and current authorization state still match the
basis on which execution was admitted.*
A small acceptance matrix could make that distinction operational:
Case Grant layer Execution binding Expected result
Exact admitted action valid exact action/parameters proceed
Parameters changed after admission valid binding is for old parameters
reject
Grant revoked after admission revoked old binding otherwise valid
reject
Binding replayed valid already consumed reject
Wrong resource/actor valid grant binding names different
resource/actor reject
Grant valid, required action binding absent valid absent reject
Observed effect differs from bound action valid valid binding
evidence mismatch / do not treat consequence as verified
The useful invariant for the document may be:
*Grant proves authority to attempt a class of action. Execution binding
proves that this concrete action is permitted now. Execution evidence
proves what was authorized/executed. Observed consequence proves what
actually followed. None of these should be treated as a substitute for
another.*
That would also reinforce the last paragraph of this issue: completing
the first-connection flow establishes grant-layer authority only; it
should not be interpreted by the client or resource server as consent to
whatever consequential action happens to follow.
I am suggesting this as a requirements/test profile rather than a new
OAuth object or token format.
— *Valentyn Rukhaylo / Altru.dev*
On 9/25/26 12:22, Laxmikant Sharma wrote:
Iman, Cliff,
Thanks, both. I agree it's a distinct case from Use Case 5, and
"terminal disposition" names the gap better than I did.
The records back Cliff's "pending" state. At the resource server,
the client that did sign in during an interactive session left the
same trace as the two that gave up: a 401, a fetch of the protected
resource metadata, then nothing until its first request with a
token. Our test user was scripted, so that silence lasted about a
second. With a person it lasts as long as they take to sign in,
and the server can't tell it from a client that has stopped.
On the boundary, completing the challenge gives grant-layer
authority and nothing more. Binding a person's decision to a
specific action is the execution-layer question the draft already
keeps separate, and the proposed text says so.
The issue is open with the results and proposed text, including a
Section 6 change along the lines Iman suggested:
https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues/30
Placement and wording are the authors' call.
Laxmikant Sharma
On Fri, Sep 25, 2026 at 7:46 AM Cliff Singletary
<[email protected]> wrote:
+1 to capturing this as a distinct case, and to the
terminal-disposition requirement.
From the resource-server operator side: a client that goes silent
after a 401 leaves the RS unable to distinguish policy refusal,
unsupported flow, pending user interaction, and failure. All four
look identical in logs, which hurts both incident triage and audit
evidence. Even a small enumerated disposition set returned to the
RS would close most of that gap.
Happy to review proposed text when the issue is opened.
Cliff Singletary
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
OAuth mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
