Boundary Jurisdiction Architecture for Agentic and Delegated Systems
draft-watts-boundary-jurisdiction-architecture-01

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", <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  IETF, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
              Words", <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC7009]  IETF, "OAuth 2.0 Token Revocation",
              <https://www.rfc-editor.org/rfc/rfc7009>.

   [RFC8785]  IETF, "JSON Canonicalization Scheme (JCS)",
              <https://www.rfc-editor.org/rfc/rfc8785>.

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]