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.
> 
> https://github.com/mcguinness/mission-bound-authorization
> 
> 
> --
> 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]

Reply via email to