Individual Submission D. Watts Internet-Draft Independent Researcher Intended status: Informational 11 October 2026 Expires: 14 April 2027 Boundary Jurisdiction Architecture for Agentic and Delegated Systems draft-watts-boundary-jurisdiction-architecture-01 Abstract This document describes a protocol-neutral architecture for separating possession of capability from jurisdiction over consequential authority boundaries. It models authority as reachability in a time-indexed capability graph, defines revocation cuts, and specifies fail-closed semantics for delegation and revocation closure. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Watts Expires 14 April 2027 [Page 1] Internet-Draft Boundary Jurisdiction Architecture for A October 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 3. Capability Graph Model . . . . . . . . . . . . . . . . . . . 3 4. Revocation-Dominating Cut . . . . . . . . . . . . . . . . . . 3 5. Revocation Closure Semantics . . . . . . . . . . . . . . . . 3 6. Authority Diode . . . . . . . . . . . . . . . . . . . . . . . 3 7. Delegation and Descendant Revocation . . . . . . . . . . . . 4 8. Closure Receipt . . . . . . . . . . . . . . . . . . . . . . . 4 9. Failure Semantics . . . . . . . . . . . . . . . . . . . . . . 4 10. Security Considerations . . . . . . . . . . . . . . . . . . . 4 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 13. Illustrative Conformance Checks . . . . . . . . . . . . . . . 5 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Agentic and delegated systems can create, cache, exchange, and exercise authority through multiple services. Revocation of one credential can leave consequential paths through derived credentials, queues, cached decisions, or delegated descendants. The governing principle is that possession of a capability does not imply jurisdiction over the boundary conditions that enable its consequential use. Capability, evidence, authorization, enforcement, and execution are distinct states. 2. Conventions and Terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals. Untrusted closure C is the set of principals whose consequential authority derives from an untrusted or adaptively controlled root. Consequential resource Q is a resource or state transition with an external effect. Commitment boundary B_Q is the first state after which an action cannot reliably be revoked by the registered control plane. Revocation cut K is a declared set of independently controlled capability edges disconnecting registered paths from C to commitment boundaries. Closure is a bounded prospective claim relative to a documented inventory. Watts Expires 14 April 2027 [Page 2] Internet-Draft Boundary Jurisdiction Architecture for A October 2026 3. Capability Graph Model A deployment is modeled as a time-indexed directed graph G_t=(V_t,E_t) with nodes for principals, services, credentials, queues, commitment boundaries, and resources, and edges for enabled capabilities. Each edge SHOULD bind source, destination, operation, scope, issuer, subject, start, expiry, parent grant, revocation identifier, risk class, and provenance. Implementations MUST distinguish structural paths from paths enabled at evaluation time. 4. Revocation-Dominating Cut A registered cut K is structurally valid only if every registered path from an authority-derived untrusted principal to every registered commitment boundary intersects K. A validator SHOULD compute the descendant closure, remove K, and check that no boundary remains reachable. A closure claim is invalid if the sink set, cut set, or path inventory is absent. Empty inventory MUST NOT be interpreted as proof of complete coverage. 5. Revocation Closure Semantics Let t_r denote the request time and T_prop the declared upper bound on propagation. A system MUST NOT report prospective closure before enforcement becomes effective at t_r+T_prop, absent independently justified earlier effective time. Prospective closure requires independently controlled cut enforcement, descendant revocation, deferred-effect inventory, fail- closed enforcement, no known bypass outside the registered graph, and measured propagation. Closure is model-relative and does not prove absence of all physical channels. 6. Authority Diode Evidence MAY flow from untrusted computation to an authorization service. Untrusted computation MUST NOT have arbitrary write access to authorization state. Authority returns only via bounded grants issued by an authorization principal and enforced by an independent gate. A grant SHOULD bind principal, resource, operations, scope, budget, expiry, policy digest, nonce, parent grant, and issuer integrity protection. Watts Expires 14 April 2027 [Page 3] Internet-Draft Boundary Jurisdiction Architecture for A October 2026 7. Delegation and Descendant Revocation Delegation MUST be representable as a derivation relation. Revoking a parent MUST NOT leave descendants enabled beyond the specified propagation bound unless independently authorized under recorded policy. Inventories SHOULD cover cached bearer credentials, presigned URLs, leases, persistent sessions, queues, retry workers, scheduled jobs, and remote delegates. 8. Closure Receipt A closure receipt SHOULD include authority epoch, root revocation identifier, graph/profile version, cut-set digest, sink-set digest, completion time, coverage statement, unresolved paths, evidence digest, and status. Permitted statuses are REQUESTED, PROPAGATING, CLOSED, PARTIAL, FAILED, and UNKNOWN. CLOSED MUST NOT be emitted if required paths are unresolved or a verifier is indeterminate. 9. Failure Semantics Missing topology, stale graph state, monitoring failures, unverifiable policy state, or unmodeled consequential paths MUST NOT silently promote a claim to CLOSED; return PARTIAL, FAILED, or UNKNOWN as appropriate. 10. Security Considerations Threats include stale replicas, replayed grants, cache divergence, races, queue persistence, compromised enforcement, incomplete cut sets, confused-deputy delegation, and missing topology. A cut controlled by the untrusted authority cannot establish independent enforcement. Cryptographic integrity provides representation and provenance integrity, not graph completeness or policy correctness. Operational closure requires structural validation and measured enforcement. 11. Privacy Considerations Capability graphs and closure receipts can expose organizational topology and principal relationships. Implementations SHOULD minimize topology disclosure and use opaque identifiers. Watts Expires 14 April 2027 [Page 4] Internet-Draft Boundary Jurisdiction Architecture for A October 2026 12. IANA Considerations This document requests no IANA actions. 13. Illustrative Conformance Checks A verifier MUST NOT issue CLOSED for a registered path that remains enabled after the propagation bound. A verifier MUST NOT issue CLOSED when its commitment-boundary inventory is empty or unavailable without separately documented proof that this is the complete expected inventory. A verifier SHOULD test queued work, descendant grants, replayed tokens, stale cache state, and independently administered cut enforcement. These are proposed tests, not assertions that implementations have passed them. 14. References [RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement Levels", . [RFC8174] IETF, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", . [RFC7009] IETF, "OAuth 2.0 Token Revocation", . [RFC8785] IETF, "JSON Canonicalization Scheme (JCS)", . Author's Address Deonte Watts Independent Researcher San Francisco, CA United States of America Email: deonte@goodshyt.fun URI: https://orcid.org/0009-0005-8586-3650 Watts Expires 14 April 2027 [Page 5]