Hi Iman, Thank you — this is very helpful, and this is substantially closer to the boundary I was trying to understand.
I looked at the pinned profile. The pre-dispatch reservation, exact expected-action binding, refusal of a changed beneficiary before provider entry, and reconciliation without re-invoking execution are particularly relevant. I also appreciate the scope statement. The distinction that caught my attention is the one-live-instance boundary: the harness demonstrates admission and single-attempt behavior within that executor, while durable custody across restart, coverage of every execution path, and prevention of bypass are left as production-integration requirements. That gets very close to the question I am trying to isolate. For me, the stronger invariant is not merely that a conforming executor checks the exact action before calling the provider. It is that the consequential act is structurally unable to complete through any covered path unless the act-bound authority/state required for that exact effect is successfully verified or consumed at the effectuation boundary. So I would be interested in one distinction: When the README says production integration must provide durable atomic custody shared by every execution path and prevent bypass, do you view that as part of the intended EMILIA execution model itself, with this harness simply not yet proving it, or as a deployment responsibility outside the protocol/profile? That answer would help me determine whether we are describing essentially the same downstream invariant at different maturity levels, or whether the overlap is limited to the pre-dispatch admission mechanism demonstrated by this profile. Thanks again for sharing the pinned runnable version. Regards, Sangam On Tue, 15 Sep 2026 at 8:20 PM, Iman Schrock <[email protected]> wrote: > Hi Sangam, > > I can offer the EMILIA reference profile for that comparison. We shared it > on the AuthZEN list, and the runnable version is pinned here: > > > https://github.com/emiliaprotocol/emilia-protocol/tree/fd8378671ab863a47f35e18503e5ab1929ae2fcd/conformance/composition/authzen-coaz-mcp-aeb-v0.1 > > The executor checks the full action against a separately signed > expected-action record pinned by its owner. It reserves one attempt before > entering the provider callback. A changed beneficiary is refused before > that entry, even when the toy PDP returns the same coarse allow. > > After entry, a timeout leaves the reservation unresolved. Reconciliation > verifies signed evidence for the original provider and action; it cannot > invoke execution again. The admission check therefore happens before > dispatch. > > This is a single-live-instance harness. It does not establish durable > custody across restarts or prove that a deployment has no bypass. It uses a > toy PDP and test keys, and is an EMILIA proposal, not an adopted AuthZEN > profile. The README includes the commands to rerun the cases. > > Best, > Iman >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
