Individual Submission S. Das Internet-Draft Independent Intended status: Informational 16 September 2026 Expires: 20 March 2027 Authorized Here, Not Authorized There: Jurisdiction-Bound Execution Finality for Cross-Border and Sovereign Systems draft-das-jurisdiction-bound-execution-finality-00 Abstract Modern cloud, AI, financial, telecom, and critical-infrastructure systems increasingly operate across regions, sovereign clouds, multi- cloud environments, and distributed workload chains. A high- consequence authorization failure can occur even when identity, cryptography, policy evaluation, and platform attestation all succeed: the same Candidate Act can become effective under a jurisdictional or governance context different from the one under which it was authorized. Workload migration, disaster-recovery failover, cross-region queues, service rerouting, remote administration, control-plane changes, destination substitution, key- control changes, or downstream processing can convert an authorization that was valid under context J1 into an effect occurring under context J2. No token forgery or cryptographic break is required. Existing mechanisms already address important parts of this problem. OAuth Rich Authorization Requests [RFC9396] can carry fine-grained authorization details; OAuth Resource Indicators [RFC8707] bind authorization requests to protected resources; JWT [RFC7519] can carry signed application claims; WIMSE [WIMSE-ARCH] provides workload-identity and security-context architecture for multi-system environments; RATS [RFC9334] provides Evidence, Verifiers, and Attestation Results; and SCITT [RFC9943] provides signed statements, transparency, and receipts. Industry systems also provide concrete sovereignty and data-boundary controls: Microsoft documents its EU Data Boundary [MS-EUDB], AWS operates the European Sovereign Cloud [AWS-ESC], and Google Cloud provides Sovereign Controls by Partners [GOOGLE-SOV]. The residual gap exists only where jurisdiction is treated as descriptive metadata, inferred from weak location signals, enforced only at deployment time, or checked at an upstream boundary while the actual consequence can later move through another region, operator, administrative path, processing service, destination, failover route, or control domain. A workload can be correctly authenticated and a platform correctly attested while the current effectuation context no Das Expires 20 March 2027 [Page 1] Internet-Draft Jurisdiction-Bound Finality September 2026 longer satisfies the deployment's sovereignty rule. Likewise, storing data in one region does not by itself prove where it is processed, remotely administered, decrypted, transmitted, or finally disclosed. This document proposes a jurisdiction-bound execution-finality invariant. A Candidate Act remains in a Non-Effective State until the Finality Sink establishes a current, authoritative Jurisdiction Execution Context (JEC) for the exact act and verifies that the present effectuation environment satisfies the deployment-defined Jurisdiction Policy. The JEC can combine workload identity, compute and processing domain, storage location, destination, operator/ control domain, key-control domain, remote-access state, attested trust state, and policy generation. JEC is an architectural role, not a mandated token format. Prevention is claimed only when the jurisdiction policy, evidence sources, current effectuation context, exact-act binding, state continuity, and consequence path are load-bearing and non-bypassable. If the deployment relies only on GeoIP, region labels, advisory metadata, best-effort routing, post-hoc audit, or incomplete path coverage, the result is mitigation or evidence rather than the same prevention guarantee. The architecture enforces machine-readable jurisdiction or compliance policy supplied by an authoritative deployment source; it does not determine what law applies or provide a legal conclusion. Microsoft, AWS, Google Cloud, NVIDIA, and Arm are discussed only as complementary industrial examples or potential integration points. The document does not assert vulnerability, deficiency, non- conformance, affiliation, or endorsement by any named organization. A deployment that already makes its required jurisdictional constraints current, non-bypassable, and mandatory at the actual consequence boundary already satisfies the core property. Criticism, corrections, counterexamples, prior-art pointers, implementation experience, and evidence of equivalent existing mechanisms are explicitly invited. 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/. Das Expires 20 March 2027 [Page 2] Internet-Draft Jurisdiction-Bound Finality September 2026 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 20 March 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1. Vulnerability: Authorization Can Survive a Jurisdiction Change . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Existing Mechanisms Already Address Important Parts . . . 8 1.3. Why the Residual Gap Can Remain . . . . . . . . . . . . . 9 1.4. What This Architecture Introduces . . . . . . . . . . . . 9 2. Conventions and Requirements Language . . . . . . . . . . . . 10 3. Direct Question: What Threat Does This Architecture Solve? . 10 4. Motivating Scenario: Authorized in J17, Effectuated in J18 . 11 5. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Jurisdiction Is Not Merely Location . . . . . . . . . . . 11 5.2. Data Residency Is Not Complete Sovereignty . . . . . . . 12 5.3. Identity Is Not Jurisdiction . . . . . . . . . . . . . . 12 5.4. Attestation Is Not Legal Classification . . . . . . . . . 12 5.5. Audit Is Not Prevention . . . . . . . . . . . . . . . . . 12 6. Threat Model and Assurance Scope . . . . . . . . . . . . . . 12 6.1. Adversary Capabilities . . . . . . . . . . . . . . . . . 13 6.2. Threat Severity and Applicability . . . . . . . . . . . . 13 6.3. Baseline Jurisdiction-Finality Profile . . . . . . . . . 13 6.4. High-Assurance Jurisdiction-Finality Profile . . . . . . 13 6.5. Trusted Roots and Limits . . . . . . . . . . . . . . . . 14 7. Design Goals and Non-Goals . . . . . . . . . . . . . . . . . 14 8. Existing Mechanisms and the Proposed Delta . . . . . . . . . 14 8.1. OAuth Rich Authorization Requests . . . . . . . . . . . . 14 8.2. OAuth Resource Indicators . . . . . . . . . . . . . . . . 15 Das Expires 20 March 2027 [Page 3] Internet-Draft Jurisdiction-Bound Finality September 2026 8.3. JWT and Application Claims . . . . . . . . . . . . . . . 15 8.4. WIMSE . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.5. RATS . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.6. SCITT . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.7. Cloud Sovereignty and Data-Boundary Controls . . . . . . 16 8.8. Comparison Summary . . . . . . . . . . . . . . . . . . . 16 8.9. What Is New in This Document . . . . . . . . . . . . . . 17 9. Prevention and Mitigation Property . . . . . . . . . . . . . 18 9.1. Prevention Profile . . . . . . . . . . . . . . . . . . . 18 9.2. Mitigation or Evidence Profile . . . . . . . . . . . . . 18 9.3. Unknown Jurisdiction Context . . . . . . . . . . . . . . 19 10. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Jurisdiction Execution Context (JEC) . . . . . . . . . . . . 19 11.1. Typed Jurisdiction Dimensions . . . . . . . . . . . . . 20 11.2. Dimension State and UNKNOWN Semantics . . . . . . . . . 21 11.3. Jurisdiction Evidence Source Model . . . . . . . . . . . 21 11.4. Evidence-Assurance Ordering . . . . . . . . . . . . . . 21 11.5. Multi-Source Corroboration . . . . . . . . . . . . . . . 22 12. Multi-Dimensional Jurisdiction Policy . . . . . . . . . . . . 23 12.1. Data-Residency Profile . . . . . . . . . . . . . . . . . 23 12.2. Processing-Sovereignty Profile . . . . . . . . . . . . . 23 12.3. Operational-Sovereignty Profile . . . . . . . . . . . . 23 12.4. Strict Effectuation Profile . . . . . . . . . . . . . . 23 12.5. Formal Jurisdiction Policy . . . . . . . . . . . . . . . 23 12.6. Jurisdiction Rule Composition . . . . . . . . . . . . . 24 12.7. Alternative and Conditional Sovereignty Rules . . . . . 24 12.8. Jurisdiction-Context Equivalence . . . . . . . . . . . . 25 13. Formal Mathematical Model . . . . . . . . . . . . . . . . . . 26 13.1. Bounded Prevention Argument . . . . . . . . . . . . . . 27 13.2. Formal Jurisdiction Evidence Predicate . . . . . . . . . 27 13.3. Dimension Validity . . . . . . . . . . . . . . . . . . . 27 13.4. Cross-Dimension Context Consistency . . . . . . . . . . 27 13.5. Expanded Jurisdiction Applicability . . . . . . . . . . 28 13.6. Policy and Context Generation Vector . . . . . . . . . . 28 13.7. Context-Transition Applicability . . . . . . . . . . . . 29 13.8. Migration and Failover Rule . . . . . . . . . . . . . . 29 13.9. UNKNOWN and Partial-Evidence Semantics . . . . . . . . . 29 13.10. Coupling to Consequence-Path Completeness . . . . . . . 29 13.11. Verification-to-Commit Serialization . . . . . . . . . . 30 13.12. Strict Prevention Invariant . . . . . . . . . . . . . . 30 13.13. Expanded Bounded Prevention Proof . . . . . . . . . . . 31 14. Jurisdiction Generation and State Continuity . . . . . . . . 31 15. Exact-Act Binding . . . . . . . . . . . . . . . . . . . . . . 34 16. Destination and Recipient Binding . . . . . . . . . . . . . . 34 17. Operator, Control-Plane, and Key-Control Binding . . . . . . 34 18. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 34 19. Solution Architecture . . . . . . . . . . . . . . . . . . . . 36 19.1. Resolve the Jurisdiction Policy . . . . . . . . . . . . 37 Das Expires 20 March 2027 [Page 4] Internet-Draft Jurisdiction-Bound Finality September 2026 19.2. Establish Current JEC . . . . . . . . . . . . . . . . . 37 19.3. Bind JEC to Workload, Sink, and Generation . . . . . . . 37 19.4. Remain Non-Effective . . . . . . . . . . . . . . . . . . 37 19.5. Verify and Commit at the Finality Sink . . . . . . . . . 37 19.6. Architecture and Evidence Flow Diagrams . . . . . . . . 37 20. Illustrative Pseudocode . . . . . . . . . . . . . . . . . . . 39 20.1. Resolve the Jurisdiction Policy . . . . . . . . . . . . 40 20.2. Select Required JEC Dimensions . . . . . . . . . . . . . 40 20.3. Collect Evidence for Each Required Dimension . . . . . . 40 20.4. Verify One Dimension's Evidence . . . . . . . . . . . . 41 20.5. Assemble the Current JEC . . . . . . . . . . . . . . . . 42 20.6. Verify Cross-Dimension Context Consistency . . . . . . . 43 20.7. Evaluate the Multi-Dimensional Jurisdiction Policy . . . 44 20.8. Handle UNKNOWN and Explicit Fallback Profiles . . . . . 45 20.9. Handle Migration, Failover, and Context Transitions . . 45 20.10. Validate Context Equivalence . . . . . . . . . . . . . . 46 20.11. Verify Jurisdiction Enforcement Across Effectuation Paths . . . . . . . . . . . . . . . . . . . . . . . . . 46 20.12. Preserve JEC References Across Multi-Hop Systems . . . . 46 20.13. Protected Jurisdiction Finalization . . . . . . . . . . 47 20.14. Select an Emergency or Break-Glass Profile . . . . . . . 48 20.15. Crash-Safe Recovery . . . . . . . . . . . . . . . . . . 49 20.16. Generate a Reviewable Jurisdiction Failure Explanation . . . . . . . . . . . . . . . . . . . . . . 49 21. Multi-Hop and WIMSE Composition . . . . . . . . . . . . . . . 50 22. RATS-Based Jurisdiction Context . . . . . . . . . . . . . . . 52 23. SCITT-Based Policy and Configuration Evidence . . . . . . . . 53 24. Alternate-Path Resistance . . . . . . . . . . . . . . . . . . 53 25. Attack Analysis . . . . . . . . . . . . . . . . . . . . . . . 54 25.1. Forged or Advisory Region Label . . . . . . . . . . . . 54 25.2. Stale Jurisdiction Evidence . . . . . . . . . . . . . . 54 25.3. Disaster-Recovery Failover . . . . . . . . . . . . . . . 55 25.4. Destination Substitution . . . . . . . . . . . . . . . . 55 25.5. Remote Administration Outside Policy . . . . . . . . . . 55 25.6. Key-Control Change . . . . . . . . . . . . . . . . . . . 55 25.7. Cross-Region Queue or Worker . . . . . . . . . . . . . . 55 25.8. Alternate Path Around Jurisdiction Enforcement . . . . . 55 26. High-Assurance Enforcement . . . . . . . . . . . . . . . . . 55 27. Deployment Patterns . . . . . . . . . . . . . . . . . . . . . 57 27.1. Single Sovereign Region . . . . . . . . . . . . . . . . 57 27.2. Multi-Region with Policy-Constrained Failover . . . . . 57 27.3. Sovereign plus Global Cloud . . . . . . . . . . . . . . 57 27.4. Hybrid or Edge Deployment . . . . . . . . . . . . . . . 58 28. Performance and Availability . . . . . . . . . . . . . . . . 58 29. Relationship to OAuth . . . . . . . . . . . . . . . . . . . . 58 30. Relationship to WIMSE . . . . . . . . . . . . . . . . . . . . 58 31. Relationship to RATS . . . . . . . . . . . . . . . . . . . . 59 32. Relationship to SCITT . . . . . . . . . . . . . . . . . . . . 59 Das Expires 20 March 2027 [Page 5] Internet-Draft Jurisdiction-Bound Finality September 2026 33. Industrial Relevance and Sovereign-Cloud Alignment . . . . . 59 33.1. Government and Sovereign Cloud . . . . . . . . . . . . . 59 33.2. AI and Confidential Inference . . . . . . . . . . . . . 59 33.3. Financial, Payment, and CBDC Systems . . . . . . . . . . 59 33.4. Telecom and Critical Infrastructure . . . . . . . . . . 59 34. Complementary Industrial Alignment . . . . . . . . . . . . . 59 34.1. Microsoft EU Data Boundary . . . . . . . . . . . . . . . 60 34.2. AWS European Sovereign Cloud . . . . . . . . . . . . . . 60 34.3. Google Cloud Sovereign Controls by Partners . . . . . . 60 34.4. NVIDIA Attestation and Arm CCA . . . . . . . . . . . . . 60 34.5. Non-Endorsement and Non-Criticism . . . . . . . . . . . 60 35. Required Classes of Test Vectors . . . . . . . . . . . . . . 61 36. Questions to the IETF Community . . . . . . . . . . . . . . . 62 37. Potential IETF Discussion Venues . . . . . . . . . . . . . . 63 37.1. WIMSE . . . . . . . . . . . . . . . . . . . . . . . . . 64 37.2. RATS . . . . . . . . . . . . . . . . . . . . . . . . . . 64 37.3. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . 64 37.4. SCITT . . . . . . . . . . . . . . . . . . . . . . . . . 64 37.5. DISPATCH . . . . . . . . . . . . . . . . . . . . . . . . 64 37.6. SAAG . . . . . . . . . . . . . . . . . . . . . . . . . . 64 37.7. No Presumed Home . . . . . . . . . . . . . . . . . . . . 64 38. Relationship to Other Execution-Finality Internet-Drafts . . 64 39. Public Implementations and Companion Engineering Material . . 66 40. Security Considerations . . . . . . . . . . . . . . . . . . . 66 40.1. False or Advisory Jurisdiction Label . . . . . . . . . . 66 40.2. Stale Region Evidence . . . . . . . . . . . . . . . . . 66 40.3. Workload Migration . . . . . . . . . . . . . . . . . . . 66 40.4. Failover and Disaster Recovery . . . . . . . . . . . . . 66 40.5. Remote Administration . . . . . . . . . . . . . . . . . 67 40.6. Control-Plane/Data-Plane Mismatch . . . . . . . . . . . 67 40.7. Storage Versus Processing Confusion . . . . . . . . . . 67 40.8. Key-Control Mismatch . . . . . . . . . . . . . . . . . . 67 40.9. Destination or Recipient Change . . . . . . . . . . . . 67 40.10. GeoIP Spoofing and Inaccuracy . . . . . . . . . . . . . 67 40.11. Cloud-Region Metadata Forgery . . . . . . . . . . . . . 67 40.12. Compromised Scheduler or Orchestrator . . . . . . . . . 67 40.13. Compromised Host . . . . . . . . . . . . . . . . . . . . 67 40.14. Compromised Jurisdiction Evidence Source . . . . . . . . 68 40.15. Valid Attestation but Insufficient Semantics . . . . . . 68 40.16. Jurisdiction-Policy Rollback . . . . . . . . . . . . . . 68 40.17. Context-Evidence Replay . . . . . . . . . . . . . . . . 68 40.18. Cross-Tenant or Cross-Workload Reuse . . . . . . . . . . 68 40.19. Multi-Hop Context Loss . . . . . . . . . . . . . . . . . 68 40.20. Alternate Effectuation Path . . . . . . . . . . . . . . 68 40.21. Replication and Direct Storage Paths . . . . . . . . . . 68 40.22. Queue or Worker Relocation . . . . . . . . . . . . . . . 69 40.23. Service-Mesh or Routing Change . . . . . . . . . . . . . 69 40.24. Emergency and Break-Glass Paths . . . . . . . . . . . . 69 Das Expires 20 March 2027 [Page 6] Internet-Draft Jurisdiction-Bound Finality September 2026 40.25. Jurisdiction-Policy Authority Compromise . . . . . . . . 69 40.26. Legal or Policy Misconfiguration . . . . . . . . . . . . 69 40.27. Fail-Open on Unknown Context . . . . . . . . . . . . . . 69 40.28. Denial of Service . . . . . . . . . . . . . . . . . . . 69 40.29. Jurisdiction and Location Privacy . . . . . . . . . . . 69 40.30. Correlation . . . . . . . . . . . . . . . . . . . . . . 70 40.31. Physical-Site Falsification . . . . . . . . . . . . . . 70 40.32. Topology Drift . . . . . . . . . . . . . . . . . . . . . 70 40.33. Crash Consistency . . . . . . . . . . . . . . . . . . . 70 40.34. Audit-Only Enforcement . . . . . . . . . . . . . . . . . 70 40.35. Technical Enforcement Is Not Legal Advice . . . . . . . 70 41. Privacy Considerations . . . . . . . . . . . . . . . . . . . 70 42. Criticism, Corrections, and Review Invited . . . . . . . . . 71 43. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 44. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 71 45. Normative References . . . . . . . . . . . . . . . . . . . . 72 46. Informative References . . . . . . . . . . . . . . . . . . . 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 75 1. Introduction 1.1. Vulnerability: Authorization Can Survive a Jurisdiction Change A system can authenticate a workload correctly, evaluate authorization correctly, establish an encrypted channel, verify a valid credential, and attest a healthy execution environment, yet still allow the resulting act to become effective under a jurisdictional or governance context that was not authorized for that act. The central failure is continuity. Authorization may be issued while the workload is in one region or sovereign context, but the actual effect can occur later after migration, failover, rerouting, destination change, remote administrative intervention, key-control change, or downstream processing. t0 t1 t2 | | | | Candidate C authorized | workload / route / | protected | under context J17 | control context changes | effect K | | to J18 | |--------------------------|--------------------------| | v EFFECT under J18 If J18 is not permitted for C, a valid authorization at t0 MUST NOT silently survive to t2. Das Expires 20 March 2027 [Page 7] Internet-Draft Jurisdiction-Bound Finality September 2026 Figure 1: Authorization survives a jurisdiction change This attack does not necessarily require token forgery, identity theft, broken encryption, or compromised attestation. The earlier authorization can remain authentic while the context that made the act permissible has changed. 1.2. Existing Mechanisms Already Address Important Parts OAuth Rich Authorization Requests can carry fine-grained authorization data [RFC9396]. A deployment can define authorization- detail fields for region, sovereign domain, destination, data handling, or other jurisdiction-sensitive constraints. OAuth Resource Indicators identify the protected resource for which access is requested [RFC8707]. JWT can carry signed application-specific claims such as issuer, audience, and private context claims [RFC7519]. WIMSE addresses workload identity and security context in multi- system environments [WIMSE-ARCH]. RATS supplies a standardized architecture for Evidence, Verifiers, Attestation Results, Reference Values, and Relying Party decisions [RFC9334]. SCITT supplies signed statements, transparency, registration, and verifiable receipts [RFC9943]. Industrial platforms likewise already implement substantial sovereignty controls. Microsoft documents the EU Data Boundary and continuing-transfer cases [MS-EUDB] [MS-EUDB-TRANSFERS]. AWS documents the European Sovereign Cloud as an independent cloud environment designed for European sovereignty requirements [AWS-ESC]. Google Cloud documents partner-operated Sovereign Controls including data-residency controls, external key management, and local supervision [GOOGLE-SOV]. These mechanisms are not treated as deficient. The ability to express region or jurisdiction constraints, attest a workload, constrain data residency, or operate a sovereign cloud is not the proposed novelty. If a deployment already enforces all required jurisdiction dimensions at the actual non-bypassable consequence boundary, it already satisfies the core property described here. Das Expires 20 March 2027 [Page 8] Internet-Draft Jurisdiction-Bound Finality September 2026 1.3. Why the Residual Gap Can Remain The residual gap appears when the enforcement boundary is narrower than the policy semantics. A signed claim such as "region=EU" can be authentic while the downstream processing path has moved. A workload identity can still name the correct workload while that workload runs in a disallowed control domain. A platform can be correctly attested while the destination, operator, remote-access context, or data- egress path violates the deployment's jurisdiction policy. Storage residency is also not automatically equivalent to complete processing sovereignty. Data can remain at rest in one region while being remotely accessed, processed, decrypted, transmitted, or disclosed through another operational context. Microsoft's own EU Data Boundary documentation distinguishes storage/processing commitments from documented continuing transfers and remote-access scenarios [MS-EUDB] [MS-EUDB-TRANSFERS]. This is an example of why a useful technical model must define the exact policy dimensions rather than reduce jurisdiction to one country code. RATS can provide trustworthy technical evidence, but an Attestation Result is not itself a legal determination. OAuth RAR can express jurisdiction-sensitive authorization detail, but expression does not prove that the current downstream effectuation environment still satisfies the detail. WIMSE can identify workloads across systems, but workload identity is not automatically operational or geographic jurisdiction. SCITT can prove that a statement was signed or registered, but that statement is not automatically a load-bearing effectuation rule. 1.4. What This Architecture Introduces The proposed contribution is deliberately narrow: jurisdictional authority is treated as an effectuation-time property of the exact Candidate Act. A Candidate Act remains non-effective until the Finality Sink establishes a current Jurisdiction Execution Context and verifies that the present effectuation environment satisfies the applicable machine-readable Jurisdiction Policy. * Define the jurisdiction-sensitive Candidate Act and Protected Consequence. * Define the deployment's authoritative Jurisdiction Policy instead of inferring law from geography. * Establish a current Jurisdiction Execution Context from trusted evidence sources. Das Expires 20 March 2027 [Page 9] Internet-Draft Jurisdiction-Bound Finality September 2026 * Represent all policy dimensions that are actually load-bearing for the deployment. * Bind jurisdiction applicability to the exact act, destination, sink, and current policy/context generation. * Revalidate after migration, failover, routing, destination, operator, key-control, or equivalent context change. * Keep the act non-effective when jurisdiction context is unknown, stale, or disallowed. * Require every consequence-producing path to preserve equivalent jurisdiction enforcement. 2. Conventions and Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. 3. Direct Question: What Threat Does This Architecture Solve? If Candidate Act C is authorized under jurisdiction or governance context J1, what prevents C from becoming effective after the execution context changes to J2? RequiredJurisdiction(C) = J_req CurrentContext(C, sink) = J_now NOT JurisdictionApplicable(J_req, J_now) ==> NOT Effective(K, C) The architecture does not decide whether J1 or J2 is legally correct. It enforces the authoritative machine-readable policy selected by the deployment. Das Expires 20 March 2027 [Page 10] Internet-Draft Jurisdiction-Bound Finality September 2026 4. Motivating Scenario: Authorized in J17, Effectuated in J18 Consider a sensitive AI inference result whose release is authorized only while the model, input data, decryption keys, and output release are governed by an approved sovereign processing context. The workload is initially scheduled in J17 and receives authorization. Before output release, an availability event activates failover to J18. Identity and workload credentials remain valid, and the replacement platform is healthy, but J18 is not within the policy permitted for that result. Authorization under J17 | v +-------------+ +-------------+ | Workload W |------>| Candidate C | | Region J17 | | non-effective| +-------------+ +------+------+ | failover / DR | v +-------------+ | Workload W | | Region J18 | +------+------+ | v [ Finality Sink ] | J18 allowed for C? / \ no yes | | REJECT EFFECT Figure 2: Failover converts valid authority into stale jurisdiction authority 5. Problem Space 5.1. Jurisdiction Is Not Merely Location A deployment's jurisdiction policy can include physical processing location, sovereign cloud membership, operator/control domain, key custody, remote-access policy, destination, trust state, and other dimensions. A country or region code alone is not a universal jurisdiction model. Das Expires 20 March 2027 [Page 11] Internet-Draft Jurisdiction-Bound Finality September 2026 5.2. Data Residency Is Not Complete Sovereignty DATA STORED IN EU | +---------------+----------------+ | | | v v v processing remote admin destination outside EU outside policy outside policy A storage-location fact can be true while another load-bearing sovereignty dimension is false. Figure 3: Storage residency does not prove complete effectuation context The deployment must state which dimensions are required. A data- residency-only profile is valid if residency is the entire intended property, but it must not be described as a broader sovereignty guarantee. 5.3. Identity Is Not Jurisdiction A valid workload credential establishes workload identity under its profile. It does not automatically establish processing location, operator control, remote access, or destination. Those facts can be separately bound to the workload or resolved at the Finality Sink. 5.4. Attestation Is Not Legal Classification RATS and platform attestation establish technical claims and appraisal results. An application policy can interpret those technical claims as satisfying a jurisdiction profile, but the attestation protocol does not itself decide what law applies. 5.5. Audit Is Not Prevention Recording after the fact that processing occurred in a particular region can support compliance evidence, incident response, and accountability. It does not prevent an act from becoming effective under a disallowed context. 6. Threat Model and Assurance Scope Das Expires 20 March 2027 [Page 12] Internet-Draft Jurisdiction-Bound Finality September 2026 6.1. Adversary Capabilities The adversary MAY control or influence the requester, AI agent, application process, workflow engine, scheduler, ordinary operating system, service-mesh routing, unprotected region labels, an untrusted GeoIP or location service, queue producers, ordinary configuration caches, downstream service selection, user-controlled destinations, failover requests, or network routing outside protected enforcement. The adversary MAY replay old jurisdiction evidence, move a workload after authorization, redirect processing, alter destination, choose a global endpoint, activate a recovery path, exploit remote administration, suppress a policy update, or substitute context evidence from another workload, tenant, region, or generation. 6.2. Threat Severity and Applicability Severity is consequence-dependent. The issue deserves high attention for sovereign or public-sector cloud, regulated financial processing, health or sensitive personal data, national-security and defence data, AI model weights and confidential inference, cross-border AI agents, telecom/network control, critical infrastructure, government workloads, controlled technical data, cross-border payment or CBDC systems, and cryptographic key custody. The same architecture can be used for lower-risk applications, but a routine regional routing preference should not be mislabeled as a high-severity jurisdictional security requirement. 6.3. Baseline Jurisdiction-Finality Profile The requester, application, ordinary network, unprotected location metadata, and ordinary caches are untrusted. The authoritative Jurisdiction Policy source, required JEC evidence sources, cryptographic verification roots, and Finality Sink are trusted. 6.4. High-Assurance Jurisdiction-Finality Profile A higher-assurance profile MAY additionally distrust the host operating system, hypervisor where appropriate, orchestrator, scheduler, service mesh, ordinary cloud metadata cache, application- level region tags, or local configuration database. JEC inputs and finality enforcement must then be anchored in protection domains those components cannot rewrite or bypass. Das Expires 20 March 2027 [Page 13] Internet-Draft Jurisdiction-Bound Finality September 2026 Potential substrates include attested confidential compute, HSMs, TEEs, DPUs or SmartNICs, protected network boundaries, protected storage or transaction services, and independently controlled policy authorities. 6.5. Trusted Roots and Limits The base model assumes the selected jurisdiction policy is authoritative for the deployment and that at least one trusted evidence path exists for every required JEC dimension. Compromise of every policy/evidence authority, physical site falsification beyond the deployment's evidence model, or effectuation outside the declared consequence domain is outside the base prevention claim. 7. Design Goals and Non-Goals The design goal is to make jurisdiction-sensitive authority current, explicit, bounded, testable, and load-bearing at effectuation. This document does not determine which law applies, define regulatory compliance, replace legal analysis, define a universal country-code taxonomy, mandate GeoIP, create a new OAuth grant type, replace WIMSE workload identity, replace RATS, replace sovereign-cloud products, or mandate a new JEC token format. A profile MAY encode JEC in JWT, EAT, OAuth authorization details, WIMSE context, SCITT statements, protected local state, or another representation. The architecture requires the semantics, not a specific encoding. 8. Existing Mechanisms and the Proposed Delta 8.1. OAuth Rich Authorization Requests RFC 9396 defines `authorization_details` for fine-grained authorization [RFC9396]. A deployment can define region, sovereign domain, resource, destination, or data-handling constraints within an authorization-details type. This document does not claim that expressing those constraints is new. The residual question is whether they remain current and mandatory at the actual consequence after downstream movement or context change. Das Expires 20 March 2027 [Page 14] Internet-Draft Jurisdiction-Bound Finality September 2026 8.2. OAuth Resource Indicators RFC 8707 allows an authorization request to identify the protected resource [RFC8707]. Resource binding is valuable, but resource identity does not automatically establish the current processing region, operator/control domain, key control, or effect destination. 8.3. JWT and Application Claims JWT defines signed claims including issuer, subject, audience, and extensible application claims [RFC7519]. A jurisdiction or region claim can therefore be carried using existing token machinery. The effectuation question is who vouches for the claim, what it means, how current it is, whether it applies to the present workload and sink, and whether the final effect technically depends on it. 8.4. WIMSE The WIMSE architecture addresses workload identity in multi-system environments [WIMSE-ARCH]. Workload identity is a strong input to JEC because JEC evidence must apply to a specific workload or trust domain. This document does not define a competing workload identity. It asks whether the identified workload's current effectuation context satisfies a separate deployment jurisdiction policy. 8.5. RATS RATS supplies technical Evidence and Attestation Results [RFC9334]. Attestation can be a high-assurance JEC evidence source for platform, firmware, workload, configuration, or other profile-specific claims. The application still decides whether those technical claims satisfy J_req(C). This document does not turn RATS into a legal-jurisdiction oracle. 8.6. SCITT SCITT provides signed statements, transparency, and receipts [RFC9943]. These can protect jurisdiction-policy manifests, sovereign-domain statements, configuration records, or evidence provenance. Registration or transparency does not by itself make a jurisdiction statement a load-bearing precondition of effectuation. Das Expires 20 March 2027 [Page 15] Internet-Draft Jurisdiction-Bound Finality September 2026 8.7. Cloud Sovereignty and Data-Boundary Controls Microsoft, AWS, and Google Cloud provide concrete controls and commitments addressing residency, sovereignty, operational control, or partner supervision [MS-EUDB] [AWS-ESC] [GOOGLE-SOV]. These are strong industrial precedents. The proposed model is not a replacement. A deployment using those controls may already satisfy the invariant if the policy dimensions required for C remain current and non-bypassable at the effectuation boundary. Example policy: processing_region: require ATTESTED_PROTECTED_ASSERTION storage_region: require SIGNED_CONTROL_PLANE_ASSERTION operator_domain: require SIGNED_OPERATOR_ASSERTION destination: require exact observed endpoint + policy match remote_access: require protected session/control-state evidence No single "region=EU" label is sufficient for this profile. Figure 4: Different JEC dimensions can require different evidence assurance 8.8. Comparison Summary +=================+==========================+======================+ | Mechanism | Strong existing property | Residual question | | | | only where not | | | | already enforced | +=================+==========================+======================+ | OAuth RAR | Fine-grained | Does the | | | authorization data | jurisdiction | | | | constraint remain | | | | applicable at the | | | | actual effect? | +-----------------+--------------------------+----------------------+ | Resource | Resource-specific | Is current | Das Expires 20 March 2027 [Page 16] Internet-Draft Jurisdiction-Bound Finality September 2026 | Indicators | authorization request | jurisdiction/ | | | | control context | | | | also required? | +-----------------+--------------------------+----------------------+ | JWT | Signed/extensible claims | Who establishes | | | | jurisdiction, how | | | | current is it, and | | | | is it effectuation- | | | | bound? | +-----------------+--------------------------+----------------------+ | WIMSE | Workload identity/ | Does the current | | | security context | workload context | | | | satisfy sovereign | | | | policy at final | | | | effect? | +-----------------+--------------------------+----------------------+ | RATS | Evidence and Attestation | Do the technical | | | Results | claims establish | | | | the required JEC | | | | dimensions for C? | +-----------------+--------------------------+----------------------+ | SCITT | Signed | Is the statement a | | | statements/transparency/ | load-bearing rule | | | receipts | or only evidence/ | | | | audit? | +-----------------+--------------------------+----------------------+ | Sovereign-cloud | Concrete residency/ | Does the | | controls | sovereignty controls | deployment's exact | | | | consequence remain | | | | confined to all | | | | required | | | | dimensions? | +-----------------+--------------------------+----------------------+ Table 1: Existing mechanism and residual effectuation question 8.9. What Is New in This Document The proposed contribution is the composition invariant, not the individual inputs. Jurisdiction-sensitive authority is evaluated again at the actual consequence boundary using the current effectuation context. Das Expires 20 March 2027 [Page 17] Internet-Draft Jurisdiction-Bound Finality September 2026 Authorization under J17 != automatic authority under J18 For protected act C: Current JEC must satisfy J_req(C) immediately before or atomically with effectuation. If an existing OAuth, WIMSE, RATS, SCITT, sovereign-cloud, or proprietary architecture already provides that exact property for a deployment, the deployment already satisfies the core invariant. 9. Prevention and Mitigation Property 9.1. Prevention Profile Prevention of the governed jurisdiction-substitution class can be claimed only where the policy is authoritative, the exact Candidate Act is bound, the current JEC is established from trusted evidence, all load-bearing dimensions are checked, state/context changes cannot silently preserve stale authority, every effectuation path preserves equivalent enforcement, and successful verification is coupled to protected commit. authoritative J_req(C) + exact-act binding + trusted current JEC + all load-bearing jurisdiction dimensions + current policy/context generation + non-bypassable consequence path + protected verification-to-commit ordering = PREVENTION of the governed J1-to-J2 substitution class 9.2. Mitigation or Evidence Profile GeoIP, unsigned region labels, application deployment annotations, best-effort routing, post-hoc audit, stale region configuration, or incomplete consequence-path coverage can be useful controls but do not establish the same prevention invariant. Das Expires 20 March 2027 [Page 18] Internet-Draft Jurisdiction-Bound Finality September 2026 9.3. Unknown Jurisdiction Context A high-assurance profile SHOULD define an explicit JEC_UNKNOWN state. When a required JEC dimension cannot be established, a prevention profile MUST NOT silently interpret unknown as permitted. The Candidate Act should remain non-effective or enter a clearly identified lower-assurance policy. 10. Terminology *Candidate Act:* A proposed consequence-bearing operation that is prepared but has not yet been permitted to become externally effective. *Protected Consequence:* The first external, persistent, financial, physical, disclosure, administrative, or other effect governed by the deployment. *Jurisdiction Policy:* Machine-readable deployment policy defining the jurisdiction, sovereignty, data-boundary, control, destination, or related technical constraints required for a Candidate Act. It is not a legal opinion. *Jurisdiction Execution Context (JEC):* The current set of technical context facts used to evaluate Jurisdiction Policy at effectuation. *Jurisdiction Context Evidence:* Protected or authenticated evidence used to establish one or more JEC dimensions. *Jurisdiction Generation:* A protected epoch, version, digest, or equivalent identifier representing current jurisdiction policy and/or context state. *Jurisdiction Applicability:* The property that the current JEC satisfies the Jurisdiction Policy for the exact Candidate Act. *Non-Effective State:* A state in which the Candidate Act cannot yet produce the protected consequence. *Finality Sink:* The protected functional boundary where the Candidate Act first becomes externally effective and where final jurisdiction applicability is verified. 11. Jurisdiction Execution Context (JEC) JEC is intentionally multi-dimensional. A deployment selects only the dimensions required by its policy. Das Expires 20 March 2027 [Page 19] Internet-Draft Jurisdiction-Bound Finality September 2026 X_now = ( workload_identity, compute_domain, processing_region, storage_region, destination_domain, operator_control_domain, key_control_domain, remote_access_context, sovereign_boundary, trust_state, policy_generation ) JEC is an architectural role and can be reconstructed from multiple sources rather than carried in a single token. 11.1. Typed Jurisdiction Dimensions A Jurisdiction Execution Context is not one country code. It is a typed set of dimensions, each with its own evidence source, assurance requirement, currentness rule, and policy semantics. A deployment selects only the dimensions that are load-bearing for a Candidate Act. JEC(C,t) = { workload_identity : W, compute_domain : CD, processing_region : PR, storage_region : SR, destination_domain : DD, operator_control_domain : OD, key_control_domain : KD, remote_access_context : RA, sovereign_boundary : SB, trust_state : TS, policy_generation : Gp, topology_generation : Gt } Each dimension d has: Value_d Evidence_d Assurance_d Freshness_d Authority_d Scope_d Das Expires 20 March 2027 [Page 20] Internet-Draft Jurisdiction-Bound Finality September 2026 11.2. Dimension State and UNKNOWN Semantics DimensionState_d ∈ { KNOWN_ALLOWED, KNOWN_DENIED, UNKNOWN, STALE, CONFLICTING, UNAVAILABLE } For strict prevention: UNKNOWN OR STALE OR CONFLICTING OR UNAVAILABLE MUST NOT silently become ALLOW. A profile may define a lower-assurance fallback, but it must be explicit and must not be described as equivalent to the strict prevention profile. 11.3. Jurisdiction Evidence Source Model Source_d = ( issuer, evidence_type, protected_scope, freshness_model, assurance_class, rollback_protection, workload_binding, sink_binding_if_required ) TrustedFor(Source_d, dimension=d, policy=P) iff Source_d.issuer ∈ P.trusted_issuers[d] AND Source_d.assurance_class >= P.min_assurance[d] AND Source_d.scope covers P.required_scope[d] 11.4. Evidence-Assurance Ordering Assurance can be modeled as a partial order rather than a universal numeric scale. A policy can require one assurance class for processing region and a different class for key-control domain. Das Expires 20 March 2027 [Page 21] Internet-Draft Jurisdiction-Bound Finality September 2026 Example partial order: APP_LABEL < AUTHENTICATED_METADATA < SIGNED_CONTROL_PLANE_ASSERTION < ATTESTED_PROTECTED_ASSERTION But: NETWORK_GEOLOCATION may be incomparable with SIGNED_OPERATOR_ASSERTION unless the deployment explicitly defines a relation. Requirement: EvidenceClass(E_d) ⪰ RequiredClass(P,d) This avoids implying that every evidence source can be ranked globally or that a weak source becomes strong merely because its value happens to be correct. 11.5. Multi-Source Corroboration Corroborated(d, E_set, P) := P.corroboration_rule[d]( { e ∈ E_set | TrustedFor(e.source, d, P) AND EvidenceFresh(e) AND EvidenceScopeValid(e) } ) Examples: ALL_OF(E_region_attestation, E_control_plane) ANY_OF(E_operator_A, E_operator_B) THRESHOLD(2 of {E1,E2,E3}) A profile can require corroboration where one source alone is insufficient. The rule must be protected policy rather than an application hint. Das Expires 20 March 2027 [Page 22] Internet-Draft Jurisdiction-Bound Finality September 2026 12. Multi-Dimensional Jurisdiction Policy 12.1. Data-Residency Profile ALLOW if: storage_region IN ApprovedStorageRegions 12.2. Processing-Sovereignty Profile ALLOW if: storage_region IN ApprovedStorageRegions AND processing_region IN ApprovedProcessingRegions 12.3. Operational-Sovereignty Profile ALLOW if: processing_region IN ApprovedProcessingRegions AND operator_control_domain IN ApprovedOperators AND key_control_domain IN ApprovedKeyDomains AND remote_access_context satisfies RemoteAccessPolicy 12.4. Strict Effectuation Profile ALLOW if: processing boundary allowed AND storage boundary allowed (when required) AND destination allowed AND operator/control domain allowed AND key-control domain allowed AND remote-access policy satisfied AND trust state acceptable AND jurisdiction generation current AND consequence path cannot bypass final enforcement 12.5. Formal Jurisdiction Policy Das Expires 20 March 2027 [Page 23] Internet-Draft Jurisdiction-Bound Finality September 2026 J_req(C) = ( RequiredDimensions, AllowedValues, MinAssurance, FreshnessBounds, CorroborationRules, DestinationRules, ControlRules, KeyControlRules, RemoteAccessRules, TrustRules, TransitionRules, UnknownHandling, EmergencyProfile ) The policy can be act-specific. A low-sensitivity read can require only storage residency, while release of a high-value model or regulated dataset can additionally require processing, operator- control, key-control, destination, and remote-access predicates. 12.6. Jurisdiction Rule Composition JurisdictionPolicySatisfied(J_req, X_now) := FOR ALL d ∈ J_req.RequiredDimensions: DimensionSatisfied(d, J_req, X_now) DimensionSatisfied(d,P,X) := State_d(X) == KNOWN_ALLOWED AND ValueAllowed(P,d,X[d]) AND EvidenceAssuranceSufficient(P,d,X) AND EvidenceFreshEnough(P,d,X) AND CorroborationSatisfiedIfRequired(P,d,X) 12.7. Alternative and Conditional Sovereignty Rules Das Expires 20 March 2027 [Page 24] Internet-Draft Jurisdiction-Bound Finality September 2026 Examples: ANY_OF processing regions: PR ∈ {EU-A, EU-B, EU-C} Conditional key rule: IF DataClass(C) == HIGHLY_SENSITIVE THEN KD ∈ ApprovedSovereignKMS Destination condition: IF Operation(C) == DISCLOSE THEN DD ∈ ApprovedRecipientDomains Emergency rule: IF EmergencyProfileActive THEN use separately labeled J_emergency with explicit weaker guarantees Conditional or emergency rules are valid only when machine-readable and explicit. A hidden operator override is an alternate policy path, not the same strict profile. 12.8. Jurisdiction-Context Equivalence Two contexts need not be byte-identical to be equivalent for a particular Candidate Act. Equivalence must be policy-defined and dimension-scoped. EquivalentFor(C, X1, X2, P) := FOR ALL d ∈ P.RequiredDimensions(C): EquivalentValue_d( X1[d], X2[d], P.equivalence_rule[d]) AND Assurance(X2[d]) >= RequiredAssurance(P,d) AND FreshnessValid(X2[d]) This permits, for example, migration between two approved sovereign regions while preventing a generic claim that all EU-labelled environments are automatically interchangeable. Das Expires 20 March 2027 [Page 25] Internet-Draft Jurisdiction-Bound Finality September 2026 13. Formal Mathematical Model Let C be the Candidate Act, K the Protected Consequence, S the Finality Sink, J_req(C) the required Jurisdiction Policy for C, X_now the current JEC, E_J the context evidence set, and g_J the current jurisdiction generation. ContextEvidenceValid(E_J, X_now, S, g_J) := EvidenceIntegrityValid(E_J) AND EvidenceIssuerTrusted(E_J) AND EvidenceFresh(E_J) AND EvidenceAppliesToWorkload(E_J, X_now.workload_identity) AND EvidenceAppliesToSink(E_J, S) AND EvidenceGenerationCurrent(E_J, g_J) JurisdictionApplicable(J_req, X_now, E_J) := ContextEvidenceValid(E_J, X_now, S, g_J) AND RequiredComputeDomainSatisfied(J_req, X_now) AND RequiredProcessingBoundarySatisfied(J_req, X_now) AND RequiredStorageBoundarySatisfiedIfAny(J_req, X_now) AND RequiredDestinationSatisfied(J_req, X_now) AND RequiredControlDomainSatisfied(J_req, X_now) AND RequiredKeyControlSatisfied(J_req, X_now) AND RequiredRemoteAccessRuleSatisfied(J_req, X_now) AND RequiredTrustStateSatisfied(J_req, X_now) The finality safety invariant is: Effective(K, C) ==> ExactActBindingValid(C) AND JurisdictionApplicable(J_req(C), X_now, E_J) AND JurisdictionGenerationCurrent(g_J) AND EffectuationPathAuthorized(C, S) For a strict prevention profile: NOT JurisdictionApplicable(J_req(C), X_now, E_J) ==> NOT Effective(K, C) Das Expires 20 March 2027 [Page 26] Internet-Draft Jurisdiction-Bound Finality September 2026 13.1. Bounded Prevention Argument Assume that the Jurisdiction Policy is authoritative for the deployment, every load-bearing JEC dimension is represented by trusted current evidence, the Finality Sink evaluates the exact Candidate Act immediately before protected commit, and every path to K preserves equivalent enforcement. Under those assumptions, an adversary cannot make K effective under a disallowed JEC without violating at least one explicit assumption: policy integrity, evidence integrity/currentness, exact-act binding, context continuity, or path non-bypassability. This is not proof of legal compliance. It is a technical prevention argument for the machine-readable policy selected by the deployment. 13.2. Formal Jurisdiction Evidence Predicate EvidenceValidForDimension(E_d, d, C, S, P, t) := IntegrityValid(E_d) AND IssuerTrustedForDimension(E_d.issuer, d, P) AND ScopeApplies(E_d, C, S) AND WorkloadBindingValidIfRequired(E_d,C) AND SinkBindingValidIfRequired(E_d,S) AND FreshnessValid(E_d,t,P.freshness[d]) AND GenerationCurrent(E_d) AND AssuranceClass(E_d) ⪰ P.min_assurance[d] AND NotSuperseded(E_d) AND ReplayRuleSatisfied(E_d) 13.3. Dimension Validity DimensionValid(d, C, X_now, E_set, P, t) := X_now[d] != UNKNOWN AND X_now[d] != STALE AND X_now[d] != CONFLICTING AND ValueAllowed(P,d,X_now[d]) AND EXISTS E_d ⊆ E_set: Corroborated(d,E_d,P) AND FOR EACH e ∈ E_d: EvidenceValidForDimension(e,d,C,S,P,t) 13.4. Cross-Dimension Context Consistency Individually valid dimension claims can still describe inconsistent worlds. A processing region claim for workload W1 must not be combined with a key-control claim for W2 or a destination claim from another transaction. Das Expires 20 March 2027 [Page 27] Internet-Draft Jurisdiction-Bound Finality September 2026 ContextConsistent(C, X_now, E_set) := SameWorkloadContext(E_set, C) AND SameTransactionOrActContext(E_set, C) AND SameTopologyGenerationWhereRequired(E_set) AND NoContradictoryDimensionClaims(E_set) AND CrossDimensionBindingsValid(E_set) 13.5. Expanded Jurisdiction Applicability JurisdictionApplicable(C,S,P,X_now,E_set,t) := ExactActBindingValid(C) AND PolicyApplies(P,C) AND ContextConsistent(C,X_now,E_set) AND FOR ALL d ∈ P.RequiredDimensions(C): DimensionValid(d,C,X_now,E_set,P,t) AND DestinationAndRecipientRulesSatisfied(P,C,X_now) AND ControlDomainRulesSatisfied(P,C,X_now) AND KeyControlRulesSatisfied(P,C,X_now) AND RemoteAccessRulesSatisfied(P,C,X_now) AND TrustRulesSatisfied(P,C,X_now) AND PolicyGenerationCurrent(P) AND TopologyGenerationCurrent(X_now) AND EffectuationPathAuthorized(C,S) 13.6. Policy and Context Generation Vector G_now = ( G_policy, G_workload, G_processing, G_storage, G_operator, G_key, G_remote_access, G_topology, G_trust ) GenerationVectorCurrent(G_eval,G_now,P,C) := FOR ALL dimension generations g_d that are load-bearing for P(C): g_eval[d] == g_now[d] OR AuthoritativeCompatibilityProof( g_eval[d], g_now[d], C, d) Das Expires 20 March 2027 [Page 28] Internet-Draft Jurisdiction-Bound Finality September 2026 A single global generation is not required. A vector prevents unrelated state changes from forcing unnecessary invalidation while still binding every load-bearing dimension. 13.7. Context-Transition Applicability TransitionAffects(C, X_old, X_new, P) := EXISTS d ∈ P.RequiredDimensions(C): NOT EquivalentForDimension( C, X_old[d], X_new[d], P.equivalence_rule[d]) If TransitionAffects(...) = TRUE: prior jurisdiction approval MUST NOT automatically survive. 13.8. Migration and Failover Rule MigrationValid(C, X_old, X_new, P) := AuthorizedTransition(X_old, X_new, P) AND JurisdictionApplicable( C, S, P, X_new, Evidence_new, t_now) AND GenerationVectorCurrent( G_new_eval, G_new_now, P, C) Otherwise: Candidate remains NON-EFFECTIVE. 13.9. UNKNOWN and Partial-Evidence Semantics Strict profile: ∃ d ∈ RequiredDimensions(C) such that State_d ∈ {UNKNOWN, STALE, CONFLICTING, UNAVAILABLE} => NOT JurisdictionApplicable(...) Lower-assurance fallback is allowed only if: ExplicitFallbackProfileSelected AND FallbackProfileIsLabeledDistinctly AND RequiredSafety/Security PolicyAllowsFallback 13.10. Coupling to Consequence-Path Completeness Das Expires 20 March 2027 [Page 29] Internet-Draft Jurisdiction-Bound Finality September 2026 JurisdictionPathSafe(C,K,D) := FOR ALL technically viable paths p capable of producing K: p crosses a jurisdiction-finality sink OR p enforces an equivalent jurisdiction invariant If EXISTS p bypassing the invariant: strict jurisdiction prevention fails. 13.11. Verification-to-Commit Serialization VerifyJEC(C, G17) | | success v ContextChange(G17 -> G18) | v CommitEff(C) If: VerifyJEC(C,G17) ≺_S Change(G17->G18) ≺_S CommitEff(C) then: CommitEff(C) MUST NOT proceed unless transition compatibility is authoritatively proven. 13.12. Strict Prevention Invariant Effective(K,C) => JurisdictionApplicable( C,S,J_req(C),X_now,E_set,t_now) AND ProtectedCommitAtFinalitySink(C,S) AND EffectuationPathAuthorized(C,S) Strict prevention: NOT JurisdictionApplicable(...) => NOT Effective(K,C) Das Expires 20 March 2027 [Page 30] Internet-Draft Jurisdiction-Bound Finality September 2026 13.13. Expanded Bounded Prevention Proof Assume: (1) J_req(C) completely identifies every load-bearing jurisdiction dimension for C; (2) every required dimension is established from sufficiently trusted, current evidence; (3) cross- dimension evidence is context-consistent; (4) every relevant migration/failover/context transition advances or validates the required generation vector; (5) the Finality Sink checks the exact Candidate Act and current JEC; (6) verification and protected commit are serialized against load-bearing context changes; and (7) every consequence-producing path crosses equivalent jurisdiction enforcement. Suppose K becomes effective while some required dimension is disallowed, stale, unknown, inconsistently bound, or below the required assurance. DimensionValid is then false, which makes JurisdictionApplicable false. The strict prevention invariant prohibits the effect, contradicting the assumed effect unless at least one premise — policy completeness, evidence trust/currentness, context consistency, transition handling, sink integrity, serialization, or path completeness — failed. The proof establishes only enforcement of the supplied machine-readable policy; it does not prove that the policy is legally correct. 14. Jurisdiction Generation and State Continuity A valid jurisdiction conclusion is a statement about current policy and current effectuation context. It MUST NOT silently survive a security-relevant context change. Das Expires 20 March 2027 [Page 31] Internet-Draft Jurisdiction-Bound Finality September 2026 Generation J17: workload=W processing=EU-A operator=OP-A key-domain=K-A policy=JP17 | +---- C authorized Migration / failover / routing / operator / key change | v Generation J18: processing=EU-B or non-EU operator=OP-B key-domain=K-B policy=JP18 Result: Applicable(C, J17) does NOT imply Applicable(C, J18) Figure 5: Jurisdiction generation changes after migration or failover A relevant context change should advance a protected generation, invalidate pending jurisdiction authority, or require an authoritative proof that the change is irrelevant to the policy dimensions required for C. Das Expires 20 March 2027 [Page 32] Internet-Draft Jurisdiction-Bound Finality September 2026 At evaluation time: G_eval = { policy: 17, processing: 44, operator: 8, key: 31, remote_access: 12, topology: 21 } Before commit: G_now = { policy: 17, processing: 45, <-- changed operator: 8, key: 31, remote_access: 12, topology: 22 <-- changed } Result: revalidate affected dimensions and path coverage rather than trusting the old aggregate approval. Figure 6: Multi-dimensional generation vector J17: EU-A / Operator-A / KeyDomain-K1 | failover / \ v v J18a: EU-B / Operator-A / KeyDomain-K1 | approved by policy equivalence v REVALIDATE -> may remain eligible J18b: Global-X / Operator-B / KeyDomain-K9 | not equivalent for C v NON-EFFECTIVE / RE-AUTHORIZE Figure 7: Failover between equivalent and non-equivalent contexts Das Expires 20 March 2027 [Page 33] Internet-Draft Jurisdiction-Bound Finality September 2026 15. Exact-Act Binding Jurisdiction policy can depend on operation type, dataset, model, resource, purpose, destination, recipient, requested precision, or consequence class. The policy result MUST therefore be bound to the security-relevant Candidate Act rather than only to a session or workload. 16. Destination and Recipient Binding Processing context can be acceptable while the eventual destination is not. Where cross-border release or disclosure is jurisdiction- sensitive, the observed effect destination and recipient domain are load-bearing parts of JEC or of the Candidate Act. 17. Operator, Control-Plane, and Key-Control Binding Some sovereignty profiles require more than physical processing region. They can require a particular operator/control regime, cryptographic key-control domain, or remote-access rule. These are separate predicates and MUST NOT be inferred solely from a region label. 18. State Machine Das Expires 20 March 2027 [Page 34] Internet-Draft Jurisdiction-Bound Finality September 2026 +----------------+ | CANDIDATE ACT | +-------+--------+ | v +-------------------------+ | RESOLVE J_req(C) | +------------+------------+ | v +-------------------------+ | ESTABLISH CURRENT JEC | | + TRUSTED EVIDENCE | +------------+------------+ | v +-------------------------+ | NON-EFFECTIVE | | PENDING FINAL CHECK | +------------+------------+ | v +-------------------------+ | FINALITY SINK | | exact act | | current JEC | | current generation | | destination/control/key | | trust state/path | +------+-------------+----+ | | fail pass | | v v REJECT / PROTECTED COMMIT REVALIDATE | v EFFECTIVE Figure 8: Jurisdiction-bound execution-finality state machine Das Expires 20 March 2027 [Page 35] Internet-Draft Jurisdiction-Bound Finality September 2026 +------------------+ | Candidate Act C | +--------+---------+ | v +------------------+ | Resolve J_req(C) | +--------+---------+ | v +---------------------------+ | Collect evidence per JEC | | dimension | +-------------+-------------+ | v +---------------------------+ | Verify assurance/freshness| | corroboration/consistency | +-------------+-------------+ | +-------+--------+ | | fail pass | | v v NON-EFFECTIVE JEC CURRENT/ALLOWED | v +--------------------+ | Path coverage + | | generation check | +---------+----------+ | +------+------+ | | fail pass | | v v NON-EFFECTIVE PROTECTED COMMIT | v EFFECTIVE Figure 9: Expanded multi-dimensional jurisdiction state machine 19. Solution Architecture Das Expires 20 March 2027 [Page 36] Internet-Draft Jurisdiction-Bound Finality September 2026 19.1. Resolve the Jurisdiction Policy The system determines J_req(C) from authoritative deployment policy. The policy can depend on act class, data category, workload, resource, destination, purpose, tenant, or other application context. 19.2. Establish Current JEC Required JEC dimensions are collected from trusted sources appropriate to the assurance profile. No single evidence source is assumed to be universally authoritative. 19.3. Bind JEC to Workload, Sink, and Generation Evidence SHOULD identify the workload, sink/effectuation domain, generation, and other scope necessary to prevent cross-context substitution. 19.4. Remain Non-Effective Successful policy calculation or JEC collection does not itself create the consequence. C remains non-effective until the Finality Sink performs the current check. 19.5. Verify and Commit at the Finality Sink The Finality Sink observes or reconstructs the exact effect, verifies the current JEC and generation, evaluates J_req(C), verifies the consequence path, and couples successful evaluation to protected commit. 19.6. Architecture and Evidence Flow Diagrams Das Expires 20 March 2027 [Page 37] Internet-Draft Jurisdiction-Bound Finality September 2026 +-------------------------+ | Jurisdiction Policy | | Authority | +------------+------------+ | J_req(C) | v +-------------+ +-------------------------+ | Candidate C |------->| CURRENT JEC | +------+------+ | workload identity | | | processing/storage | | | destination | | | operator/control | | | key control | | | remote-access state | | | attested trust state | | +------------+------------+ | | +----------------------------+ | v +-------------------------+ | FINALITY SINK | | exact C | | current JEC | | current generation | | J_req(C) satisfied? | | path authorized? | +------------+------------+ | pass | fail +---------+---------+ | | v v PROTECTED COMMIT NON-EFFECTIVE | v EFFECT K Figure 10: Jurisdiction-bound finality architecture Das Expires 20 March 2027 [Page 38] Internet-Draft Jurisdiction-Bound Finality September 2026 +----------------------+ | Jurisdiction Policy | | Authority | +----------+-----------+ | J_req(C) | v +--------------+ +------------------------------+ | Candidate C |-->| Required JEC dimensions | +--------------+ +---+----+----+----+-----------+ | | | | +---------+ | | +----------+ v v v v Attestation Region Operator Key-Control Source Source Source Source \ | | / +-------------+----+------------+ | v +----------------------+ | JEC consistency + | | assurance/corrobor. | +----------+-----------+ | v +----------------------+ | Finality Sink | | exact act | | current vector | | path coverage | | protected commit | +----------+-----------+ | v EFFECT / DENY Figure 11: Full JEC evidence and enforcement flow 20. Illustrative Pseudocode The following pseudocode is non-normative. It separates policy resolution, required-dimension selection, evidence acquisition, assurance checking, context consistency, multi-source corroboration, JEC assembly, transition handling, path coverage, multi-hop propagation, protected finalization, emergency-profile selection, and crash-safe recovery. Das Expires 20 March 2027 [Page 39] Internet-Draft Jurisdiction-Bound Finality September 2026 20.1. Resolve the Jurisdiction Policy function resolve_jurisdiction_policy(candidate): C = canonical_security_relevant_act(candidate) P = protected_policy_lookup( act_class=C.operation, data_class=C.data_class, resource=C.resource, tenant=C.tenant, destination=C.destination) if !verify_policy_integrity(P): reject("invalid jurisdiction policy") if P.generation != current_policy_generation(P.id): return RELOAD_POLICY if P.undefined_unknown_handling: reject("jurisdiction policy lacks UNKNOWN semantics") return P 20.2. Select Required JEC Dimensions function required_dimensions(candidate, policy): dims = set(policy.base_required_dimensions) for conditional in policy.conditional_rules: if conditional.predicate(candidate): dims.add_all(conditional.required_dimensions) return dims 20.3. Collect Evidence for Each Required Dimension Das Expires 20 March 2027 [Page 40] Internet-Draft Jurisdiction-Bound Finality September 2026 function collect_dimension_evidence(candidate, sink, policy): E = {} for d in required_dimensions(candidate, policy): sources = policy.authoritative_sources[d] E[d] = [] for source in sources: evidence = fetch_or_observe_context_evidence( dimension=d, source=source, candidate=candidate, sink=sink) if evidence != NONE: E[d].append(evidence) return E 20.4. Verify One Dimension's Evidence function verify_dimension_evidence( dimension, candidate, sink, policy, evidence_list): valid = [] for e in evidence_list: if !verify_integrity(e): continue if !issuer_trusted_for_dimension( e.issuer, dimension, policy): continue if !scope_applies(e, candidate, sink): continue if !fresh_enough( e, policy.freshness_bound[dimension]): continue if !generation_current(e): continue Das Expires 20 March 2027 [Page 41] Internet-Draft Jurisdiction-Bound Finality September 2026 if !assurance_satisfies( e.assurance_class, policy.min_assurance[dimension]): continue if evidence_superseded(e): continue valid.append(e) if !policy.corroboration_rule[dimension].satisfied_by(valid): return DimensionResult( state=UNKNOWN, reason="insufficient corroborated evidence") value = derive_dimension_value(valid) if contradictory_values(valid): return DimensionResult( state=CONFLICTING, reason="trusted sources disagree") if !policy.value_allowed(dimension, value): return DimensionResult( state=KNOWN_DENIED, value=value) return DimensionResult( state=KNOWN_ALLOWED, value=value, evidence=valid) 20.5. Assemble the Current JEC Das Expires 20 March 2027 [Page 42] Internet-Draft Jurisdiction-Bound Finality September 2026 function assemble_current_jec(candidate, sink): policy = resolve_jurisdiction_policy(candidate) evidence = collect_dimension_evidence( candidate, sink, policy) X = {} for d in required_dimensions(candidate, policy): X[d] = verify_dimension_evidence( d, candidate, sink, policy, evidence[d]) X.policy_generation = current_policy_generation(policy.id) X.topology_generation = current_topology_generation() return { policy: policy, context: X, evidence: evidence, generation_vector: current_jurisdiction_generation_vector( candidate, policy) } 20.6. Verify Cross-Dimension Context Consistency function verify_context_consistency( candidate, jec_bundle): all_evidence = flatten(jec_bundle.evidence) if !same_workload_context(all_evidence, candidate): reject("mixed workload evidence") if !same_transaction_or_act_context( all_evidence, candidate): reject("mixed candidate/transaction context") if !compatible_topology_generations(all_evidence): reject_or_revalidate("context generation mismatch") if contradictory_cross_dimension_claims(all_evidence): reject("inconsistent jurisdiction context") return VALID Das Expires 20 March 2027 [Page 43] Internet-Draft Jurisdiction-Bound Finality September 2026 20.7. Evaluate the Multi-Dimensional Jurisdiction Policy function evaluate_jurisdiction(candidate, sink): bundle = assemble_current_jec(candidate, sink) verify_context_consistency(candidate, bundle) for d in required_dimensions( candidate, bundle.policy): state = bundle.context[d].state if state == KNOWN_DENIED: reject("jurisdiction dimension denied", d) if state in { UNKNOWN, STALE, CONFLICTING, UNAVAILABLE }: return handle_unknown_dimension( candidate, bundle.policy, dimension=d, state=state) if !destination_rules_satisfied( candidate, bundle.context, bundle.policy): reject("destination policy violation") if !control_domain_rules_satisfied( candidate, bundle.context, bundle.policy): reject("control-domain policy violation") if !key_control_rules_satisfied( candidate, bundle.context, bundle.policy): reject("key-control policy violation") if !remote_access_rules_satisfied( candidate, bundle.context, bundle.policy): reject("remote-access policy violation") if !trust_rules_satisfied( candidate, bundle.context, bundle.policy): reject("trust-state policy violation") return VALID(bundle) Das Expires 20 March 2027 [Page 44] Internet-Draft Jurisdiction-Bound Finality September 2026 20.8. Handle UNKNOWN and Explicit Fallback Profiles function handle_unknown_dimension( candidate, policy, dimension, state): if policy.strict_prevention: reject_or_remain_non_effective( "required JEC dimension unavailable", dimension, state) fallback = policy.explicit_fallback_profile if fallback == NONE: reject() if !fallback.permits( candidate, dimension, state): reject() mark_assurance_profile( candidate, profile=fallback.id, guarantee="lower than strict jurisdiction prevention") return FALLBACK_PROFILE_SELECTED 20.9. Handle Migration, Failover, and Context Transitions function on_jurisdiction_context_change(change): affected = dimensions_affected_by(change) for d in affected: advance_protected_generation(d) pending = pending_candidates_depending_on(affected) for candidate in pending: old = candidate.bound_jec_context new = observe_new_context(candidate) if transition_equivalent_for_candidate( candidate, old, new): mark_revalidation_required(candidate) else: mark_non_effective(candidate) require_reauthorization(candidate) Das Expires 20 March 2027 [Page 45] Internet-Draft Jurisdiction-Bound Finality September 2026 20.10. Validate Context Equivalence function transition_equivalent_for_candidate( candidate, old_ctx, new_ctx): P = resolve_jurisdiction_policy(candidate) for d in required_dimensions(candidate, P): if !P.equivalence_rule[d]( old_ctx[d], new_ctx[d]): return FALSE if new_ctx[d].assurance < P.min_assurance[d]: return FALSE if !fresh_enough( new_ctx[d], P.freshness_bound[d]): return FALSE return TRUE 20.11. Verify Jurisdiction Enforcement Across Effectuation Paths function verify_jurisdiction_path_coverage( consequence, path_inventory, jurisdiction_policy): for path in paths_capable_of( consequence, path_inventory): if path.crosses_jurisdiction_finality_sink( jurisdiction_policy): continue if path.enforces_equivalent_jurisdiction_invariant: continue return CoverageFailure( reason="jurisdiction-bypass path", witness=path) return COVERAGE_VALID 20.12. Preserve JEC References Across Multi-Hop Systems Das Expires 20 March 2027 [Page 46] Internet-Draft Jurisdiction-Bound Finality September 2026 function forward_candidate( candidate, next_workload, verified_jec): envelope = { candidate: candidate, act_digest: H(canonical_security_relevant_act(candidate)), jurisdiction_policy_id: verified_jec.policy.id, policy_generation: verified_jec.policy.generation, generation_vector: verified_jec.generation_vector, scoped_evidence_references: create_scoped_jec_references( verified_jec.evidence) } return authenticated_forward(next_workload, envelope) # Downstream components MUST NOT assume that forwarded # JEC references remain current. The Finality Sink # re-establishes current applicability before effect. 20.13. Protected Jurisdiction Finalization function finalize(candidate): begin_protected_finality_section() sink = current_finality_sink() if !candidate_integrity_valid(candidate): reject("invalid candidate") if !exact_observed_effect_matches(candidate): reject("exact-act mismatch") result = evaluate_jurisdiction(candidate, sink) if result.status != VALID: remain_non_effective() return REJECTED bundle = result.bundle observed_vector = bundle.generation_vector if verify_jurisdiction_path_coverage( candidate.protected_consequence, current_effectuation_path_inventory(), Das Expires 20 March 2027 [Page 47] Internet-Draft Jurisdiction-Bound Finality September 2026 bundle.policy) != COVERAGE_VALID: reject("jurisdiction path coverage incomplete") atomic { current_vector = current_jurisdiction_generation_vector( candidate, bundle.policy) assert generation_vector_matches_or_is_compatible( observed_vector, current_vector, candidate, bundle.policy) assert current_context_still_satisfies( candidate, bundle.policy, sink) assert exact_observed_effect_still_matches(candidate) consume_once_if_required( candidate.execution_authority) commit_protected_effect(candidate) } return EFFECT_COMMITTED 20.14. Select an Emergency or Break-Glass Profile Das Expires 20 March 2027 [Page 48] Internet-Draft Jurisdiction-Bound Finality September 2026 function select_emergency_profile(candidate, reason): P = resolve_jurisdiction_policy(candidate) E = P.emergency_profile if E == NONE: reject("no emergency cross-boundary policy") if !authorized_emergency_condition(reason): reject("emergency condition not authorized") if !required_break_glass_approvals(E): reject("break-glass approvals missing") record_distinct_assurance_profile( candidate, profile=E.id, reason=reason) return E 20.15. Crash-Safe Recovery function recover(candidate_id): state = protected_commit_state(candidate_id) if state == EFFECTIVE: return DO_NOT_REPLAY if state == COMMITTING: outcome = resolve_atomic_commit(candidate_id) if outcome == EFFECT_COMMITTED: return DO_NOT_REPLAY return REVALIDATE_CURRENT_JEC_AND_PATHS if state == PENDING: return REVALIDATE_CURRENT_JEC_AND_PATHS return FAIL_CLOSED 20.16. Generate a Reviewable Jurisdiction Failure Explanation Das Expires 20 March 2027 [Page 49] Internet-Draft Jurisdiction-Bound Finality September 2026 function explain_jurisdiction_failure(result): return { failed_dimensions: result.denied_or_unknown_dimensions, evidence_failures: result.invalid_or_stale_evidence, assurance_failures: result.below_required_assurance, conflicting_sources: result.conflicting_sources, generation_changes: result.changed_generations, path_witness: result.jurisdiction_bypass_path_if_any, policy_id: result.policy.id } 21. Multi-Hop and WIMSE Composition WIMSE can identify workloads and carry security context through multi-system chains. Jurisdiction-bound finality can use that identity to bind JEC evidence to the correct workload while leaving WIMSE credential semantics unchanged. Das Expires 20 March 2027 [Page 50] Internet-Draft Jurisdiction-Bound Finality September 2026 Workload A (J17) | | workload identity + transaction/security context v Workload B (J17) | | queue / async boundary v Worker C (J18 after failover) | v +-------------------------+ | FINALITY SINK | | identify Worker C | | establish CURRENT JEC | | compare to J_req(C) | +------------+------------+ | v allow / reject Figure 12: Jurisdiction context across a multi-hop workload chain The final sink does not assume that a context label forwarded by Workload A remains true after the chain moves. WIMSE workload identity: workload://tenant/service-A | | remains stable v +---------------+ | Workload W | +-------+-------+ | +--------+---------+ | | v v Region J17 Region J18 Operator A Operator B KeyDomain K1 KeyDomain K2 Stable workload identity does not imply stable sovereign context. Figure 13: Workload identity can remain stable while jurisdiction context changes Das Expires 20 March 2027 [Page 51] Internet-Draft Jurisdiction-Bound Finality September 2026 22. RATS-Based Jurisdiction Context RATS can provide high-assurance technical evidence for selected JEC dimensions, such as platform identity, workload state, security configuration, or profile-defined claims. Attestation Results may therefore be one input to JEC. Attester | Evidence v Verifier | Attestation Result: platform / workload / profile-defined claims | v +-----------------------+ | Jurisdiction Policy | | interprets technical | | claims for J_req(C) | +-----------+-----------+ | v FINALITY SINK RATS supplies technical trust evidence. Application policy decides whether that evidence satisfies J_req(C). Figure 14: Attestation as a JEC input, not a legal conclusion Das Expires 20 March 2027 [Page 52] Internet-Draft Jurisdiction-Bound Finality September 2026 Attestation Result may establish: platform identity software measurement TEE / Realm state profile-defined region claim But policy may also require: operator control domain key-control domain destination remote-access state Therefore: trusted platform evidence + separate authoritative context evidence = complete JEC only if all required dimensions are covered. Figure 15: RATS evidence can cover only the dimensions it actually attests 23. SCITT-Based Policy and Configuration Evidence SCITT can protect signed jurisdiction-policy manifests, configuration claims, sovereign- domain statements, or receipts proving registration of those statements. This can improve provenance and accountability for JEC inputs. A SCITT Receipt does not by itself establish that the currently observed effectuation context satisfies the signed policy; the Finality Sink still evaluates current applicability. 24. Alternate-Path Resistance Jurisdiction enforcement at one API or gateway is insufficient when another route can produce the same consequence. A prevention profile therefore composes directly with consequence-path completeness. Das Expires 20 March 2027 [Page 53] Internet-Draft Jurisdiction-Bound Finality September 2026 Normal EU-controlled path: C --> JEC check --> Finality Sink --> K | | protected Alternate path: admin / DR / replication / global API | +-----------------------> K If the alternate path can produce K without equivalent JEC enforcement, the deployment cannot claim consequence-wide jurisdiction prevention. Figure 16: Jurisdiction enforcement bypass through an alternate path Normal path: C -> EU workload -> JEC check -> Finality Sink -> K ^ | jurisdiction enforced Alternate path: C -> recovery queue -> global worker -------------> K If the global worker can produce K without equivalent JEC enforcement, the deployment cannot claim consequence-wide jurisdiction prevention. Figure 17: Jurisdiction-safe normal path with unsafe cross-border bypass 25. Attack Analysis 25.1. Forged or Advisory Region Label An application supplies "region=EU" from an untrusted configuration field. A high-assurance profile rejects it unless the policy explicitly allows that source. 25.2. Stale Jurisdiction Evidence A valid J17 statement is replayed after migration to J18. Generation/freshness checking rejects or revalidates the evidence. Das Expires 20 March 2027 [Page 54] Internet-Draft Jurisdiction-Bound Finality September 2026 25.3. Disaster-Recovery Failover The primary sovereign region is unavailable and the platform fails over to a global region. Availability does not silently override a prevention profile unless policy explicitly defines such a lower- assurance fallback. 25.4. Destination Substitution Processing remains in an allowed region, but the output destination changes to a disallowed recipient/domain. Destination binding fails. 25.5. Remote Administration Outside Policy Data and workload remain in the allowed region while a remote control path that policy forbids becomes active. An operational-sovereignty profile treats remote-access context as load-bearing. 25.6. Key-Control Change Workload location is unchanged but key custody moves to a disallowed control domain. Where key control is part of J_req(C), jurisdiction applicability fails. 25.7. Cross-Region Queue or Worker Authorization occurs in J17, but an asynchronous worker in J18 performs the actual consequence. The worker/final sink establishes current JEC rather than inheriting the producer's region assumption. 25.8. Alternate Path Around Jurisdiction Enforcement A protected regional API is bypassed through an administrative, recovery, replication, or direct-storage path. Prevention fails unless the alternate path enforces an equivalent invariant. 26. High-Assurance Enforcement Das Expires 20 March 2027 [Page 55] Internet-Draft Jurisdiction-Bound Finality September 2026 Compromisable plane +--------------------------------------------------+ | Agent | App | OS | Scheduler | Orchestrator | | service mesh | ordinary region metadata | +--------------------------+-----------------------+ | v +----------------------------+ | PROTECTED FINALITY SINK | | trusted J_req policy | | trusted JEC evidence | | current generation | | exact act + destination | | protected commit | +-------------+--------------+ | v EFFECT K Figure 18: Protected JEC verification below a compromisable host NVIDIA documents local and remote GPU/NVSwitch attestation [NVIDIA-ATTEST], and Arm CCA provides hardware-isolated Realms and attestation capabilities [ARM-CCA]. Such mechanisms can provide technical trust inputs or protected enforcement substrates. They are not treated as legal-jurisdiction oracles. Das Expires 20 March 2027 [Page 56] Internet-Draft Jurisdiction-Bound Finality September 2026 +--------------------+ | Policy Authority | +---------+----------+ | v +-------------------+ | Protected AFB/JFS | +----+----+----+----+ | | | +----------+ | +-----------+ v v v Attestation Sovereign/Region Key-Control Verifier Authority Authority \ | / \ | / +-------------+--------------+ | v CURRENT JEC | v effect / reject Figure 19: Protected JEC assembly from independent evidence sources 27. Deployment Patterns 27.1. Single Sovereign Region A bounded deployment can make one region or sovereign environment the only path to the consequence. JEC primarily verifies that no migration or bypass has changed that fact. 27.2. Multi-Region with Policy-Constrained Failover Several regions can be permitted under the same policy. Failover is allowed only among contexts satisfying J_req(C), and generation changes trigger revalidation. 27.3. Sovereign plus Global Cloud A deployment can use both sovereign and global environments while marking only selected Candidate Acts as jurisdiction-restricted. Unrestricted acts can take lower-cost paths; restricted acts require JEC finality. Das Expires 20 March 2027 [Page 57] Internet-Draft Jurisdiction-Bound Finality September 2026 27.4. Hybrid or Edge Deployment Edge sites can provide local context evidence while a central policy authority defines approved sovereign groups or control domains. 28. Performance and Availability Jurisdiction-policy resolution, topology appraisal, and attestation can occur on a cold path, while the hot path verifies protected generations, scoped evidence, destination, and current local JEC. Synchronous remote attestation or legal-policy service calls on every operation are not required by this architecture. Protected cached evidence, local generation state, pre-authorized region sets, or mirrored policy roots can reduce latency when their freshness and rollback semantics are explicit. Fail-closed jurisdiction enforcement creates availability tradeoffs during region outage. A deployment MAY define emergency or lower- assurance failover policy, but it MUST NOT label a fail-open global fallback as equivalent to the strict prevention profile. 29. Relationship to OAuth OAuth RAR can carry fine-grained jurisdiction-sensitive authorization details and Resource Indicators can identify the intended protected resource [RFC9396] [RFC8707]. This document does not require new OAuth semantics. The deployment question is whether the effectuation boundary re- establishes that those constraints still apply after the workload and downstream processing path have evolved. 30. Relationship to WIMSE WIMSE is directly relevant to identifying workloads and preserving security context across multi-system environments [WIMSE-ARCH]. A jurisdiction profile could use WIMSE identities as one dimension of JEC without defining a competing credential format. A useful community question is whether JEC belongs as a WIMSE security-context profile or should remain application-specific policy. Das Expires 20 March 2027 [Page 58] Internet-Draft Jurisdiction-Bound Finality September 2026 31. Relationship to RATS RATS provides a natural evidence architecture when jurisdiction policy depends on trusted platform/workload/configuration state [RFC9334]. This draft does not add legal meaning to attestation claims; it treats them as technical inputs to application policy. 32. Relationship to SCITT SCITT can protect jurisdiction policy, signed configuration, evidence provenance, and transparency records [RFC9943]. It is complementary to effectuation-time evaluation and need not be on every hot path. 33. Industrial Relevance and Sovereign-Cloud Alignment 33.1. Government and Sovereign Cloud Public-sector and sovereignty-sensitive workloads often distinguish ordinary cloud availability from permitted sovereign operating contexts. JEC provides a way to express the effectuation-time technical invariant without assuming one vendor model. 33.2. AI and Confidential Inference Model weights, prompts, retrieval data, KV caches, and generated outputs can have different jurisdiction policies. A final output- release sink can verify the current workload, region, destination, and trust context rather than assuming that inference started in the correct location. 33.3. Financial, Payment, and CBDC Systems Cross-border transactions may have technical policy constraints on processing, settlement, key custody, or destination. The architecture can enforce such machine-readable policies without deciding regulatory jurisdiction. 33.4. Telecom and Critical Infrastructure Distributed control functions, network-management operations, and critical commands can require sovereign processing or operator- control boundaries. The Finality Sink can evaluate those requirements at the actual control-effect boundary. 34. Complementary Industrial Alignment Das Expires 20 March 2027 [Page 59] Internet-Draft Jurisdiction-Bound Finality September 2026 34.1. Microsoft EU Data Boundary Microsoft documents the EU Data Boundary and service-specific continuing transfers, including scenarios involving remote access and operational requirements [MS-EUDB] [MS-EUDB-TRANSFERS]. This is relevant because it demonstrates that data-boundary semantics are richer than a simple storage-region flag. The reference is complementary only. This document does not claim that Microsoft's controls lack execution-time enforcement or that any Microsoft service is non-compliant. 34.2. AWS European Sovereign Cloud AWS announced general availability of the European Sovereign Cloud in January 2026 and describes European sovereignty requirements including data residency, operational control, and governance independence [AWS-ESC]. The architecture can treat a sovereign-cloud identity, control plane, region, and related protected metadata as JEC inputs where a deployment chooses to do so. No deficiency is asserted. 34.3. Google Cloud Sovereign Controls by Partners Google documents partner-operated sovereignty controls including data residency, external key management, and local supervision [GOOGLE-SOV]. These map naturally to distinct JEC dimensions and illustrate why sovereignty can be multi-dimensional. 34.4. NVIDIA Attestation and Arm CCA NVIDIA documents GPU/NVSwitch attestation, and Arm CCA provides isolated Realms and attestation capabilities [NVIDIA-ATTEST] [ARM-CCA]. These mechanisms can provide trusted compute-state inputs or host protected enforcement. Neither is described as a legal- jurisdiction oracle. 34.5. Non-Endorsement and Non-Criticism Named companies and products are included only as documented technical alignment or integration examples. This document does not assert vulnerability, deficiency, non-conformance, affiliation, endorsement, or a requirement that any named product adopt this architecture. Das Expires 20 March 2027 [Page 60] Internet-Draft Jurisdiction-Bound Finality September 2026 35. Required Classes of Test Vectors A concrete profile or implementation SHOULD test at least: * C authorized and effected under the same permitted current JEC: succeed; * C authorized under J17, then processing moves to disallowed J18: reject/revalidate; * processing moves from one allowed region to another allowed region under same policy: succeed after required generation handling; * stale J17 context evidence replayed after migration: reject; * untrusted application region label presented as authoritative evidence: reject; * storage in permitted region but processing outside permitted region where processing is load-bearing: reject; * processing permitted but destination disallowed: reject; * processing permitted but operator/control domain disallowed: reject; * processing permitted but key-control domain disallowed: reject; * remote administrative state changes to a prohibited mode: reject/ revalidate; * attestation valid but missing a required jurisdiction dimension: JEC_UNKNOWN or reject; * failover into explicitly permitted lower-assurance emergency profile: label and enforce that profile; * global fail-open fallback under strict prevention profile: test failure; * queue producer in allowed region, worker in disallowed region: reject at final worker/sink; * alternate admin/DR/direct-storage path bypasses JEC check: prevention profile fails; * SCITT receipt valid but current context does not satisfy signed policy: reject; Das Expires 20 March 2027 [Page 61] Internet-Draft Jurisdiction-Bound Finality September 2026 * policy generation rolls back: reject; * context evidence from another tenant/workload reused: reject; * audit record created only after cross-border effect: classify as audit, not prevention. Implementations SHOULD also test mixed-assurance and inconsistent- context cases: correct processing-region value from an under-assured source; valid region evidence for workload W1 combined with key- control evidence for W2; two trusted sources that disagree; migration between two policy-equivalent regions; migration to a non-equivalent operator/key domain; remote-access state change after verification; topology change that introduces a cross-border bypass; emergency profile activation; and crash recovery after JEC verification but before protected commit. 36. Questions to the IETF Community Criticism, corrections, counterexamples, operational experience, prior art, and evidence that existing standards already provide the full property are explicitly invited. Recommendations to narrow, merge, or stop the work are useful outcomes. 1. Is jurisdiction-bound execution finality a useful separate abstraction, or is it fully expressible using existing authorization and attestation patterns? 2. Can OAuth RAR already express all useful jurisdiction constraints, making the remaining problem purely deployment- specific? 3. Should jurisdiction context be represented as authorization metadata, WIMSE security context, attestation claims, or application policy? 4. Which jurisdiction-relevant facts can be established technically without making legal conclusions? 5. Is physical processing location sufficient for any useful profile, or must operational-control, key-control, destination, and remote-access dimensions also be represented? 6. How should deployments distinguish data residency, processing sovereignty, and operational sovereignty? 7. What evidence source can authoritatively establish processing region when the host operating system is in the adversary model? Das Expires 20 March 2027 [Page 62] Internet-Draft Jurisdiction-Bound Finality September 2026 8. Can RATS Attestation Results carry enough trusted location/ control-domain evidence for a high-assurance jurisdiction profile? 9. Which events should advance jurisdiction generation: migration, failover, DR activation, region change, operator change, key- control change, destination change, or remote-access change? 10. How should jurisdiction context remain valid across WIMSE multi- hop and asynchronous chains? 11. Can jurisdiction context safely be portable, or should the final sink re-establish it locally? 12. Is sink/audience binding necessary to prevent cross-region or cross-tenant reuse of otherwise valid evidence? 13. How should remote administrative access be represented when it is part of sovereignty policy? 14. How should emergency or break-glass cross-border operations be represented without silently weakening the normal profile? 15. Is GeoIP ever sufficient beyond a low-assurance advisory profile? 16. What is the proper relationship between SCITT transparency evidence and effectuation-time jurisdiction enforcement? 17. Which sovereign-cloud or industrial control systems already provide the full proposed invariant in concrete deployments? 18. Would a standard JEC token improve interoperability, or should the work remain architecture/BCP only? 19. What privacy risks arise from exposing exact region, sovereign domain, operator, key-control, or jurisdiction claims? 20. What counterexample would show that this architecture is unnecessary or incorrectly scoped? 21. Which venue is best for further discussion: WIMSE, RATS, OAuth, SCITT, DISPATCH, SAAG, or another group? 37. Potential IETF Discussion Venues Das Expires 20 March 2027 [Page 63] Internet-Draft Jurisdiction-Bound Finality September 2026 37.1. WIMSE WIMSE is highly relevant because it addresses workload identity in multi-system environments and could provide identity/security-context inputs to JEC [WIMSE-ARCH]. 37.2. RATS RATS is relevant where jurisdiction assurance depends on trusted platform, workload, or configuration evidence [RFC9334]. 37.3. OAuth OAuth is relevant where jurisdiction policy is part of delegated authorization or Rich Authorization Requests [RFC9396]. 37.4. SCITT SCITT is relevant to signed jurisdiction-policy/configuration statements and transparency [RFC9943]. 37.5. DISPATCH DISPATCH can be useful if the work spans ART/security/cloud architecture without a clear single Working Group owner. 37.6. SAAG SAAG is useful for broad Security Area review and criticism. It is not a Working Group that adopts documents. 37.7. No Presumed Home This document does not claim that any named group should adopt the work. Overlap review and falsification of the residual gap should come before routing. 38. Relationship to Other Execution-Finality Internet-Drafts The execution-finality family addresses different failure surfaces. This document isolates jurisdiction continuity at effectuation. * The protocol-layer draft defines the broad Candidate Act, Non- Effective State, protected validation, Execution Handle, and Finality Sink architecture. * The agentic draft applies execution finality to high-risk AI tool dispatch. Das Expires 20 March 2027 [Page 64] Internet-Draft Jurisdiction-Bound Finality September 2026 * The hardware-enforced draft focuses on hardware-rooted finality for agentic and industrial systems. * The RATS/attestation-bound draft connects trusted workload state to exact consequential authority. * The state/policy-continuity draft asks whether the earlier decision basis remains applicable. * The finality-bound-revocation draft asks whether withdrawn authority survives to commit. * The consequence-path-completeness draft asks whether the consequence can bypass enforcement. * The third-party-decision-binding draft asks whether a required external authority actually issued the applicable decision. * The purpose-execution-finality draft addresses purpose/capability laundering and cross-domain reuse. * The AI-interoperability draft applies bounded finality to third- party AI/device interoperability. State continuity: Is the authorization basis still applicable? Revocation finality: Has authority been withdrawn? Consequence-path completeness: Can the effect avoid enforcement? Third-party decision binding: Did the required external authority issue the applicable decision? Jurisdiction-bound finality: Is the exact act becoming effective under the CURRENT authorized jurisdiction / sovereignty / control context? Related documents include [DAS-PROTOCOL], [DAS-AGENTIC], [DAS-HARDWARE], [DAS-RATS], [DAS-STATE], [DAS-REVOCATION], [DAS-PATH], [DAS-THIRD-PARTY], [DAS-PURPOSE], and [DAS-INTEROP]. Das Expires 20 March 2027 [Page 65] Internet-Draft Jurisdiction-Bound Finality September 2026 39. Public Implementations and Companion Engineering Material Public execution-finality repositories provide architectural and implementation background [GH-ARCH] [GH-HARDENED]. They are not represented here as complete implementations of the multi-dimensional JEC profile. The architecture repository discusses jurisdiction as one possible finality predicate, and the hardened challenge-bound implementation demonstrates exact-effect, epoch, policy, revocation, and sink binding. A future jurisdiction-specific implementation should not be claimed until trusted JEC evidence, migration/failover behavior, policy generations, and cross-context test vectors are actually implemented. 40. Security Considerations A jurisdiction prevention claim is only as strong as the Jurisdiction Policy, the evidence used to construct JEC, the currentness model, and the non-bypassability of the Finality Sink. 40.1. False or Advisory Jurisdiction Label Application labels and configuration annotations are not trusted evidence unless the profile explicitly designates their authority and protection. 40.2. Stale Region Evidence Authentic old region evidence must not survive migration, failover, or other context change when the evidence no longer describes the current effectuation environment. 40.3. Workload Migration Live migration or rescheduling can change processing, control, or key domains without changing workload identity. Security-relevant migration must trigger revalidation. 40.4. Failover and Disaster Recovery DR routes are part of the jurisdiction threat surface. Strict profiles must pre-authorize their context or remain non-effective when failover leaves the permitted domain. Das Expires 20 March 2027 [Page 66] Internet-Draft Jurisdiction-Bound Finality September 2026 40.5. Remote Administration Physical data location can remain unchanged while a remote administration path violates an operational-sovereignty policy. 40.6. Control-Plane/Data-Plane Mismatch A permitted data-plane region does not guarantee that management/ control operations satisfy the same sovereignty rule. 40.7. Storage Versus Processing Confusion A storage-residency proof MUST NOT be interpreted as a processing or disclosure proof unless the policy defines that equivalence. 40.8. Key-Control Mismatch Where sovereign key custody is load-bearing, key-control changes must be part of JEC and jurisdiction generation. 40.9. Destination or Recipient Change Processing can be permitted while final disclosure is not. Destination-sensitive acts require exact destination binding. 40.10. GeoIP Spoofing and Inaccuracy GeoIP is generally an inference from network data, not cryptographic proof of processing jurisdiction. It can be used only at an assurance level consistent with that limitation. 40.11. Cloud-Region Metadata Forgery When the host is untrusted, ordinary instance metadata or environment variables cannot be assumed authoritative without protected provenance. 40.12. Compromised Scheduler or Orchestrator A scheduler can move a workload after authorization. High-assurance profiles must detect or make such moves generation-relevant. 40.13. Compromised Host Host-controlled JEC inputs are insufficient when the host is in the adversary model. Independent or attested sources are required for load-bearing dimensions. Das Expires 20 March 2027 [Page 67] Internet-Draft Jurisdiction-Bound Finality September 2026 40.14. Compromised Jurisdiction Evidence Source A trusted evidence source can lie if compromised. High-assurance deployments can use independent sources, threshold rules, protected policy, or narrower trust scopes. 40.15. Valid Attestation but Insufficient Semantics A valid Attestation Result proves only the claims it actually carries and appraises. It must not be stretched into jurisdiction facts absent from the evidence/profile. 40.16. Jurisdiction-Policy Rollback An attacker may restore an earlier permissive policy. Protected generations, signed policy roots, or monotonic state are required where rollback is in the threat model. 40.17. Context-Evidence Replay Evidence from a prior region, tenant, workload, or generation must not be reusable outside its applicability semantics. 40.18. Cross-Tenant or Cross-Workload Reuse JEC evidence should bind to workload/tenant where cross-context substitution could alter authorization. 40.19. Multi-Hop Context Loss Downstream workloads must not assume jurisdiction context remained unchanged merely because an upstream component sent a valid identity or context reference. 40.20. Alternate Effectuation Path Admin, DR, replication, storage, device, or global API paths can bypass otherwise correct JEC enforcement. Consequence-path completeness is required for a prevention claim. 40.21. Replication and Direct Storage Paths Replication promotion or direct storage mutation can create effects outside the normal application route and must be modeled where jurisdiction-sensitive. Das Expires 20 March 2027 [Page 68] Internet-Draft Jurisdiction-Bound Finality September 2026 40.22. Queue or Worker Relocation Asynchronous systems can authorize in one context and execute in another. The final worker/sink must establish current JEC. 40.23. Service-Mesh or Routing Change Routing changes can alter processing context without changing application-level endpoints. Load-bearing route changes must advance or invalidate jurisdiction state. 40.24. Emergency and Break-Glass Paths Emergency cross-border operation can be modeled as a separate explicit profile with stronger human/technical controls. It must not be an undocumented bypass. 40.25. Jurisdiction-Policy Authority Compromise If the authoritative policy source is compromised, it can redefine permitted context. Separation of duties, signed policy, threshold approval, or governance controls may be appropriate. 40.26. Legal or Policy Misconfiguration The mechanism enforces the supplied policy. An incorrect legal interpretation encoded into policy can be enforced perfectly and still be legally wrong. 40.27. Fail-Open on Unknown Context Unknown JEC MUST NOT silently become permitted for a strict prevention profile. Lower-assurance fallback must be explicit. 40.28. Denial of Service Attackers can disrupt attestation, context sources, region metadata, or policy services to force JEC_UNKNOWN. Availability engineering must not silently weaken the strict invariant. 40.29. Jurisdiction and Location Privacy Exact processing region, operator, key-control domain, or site identity can be sensitive. Evidence should disclose only the minimum needed for policy evaluation. Das Expires 20 March 2027 [Page 69] Internet-Draft Jurisdiction-Bound Finality September 2026 40.30. Correlation Stable JEC identifiers can allow cross-service or cross-border correlation. Scoped identifiers or local verification can reduce this risk. 40.31. Physical-Site Falsification Physical location cannot be cryptographically inferred without an evidence architecture that actually supports that claim. Profiles must state how physical-site evidence is established. 40.32. Topology Drift New services, networks, routes, regions, or failover configurations can alter effectuation context. Jurisdiction generations must track security-relevant drift. 40.33. Crash Consistency A crash between JEC verification and protected commit must not allow replay under stale context. Transactional or idempotent recovery may be required. 40.34. Audit-Only Enforcement Logging a prohibited cross-border effect after completion does not satisfy the prevention invariant. 40.35. Technical Enforcement Is Not Legal Advice The document specifies enforcement of machine-readable policy. It does not establish that a policy is legally sufficient, identify the applicable regulator, or determine the legal meaning of "jurisdiction", "sovereignty", "residency", or related terms in a particular legal system. 41. Privacy Considerations JEC can expose sensitive information about physical/processing region, operator, sovereign control, key custody, infrastructure topology, remote-access status, and destination. Profiles SHOULD disclose only the predicates needed to make the final decision. Techniques such as policy-class membership claims, scoped digests, local protected verification, selective disclosure, pairwise identifiers, and short-lived evidence can reduce unnecessary location and topology exposure. Das Expires 20 March 2027 [Page 70] Internet-Draft Jurisdiction-Bound Finality September 2026 42. Criticism, Corrections, and Review Invited This document is intentionally presented for adversarial review. Reviewers are invited to identify legal/technical boundary mistakes, existing standards or products that already provide the full invariant, jurisdiction dimensions that are technically unmeasurable, profiles that are too broad, weak evidence assumptions, bypass paths, privacy costs, terminology conflicts, and reasons that the work should be narrowed, merged, or stopped. Particularly useful feedback is a concrete deployment in which existing OAuth, WIMSE, RATS, SCITT, sovereign-cloud, workload- identity, or proprietary controls already guarantee that the exact Candidate Act cannot become effective outside the current authorized jurisdiction/governance context. Such evidence should reduce the scope of this proposal, not be ignored. 43. IANA Considerations This document has no IANA actions. 44. Conclusion Identity, authorization, attestation, residency, and sovereign-cloud controls solve indispensable parts of cross-border security. The narrow question addressed here is whether the jurisdiction-sensitive assumptions that made a Candidate Act permissible are still true at the moment the act becomes externally effective. AUTHORIZED HERE != AUTHORIZED EVERYWHERE Valid under J17 != Automatically valid under J18 For strict jurisdiction finality: Current JEC satisfies J_req(C) OR Candidate remains non-effective. Existing systems that already provide that relationship already satisfy the core invariant. The purpose of this draft is to make the relationship explicit, testable, composable with existing standards, and open to correction by the community. Das Expires 20 March 2027 [Page 71] Internet-Draft Jurisdiction-Bound Finality September 2026 A useful implementation should be able to explain not merely that "jurisdiction failed" but which required dimension failed, which source established or failed to establish it, whether the failure was value, assurance, freshness, corroboration, cross-context consistency, generation drift, migration equivalence, or path coverage, and which protected policy generation governed the decision. 45. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, May 2017, . 46. Informative References [ARM-CCA] Arm, "Arm Confidential Compute Architecture", 2026, . [AWS-ESC] Amazon Web Services, "Opening the AWS European Sovereign Cloud", January 2026, . [DAS-AGENTIC] Das, S., "Tool Selection Is Not Execution: Finality for Agentic Tool Dispatch in High-Risk AI Systems", Work in Progress, Internet-Draft, draft-das-agentic-execution- finality-02, September 2026, . [DAS-HARDWARE] Das, S., "Computation Is Not Authority: Hardware-Enforced Execution-Finality for Agentic AI, MCP Tool Calls, and Industrial Agents", Work in Progress, Internet-Draft, draft-das-hardware-enforced-execution-finality-02, September 2026, . [DAS-INTEROP] Das, S., "Secure and Privacy-Preserving AI Interoperability under Article 6(7) of the European Digital Markets Act: An Execution-Finality Architecture", Das Expires 20 March 2027 [Page 72] Internet-Draft Jurisdiction-Bound Finality September 2026 Work in Progress, Internet-Draft, draft-das-execution- finality-ai-interoperability-04, September 2026, . [DAS-PATH] Das, S., "When the Gate Can Be Bypassed: Consequence-Path Completeness for Execution Finality", Work in Progress, Internet-Draft, draft-das-consequence-path-completeness- 00, September 2026, . [DAS-PROTOCOL] Das, S., "The Missing Protocol Layer for the Agentic Internet: Computation Is Not Authority", Work in Progress, Internet-Draft, draft-das-execution-finality-protocol- layer-01, September 2026, . [DAS-PURPOSE] Das, S., "Data-Purpose Laundering Prevention: Execution- Finality for Preventing Cross-Domain Data Reuse", Work in Progress, Internet-Draft, draft-das-purpose-execution- finality-03, September 2026, . [DAS-RATS] Das, S., "Attestation-Bound Execution Finality for GPU, AI Accelerator, DPU, SmartNIC, and Confidential-Computing Infrastructure", Work in Progress, Internet-Draft, draft- das-rats-attestation-bnd-execution-finality-04, September 2026, . [DAS-REVOCATION] Das, S., "Revoked but Still Executable: Closing the Authorization-to-Effect Gap with Finality-Bound Revocation", Work in Progress, Internet-Draft, draft-das- finality-bound-revocation-00, September 2026, . Das Expires 20 March 2027 [Page 73] Internet-Draft Jurisdiction-Bound Finality September 2026 [DAS-STATE] Das, S., "When Valid Authorization Becomes Stale: State and Policy Continuity at the Execution-Finality Boundary", Work in Progress, Internet-Draft, draft-das-state-policy- continuity-finality-00, September 2026, . [DAS-THIRD-PARTY] Das, S., "When I Checked Is Not Proof: Verifiable Third- Party Decision Binding at the Execution-Finality Boundary", Work in Progress, Internet-Draft, draft-das- third-party-decision-binding-00, September 2026, . [GH-ARCH] Das, S., "Execution-Finality Architecture for Machine- Generated Acts", 2026, . [GH-HARDENED] Das, S., "Hardened Challenge-Bound Execution Finality for AI Interoperability", 2026, . [GOOGLE-SOV] Google Cloud, "Sovereign Controls by Partners", 2026, . [MS-EUDB] Microsoft, "Customer data storage and processing for European customers in Microsoft Entra ID", 2026, . [MS-EUDB-TRANSFERS] Microsoft, "Continuing data transfers that apply to all EU Data Boundary Services", 2026, . [NVIDIA-ATTEST] NVIDIA, "NVIDIA Attestation SDK — GPU and Switch Attestation", 2026, . Das Expires 20 March 2027 [Page 74] Internet-Draft Jurisdiction-Bound Finality September 2026 [RFC7519] IETF, "JSON Web Token (JWT)", RFC 7519, May 2015, . [RFC8707] IETF, "Resource Indicators for OAuth 2.0", RFC 8707, February 2020, . [RFC9334] IETF, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, January 2023, . [RFC9396] IETF, "OAuth 2.0 Rich Authorization Requests", RFC 9396, May 2023, . [RFC9943] IETF, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, June 2026, . [WIMSE-ARCH] IETF WIMSE Working Group, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft-ietf-wimse-arch-08, July 2026, . Author's Address Sangam Das Independent Balasore Odisha India Phone: +91-9861363532 Email: info@sangamdas.com Das Expires 20 March 2027 [Page 75]