Mohamad, Yaron,
Thank you. I think this makes the separation much clearer.
On the first question, I would be cautious about saying that fine-grained
authorization can only describe a class of executions. In principle, an
authorization detail could be made extremely narrow: exact amount, exact
IBAN, transaction identifier, short expiry, nonce, and single-use
semantics. If the human approves that exact authorization request, then the
authorization can describe one concrete transaction rather than merely a
broad class.
But I think a different question remains:
What artifact establishes, independently of the client and ordinary AS/RS
logs, that the human approved that exact consequential act?
That seems to be the evidence problem you are isolating.
My own concern is one step later in the execution path.
Even assuming such a human-approval artifact exists, what makes successful
validation of that artifact a technical prerequisite to the first
irreversible external effect?
I see the two problems as complementary rather than competing:
Human approval
↓
Execution-specific evidence / mandate
↓
Candidate Act
↓
Protected validation
↓
current scope + freshness + execution evidence
↓
scoped execution authority
↓
final enforcement boundary
↓
external effect
In that composition, the mandate or human-approval evidence is an input to
the enforcement decision; it is not itself assumed to be bearer authority.
That distinction matters to me because a system can have very good evidence
describing what should be allowed, while an execution path somewhere else
can still complete the consequential operation without presenting that
evidence. The architectural requirement I am trying to isolate is therefore
not only evidence-before-effect, but dependency-before-effect: the
protected effect should be technically non-completable through the governed
path unless the required evidence and current authorization state validate.
So I think there may now be three separate properties worth keeping apart:
1. Is the requested execution inside the authorized scope?
2. Is there evidence that the human approved this specific execution?
3. Is successful verification of that evidence technically required
before the external effect can complete?
RAR can address the first very strongly, and perhaps represent an exact
single transaction. Your mandate work appears aimed principally at the
second. My execution-finality work is focused on the third and on the
boundary where that dependency becomes load-bearing.
On the banking-practice question, I would also be interested in a
practitioner’s answer rather than guessing. In particular, whether the
evidence relied upon in disputes is independently verifiable
execution-specific evidence, or primarily a reconstruction from
authentication records, authorization-server records, transaction logs,
device evidence, and the bank’s own system records.
Thanks again — I think this framing removes a lot of unnecessary
disagreement between the approaches.
Best,
Sangam
On Wed, 2 Sep 2026 at 3:02 PM, Mohamad Khalil Yossif <[email protected]>
wrote:
>
> Yaron, Sangam,
>
> Yaron asked what gap fine-grained authority properties cannot mitigate.
> I think there is one, and the RAR example is the clearest way to show
> it.
>
> Take the authorization detail as written:
>
> "type": "payment_initiation",
> "instructedAmount": { "currency": "EUR", "amount": "123.50" },
> "creditorAccount": { "iban": "DE02100100109307118603" }
>
> A resource server can deny anything that does not match. That is
> correct and it is the right mechanism for the job.
>
> What it establishes is that this call is within what was authorized.
> What it does not establish is that a person approved this call.
>
> Those are different facts and the distinction is not academic. Grant
> this detail once, and the agent may present it against an endpoint an
> hour later, a day later, or three hundred times, and every one of
> those calls matches. The parameters were approved as a shape. Whether
> a human was present for any particular execution, and approved that
> particular one, is not carried anywhere in the exchange.
>
> Make the detail narrower and the gap does not close, it only shrinks:
> a single-use authorization detail bound to one amount and one IBAN
> still says the user consented to a payment of that shape, not that
> they consented at the moment the payment went out.
>
> Which is fine for most flows. It stops being fine where the action is
> consequential and irreversible, and where someone has to reconstruct
> afterwards who authorized what. A regulator, a card issuer in a
> dispute, a counterparty. They arrive after the fact, they trust
> neither the client nor the authorization server, and there is no
> artifact for them to check. The grant tells them the agent was
> permitted. It does not tell them a human approved.
>
> Yaron, your mission-bound point addresses a different half of this and
> I agree with it. An approved intent gives the enforcement gate
> something to evaluate against, and it does reduce how often the user
> must be asked. But the gate is still deciding on the strength of what
> the AS and the RS agreed, and neither of them is the human. Lowering
> consent friction and producing evidence of consent are separable
> goals, and a design can do the first well and leave the second
> untouched.
>
> I wrote the requirements up without proposing a mechanism, because I
> do not think the mechanism belongs in a problem statement:
>
> https://datatracker.ietf.org/doc/draft-yossif-agent-mandate-problem/
>
> It is cited in draft-chen-oauth-agent-authz-use-cases, where Section 5
> asks the same question in the use-case framing.
>
> Two things I would genuinely like an answer to rather than agreement.
>
> Is there a construction where a fine-grained authorization detail does
> establish that a human approved a specific execution, rather than
> approved a class the execution falls into? I have not found one, and I
> would rather be shown wrong than keep asserting a gap.
>
> And where a regulator has to reconstruct the decision after the fact,
> what does a bank present today? That is a practitioner question and I
> am asking it as one.
>
> Mohamad Khalil Yossif
>
> draft-yossif-agent-mandate-problem
> https://datatracker.ietf.org/doc/draft-yossif-agent-mandate-problem/
> draft-yossif-psea
> https://datatracker.ietf.org/doc/draft-yossif-psea/
>
>
>
>
>
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
