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

[Mohamad Khalil Yossif <[e-mail]>]

> Morgan,
> 
> Thank you. I went and checked each of the five against what I have
> running before answering, because I would rather tell you which are
> already solved than promise to consider all of them.
> 
> Bounds versus parameters. Your first half is implemented. In my
> system the signed mandate claims are bounds, documented as such - an
> amount ceiling, a daily ceiling, permitted action classes,
> counterparty allowlists carried as hashes, and an agent scope declared
> by the human at the grant ceremony rather than asserted by the agent.
> A resolver performs the subset check at execution and refuses on
> violation. So a verifier-performable subset check is not a
> hypothetical requirement for me; it is the code path.
> 
> Your second half is the more interesting one and I do not have it as a
> first-class concept. A designated class that must obtain fresh
> principal evidence at T1 regardless of whether the parameters fall
> inside the bounds is different from escalation triggered by exceeding
> a bound, and you are right that naming both keeps solutions honest
> about which they provide. That distinction is worth a requirement.
> 
> Mandate lifecycle at T1. Also implemented, and I agree it belongs in
> the statement rather than being left as deployment detail. Revocation
> is evaluated at the moment of the decision, the mandate carries an
> expiry, and issuer-key compromise cascades through a revocation path.
> What I would add to your formulation: re-verification against the
> state as of the action instant needs the verifier to be able to
> establish that state without trusting the party that held it, which is
> a harder requirement than storing a timestamp.
> 
> Single reliance. Partly. In my system a mandate is standing authority
> and is meant to be relied on repeatedly, so the requirement cannot
> attach to the mandate. It attaches to the evidence artifact, and there
> it is the ordinary replay problem - a unique identifier and a
> monotonic counter. The part of your requirement I do not have is that
> the reliance itself be auditable as a distinct event. That is a real
> gap and I will note it.
> 
> Survival across delegation. I have nothing here, and I want to be
> plain about why rather than agree politely. There is no
> sub-delegation concept in my implementation at all, so I have neither
> solved this nor discovered it is hard. That makes me a poor judge of
> the requirement. If it belongs in the statement it belongs on your
> reasoning, not on my agreement.
> 
> On amendment as a T0-grade event: I think you are right, and it closes
> something the exchange with Blake left open. If an amendment mutates
> the mandate and is not itself principal-signed at the same bar, the
> auditor is reading a state that the machinery edited. Blake's
> separation stays clean under your version, which is the test I would
> apply.
> 
> I will take all of this into the next revision and see how much of it
> survives being written down. I am not promising which requirements
> land - some of these interact and I would rather find that out in the
> text than commit here.
> 
> On the two pointers: I will read draft-reece-wimse-cross-org-delegation
> properly rather than skim it for the requirement numbers, and I will
> look at the AIMS adoption thread before I write anything.
> 
> Mohamad