[OAUTH-WG] Re: New I-D: Problem statement on verifiable human mandates for autonomous agent actions

[Blake Morrison <[e-mail]>]

Hi Mohamad,

The tiering is good structure, and PASS / CONFIRM / STEP-UP / DENY reads
the escalation trigger the way the problem statement should. It answers a
different question from the one Section 6 leaves open, though.

Your tiers grade how hard the challenge is before signing, the gap is what
comes back after it. CONFIRM and STEP-UP both resolve to a fresh mandate or
nothing, the binary again one step stronger, and the amend outcome, where
the human says the question was right and the answer space was wrong, still
has nowhere to land. "Most restrictive prevails" is the same collapse from
the policy side, right for a hard boundary and wrong for the escalating
class, where the signal worth keeping is the agent's own error.

So neither. Not full negotiation logic in the problem statement, and not
the tiers alone, since they're on a different axis from the response space.
Section 6 should require the escalation return to declare its response
space, and require that space to be wider than two, whatever tiering
triggers it.

Best,
Blake


On Friday, 24 July 2026 at 3:23 AM, Mohamad Khalil Yossif <mohamad=[e-mail]> wrote:

> Hi Blake,
> 
> Thanks for the detailed feedback—this is precisely the kind of analysis
> I was hoping to get on the initial -00 problem statement before refining
> the requirements in the next iteration.
> 
> You’ve spotted a real tension between Sections 3 and 9 regarding the
> escalation return path. The intention behind treating escalation as a
> separate class was indeed to prevent a binary fallback where "outside
> autonomous mandate" simply collapses into a silent rejection, concealing
> the specific reason or resolution path.
> 
> From an architectural perspective, an execution evaluation layer often
> needs to account for multiple policy sources—the Principal (User),
> the Institution (e.g., Bank policy), and dynamic Risk signals (Fraud Engine).
> Rather than full application-level protocol negotiation (such as Amend
> or Commit), we view the escalation space as a deterministic tiering:
> 
> 1. PASS / Silent: Action remains within autonomous mandate boundaries.
> 2. CONFIRM (WYSIWYS): Boundary threshold crossed; requires local
>    hardware-bound biometric assertion displaying exact action parameters.
> 3. STEP-UP (Active Challenge): Elevated risk signal detected; requires an
>    interactive challenge prior to cryptographic signing.
> 4. DENY (Hard Block): Hard boundary breach by any participating policy.
> 
> When requirements conflict, safety dictates that the most restrictive
> escalation requirement prevails.
> 
> From a problem statement perspective, we treat the return path as an
> escalation signal that triggers an out-of-band human assertion (WYSIWYS)
> to establish a fresh mandate, rather than a protocol-level state
> negotiation.
> 
> Do you see defining an explicit escalation / step-up state space (wider
> than binary pass/fail, but distinct from full payload amendment) as
> sufficient to bridge the gap in Section 6, or do you believe full
> protocol-level negotiation logic belongs in the problem statement itself?
> 
> Best regards,
> Mohamad
> 
> > On 23 Jul 2026, at 13:56, Blake Morrison <blake=[e-mail]> wrote:
> >
> > Mohamad,
> >
> > The problem statement is at the right level and the T0 to T1 separation is
> > the right cut to build the requirements on.
> >
> > One thing is missing from them, on the escalating class. Section 3 says a
> > crossing removes the action from the agent's autonomous authority and returns
> > the decision to the Principal for fresh authorization. Section 9 then scopes
> > out any interaction with the Principal. So for hard constraints the
> > requirements close: the action is outside the mandate and fails, and nothing
> > comes back. For escalating ones the draft names a return path and states no
> > requirement on what returns along it.
> >
> > That gap will be read as a binary approve or deny, and a binary collapses
> > outcomes that are not the same. A decline, where the question was right and
> > the answer is no, is not a rejection of the question itself, which reopens
> > what should have been asked. An amendment is a third: the question stands and
> > the answer space was wrong, so the constraint set should change rather than the
> > action proceed. The amendment case is the one that carries the agent's own
> > error signal, which is what an auditor of a mandated action most wants to find.
> >
> > draft-morrison-binding-moment-envelope-01 standardises a four-way principal
> > resolution, commit, decline, amend or reject, for exactly that return. I am not
> > asking you to cite it. I am asking that Section 6 require a solution to state
> > the response space for an escalation, and that the space be wider than two.
> >
> > Let me know if you read escalation as out of scope rather than under-specified.
> >
> > Best,
> > Blake
> >
> >
> > On Wednesday, 22 July 2026 at 11:06 PM, Mohamad Khalil Yossif <mohamad=[e-mail]> wrote:
> >
> >> George,
> >>
> >> Thanks - that was the right pointer. I have now read the "Power of
> >> Attorney" series and the Mission-Bound OAuth notes. Karl is working
> >> the same gap the problem statement describes, and the framing there
> >> is farther along than any single artifact I had cited. -01 will
> >> treat that line of work as primary related work.
> >>
> >> That said, the problem this draft is scoped to is a narrower and
> >> distinct one, and I think worth separating on the list rather than
> >> folding in.
> >>
> >> The angle here is regulated action authorization: environments where
> >> an auditor, regulator, or dispute process needs to verify, after the
> >> fact and without trusting the runtime that executed, that a specific
> >> human authorized this specific action with these specific parameters
> >> at the moment it happened. Payments under PSD2 SCA dynamic linking
> >> is the canonical case. Agentic transactions and high-consequence AI
> >> agent actions inherit the same requirement.
> >>
> >> Two properties define that scope and are load-bearing for it:
> >>
> >> First, the constraint set is signed directly by the human with a
> >> hardware-bound key gated by user verification, not issued by an
> >> authority service that references the human in a claim. The
> >> principal is the signer, not a subject of issuance. That is what
> >> makes the artifact meet an evidence bar rather than a governance
> >> bar.
> >>
> >> Second, each authorized action produces a signed evidence artifact
> >> bound to the exact payload that executed and to the mandate it was
> >> verified against, independently verifiable by a third party without
> >> access to server logs. This is what draft-yossif-psea profiles at
> >> T1. The mandate draft is the T0 counterpart against which that
> >> evidence is verified.
> >>
> >> Mission-Bound OAuth is solving the enterprise IAM lifecycle problem
> >> - should this execution still be running - and doing so at the
> >> governance layer. This draft is solving the regulated
> >> evidence-of-authorization problem - can a third party later verify
> >> that this action was authorized by this human. Different trust
> >> root, different output artifact, different consumer. Complementary,
> >> not competing.
> >>
> >> - Mohamad
> >>
> >>
> >>> On 22 Jul 2026, at 15:41, [e-mail] wrote:
> >>>
> >>> I would highly recommend looking at Karl McGuinness’s mission bound authorization work as it addresses this problem space.
> >>> mcguinness/mission-bound-authorizationgithub.com<apple-touch-icon-180x180-a80b8e11abe2.png>
> >>>
> >>>
> >>> --George Fletcher
> >>> Practical Identity LLC
> >>>
> >>>
> >>>> On Jul 22, 2026, at 2:32 PM, Mohamad Khalil Yossif <mohamad=[e-mail]> wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> I have submitted draft-yossif-agent-mandate-problem-00, a short
> >>>> problem statement. No protocol, no mechanism.
> >>>>
> >>>> The problem: a human authorizes intent at T0, an autonomous agent
> >>>> executes a specific parameterized action at T1, and nothing
> >>>> cryptographically binds the executed parameters to the constraints
> >>>> the human actually signed. OAuth scopes are static and session-bound,
> >>>> audit logs are self-asserted after the fact, and existing
> >>>> mandate-style work is payments-scoped. The draft states the gap and
> >>>> the requirements any general solution would need to meet.
> >>>>
> >>>> https://datatracker.ietf.org/doc/draft-yossif-agent-mandate-problem/
> >>>>
> >>>> Given the WG charter now covers authorization for automated agents,
> >>>> I would welcome feedback on the problem definition itself: is it
> >>>> stated at the right level, and is anything missing from the
> >>>> requirements?
> >>>>
> >>>> Mohamad Khalil Yossif
> >>>>
> >>>> _______________________________________________
> >>>> OAuth mailing list -- [e-mail]
> >>>> To unsubscribe send an email to [e-mail]
> 
>