Mohamad, The scope defense in your reply upthread is the most important paragraph this thread has produced. The evidence-bar versus governance-bar distinction is exactly right, and both load-bearing properties deserve to survive every revision: the principal as signer rather than as a subject of issuance is what makes the artifact mean something to a party who trusts neither the runtime nor its operator, and dynamic linking under PSD2 SCA is the deployed proof that regulators already require parameter binding at authorization. The general problem inherits that bar; it should not weaken it.
Four requirements I believe the statement still needs, plus one on the Morrison exchange: Bounds versus parameters. Because agent intent is generated at runtime, T0 constraints are bounds, not parameters. That yields two requirements the current text allows to blur: T1 parameters must be provably within the signed T0 bounds (a subset check any verifier can perform), and designated action classes must obtain fresh principal evidence at T1 itself, because for some consequences no bound is specific enough. Your escalating class is the second requirement; naming both keeps solutions honest about which they provide. Survival across delegation. If the executing agent sub-delegates, the binding must narrow, not merely persist: evaluation at hop N must see constraints no wider than T0's, provably, or the gap reopens at the second hop. Mandate lifecycle at T1. Your second property settles where the evidence is verified; what remains is the mandate's own state. The verifier needs to establish that the mandate had not been revoked or expired at the moment of execution, within a stated staleness bound, and that the signer's key was valid then, which implies signer-key lifecycle (rotation, compromise, repudiation) is part of the problem, not deployment detail. For the after-the-fact auditor this becomes: re-verification against the state as of the action instant, not as of the audit. Single reliance. An evidence artifact bound to an exact payload can still be replayed against a second identical execution. The statement should require that evidence be relied upon once, and that the reliance itself be auditable. On the escalation exchange: the formulation you and Blake landed on reads right to me, and the declarer-independence principle (the response space not declared by the party whose error the amendment reports) is the load-bearing part. One addition would close the evidentiary side of it: every outcome that mutates the mandate, amendment above all, must itself be a T0-grade event, signed by the principal at the same evidence bar as the original mandate, so the auditor finds an unbroken chain of principal-signed states rather than a mandate whose middle was edited by the machinery around it. That also keeps Blake's separation clean: whether an amended value is inside the constraint set stays a constraint-set question, because the amendment that produced it is just another signed T0 state to check against. For comparison while drafting -01: R1, R4, R5, R7, and R10 of draft-reece-wimse-cross-org-delegation state formulations of the narrowing, binding, principal, lifecycle, and execution-time requirements above, and the AIMS adoption thread carries an open gap item on the mid-execution case where a problem statement at this level is the frame being asked for. Morgan Sent with Proton Mail secure email. On Thursday, August 13th, 2026 at 6:01 AM, Blake Morrison <[email protected]> wrote: > Hi Mohamad, > > Property, not count. Your wording is better than mine and "wider than > two" should go. > > On who declares it - the two you have drawn are not the only options. > If the escalating side declares the space, the requirement is met by > an agent that never offers amend, and the amend outcome exists to > report that agent's own error. So the party that declares the response > space cannot be the party whose error the amendment reports. That > rules out agent-declared without putting you in the position of > requiring anyone to accept an unanticipated response and it says what > must be true rather than how to build it. > > Third one, separate, for your reason. Whether 500 instead of 5000 is > inside what was authorised is a question about the constraint set and > it is asked the same way whether the value arrived by amendment or in > the original request. Folding it into Section 6 makes the escalation > requirement carry a check that is not about escalation. > > So your landing holds with one addition. Neither acceptance nor > refusal, declared rather than implied, and not declared by the party > being corrected. > > Best, > Blake > > > On Thursday, 13 August 2026 at 5:57 PM, Mohamad Khalil Yossif > <[email protected]> wrote: > > > > > > > > Blake, > > > > > > You're right about the axis. My tiers grade how hard the challenge is > > > before signing. You're asking what can come back after it. Those are > > > different questions and mine doesn't touch yours - CONFIRM and STEP_UP > > > both still end in accept or refuse, so I made the question harder > > > without making the answer wider. > > > > > > The amend case is the one with nowhere to land, and I agree it's the > > > one worth keeping. "Right question, wrong amount" is the human telling > > > you the agent got something wrong. Collapsing that into a refusal > > > keeps the outcome and throws away the reason, and the reason is the > > > more useful half. > > > > > > Before I write it into -01 I want to get the requirement right rather > > > than the mechanism, and three things are unclear to me. This is a > > > problem statement, so anything I put in Section 6 has to say what must > > > be true without saying how to build it. > > > > > > First, "wider than two" counts options, and counting is already a > > > design choice. What I think you're actually pointing at is a property: > > > the return must be able to carry a response that is neither acceptance > > > nor refusal. That states the failure without prescribing a shape. Is > > > that the requirement you mean, or do you mean something stronger that > > > a count captures and a property doesn't? > > > > > > Second, and this is the one I keep going back and forth on - who > > > declares the response space? > > > > > > If the escalating side declares it, the space is closed and the agent > > > still controls it. An agent that never offers amend leaves the human > > > exactly where they were, and the requirement is satisfied on paper > > > while the gap survives. > > > > > > If the human can return an amendment whether or not it was offered, > > > the space is open, but then the requirement lands on the party that > > > has to accept an unanticipated response, which is a much larger claim > > > for a problem statement to make. > > > > > > I don't think Section 6 can be written without choosing, and I don't > > > want to choose by accident. > > > > > > Third, an amendment carries a value the original didn't. Something has > > > to decide whether that value is within what was originally authorized > > > - 500 instead of 5000 is fine, 50000 instead of 5000 is not. Is that > > > inside the escalation requirement, or a separate one about the > > > constraint set the amendment is checked against? My instinct is > > > separate, because otherwise Section 6 quietly becomes a negotiation > > > protocol. > > > > > > Where I've landed provisionally, and tell me if it's wrong: the > > > requirement is that the escalation return be able to carry a response > > > that is neither acceptance nor refusal, and that whatever the response > > > space is, it be declared rather than implied. What that space contains, > > > and who is bound by it, sits outside a problem statement. > > > > > > Mohamad > > > > > > > > _______________________________________________ > 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]
