Amr, Jijie, Yes, that is the interpretation I intended.
The enforcement point is *per effect-capable path*, while the closure property is system-wide. If the same protected effect can be reached through two disjoint paths, then each path needs a verifier whose successful admission is necessary for the effect to complete through that path. So, for paths P1 and P2: P1 -> verifier V1 -> effect P2 -> verifier V2 -> effect there does not need to be one physical verifier common to both paths. The system-level requirement is instead: every path capable of producing the protected effect MUST cross a qualifying enforcement boundary before that effect can complete. That also gives the bypass test its system meaning. If any alternate path can produce the same protected effect without crossing such a verifier, enforcement is not closed for that effect. So I would distinguish: - *boundary identification:* per path; and - *anti-bypass / closure invariant:* across all effect-capable paths. This is also why I would avoid defining the boundary by component identity. It is a role in the effectuation path. Different paths may realize that role at different components or layers. Your two-path example is useful because it catches an ambiguity in the shorter formulation. I agree that -02 should make the per-path aspect explicit. And yes, please feel free to name me for the boundary definition and bypass formulation. I am comfortable with attribution. Best, Sangam On Wed, 2 Sep 2026 at 6:00 PM, Amr Hassan <[email protected]> wrote: > Sangam, Jijie, > > Both points taken. > > On the four predicates: the correction is right and my wording was wrong. I > offered actionClass as vocabulary for "class grant" in a way that reads as > collapsing tool identity into r/w/x, and that is not a distinction worth > losing. read_file("/etc/shadow") being simultaneously permitted by tool > identity, classed r, and unrejectable on path subset is exactly the case > that > needs three names rather than one. > > For the record the draft itself does not make that error: the layering > section places tool name and argument set at the per-invocation layer, and > says a floor constrains a category of action across a chain, "not the > arguments of any single call". The fix is to my email, not to the text. I > support the four-predicate list for the write-up — a denial naming which > predicate failed is strictly better than four things sharing the words > "policy denial". > > On placement, I am adopting the rule, and I would like to cite it. Jijie > proposed the host wrap; Sangam gave it a definition: > > The relevant boundary is the first point whose successful admission is > necessary for the effect to occur. > > That is better than what -01 has. My subsection says admission is not > performed by a harness or orchestration layer upstream of the boundary. > That > is not wrong, but it never says what makes something the boundary, so it > leaves a verifier author to decide by intuition. The formulation above > decides it, and the bypass test makes it checkable: "if another path can > produce the same effect without crossing the verifier, the claimed boundary > is not yet load-bearing." A normative section needs a test two implementers > can run and agree on. Mine did not have one. > > It also preserves the failure the subsection was written to close, so I can > take it without loosening anything: a harness that merely knows about a > floor, where the resource stays reachable by another path, fails the bypass > test. The rule is a tightening with a definition attached. > > One drafting problem I will have to handle carefully, raised as my work and > not as an objection. "First point whose admission is necessary" is > unambiguous along a single path. Where a resource has two disjoint guarded > paths, no single point is necessary for the effect, so read strictly there > is > no boundary at all — while the bypass test gives the answer I think you > both > intend, which is that each path needs its own verifier. So the property is > per path, not per system, and -02 will have to say so explicitly or the two > halves of the rule can be read against each other. If you meant it per > system, tell me, because then I have it wrong. > > May I name you both for this, or would you prefer the citation without the > attribution? Either is fine; I would rather ask than assume. > > Amr > draft-hamr-oauth-agent-delegation-01 > On 9/2/26 2:19 PM, Sangam Das wrote: > > Amr, Jijie, > > Thanks. This helps, particularly the boundary definition. > > On placement, I mean your reading (i), with one qualification. > > For an in-process tool, if the host function table is the first boundary > that can actually admit or refuse the consequential invocation, then that > function-table boundary is the enforcement boundary. No network hop is > required. > > I would phrase the general rule as: > > The relevant boundary is the first point whose successful admission is > necessary for the effect to occur. > > So if a host wrapper validates the AIC and the protected function cannot > be reached except through that wrapper, the wrapper can be the boundary. If > the same function can still be invoked through another local path that > bypasses the wrapper, then the wrapper is only upstream defence-in-depth > and does not satisfy the property by itself. > > That is the placement point I was trying to express. “Boundary” should be > defined by effectuation dependency, not by whether a socket exists. > > On actionClass, I think there is one distinction worth preserving. > > I am happy to use r / w / x as the vocabulary for the action-class axis, > but I would not make it synonymous with the current AIC named-tool > allowlist. > > For example: > > AIC: > tools = ["read_file", "list_dir"] > > establishes a tool-identity predicate. > > Separately: > > read_file -> r > list_dir -> r > bash -> x > > establishes an action-class predicate. > > And separately again: > > read_file: > path-prefix = /tmp/ > > would establish an argument-subset predicate if such a field were actually > bound in the certificate. > > Those predicates answer different questions. > > read_file("/etc/shadow") can therefore simultaneously be: > > - permitted by tool identity; > - classed as r; > - not rejectable on path subset under the present vectors, because no > path constraint is bound. > > That last point is what I meant by saying the current named-tool > authorization behaves as a class grant for that tool. I was not intending > to collapse tool membership into the r/w/x consequence classification. > > So for the write-up I would now keep the predicates explicit: > > 1. tool identity; > 2. action class; > 3. argument subset, where present; and > 4. enforcement placement / necessary effect boundary. > > Then a denial can state exactly which predicate failed rather than using > “policy denial” for all four. > > And yes, I agree that for a purely local tool the absence of a network > credential boundary should not mean that no admissible enforcement boundary > exists. If the protected local dispatch is where the operation becomes > executable, that can be the boundary. > > That definition also makes the bypass test straightforward: if another > path can produce the same effect without crossing the verifier, the claimed > boundary is not yet load-bearing. > > Best, > > Sangam > > -- > Ciao, Amr > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
