Individual Submission S. Das Internet-Draft Independent Intended status: Informational 16 September 2026 Expires: 20 March 2027 Partial Commit Is Not Finality: Composite Candidate Acts Across Multiple Finality Sinks draft-das-composite-execution-finality-00 Abstract An agent, a payment orchestrator, or a control-plane applicator often intends one Candidate Act that would become real only as several consequences: a settlement post, a ledger write, a tool invoke, a notification, a radio enable. [DAS-HANDLE] specifies verify, consume, and receipt at one Finality Sink. It does not say what "the act was permitted" means when sink S1 has consumed and posted and sink S2 has rejected, timed out, or committed a different digest. Existing distributed-transaction tools already address adjacent problems. Two-phase commit, XA, sagas, TCC, transactional outbox, and workflow engines coordinate steps. OAuth, WIMSE, RATS, and SCITT still name identity, environment, and signed statements. None of them, by themselves, bind N sink-local Execution Handles to one composite Act Digest and require that no child consequence become externally effective unless every required child reaches a defined terminal state. This document specifies Composite Candidate Acts, child handles, a coordinator that may only prepare, a two-phase consume rule, and the distinction between prevention (no child commits unless the composite closes) and mitigation (compensate after a partial post). Compensation is itself a Candidate Act. It is not a silent undo and not a license to skip verify on the original child. This is not a new consensus protocol and not a claim that XA is obsolete. Profiles that cannot obtain prepare-from-every-sink MUST NOT claim all-or-none prevention. Three rejections are expected and are treated as design constraints. "Saga plus handle is enough" is accepted when each saga step already reconstructs the live child, consumes a child handle, and cannot log SUCCESS after a required child rejects; this draft then shrinks to join fields. Prepare across N sinks is a latency tax only if consume-state is global; it is per child handle, and a no_prepare mail or MCP child must use the mitigation profile rather than pretend 2PC. Child sinks reconstruct only their own pending effect, not a Das Expires 20 March 2027 [Page 1] Internet-Draft Composite Execution Finality September 2026 mesh-wide CAD. Reviewers who would reject on saga, performance, or reconstruction grounds are asked to read those sections before discarding the document. Criticism, including "this should stay a note in the handle draft," remains 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/. 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Vulnerability: One Intent, Split Reality . . . . . . . . 4 1.2. Existing Mechanisms Already Coordinate Steps . . . . . . 4 1.3. Residual Gap After a Single-Sink Handle . . . . . . . . . 4 1.4. What This Document Introduces . . . . . . . . . . . . . . 4 2. Conventions and Requirements Language . . . . . . . . . . . . 5 3. Direct Question . . . . . . . . . . . . . . . . . . . . . . . 5 4. Motivating Scenario: Pay, Book, Notify . . . . . . . . . . . 5 5. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . . 6 Das Expires 20 March 2027 [Page 2] Internet-Draft Composite Execution Finality September 2026 7. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Composite Objects . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Composite CAD . . . . . . . . . . . . . . . . . . . . . . 7 8.2. Child Handles . . . . . . . . . . . . . . . . . . . . . . 8 8.3. Composite Handle . . . . . . . . . . . . . . . . . . . . 8 9. Composite State Machine . . . . . . . . . . . . . . . . . . . 8 10. Prepare, Commit, Abort . . . . . . . . . . . . . . . . . . . 9 10.1. Phase 0: Reconstruct Each Child . . . . . . . . . . . . 9 10.2. Phase 1: Prepare . . . . . . . . . . . . . . . . . . . . 9 10.3. Phase 2: Commit or Abort . . . . . . . . . . . . . . . . 10 11. Join Rules . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. Compensation Is a New Act . . . . . . . . . . . . . . . . . . 11 13. Coordinator Rules . . . . . . . . . . . . . . . . . . . . . . 11 14. Timeouts and Crash . . . . . . . . . . . . . . . . . . . . . 12 15. Formal Join . . . . . . . . . . . . . . . . . . . . . . . . . 12 16. Illustrative Pseudocode . . . . . . . . . . . . . . . . . . . 13 17. Composition with Existing Tools . . . . . . . . . . . . . . . 14 18. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 15 19. Anticipated Criticisms . . . . . . . . . . . . . . . . . . . 15 19.1. Objection: Saga Plus Handle Is Enough . . . . . . . . . 15 19.2. Objection: Prepare Across N Sinks Is a Latency Tax . . . 16 19.3. Objection: Each Child Cannot Reconstruct a Unified CAD . . . . . . . . . . . . . . . . . . . . . . . . . . 16 19.4. What Would Settle the Argument . . . . . . . . . . . . . 17 20. Industrial Relevance and Public-Roadmap Alignment . . . . . . 17 21. Questions to the IETF Community . . . . . . . . . . . . . . . 17 22. Potential IETF Discussion Venues . . . . . . . . . . . . . . 18 22.1. DISPATCH . . . . . . . . . . . . . . . . . . . . . . . . 18 22.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . 18 22.3. WIMSE . . . . . . . . . . . . . . . . . . . . . . . . . 18 22.4. RATS . . . . . . . . . . . . . . . . . . . . . . . . . . 18 22.5. HTTPAPI . . . . . . . . . . . . . . . . . . . . . . . . 18 22.6. SCITT . . . . . . . . . . . . . . . . . . . . . . . . . 18 22.7. SAAG . . . . . . . . . . . . . . . . . . . . . . . . . . 19 22.8. No Presumed Home . . . . . . . . . . . . . . . . . . . . 19 23. Relationship to Other Execution-Finality Internet-Drafts . . 19 24. Security Considerations . . . . . . . . . . . . . . . . . . . 19 25. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 26. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 27. Criticism, Corrections, and Review Invited . . . . . . . . . 20 28. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 20 29. Normative References . . . . . . . . . . . . . . . . . . . . 20 30. Informative References . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 Das Expires 20 March 2027 [Page 3] Internet-Draft Composite Execution Finality September 2026 1. Introduction 1.1. Vulnerability: One Intent, Split Reality A composite intent C is authorized as a unit: pay vendor X AND write the invoice AND notify finance. If the settlement sink consumes its handle and posts, and the notification sink times out, operators still say "the agent paid." The Candidate Act that was reviewed was not the world that occurred. No child token was forged. The failure is split effectuation of one intended act. Intended C = { pay X, book invoice, notify finance } +-- S1 SETTLEMENT consume + post EFFECTUATED C ---+-- S2 CONTROL timeout NON_EFFECTIVE +-- S3 TOOL never invoked NON_EFFECTIVE Reviewed act: C Occurred world: pay X only Partial commit != composite finality Figure 1: Child S1 commits; child S2 never becomes effective 1.2. Existing Mechanisms Already Coordinate Steps Two-phase commit and XA serialize prepare/commit across resource managers. Sagas and TCC specify forward actions plus compensations. Outbox and workflow engines order side effects. Those tools should be used. They do not define an Execution Handle per child sink, do not reconstruct each live child act, and do not make "compensation" a second handled Candidate Act. 1.3. Residual Gap After a Single-Sink Handle [DAS-HANDLE] closes possession-versus-authority at one boundary. After that draft, each child can be locally correct and the composite still wrong. Registries reserve COMPOSITE as a class and a sink type [DAS-REG]. They do not specify the protocol. 1.4. What This Document Introduces * Composite CAD with an ordered, explicit child list and a composite Act Digest. Das Expires 20 March 2027 [Page 4] Internet-Draft Composite Execution Finality September 2026 * One child Execution Handle per required sink, all bound to the same composite id. * Prepare / commit / abort on consume-state, with fail-closed defaults. * A coordinator role that cannot substitute for child sinks. * Compensation as a new Candidate Act, not a hidden reverse of the original handle. 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 If C is the act that was authorized, and only a proper subset of C's required children have become externally effective, was C effectuated? Prevention profile: C is EFFECTUATED iff every required child is EFFECTUATED under handles bound to C and no extra child effect is attributed to C. Otherwise C remains NON_EFFECTIVE even if some child already moved money or iron. That last sentence is the operational cost. If a profile cannot prevent the child post, it must not advertise all-or-none prevention. 4. Motivating Scenario: Pay, Book, Notify An enterprise agent is allowed to settle a vendor invoice only as a unit with the ERP booking and an audit mail. Settlement posts in 80 ms. ERP is in a change window. Mail is a third-party API with no prepare. A coordinator that "retries notify later" has not effectuated C. It has effectuated a different act: pay-without-book. Das Expires 20 March 2027 [Page 5] Internet-Draft Composite Execution Finality September 2026 Authorized C17 = pay + book + notify [all required] After S1 post, S2 reject: world = paid, not booked C17 = still NON_EFFECTIVE C18 = "notify later about a payment already posted" is a new CAD and needs its own handle Figure 2: Why retry-later is a different Candidate Act 5. Threat Model The attacker need not forge handles. Relevant failures: * Child reordering so an optional notify is treated as required, or the reverse. * Coordinator crash after S1 prepare and before S2 prepare. * S2 commit of a mutated child CAD under the same composite id. * Calling compensation on S1 without a new handle. * Declaring success from the coordinator receipt while a required child is still PENDING. * Using a saga log as proof that no child effect exists. 6. Goals and Non-Goals Goal: define when a multi-sink Candidate Act may be called EFFECTUATED, PREPARED, ABORTED, or COMPENSATING, using the objects in [DAS-HANDLE]. Non-goals: a new Paxos/Raft; replacing XA or workflow engines; requiring every SaaS to implement prepare; claiming exactly-once delivery across the open Internet; automatic legal netting of a posted payment. 7. Terminology *Composite Candidate Act (C):* A Candidate Act whose intended consequence is the conjunction of two or more child consequences. *Child Act C_i:* The component that one sink would effectuate. Das Expires 20 March 2027 [Page 6] Internet-Draft Composite Execution Finality September 2026 *Required child:* A child that MUST reach EFFECTUATED for C to reach EFFECTUATED. *Optional child:* A child that MUST NOT block C if it fails, and MUST NOT be advertised as part of C's authorized unit if it is skipped. Optional children SHOULD be separate acts. *Coordinator:* The component that records composite state. It is not a Finality Sink for a child effect unless it is also that child's sink. *Prepare:* Child sink has verified the live child act, reserved consume-state, and promises not to post until commit or abort. *Compensation act:* A new Candidate Act that would reverse or contain a child effect that already escaped. It uses a new handle. 8. Composite Objects 8.1. Composite CAD A composite CAD is a CAD whose consequence_class and coordinator sink_type are COMPOSITE [DAS-REG]. It MUST list children explicitly. composite_cad = { candidate_act_id, composite_act_digest, // over canonical child list consequence_class: "COMPOSITE", children: [ { child_id, cad_i, sink_i, required: true|false }, ... ], join_rule: "ALL_REQUIRED", expires_at, generations } ALL_REQUIRED: every child with required=true must EFFECTUATE for C to EFFECTUATE. QUORUM / BEST_EFFORT: MUST NOT be used in a prevention profile for FINANCIAL, PHYSICAL, RF, CLINICAL, MODEL_RELEASE. Das Expires 20 March 2027 [Page 7] Internet-Draft Composite Execution Finality September 2026 8.2. Child Handles Each required child has its own Execution Handle EH_i issued by the PED. EH_i MUST bind: * act_digest of child CAD_i * sink_id of S_i * composite_id = C.candidate_act_id * reuse_policy compatible with the child class A child handle MUST NOT be accepted at a sink whose consume would not serve that composite_id. Presenting EH_i for a standalone payment that is not C is EF-023 or EF-040 [DAS-REG]. 8.3. Composite Handle The coordinator MAY hold a composite handle EH_C whose digest is the composite Act Digest. EH_C authorizes the coordinator to drive prepare/commit/abort. It does not authorize S_i to post. 9. Composite State Machine Das Expires 20 March 2027 [Page 8] Internet-Draft Composite Execution Finality September 2026 issue | v NON_EFFECTIVE | children verify v PREPARED -------- abort / timeout ------> ABORTED | all required commit v EFFECTUATED If any required child already posted and others cannot: EFFECTUATED is forbidden | v COMPENSATING -- compensation C' --> CONTAINED | +--> UNKNOWN (compensation also split) Prevention profile forbids entering COMPENSATING because a required child posted before join. Figure 3: States of C, distinct from child sink states Child sinks use the handle draft states locally: verify, consume (here: reserve / commit / abort), receipt. C's state is a join of those receipts, not a vote by the model that proposed C. 10. Prepare, Commit, Abort 10.1. Phase 0: Reconstruct Each Child Each S_i MUST reconstruct live child CAD_i from the pending local effect, not from a coordinator-supplied blob alone [DAS-HANDLE]. Coordinator-supplied CAD_i is a hint. Digest mismatch is EF-023. 10.2. Phase 1: Prepare Prepare is consume-state reservation without external effect. Das Expires 20 March 2027 [Page 9] Internet-Draft Composite Execution Finality September 2026 S_i.prepare(EH_i, live_cad_i): verify handle and reconstruct digest if fail: receipt REJECTED, do not reserve if consume-store down: EF-081, fail closed reserve EH_i (not yet posted) return PREPARED Coordinator: if any required child not PREPARED before deadline: abort all prepared children C = ABORTED A sink that cannot reserve without posting (typical third-party mail or card API) MUST be declared no_prepare=true. A composite that includes a required no_prepare sink MUST NOT use the prevention profile. It MAY use mitigation: post last, or accept COMPENSATING. 10.3. Phase 2: Commit or Abort Coordinator.commit(C): require all required children PREPARED require EH_C still current for each S_i: S_i.commit(EH_i) // post + CONSUMED if all required EFFECTUATED: C = EFFECTUATED emit composite receipt else: // prevention profile: this branch // should be unreachable if prepare held C = COMPENSATING Coordinator.abort(C): for each PREPARED S_i: S_i.abort(EH_i) // release reserve, no post C = ABORTED 11. Join Rules +===================+====================+========================+ | Rule | C EFFECTUATED when | Prevention claim | +===================+====================+========================+ | ALL_REQUIRED | every required | Yes, if every required | | | child EFFECTUATED | sink supports prepare | +-------------------+--------------------+------------------------+ | ALL_THEN_OPTIONAL | required set | Only over the required | | | EFFECTUATED; | set | Das Expires 20 March 2027 [Page 10] Internet-Draft Composite Execution Finality September 2026 | | optional attempted | | +-------------------+--------------------+------------------------+ | QUORUM(k) | any k children | No for high- | | | | consequence classes | +-------------------+--------------------+------------------------+ | BEST_EFFORT | coordinator tried | Never | +-------------------+--------------------+------------------------+ Table 1: Join rules and whether prevention may be claimed 12. Compensation Is a New Act If a required child has already posted, C cannot become EFFECTUATED and cannot become cleanly ABORTED. A compensation Candidate Act C' MAY be issued: reverse the post, hold the funds, disable the radio, retract the tool side effect. EH_pay CONSUMED + posted EH_book REJECTED Forbidden: S_pay.undo(EH_pay) // handle already consumed Required: C' = "return funds for composite C17" new CAD', new EH' S_pay.verify/consume(EH') C = COMPENSATING then CONTAINED only if C' EFFECTUATED Figure 4: Compensation does not reuse the original child handle Success of C' is not success of C. Receipts MUST keep the two identifiers distinct. Failure of C' leaves C in UNKNOWN containment and MUST be visible. 13. Coordinator Rules * The coordinator MUST NOT post a child effect itself unless it is that child's sink. * The coordinator MUST persist composite state before sending commit. * After crash, the coordinator MUST query child receipts; it MUST NOT assume commit or abort. Das Expires 20 March 2027 [Page 11] Internet-Draft Composite Execution Finality September 2026 * A coordinator receipt without child receipts is not evidence that C effectuated. * The coordinator SHOULD be identifiable as sink type COMPOSITE in the registry sense only: it joins, it does not replace SETTLEMENT or ACTUATION. 14. Timeouts and Crash prepare_deadline exceeded -> abort all PREPARED children -> C = ABORTED commit sent, coordinator dies -> children stay PREPARED until commit, abort, or child-local reserve TTL -> reserve TTL MUST fail closed (no automatic post) child PREPARED, never hears commit/abort -> on TTL: abort locally -> report EF-080 / EF-081 if store cannot decide Automatic commit on coordinator silence is forbidden in the prevention profile. That pattern is how partial posts happen. 15. Formal Join Das Expires 20 March 2027 [Page 12] Internet-Draft Composite Execution Finality September 2026 Required(C) = { i | child_i.required } Prepared(C) = { i in Required(C) | S_i.state == PREPARED } Posted(C) = { i in Required(C) | S_i.state == EFFECTUATED } Rejected(C) = { i in Required(C) | S_i.state == REJECTED } C.EFFECTUATED iff Posted(C) == Required(C) AND no child digest diverged AND join_rule == ALL_REQUIRED or ALL_THEN_OPTIONAL C.ABORTED iff Posted(C) empty AND (Rejected(C) nonempty OR prepare_deadline missed) C.COMPENSATING iff Posted(C) nonempty AND Posted(C) != Required(C) PreventionWellFormed(C) iff join_rule == ALL_REQUIRED AND every required S_i supports prepare AND no required S_i has no_prepare AND reserve TTL fail-closed PreventionWellFormed(C) == false ==> MUST NOT claim all-or-none prevention 16. Illustrative Pseudocode Das Expires 20 March 2027 [Page 13] Internet-Draft Composite Execution Finality September 2026 function effectuate_composite(C, handles): if not PreventionWellFormed(C): return mitigation_mode(C, handles) # different claim prepared = [] for child in required(C): live = child.sink.reconstruct() r = child.sink.prepare(handles[child], live) if r.decision != "PREPARED": abort_all(prepared) return receipt(C, "ABORTED", r.reason_code) prepared.append(child) for child in prepared: r = child.sink.commit(handles[child]) if r.decision != "EFFECTUATED": return receipt(C, "COMPENSATING", "EF-044") return receipt(C, "EFFECTUATED", consume_outcome="CONSUMED") function compensate(C, child_posted): C2 = new_cad(reverse_of(child_posted), parent=C.id) eh2 = PED.issue(C2) return child_posted.sink.verify_consume(eh2) 17. Composition with Existing Tools +===============+==================+=========================+ | Existing tool | Supplies | Still required | +===============+==================+=========================+ | XA / 2PC | Prepare/commit | Child Act Digest + | | | wire to RMs | handle bind | +---------------+------------------+-------------------------+ | Saga / TCC | Forward + | Compensation as new | | | compensate graph | handle; no silent undo | +---------------+------------------+-------------------------+ | Outbox / | Ordered jobs, | Retries are new | | workflow | retries | attempts, not C success | +---------------+------------------+-------------------------+ | SCITT | Logged composite | Log is not child commit | | | receipt | | +---------------+------------------+-------------------------+ | Single-sink | Local authority | This join | | handle | | | +---------------+------------------+-------------------------+ Table 2: What existing coordinators supply versus what is Das Expires 20 March 2027 [Page 14] Internet-Draft Composite Execution Finality September 2026 still required 18. Profiles ef-composite-strict: ALL_REQUIRED, every required sink supports prepare, reserve TTL fail-closed, compensation is a new act, coordinator receipt insufficient. ef-composite-mitigation: at least one required sink is no_prepare; document the escaped-effect window; MUST NOT claim prevention. 19. Anticipated Criticisms The invitation in the abstract to treat "saga plus handle is enough" as a successful review outcome is deliberate. The same is true of the performance and reconstruction objections. This section states where those objections are accepted. 19.1. Objection: Saga Plus Handle Is Enough If each saga step is already a handle-using sink — reconstruct live child, prepare or consume, fail closed — then this draft is a join profile on top of that saga, not a replacement for it. XA resource managers that expose prepare, and PSP authorize/capture pairs, are the same pattern under other names. The residual cases this draft still names: * the saga logs SUCCESS after a required child posts and another required child rejects; * compensation reuses the original child handle instead of a new reverse act; * a no_prepare child (mail, many MCP tools) is treated as if 2PC applied; * the coordinator receipt is taken as proof that settlement occurred. Das Expires 20 March 2027 [Page 15] Internet-Draft Composite Execution Finality September 2026 Accepted: saga / XA / workflow AS coordinator child Execution Handle AS per-sink authority Not accepted as prevention: saga success without child PREPARED/EFFECTUATED receipts compensate(original_token) after the original handle is CONSUMED BEST_EFFORT notify advertised as C EFFECTUATED If reviewers produce a saga profile that already forbids those four cases, this document should shrink to that profile plus the composite CAD fields. That outcome is welcome. 19.2. Objection: Prepare Across N Sinks Is a Latency Tax ALL_REQUIRED prepare adds one reservation round to every required child before any child posts. On a payment rail that is already authorize-then-capture, that round already exists. On a three-sink agent path where mail cannot prepare, the honest profile is mitigation: do not claim all-or-none, or split notify into a later act. Consume-state remains per child handle, not one lock for the whole composite. The coordinator persists join state; it does not serialize unrelated composites. Automatic commit on coordinator silence is still forbidden in the strict profile, because that is how partial posts happen. 19.3. Objection: Each Child Cannot Reconstruct a Unified CAD Children do not reconstruct the composite CAD. Each sink reconstructs only its child: the payment it would post, the tool it would invoke, the row it would write. The coordinator compares child receipts and the composite digest over the declared child list. A mesh hop that is not a child sink does not reconstruct anything. If a child sink cannot observe the fields that change its own effect, that child cannot be in a prevention-profile composite. It can be an optional later act. Hiding that limitation inside a caller-supplied composite blob is how split reality occurs. Das Expires 20 March 2027 [Page 16] Internet-Draft Composite Execution Finality September 2026 19.4. What Would Settle the Argument A minimal demonstration is more useful than another join diagram: one MCP (or payment) middleware that consumes a child handle, one second sink that can prepare, and a coordinator that aborts when the second child rejects — including the case where a prompt-injected destination changes only one child's digest. This document does not ship that code. An implementation that does is invited. 20. Industrial Relevance and Public-Roadmap Alignment Agent products already chain tools: pay, ticket, mail, CRM write. Cloud workflow services already run sagas. PSPs already split authorize and capture. Those roadmaps are complementary. This document does not assert that any named orchestrator is unsafe, incomplete, or required to implement prepare. PSP authorize/capture ~ prepare/commit at SETTLEMENT Cloud workflow / saga ~ coordinator + compensation graph MCP tool chain ~ children; often no_prepare Agent runtime ~ proposer of C, not the join A PSP capture API that already holds an authorization and voids it on timeout is already a prepare-capable SETTLEMENT sink under another name. An MCP server that cannot reserve a Gmail send is a no_prepare TOOL_DISPATCH sink. Putting both in one "strict" composite would be a mis-profile, not a vendor defect. Named companies are not claimed as reviewers, implementers, or endorsers. Corrections and requests to remove a framing are invited. Silence is not agreement. 21. Questions to the IETF Community 1. Is composite finality a separate document, or a section of the handle draft? 2. Is ALL_REQUIRED the only join rule worth specifying? 3. Must every prevention-profile child support prepare, or is "post last no_prepare sink" an acceptable prevention trick? 4. Should reserve TTL default to abort or to hold-until-operator? 5. Is compensation in scope here or a later draft? 6. How should composite receipts nest child receipts without becoming a new transparency protocol? Das Expires 20 March 2027 [Page 17] Internet-Draft Composite Execution Finality September 2026 7. What prior art (XA, saga, TCC, TN, workflow) already closes this if child handles are added as resources? 8. Should optional children be forbidden in v1 so that notify-later is always a new act? 9. Which venue: DISPATCH, then none until handle lands? 10. If a saga profile already forbids success-without-child-receipts and silent reuse of a consumed handle, should this draft shrink to CAD fields only? 11. Is authorize/capture on existing rails accepted as prepare/ commit, or must the wire names change? 22. Potential IETF Discussion Venues This document does not claim that any named group should adopt the work. 22.1. DISPATCH Natural first stop: the work spans payments, HTTP APIs, and agents. 22.2. OAuth Relevant only if child handles are token profiles. OAuth should not own actuation join. 22.3. WIMSE Relevant if child actors are workloads on different hops. Workload identity is not composite join. 22.4. RATS Relevant if a child CAD includes environment currentness. Attestation is not prepare. 22.5. HTTPAPI Relevant to coordinator HTTP resources and problem+json mapping of EF-044 / COMPENSATING. 22.6. SCITT Relevant to logging composite receipts. Not the commit protocol. Das Expires 20 March 2027 [Page 18] Internet-Draft Composite Execution Finality September 2026 22.7. SAAG Useful for whether all-or-none across administrative domains is in scope for the IETF at all. 22.8. No Presumed Home Individual -00. No IANA request in this revision beyond codes already reserved in [DAS-REG]. 23. Relationship to Other Execution-Finality Internet-Drafts This draft sits above the handle and the registries. It does not replace predicate or domain drafts. DAS-PROTOCOL architecture DAS-HANDLE authority at ONE sink DAS-REG COMPOSITE class/type, EF-044 this document join of N handle-using sinks DAS-PATH every child path must still be covered DAS-STATE generations still current at commit DAS-REVOCATION a child handle can be withdrawn before commit DAS-JURISDICTION each child JEC may differ; join must see that DAS-PURPOSE live purpose of C and of each child DAS-AGENTIC tool chain is often the composite proposer Still not this draft: delegation warrant break-glass override See [DAS-HANDLE], [DAS-REG], [DAS-PROTOCOL], [DAS-PATH], [DAS-STATE], [DAS-REVOCATION], [DAS-JURISDICTION], [DAS-PURPOSE], and [DAS-AGENTIC]. 24. Security Considerations Coordinator compromise is not child-sink compromise, but a malicious coordinator can withhold abort and leave reserves hanging. Child sinks MUST expire reserves fail-closed. Treating a coordinator signature as a settlement receipt recreates bearer authority at the wrong layer. Quorum join on financial or physical children is a safety bug, not an availability feature. Das Expires 20 March 2027 [Page 19] Internet-Draft Composite Execution Finality September 2026 25. Privacy Considerations A composite CAD lists every child destination. That list can reveal a payment, a patient-adjacent system, and a mail target together. Coordinators SHOULD store child digests and sink ids, and SHOULD omit raw arguments from composite receipts sent off-path. 26. IANA Considerations This version does not request IANA action. It uses COMPOSITE, EF- 044, and profile names already proposed in [DAS-REG]. A later revision MAY add ef-composite-strict and ef-composite-mitigation to the profile registry. 27. Criticism, Corrections, and Review Invited The most useful criticism is that XA plus per-resource handles already yields this join, or that mitigation sagas are the only honest Internet profile. Either result should shrink the draft. Named-product corrections are welcome. Silence is not endorsement. 28. Conclusion Local handle correctness at each sink does not make a multi-sink intent final. C is effectuated only when every required child is effectuated under handles bound to C. If a required child cannot prepare, the honest claim is mitigation plus a later compensation act — not all-or-none prevention. CHILD POST != COMPOSITE FINALITY SAGA COMPENSATION != THE ORIGINAL ACT SUCCEEDED PREPARE ALL REQUIRED or DO NOT CLAIM PREVENTION 29. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997, . Das Expires 20 March 2027 [Page 20] Internet-Draft Composite Execution Finality September 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, May 2017, . 30. Informative References [DAS-AGENTIC] Das, S., "Agentic Execution Finality", Work in Progress, Internet-Draft, draft-das-agentic-execution-finality-00, September 2026, . [DAS-HANDLE] Das, S., "Possession Is Not Authority: Execution Handle, Sink Verification, Atomic Consumption, and Finality Receipt", Work in Progress, Internet-Draft, draft-das- execution-handle-00, September 2026, . [DAS-JURISDICTION] Das, S., "Authorized Here, Not Authorized There: Jurisdiction-Bound Execution Finality for Cross-Border and Sovereign Systems", Work in Progress, Internet-Draft, draft-das-jurisdiction-bound-execution-finality-00, September 2026, . [DAS-PATH] Das, S., "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., "Purpose-Bound Execution Finality", Work in Progress, Internet-Draft, draft-das-purpose-execution- finality-00, September 2026, . Das Expires 20 March 2027 [Page 21] Internet-Draft Composite Execution Finality September 2026 [DAS-REG] Das, S., "Illustrative Codes Are Not a Namespace: Registries for Execution-Finality Objects", Work in Progress, Internet-Draft, draft-das-ef-registries-00, 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-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, . Author's Address Sangam Das Independent Balasore Odisha India Phone: +91-9861363532 Email: info@sangamdas.com Das Expires 20 March 2027 [Page 22]