> 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]
