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

[Blake Morrison <[e-mail]>]

Brian,

Issuance, subset check, and spend does not distinguish a mandate spent by the
action it authorised from one spent by being superseded. Under that resolver
both are the same event and the auditor sees a spent mandate either way.

That distinction is why amend is in the response space at all. It is the
outcome that carries the agent's own error. A refusal says the answer is no.
An amendment says the question stood and the answer space the agent offered
was wrong. Collapse the two into spend and the resolver stays small while the
signal the escalating class exists to produce is gone.

It costs nothing to keep. You have already argued that reliance has to be an
emitted, independently checkable event rather than a counter, and I agree with
the reason. Why a mandate was spent belongs in that same event. One structure
carries both requirements, no verifier reasons about mutation, and no
amendment code path comes back.

So the smaller trusted surface holds. What it needs is for spend to say which
of the two it was.

Best,
Blake


On Thursday, 27 August 2026 at 10:41 AM, Brian Vicente <bvicente=[e-mail]> wrote:

> Blake, Morgan, Mohamad,
> 
> On amendment as a T0-grade event: I agree with the conclusion and want to state the operational consequence plainly, because it is the part an implementer will get wrong.
> 
> If an amendment is a principal-signed T0 event at the original evidence bar, then there is no amended mandate. There is a second mandate and the first is spent. That means a verifier never needs to reason about mandate mutation, and a resolver never needs an amendment code path. It only needs issuance, subset check, and spend. That is a smaller trusted surface, and it is the reason I would keep the T0 framing even though it prices amendment out of the asynchronous case.
> 
> One consequence worth writing into the problem statement: because amendment requires a present principal, the response space an escalation may offer is bounded by reachability, not only by declarer independence. A statement that lists accept, refuse, and amend as peers will mislead implementers into building an amend path that is unreachable in exactly the deployments that motivated escalation in the first place.
> 
> On single reliance, I support Morgan's split as stated: the mandate is standing authority, and reliance attaches to the evidence artifact. I want to reinforce why reliance must be an auditable event rather than something a counter prevents. With independent verifiers, each can honestly rely once. A counter held by any single party cannot distinguish honest concurrent reliance from replay, and a counter held by the runtime is held by the party the artifact exists to avoid trusting. An emitted, independently checkable reliance event is the only construction I have been able to make work across verifiers that do not coordinate.
> 
> On the lifecycle requirement, I would go one step further than "a timestamp is not a mechanism." The requirement is establishing the as-of state without trusting the party that held it. In deployed PKI terms that means the status assertion has to be verifiable by a relying party that trusts neither the issuer's runtime nor its operator. We run this against hardware-bound signing on our own CA and it is the requirement most often quietly unmet.
> 
> I am happy to contribute text for the amendment and reliance requirements if the authors want it.
> 
> Best,
> Brian Vicente
> Sanctum SecOps LLC