> 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]
