| Internet-Draft | Boundary Jurisdiction Architecture | October 2026 |
| Watts | Expires 11 April 2027 | [Page] |
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 commitment boundaries and independently controlled revocation cuts, and specifies fail-closed semantics for evidence, authorization, delegation, and revocation closure.¶
This RFCXML source is an archive working draft. It is not represented as submitted, adopted, or endorsed by the IETF.¶
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 11 April 2027.¶
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.¶
Agentic and delegated systems can create, cache, exchange, and exercise authority through multiple services. A revocation request can invalidate one credential while consequential paths remain available through derived credentials, asynchronous queues, pre-authorized work, 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. This document therefore separates capability, evidence, authorization, enforcement, and execution as distinct states.¶
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.¶
The set of principals whose consequential authority derives from an untrusted or adaptively controlled root.¶
A resource or state transition whose exercise can create a material external effect.¶
The first state after which a requested action can no longer be reliably revoked by the registered control plane.¶
A declared set of independently controlled capability edges whose removal disconnects all registered paths from the untrusted closure to all registered commitment boundaries.¶
A bounded claim that no registered prospective consequential path remains reachable after the declared propagation bound.¶
A deployment is modeled as a time-indexed directed graph G_t=(V_t,E_t). Nodes represent principals, services, credentials, queues, commitment boundaries, and resources. Edges represent enabled capabilities.¶
Each edge SHOULD bind at least: source principal, destination resource, operation, scope, issuer, subject, start time, expiry, parent grant, revocation identifier, risk class, and provenance reference.¶
An actionable path exists only when every edge on the path is enabled at the evaluation time. Implementations MUST distinguish a path that exists structurally from a path that is presently enabled.¶
A registered cut K is structurally valid only when every path from every authority-derived untrusted principal to every registered commitment boundary intersects K. A validator SHOULD check this property by computing the authority-derived descendant closure, removing K, and verifying that no commitment boundary remains reachable.¶
A closure claim is invalid if the sink set, the cut set, or the NORMAL path inventory is absent. This prevents a vacuous universal-path statement from being treated as evidence of enforcement completeness.¶
Let t_r be the time a revocation is requested and T_prop the registered upper bound for revocation propagation. A system MUST NOT report prospective closure before the enforcement condition is effective at t_effective=t_r+T_prop, unless it has an independently justified earlier effective time.¶
Within the declared model, prospective consequential authority is closed after t_effective only if: all paths to commitment boundaries intersect independently controlled cut edges; derived capabilities inherit revocation; deferred effects are represented; cut enforcers fail closed; untrusted principals cannot create a bypass outside the registered graph; and the measured propagation condition is satisfied.¶
Closure is model-relative. It does not establish the absence of every physically possible communication or actuation channel.¶
Evidence MAY flow from untrusted computation toward an authorization service. Untrusted computation MUST NOT have arbitrary write authority over authorization state. Authority returns only through bounded capability objects issued by an authorization principal and enforced by an independent capability gate.¶
A grant SHOULD bind principal, resource, permitted operations, scope, budget, expiry, policy digest, nonce, parent grant, and issuer signature or equivalent integrity protection.¶
Delegated authority MUST be representable as a derivation relation. Revoking a parent grant MUST NOT leave a descendant grant enabled after the profile's propagation bound unless the descendant is explicitly independent under the registered policy.¶
Implementations SHOULD inventory cached bearer credentials, presigned resource locators, leases, long-lived sessions, queues, retry workers, scheduled jobs, and remote delegates as potential authority descendants or deferred-effect paths.¶
A deployment MAY issue a closure receipt. A receipt SHOULD identify the authority epoch, root revocation identifier, graph/profile version, cut-set digest, sink-set digest, completion time, coverage statement, unresolved paths, evidence digest, and receipt status.¶
Permitted statuses are REQUESTED, PROPAGATING, CLOSED, PARTIAL, FAILED, and UNKNOWN. CLOSED MUST NOT be emitted if a required path is unresolved or a required verifier returns an indeterminate result.¶
Missing topology information, stale graph state, failed monitoring, unverifiable policy state, or an unmodeled consequential path MUST NOT silently promote a revocation to CLOSED. Profiles SHOULD map such conditions to PARTIAL, FAILED, or UNKNOWN.¶
Threats include stale replicas, replayed grants, authorization-cache divergence, race conditions, queue persistence, compromised enforcement points, cut-set incompleteness, confused-deputy delegation, and topology omissions. A cut edge controlled by the same untrusted principal whose authority it is meant to constrain does not provide independent enforcement.¶
Cryptographic integrity protects representation and provenance but does not establish graph completeness or correct policy. Operational closure requires both structural validation and measured enforcement behavior.¶
Capability graphs and closure receipts can reveal organizational topology and principal relationships. Deployments SHOULD minimize exposed topology, use opaque identifiers when possible, and avoid embedding unnecessary personal or sensitive data in receipts.¶
This document has no IANA actions.¶