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 <[email protected]> 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, [email protected] 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 > > > <[email protected]> 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 -- [email protected] > > > To unsubscribe send an email to [email protected] _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
