Mohamad,
Checking each against running code before answering is the standard this genre
should hold itself to; thank you for setting it.
Your hardening of the lifecycle requirement is right and better than my
formulation: establishing the as-of state without trusting the party that held
it is the requirement, and a timestamp is not a mechanism for it.
On single reliance, your split is the correct one and worth writing down as you
stated it: the mandate is standing authority and reliance attaches to the
evidence artifact. The reason the reliance itself must be auditable as an
event, not just prevented by counter: with independent verifiers, each can
honestly rely once unless consumption is provable between them, and an auditor
reconciling an incident needs to know not only that evidence existed but which
execution spent it.
On delegation: fair, and I will own the reasoning. The one-sentence version:
standing authority that can be handed on without provable narrowing becomes
wider than what the principal signed, silently, at the second hop: which is the
T0-to-T1 gap reappearing between agents instead of between times. Happy to
compare your implemented bounds vocabulary against the narrowing dimensions in
draft-reece when you get to it; the mapping should be nearly mechanical, which
is itself evidence the requirements are converging.
Morgan
On Tuesday, August 25th, 2026 at 12:02 PM, Mohamad Khalil Yossif
<[email protected]> wrote:
>> 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
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
