Hi Sangam, I mean the first: durable custody and prevention of bypass are part of the intended execution model. The deployment has to implement and demonstrate them; they are not optional assumptions outside the claim.
The published AEB -04 makes that distinction explicitly. Section 5.8 requires an atomic durable reservation or consumption before invocation. Section 8 permits a complete-mediation claim only when the protected system rejects material alternate paths or subjects them to an equivalent boundary: https://www.ietf.org/archive/id/draft-schrock-action-evidence-boundary-04.html#section-8 In practice, that means controlling the credentials and interfaces that can cause the protected effect, sharing the relevant reservation state across every executor that can reach it, and retaining unresolved attempts through recovery. A wrapper that an agent can bypass with another credential does not meet that claim. The AuthZEN harness establishes only the narrower single-instance behavior. It is not evidence that those deployment conditions have been met. So I think we are aiming at the same invariant within a declared protected boundary. The remaining qualification is the remote provider: AEB does not make our local transaction atomic with its effect, or prove that the provider physically did what it reported. That is why post-dispatch uncertainty stays unresolved until matching authoritative evidence is available. Best, Iman _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
