Network Working Group S. K. Das Internet-Draft Independent Researcher Intended status: Informational 22 September 2026 Expires: 26 March 2027 Execution-Finality Architecture for AI and Autonomous Critical Systems draft-das-execution-finality-deployment-01 Abstract AI models, agents, and autonomous services increasingly initiate payments, communications, data releases, infrastructure changes, and physical actions in critical systems. Authentication, authorization, human approval, proof of possession, attestation, policy evaluation, and audit are important, but none of them alone establishes that the exact operation becoming externally effective is the operation that was authorized and remains permitted under current protected state. This document defines an execution-finality architecture in which a proposed operation remains non-effective until a mandatory enforcement function controlling the effectuation boundary reconstructs the actual operation, verifies exact-act binding and current protected state, prevents replay or stale authority, and couples the decision to the resulting consequence through an atomic or equivalently crash-consistent transition. The document explains why latency is only one engineering consideration and is often not the dominant problem. Consequence-path completeness, deterministic act representation, protected state, atomicity, crash recovery, safe degraded operation, and legacy-system integration are usually harder requirements. A detailed FAQ addresses whether placing OAuth at the last irreversible execution boundary is the same architecture. It is not automatically equivalent merely because a token, scope, or sender- constrained proof is checked at that location. An OAuth-protected implementation is functionally equivalent only when it also exclusively mediates every consequence path, reconstructs and binds all consequence-relevant fields, revalidates authoritative current state, enforces replay and generation controls, atomically couples authorization consumption to the exact effect, and provides safe failure and recovery semantics. In that case, the implementation is functioning as the Finality Sink, regardless of terminology. The document also identifies the division of responsibility and possible relevance of OAuth, RATS, WIMSE, Web Bot Auth, other IETF communities, and longer-term IRTF research. This document is architectural and informational; it does not define a wire protocol. Das Expires 26 March 2027 [Page 1] Internet-Draft Execution-Finality Architecture September 2026 Discussion Venue Discussion of this document is intended to determine whether further work belongs in an existing security, authorization, attestation, workload-identity, or application-area venue, or requires cross-area dispatch. Repository and issue-tracker information may be added in a later revision. 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 26 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. Problem, Existing Mechanisms, Residual Gap, and Delta . . 4 1.2. Industry-Standard Terminology and Functional Equivalence . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Clear Differentiation from Traditional Systems and Their Combination . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 9 Das Expires 26 March 2027 [Page 2] Internet-Draft Execution-Finality Architecture September 2026 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Architectural Model . . . . . . . . . . . . . . . . . . . . . 10 4. Deployment Requirements . . . . . . . . . . . . . . . . . . . 11 4.1. Consequence-Path Completeness . . . . . . . . . . . . . . 11 4.2. Deterministic Exact-Act Representation . . . . . . . . . 11 4.3. Protected Current State . . . . . . . . . . . . . . . . . 12 4.4. Atomic Check, Consumption, and Effectuation . . . . . . . 12 4.5. Freshness, Replay, and Generation Control . . . . . . . . 12 4.6. Crash Consistency and Outcome Recovery . . . . . . . . . 13 4.7. Availability and Safe Degraded Operation . . . . . . . . 13 5. Latency Analysis . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Measurement Requirements . . . . . . . . . . . . . . . . 14 6. Addressing Practical Deployment Concerns . . . . . . . . . . 14 6.1. Latency Cost in High-Criticality Systems . . . . . . . . 14 6.2. Legacy Architecture and Deployment Complexity . . . . . . 15 7. Problems That Are Often Harder Than Latency . . . . . . . . . 17 8. Relationship to Existing IETF Mechanisms and Communities . . 17 8.1. FAQ: If OAuth Is Enforced at the Final Effectuation Boundary, Is That the Same Architecture? . . . . . . . . 18 8.2. OAuth and Fine-Grained Authorization . . . . . . . . . . 19 8.3. HTTP Preconditions . . . . . . . . . . . . . . . . . . . 19 8.4. Remote Attestation . . . . . . . . . . . . . . . . . . . 20 8.5. COSE and Protected Objects . . . . . . . . . . . . . . . 20 8.6. WIMSE and Workload-to-Workload Paths . . . . . . . . . . 20 8.7. Web Bot Auth and Automated Web Clients . . . . . . . . . 21 8.8. IRTF and the Internet Research Community . . . . . . . . 21 8.9. Cross-Area Dispatch and Possible Work Products . . . . . 22 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Automated Payment . . . . . . . . . . . . . . . . . . . . 23 9.2. Message or File SEND . . . . . . . . . . . . . . . . . . 23 9.3. Physical or Infrastructure Actuation . . . . . . . . . . 23 10. Illustrative Deployment Profiles . . . . . . . . . . . . . . 23 11. Reference Implementation and Adversarial Validation . . . . . 24 12. Illustrative Binding Representation Profiles . . . . . . . . 25 12.1. Illustrative Financial Command in JSON . . . . . . . . . 25 12.2. Illustrative Cloud Privileged Command in JSON . . . . . 26 12.3. Illustrative CBOR/CDDL Shape . . . . . . . . . . . . . . 26 13. Open Questions for IETF Discussion . . . . . . . . . . . . . 27 14. Possible Next Research Directions . . . . . . . . . . . . . . 28 15. Security Considerations . . . . . . . . . . . . . . . . . . . 29 15.1. Specific Sink Attack and Failure Modes . . . . . . . . . 29 16. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 18. Additional Disclosures and Implementation Resources . . . . . 30 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31 Normative References . . . . . . . . . . . . . . . . . . . . . . 31 Informative References . . . . . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 Das Expires 26 March 2027 [Page 3] Internet-Draft Execution-Finality Architecture September 2026 1. Introduction Networked systems are good at transporting requests and establishing authenticated channels. Authorization systems can express what a principal may request. Proof-of-possession mechanisms can bind use of a credential to a key. Attestation can provide evidence about the operating state of a component. Conditional requests and concurrency controls can prevent some stale updates. These mechanisms remain necessary. However, an authorized request is not necessarily identical to the consequence that is finally produced. Between authorization and effectuation, parameters can be substituted, state can change, authority can be revoked, a request can be replayed, a downstream component can reinterpret data, a crash can create an ambiguous outcome, or an alternate path can bypass the intended enforcement point. This distinction becomes more important when an AI agent, workflow engine, or autonomous service can cause high-impact consequences. A well-authenticated and properly authorized agent can still be mistaken, manipulated, compromised, stale, or operating on an inaccurate representation of the intended act. An execution-finality architecture therefore keeps a candidate operation non-effective until the component controlling the consequence independently determines that the exact operation about to become effective remains permitted under current protected authorization and system state. The determination is coupled to the state transition so that the verified operation cannot be replaced or replayed between check and commit. 1.1. Problem, Existing Mechanisms, Residual Gap, and Delta Vulnerability: An operation may be validly requested or authorized while the final effect differs from, outlives, duplicates, or bypasses that authority. Existing mechanisms: OAuth, fine-grained authorization, sender-constrained tokens, workload identity, secure channels, remote attestation, policy engines, reference monitors, safety interlocks, idempotency keys, conditional requests, database transactions, and audit logs each address important portions of the problem. Das Expires 26 March 2027 [Page 4] Internet-Draft Execution-Finality Architecture September 2026 Why the gap can remain: These mechanisms do not, merely by being present, prove that one non-bypassable component reconstructed the actual act, compared it with current protected state, consumed replay-sensitive authority, and committed the exact consequence as one crash-consistent transition. Architectural delta: Place a mandatory enforcement function at the last component able to prevent the consequence; bind authorization to a deterministic representation of the exact act; revalidate current protected state; and couple allow, consumption, effectuation, and evidence generation. 1.2. Industry-Standard Terminology and Functional Equivalence The term _Finality Sink_ denotes a function, not necessarily a new appliance. Depending on the system, an equivalent implementation might be called a policy enforcement point, reference monitor, transaction coordinator, commit gate, command gate, actuation interlock, egress guard, storage commit hook, kernel mediation point, or hardware-enforced control point. The defining property is placement and control: the function is on every relevant consequence path and retains the ability to prevent the effect. A policy engine that advises another component is not functionally equivalent unless its decision cannot be ignored or replaced before effectuation. An _execution handle_ can be implemented as a bounded capability, transaction authorization object, signed or MAC-protected command envelope, one-time permit, or another non-bearer or sender- constrained object. Its name and encoding are secondary to its function: it binds authority to an exact act and to freshness, destination, generation, and consumption constraints that the enforcing sink can verify. _Non-Effective State_ means that preparation, computation, simulation, staging, or preview has not yet produced the protected external consequence. An operation can exist in queues, memory, or a user interface while remaining non-effective if no bypass path can publish, transmit, commit, transfer, actuate, or render it as the protected effect. _Exact-act binding_ corresponds to cryptographic parameter binding over a deterministic representation of all consequence-relevant fields. _Current-state revalidation_ corresponds to checking protected policy, authorization generation, revocation, quota, Das Expires 26 March 2027 [Page 5] Internet-Draft Execution-Finality Architecture September 2026 resource version, and replay state immediately within the protected commit procedure. _Atomic effectuation_ corresponds to a TOCTOU- resistant check-and-commit transition or an equivalent protocol whose failure modes do not create an unverified effect. 1.3. Clear Differentiation from Traditional Systems and Their Combination Execution finality does not depend on inventing a new name for every underlying mechanism. An implementation may reuse identity systems, OAuth, policy engines, capabilities, remote attestation, reference monitors, database transactions, idempotency controls, trusted hardware, safety interlocks, and audit logs. The architectural distinction is the required relationship among those components at the consequence boundary. Das Expires 26 March 2027 [Page 6] Internet-Draft Execution-Finality Architecture September 2026 TRADITIONAL ASSURANCE INPUTS +----------+ +-------------+ +------+ +-------------+ | Identity | | OAuth / RAR | | RATS | | Web Bot Auth| | / WIMSE | | / DPoP | | | | | +----------+ +-------------+ +------+ +-------------+ \ | | / \ | | / +-----------+------------+-----------+ | +------v-------+ | Candidate Act| NON-EFFECTIVE | + evidence | STATE +------+-------+ | v =========== LAST PREVENTABLE / EFFECTUATION BOUNDARY ========== | +--------------v--------------------------------+ | FINALITY SINK | | | | 1. Reconstruct the actual semantic act | | 2. Verify exact-act binding | | 3. Check current protected state | | 4. Check revocation, generation, and replay | | 5. Atomically consume authority and commit | | 6. Record a crash-resolvable outcome | +--------------+--------------------------------+ | ALLOW ----+---- DENY / SAFE FAILURE | v +----------------------------------+ | EXTERNALLY EFFECTIVE CONSEQUENCE | | Payment / SEND / Write / Actuate | +----------------------------------+ Identity, authorization, attestation, and bot authentication inform the decision. They do not replace boundary enforcement. Figure 1: Traditional assurance inputs and the execution-finality boundary Das Expires 26 March 2027 [Page 7] Internet-Draft Execution-Finality Architecture September 2026 +================+====================+============================+ | Traditional | What it normally | What still has to be | | component or | establishes | established | | combination | | | +================+====================+============================+ | Authentication | Who or which | Whether the exact act | | or workload | workload is making | becoming effective is | | identity | a request | currently permitted | +----------------+--------------------+----------------------------+ | OAuth token, | Delegated | Exact consequence | | scope, RAR, or | authority, | reconstruction, current- | | sender | authorization | state revalidation, one- | | constraint | details, or | time consumption, and | | | possession by the | atomic effectuation | | | intended presenter | | +----------------+--------------------+----------------------------+ | API gateway or | Policy enforcement | Whether downstream | | policy | at an ingress or | transformation, queues, | | enforcement | service boundary | retries, storage, | | point | | alternate egress, and | | | | administrative paths | | | | remain completely mediated | +----------------+--------------------+----------------------------+ | Remote | Evidence that a | Evidence that this exact | | attestation or | component is in an | act was checked against | | trusted | appraised | current authority and | | execution | operating state | coupled to its consequence | | evidence | | | +----------------+--------------------+----------------------------+ | Database | Atomicity and | Whether the transaction | | transaction or | durability for | includes authorization | | atomic commit | participating | consumption and the actual | | | state changes | external consequence, with | | | | no unmediated side effect | +----------------+--------------------+----------------------------+ | Idempotency or | Repeated requests | Whether the key is bound | | duplicate | with a recognized | to the authorized exact | | suppression | key do not create | act and cannot be | | | repeated | substituted, reset, or | | | processing | bypassed | +----------------+--------------------+----------------------------+ | Audit log, | Detection, | Prevention of an | | SIEM, or post- | investigation, or | unauthorized effect and | | event | accountability | unambiguous crash-time | | monitoring | after processing | outcome recovery | +----------------+--------------------+----------------------------+ | Safety | Mandatory | Whether its scope covers | | interlock or | mediation within | every consequence path and | Das Expires 26 March 2027 [Page 8] Internet-Draft Execution-Finality Architecture September 2026 | reference | its defined scope | whether it binds current | | monitor | | authority to the exact | | | | semantic act | +----------------+--------------------+----------------------------+ Table 1: Traditional guarantees and the residual execution- finality question Combining traditional components does not automatically close these gaps. Security properties are not necessarily compositional: a valid token can be checked by a correctly attested gateway, followed by a valid database transaction, while a downstream worker changes the destination, retries after revocation, or produces an external side effect outside that transaction. Every component can work as designed while the end-to-end consequence remains insufficiently controlled. The differentiating invariant is: | No protected consequence may become effective unless one non- | bypassable enforcement procedure reconstructs the actual semantic | act, verifies its exact binding to current protected authority and | state, consumes replay-sensitive authority, and commits that exact | consequence with defined crash semantics. A traditional implementation or combination of traditional components that satisfies this invariant is functionally equivalent to the architecture described here. The difference is not branding or component novelty; it is whether the complete end-to-end property is specified, testable, and, where required across a trust boundary, externally supportable by evidence. 1.4. Scope and Non-Goals This document does not claim that OAuth, remote attestation, proof of possession, conditional requests, database transactions, or existing safety controls are defective. It identifies the additional composition and placement properties required when those mechanisms are used to control an externally meaningful consequence. This document does not define a universal canonicalization format, authorization language, ledger, consensus algorithm, trusted execution environment, or wire protocol. It also does not assert that every operation requires identical assurance or latency. Deployments are expected to select profiles proportional to consequence and threat. Das Expires 26 March 2027 [Page 9] Internet-Draft Execution-Finality Architecture September 2026 2. Terminology 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, as shown here. Candidate Act: A fully parameterized operation proposed for effectuation but not yet accepted as the protected external consequence. Effectuation Boundary: The last system boundary at which the protected consequence can still be prevented. Finality Sink (FS): The mandatory function controlling the Effectuation Boundary and deciding whether the Candidate Act may become effective. Binding Representation: A deterministic representation of all consequence-relevant fields used to bind authority to the Candidate Act. Protected State: Authorization, revocation, generation, quota, replay, resource- version, and policy state that an untrusted proposer cannot undetectably modify. Finality Receipt: Evidence identifying the verified act, decision context, relevant state version, outcome, and, where appropriate, the resulting state transition. 3. Architectural Model A proposer constructs a Candidate Act. Authorization services, policy engines, human approvals, and attestation services may contribute evidence. The Candidate Act remains non-effective until the Finality Sink reconstructs the act from the parameters actually presented to the protected resource or actuator. Das Expires 26 March 2027 [Page 10] Internet-Draft Execution-Finality Architecture September 2026 Proposer / Agent | | Candidate Act + authority + evidence v Preparation / Queue / Preview (non-effective) | v +-----------------------------------------------+ | Finality Sink at Effectuation Boundary | | reconstruct -> bind -> check current state | | -> consume authority -> commit -> receipt | +-----------------------------------------------+ | v Payment / SEND / Write / Actuation / Publication (externally effective) Figure 2: Abstract effectuation flow The Finality Sink need not repeat every upstream policy computation. It needs sufficient trusted inputs and protected state to determine that the actual act is within the current authorization. It also needs exclusive or complete mediation over the protected consequence path. 4. Deployment Requirements 4.1. Consequence-Path Completeness Every path capable of producing the protected consequence MUST pass through an equivalent enforcement decision. This includes administrative interfaces, retry workers, batch jobs, direct database access, fallback transports, local IPC, alternate network egress, maintenance modes, and recovery procedures. A deployment SHOULD maintain a consequence-path inventory and test negative controls that attempt effectuation without required evidence. The expected result is denial without a protected external effect. 4.2. Deterministic Exact-Act Representation The Binding Representation MUST cover every field that can materially change the consequence. Examples include operation type, resource, destination, amount or quantity, content digest, purpose, tenant, jurisdiction, expiry, permitted transformation, and relevant resource version. Das Expires 26 March 2027 [Page 11] Internet-Draft Execution-Finality Architecture September 2026 Canonicalization rules MUST be deterministic across participating implementations. Deployments MUST NOT treat unknown fields as absent when an unknown field can affect interpretation. Aliases, redirects, Unicode normalization, number formats, time zones, content transformations, and downstream default values require explicit treatment. 4.3. Protected Current State The sink MUST evaluate the act against an authoritative state that the proposer cannot forge. At minimum, the state needed for the selected profile can include authorization generation, revocation, expiry, replay or consumption status, quota, resource version, policy version, and operational mode. Cached state MAY be used where bounded staleness is explicitly accepted. The profile MUST define the maximum permitted staleness and the consequence of uncertainty. Missing state is not equivalent to an empty or permissive state. 4.4. Atomic Check, Consumption, and Effectuation The authorization decision, replay-sensitive consumption, and effectuation MUST be coupled so that a concurrent update or crash cannot substitute an unchecked act or create multiple effects. A local database transaction, compare-and-swap, transactional outbox, hardware state transition, consensus transaction, or application- specific commit protocol may provide this property. Where the consequence cannot participate in the same atomic transaction, the deployment MUST specify an equivalent state machine, idempotency rule, reconciliation procedure, and durable outcome classification. Merely writing an audit record before or after an unrelated side effect is insufficient. 4.5. Freshness, Replay, and Generation Control A high-impact execution authorization SHOULD be bounded by expiry, nonce or unique identifier, authorization generation, destination, and permitted use count. Single-use authority MUST be consumed in a concurrency-safe manner. Proof of possession, such as DPoP [RFC9449], reduces the usefulness of stolen tokens but does not by itself establish that the key holder is executing the exact currently permitted consequence. Sender constraint and exact-act finality are complementary properties. Das Expires 26 March 2027 [Page 12] Internet-Draft Execution-Finality Architecture September 2026 4.6. Crash Consistency and Outcome Recovery After restart, the system MUST distinguish at least: not committed, committed exactly once, denied, and indeterminate. An indeterminate outcome MUST NOT be automatically retried when retry could duplicate an irreversible consequence. Receipts and recovery records SHOULD bind the Candidate Act digest, decision, protected-state generation, consumption record, sink identity where relevant, and resulting transaction or consequence identifier. 4.7. Availability and Safe Degraded Operation Fail-closed behavior prevents uncertain authority from becoming an effect, but it can reduce availability. A deployment MUST define behavior for loss of policy service, clock, revocation feed, attestation service, protected storage, or network connectivity. Emergency or degraded modes MUST NOT silently become bypass modes. They require separately bounded authority, narrowed operations, short lifetimes, durable evidence, and explicit recovery semantics. Safety-critical systems may define a domain-specific fail-safe action that differs from simply doing nothing. 5. Latency Analysis Verification adds work to the critical path, but raw cryptographic verification is only one component. A useful latency budget is: T(finality) = T(parse/canonicalize) + T(cryptographic verification) + T(state lookup) + T(policy check) + T(contention) + T(commit) + T(evidence) In many deployments, remote state lookup, lock contention, durable storage, consensus, and downstream commit dominate signature or MAC verification. Therefore, reporting only cryptographic operations per second is not sufficient. Implementations can reduce latency through sink-local protected state, prevalidated policy snapshots, bounded capabilities, hardware acceleration, batching where semantics permit, sharding replay state, and avoiding synchronous remote calls. Precomputation MUST NOT freeze a decision that depends on mutable state unless the accepted staleness is explicit. Das Expires 26 March 2027 [Page 13] Internet-Draft Execution-Finality Architecture September 2026 Latency optimization cannot remove a required field from exact-act binding, weaken freshness below the selected profile, or separate verification from commit in a way that reintroduces a time-of-check/ time-of-use gap. 5.1. Measurement Requirements Evaluation SHOULD report median and tail latency, throughput, contention level, protected-state locality, durability mode, failure rate, recovery time, and the number of consequence paths tested. Benchmarks SHOULD include replay, revocation races, concurrent use, crash injection, stale state, malformed representations, and attempted bypass. A fast implementation that does not completely mediate the consequence path is not an execution-finality implementation for that consequence. 6. Addressing Practical Deployment Concerns 6.1. Latency Cost in High-Criticality Systems Introducing cryptographic verification, freshness checks, replay protection, protected-state lookup, and exact-act validation at an execution boundary can add processing overhead. Execution-finality architecture is primarily intended for high- criticality systems and high-consequence operations, where some bounded additional latency may be acceptable if it materially reduces the risk of catastrophic, irreversible, or safety-critical consequences. In such environments, the relevant engineering trade-off is not simply maximum speed. It is whether a small and bounded verification delay is preferable to an unauthorized action that could cause financial loss, infrastructure disruption, data exfiltration, unsafe physical actuation, or other catastrophic consequences. For example, an additional verification step may be acceptable before: * transferring a large financial value; * sending highly sensitive data to an external destination; * changing a power-grid configuration; * issuing an industrial-control command; Das Expires 26 March 2027 [Page 14] Internet-Draft Execution-Finality Architecture September 2026 * modifying critical telecommunications routing; * committing a privileged cloud action; or * releasing a safety-critical autonomous-system command. The architecture does not assume that every operation requires the same verification depth, nor that every check must use expensive public-key cryptography. The relevant engineering question is therefore not whether execution finality has zero latency, but whether the added latency is proportionate to the consequence being protected. Deployments can reduce overhead through mechanisms such as hardware- assisted verification, symmetric MACs where appropriate, cached or prevalidated policy state, compact bounded execution capabilities, monotonic counters, generation epochs, local protected-state verification, precomputation, batching, and selective enforcement based on consequence sensitivity. The architecture therefore does not require placing an expensive cryptographic transaction in the critical path of every CPU instruction or memory access. The Finality Sink should be positioned at the meaningful effectuation boundary where an operation acquires external, persistent, privileged, safety-relevant, or otherwise material consequence. This distinction is important. A system may perform millions of speculative or internal computations without finality checks, while requiring final verification only when an operation crosses into a protected consequence. | For high-criticality systems, bounded latency is often an | acceptable engineering cost; catastrophic consequence is not. 6.2. Legacy Architecture and Deployment Complexity Retrofitting existing enterprise systems, operating systems, telecommunications infrastructure, industrial systems, and hardware platforms with mandatory execution-finality enforcement can be difficult. A universal immediate redesign of existing infrastructure would be unrealistic. Execution finality should therefore be understood as a deployable architectural pattern rather than a requirement for simultaneous replacement of entire technology stacks. Das Expires 26 March 2027 [Page 15] Internet-Draft Execution-Finality Architecture September 2026 In many environments, the enforcement point can initially be introduced at existing choke points, including API gateways, service meshes, database commit paths, payment gateways, secure proxies, storage controllers, egress gateways, network control interfaces, hypervisors, privileged system services, hardware security modules, trusted execution environments, industrial control gateways, and telecom policy or signaling enforcement points. This allows incremental deployment. A legacy application may continue generating requests in its existing form while a new enforcement component verifies whether the exact requested consequence remains authorized before the irreversible operation is committed. Legacy application / AI agent | | existing request v Compatibility / enforcement gateway | v Execution-finality verification | +-----+-----+ | | ALLOW DENY | | v v Existing No protected backend effectuation Figure 3: Incremental enforcement for a legacy deployment This permits deployment without requiring every upstream component to be rewritten immediately. Over time, tighter integration can move the enforcement point closer to the true consequence boundary, for example, from an application gateway to a storage controller, network interface, device firmware, secure processor, or hardware execution boundary. The practical migration path is gateway enforcement to native system integration to hardware-assisted enforcement, where justified by the risk and performance requirements. Das Expires 26 March 2027 [Page 16] Internet-Draft Execution-Finality Architecture September 2026 The presence of deployment difficulty does not remove the underlying security problem. It instead means that execution-finality mechanisms should support staged adoption, backward compatibility, multiple enforcement profiles, and progressively stronger assurance levels. 7. Problems That Are Often Harder Than Latency Boundary identification: The apparent API endpoint may not be the last preventable point. Queues, proxies, schedulers, databases, device firmware, and downstream providers can move the true boundary. Legacy integration: Existing systems may expose no transactional hook spanning authorization consumption and the protected consequence. Semantic agreement: Different services may interpret the same field differently, making a shared digest misleading unless the semantics are versioned and testable. Operational ownership: No single operator may control the authorization service, transport, final resource, and audit system. Cross-domain assurance requires explicit trust and failure contracts. Administrative bypass: Privileged maintenance paths can invalidate complete mediation unless they are included in the threat model and evidence model. Availability policy: Operators must decide which consequences stop, degrade, or enter a separately authorized emergency mode when verification dependencies fail. Assurance evidence: A relying party needs evidence of the sink's placement and behavior, not merely evidence that an upstream service issued an authorization. 8. Relationship to Existing IETF Mechanisms and Communities Das Expires 26 March 2027 [Page 17] Internet-Draft Execution-Finality Architecture September 2026 8.1. FAQ: If OAuth Is Enforced at the Final Effectuation Boundary, Is That the Same Architecture? *It can be functionally equivalent, but boundary placement alone does not make it equivalent.* If an implementation merely validates an OAuth access token, its scopes, or a sender-constrained proof at the last API endpoint, it establishes that the requester is entitled to make a class of requests. It does not necessarily establish that the exact consequence about to occur is identical to what was authorized, remains permitted under current protected state, has not already been consumed, and will be committed without a substitution or time-of- check/time-of-use gap. An OAuth-protected resource server at the final boundary is functionally equivalent to an execution-finality architecture for a defined consequence if, and only if, it also: * exclusively mediates every path capable of producing that consequence; * reconstructs the actual operation from the parameters that the protected resource, ledger, egress mechanism, or actuator will use; * binds and compares all consequence-relevant fields, including destination and permitted transformations, against the granted authorization; * checks authoritative current revocation, generation, expiry, quota, resource-version, and replay state as required by the selected profile; * atomically couples the allow decision, any single-use consumption, and the exact effectuation, or supplies an equivalent crash- consistent transaction protocol; and * fails safely and produces durable evidence sufficient to resolve committed, denied, and indeterminate outcomes. Das Expires 26 March 2027 [Page 18] Internet-Draft Execution-Finality Architecture September 2026 When all of these properties are present, the difference is terminological rather than functional: that OAuth deployment is acting as the Finality Sink. OAuth supplies the authorization framework and may carry fine-grained authorization data or proof-of- possession evidence; the application-specific enforcement and transaction design supplies the execution-finality semantics. Conversely, describing atomicity, complete mediation, or fail-closed behavior as an internal design choice does not make those properties verifiable across a trust boundary. A relying party can claim equivalence only to the extent that the deployment profile specifies and, where required, evidences them. 8.2. OAuth and Fine-Grained Authorization Rich Authorization Requests [RFC9396] can express fine-grained authorization details. DPoP [RFC9449] can sender-constrain tokens. These can supply authority and proof inputs to a Finality Sink. They are not automatically execution finality because a deployment still needs to define which exact fields are bound, how the sink reconstructs the actual consequence, which protected state is current, how single use is consumed, and how decision and effectuation are coupled. If one resource server already performs all these functions at the irreversible boundary, it may be functionally equivalent regardless of terminology. The relevance to the OAuth Working Group (https://datatracker.ietf.org/wg/oauth/about/) is primarily at the authorization interface: how transaction-specific details, resource identity, sender constraint, freshness, and authorization-server state are conveyed to a protected resource. Application-specific canonicalization, physical actuation, database atomicity, and crash recovery are not automatically OAuth protocol problems. A useful OAuth-related output could therefore be a precise statement of which execution-finality inputs an OAuth profile carries and which guarantees remain the responsibility of the resource server and its commit path. 8.3. HTTP Preconditions The If-Match mechanism in [RFC9110] can prevent a method from being applied when the current representation no longer matches a supplied entity tag. This is a useful state-continuity primitive. It does not by itself bind all authorization, destination, replay, and downstream-effect semantics, but it may form part of a finality profile. Das Expires 26 March 2027 [Page 19] Internet-Draft Execution-Finality Architecture September 2026 8.4. Remote Attestation The RATS architecture [RFC9334] supports appraisal of evidence about whether an attester is in an intended operating state. Such Attestation Results can inform whether a sink or proposer is acceptable. Attestation of software or platform state is not identical to evidence that one exact act was checked against current authority and atomically effected. A useful integration would bind the sink's attested identity and security version to its Finality Receipt. The relevance to the RATS Working Group (https://datatracker.ietf.org/wg/rats/about/) is whether Evidence, Reference Values, Endorsements, or Attestation Results can describe trustworthy properties of a Finality Sink, such as approved code identity, protected-state support, rollback resistance, and enforcement configuration. The architecture must keep two claims distinct: attestation can support confidence that a sink has certain properties, while a Finality Receipt concerns the sink's processing of a particular act and consequence. 8.5. COSE and Protected Objects COSE [RFC9052] can protect an execution authorization, Binding Representation, or receipt. COSE supplies cryptographic containers and algorithms; application profiles still need to specify semantics, mandatory fields, canonicalization, critical parameters, freshness, and consumption behavior. 8.6. WIMSE and Workload-to-Workload Paths The Workload Identity in Multi-System Environments (WIMSE) (https://datatracker.ietf.org/wg/wimse/about/) work addresses identity and access-management problems for workloads at runtime across service and cloud boundaries. WIMSE can help establish which workload is calling, its execution context, how workload credentials are presented, and how service-to-service trust is constructed. Execution finality addresses the adjacent question of what exact consequence that authenticated workload may cause now. A multi- service path can preserve workload identity while still allowing parameter drift, stale authorization, replay, a changed destination, or a side effect outside the protected transaction. A useful integration point is to bind WIMSE workload identity and relevant execution-context claims into the exact-act authorization and receipt while leaving application-specific consequence semantics to the final resource or actuator. Das Expires 26 March 2027 [Page 20] Internet-Draft Execution-Finality Architecture September 2026 This document does not assert that general transaction or actuation semantics fall within the WIMSE charter. The relevance is the interface between trustworthy workload identity and enforcement of a workload's exact externally effective act. 8.7. Web Bot Auth and Automated Web Clients The Web Bot Authentication (webbotauth) (https://datatracker.ietf.org/wg/webbotauth/about/) work focuses on cryptographically authenticating automated clients and providing additional information about their operators to Web sites. This is directly useful for establishing bot identity, provenance, accountability, and site policy inputs. Bot authentication does not by itself determine whether a particular purchase, publication, account modification, data export, message SEND, or other irreversible Web action remains authorized in its final form. A correctly authenticated bot can be compromised, confused, stale, or acting outside a transaction-specific grant. Execution finality can consume authenticated bot and operator information as inputs, then bind them to the actual resource, destination, content, action, current site state, and commit result. The possible community contribution is not to expand Web Bot Auth into a universal transaction protocol. It is to ensure that bot- authentication outputs can be securely carried into resource-specific enforcement and are not mistaken for proof that the final consequence was authorized. 8.8. IRTF and the Internet Research Community Some questions raised here are architectural or empirical rather than ready for immediate protocol standardization. They include formal models for exact-act equivalence, composition of independently correct security controls, proof of consequence-path completeness, latency and availability tradeoffs, crash-time ambiguity, cross- operator verification, and privacy-preserving finality evidence. The Internet Research Task Force (IRTF) (https://www.irtf.org/), its open discussions, and the Applied Networking Research Workshop can provide venues for research and measurements without prematurely assigning a standards solution. Depending on the use case, more focused discussion could also be relevant to: * the Thing-to-Thing Research Group (T2TRG), where autonomous agents interact with constrained devices and physical effects; Das Expires 26 March 2027 [Page 21] Internet-Draft Execution-Finality Architecture September 2026 * the Network Management Research Group (NMRG), where agentic systems can change operational network state; * the Privacy Enhancements and Assessments Research Group (PEARG), for privacy leakage and minimization in receipts and protected evidence; * the Decentralization of the Internet Research Group (DINRG), where authority and enforcement span independently controlled systems; and * the ACM/IRTF Applied Networking Research Workshop (ANRW), for reproducible prototypes, benchmarks, failure injection, and deployment measurements. This list identifies research intersections, not endorsement, charter acceptance, or a claim that any named research group is the correct final home. 8.9. Cross-Area Dispatch and Possible Work Products No single existing working group necessarily owns the entire problem. Authorization syntax may relate to OAuth; attested enforcement properties may relate to RATS; workload context may relate to WIMSE; automated-client identity may relate to Web Bot Auth; protected object formats may relate to COSE; and final consequence semantics remain application-specific. An initial cross-area dispatch discussion could separate possible work products rather than proposing one universal protocol: 1. an informational problem statement and terminology; 2. a common claim or receipt information model; 3. application-specific exact-act and atomic-effectuation profiles; 4. attestation claims describing Finality Sink properties; 5. interoperability and adversarial test requirements; and 6. research questions that should remain in the IRTF until evidence supports standardization. Dispatch should test whether existing protocols already provide functional equivalence in a given application before creating new protocol machinery. Das Expires 26 March 2027 [Page 22] Internet-Draft Execution-Finality Architecture September 2026 9. Examples 9.1. Automated Payment An agent is authorized to pay a named beneficiary up to a stated amount before an expiry. The protected ledger or payment connector reconstructs the actual debit account, beneficiary, amount, currency, rail, fees, and execution time. It verifies the bound authorization and current generation, checks revocation and balance policy, atomically consumes the one-time handle, commits the transfer, and records the resulting transaction identifier. Checking the token only at an agent gateway is insufficient if a downstream component can replace the beneficiary or retry the payment after an ambiguous timeout. 9.2. Message or File SEND An agent is authorized to send one identified document to one recipient through an approved service. The egress sink reconstructs the actual content digest, recipient, destination service, visibility, permitted transformation, and policy generation. It consumes the authority and releases the bytes as one controlled transition. Approval of a preview is insufficient if the attachment, recipient, link target, or access-control setting can change after approval. The sink must bind what the recipient can actually obtain, not merely what the user interface displayed. 9.3. Physical or Infrastructure Actuation An autonomous service proposes a configuration change or actuator command. The command gate verifies the exact target, command parameters, allowed operating envelope, current controller generation, freshness, and safety state. It then commits the command through the only actuation path. When immediate inaction is itself unsafe, the profile defines an independently bounded fail-safe action. 10. Illustrative Deployment Profiles Local low-latency profile: Sink-local keys and replay state; deterministic bounded act; local atomic transaction; suitable for high-rate API, kernel, accelerator, or device enforcement. Das Expires 26 March 2027 [Page 23] Internet-Draft Execution-Finality Architecture September 2026 Distributed transaction profile: Authority and effect span services; uses a transaction state machine, durable idempotency, fencing generations, and explicit indeterminate-outcome handling. Safety-critical profile: Hardware or firmware mediation, attested sink state, bounded offline authority, deterministic timing, and domain-specific fail- safe behavior. Audit-enhanced profile: Externally verifiable receipts and append-only evidence supplement prevention where independent assurance is required. Profiles should specify which guarantees are local assertions and which can be verified across an organizational boundary. 11. Reference Implementation and Adversarial Validation The adversarial implementation referenced in the Additional Disclosures section provides an executable way to test whether the architectural invariants survive mutation, concurrency, stale authority, replay, crash conditions, canonicalization differences, unavailable consume state, and simulated bypass paths. The current repository reports 36/36 adversarial and positive unit tests passed, 12/12 profile and variable-matrix cases passed, a deterministic 2,000-case mutation and canonicalization probe, cross-language digest agreement across Python, Node.js, and Go, and single-use concurrency races at 2, 8, 32, and 64 workers in which exactly one commit succeeded. The harness is particularly relevant to canonicalization ambiguity because it includes deterministic canonicalization vectors, key- reordering tests, mutation probes, Unicode and integer cases, and cross-language digest comparison. It is also relevant to replay and atomic-consumption claims because the strict path reconstructs the live Candidate Act, rechecks sink, generation, revocation, act digest, optional key binding, and reuse state, and serializes verification, consumption, and the protected local commit. The harness should not be treated as proof of production deployment security. It does not by itself establish non-bypassability in a commercial payment rail, cloud platform, industrial controller, or hardware execution path. In particular, dedicated tests are still needed for restored-snapshot rollback resistance, large-scale verification-exhaustion and denial-of-service behavior, HSM or TEE failure modes, distributed replicas, remote effect atomicity, and site-specific alternate paths. Das Expires 26 March 2027 [Page 24] Internet-Draft Execution-Finality Architecture September 2026 Reference implementation: Execution Handle, Exact-Act Binding, Sink Verification, Atomic Consumption, and Adversarial Test Harness (https://github.com/sangmdas/Execution-Handle-Exact-Act-Binding-Sink- Verification-Atomic-Consumption-Adversarial-Test-Harness). 12. Illustrative Binding Representation Profiles The following examples are non-normative and are included to make the Binding Representation concrete. They are not proposed wire formats and do not imply adoption by any named payment, cloud, or infrastructure provider. A real profile would need to define field semantics, canonicalization, type limits, mandatory and optional fields, unknown-field handling, protected-state sources, and the exact consequence boundary. 12.1. Illustrative Financial Command in JSON A high-impact payment profile could bind the exact amount, currency, source resource, beneficiary, purpose, state generations, expiry, unique nonce, and intended Finality Sink: { "profile": "ef-financial-01", "act_type": "PAYMENT_POST", "actor": "agent-7", "resource": "acct:source-A", "operation": "post_payment", "arguments": { "amount_minor": 12500, "currency": "INR" }, "destination": "acct:beneficiary-A", "purpose": "invoice_settlement", "jurisdiction": "IN", "resource_version": "ledger:99182", "policy_generation": 42, "revocation_generation": 8, "expires_at": 2000000060, "nonce": "n-7f2c9a", "finality_sink": "payment-post" } Figure 4 Das Expires 26 March 2027 [Page 25] Internet-Draft Execution-Finality Architecture September 2026 The sink would reconstruct these fields from the operation actually presented to the protected payment connector or ledger. A change in beneficiary, amount, currency, source account, purpose, generation, resource version, or other consequence-relevant field would therefore produce a different Binding Representation and would not satisfy the exact-act comparison. 12.2. Illustrative Cloud Privileged Command in JSON A cloud-control profile could similarly bind a privileged action to the exact account, role, policy object, target, purpose, tenant, and current authorization state: { "profile": "ef-cloud-admin-01", "act_type": "CLOUD_PRIVILEGED_CHANGE", "actor": "workload:ops-agent-3", "resource": "iam:role/ProductionDeployer", "operation": "attach_policy", "arguments": { "policy_digest": "sha256:EXAMPLE", "target_role": "ProductionDeployer" }, "destination": "cloud-account:123456789012", "tenant": "example-enterprise", "purpose": "approved_deployment", "jurisdiction": "EU", "resource_version": "iam-state:8841", "policy_generation": 77, "revocation_generation": 19, "expires_at": 2000000030, "nonce": "n-cloud-19a2", "finality_sink": "cloud-privileged-commit" } Figure 5 The same structure can be used for other cloud providers or private infrastructure by substituting provider-specific resource identifiers and semantics. The important property is not the field names but deterministic binding of every field that can materially change the protected consequence. 12.3. Illustrative CBOR/CDDL Shape A compact CBOR profile could express the same information. The following CDDL-like shape is illustrative only: Das Expires 26 March 2027 [Page 26] Internet-Draft Execution-Finality Architecture September 2026 binding-representation = { "profile": tstr, "act_type": tstr, "actor": tstr, "resource": tstr, "operation": tstr, "arguments": { * tstr => any }, "destination": tstr, ? "tenant": tstr, ? "purpose": tstr, ? "jurisdiction": tstr, ? "resource_version": tstr, "policy_generation": uint, "revocation_generation": uint, "expires_at": uint, "nonce": tstr, "finality_sink": tstr } Figure 6 A CBOR profile intended for interoperable security use would additionally need deterministic encoding requirements, duplicate-key rejection, numeric and string normalization rules, treatment of tags and unknown members, and an explicit rule that fields affecting downstream interpretation cannot be silently omitted from the protected representation. 13. Open Questions for IETF Discussion 1. Should a common information model identify the act digest, semantic profile, sink, authorization generation, state generation, consumption identifier, outcome, and receipt? 2. Which existing application protocols already provide functional equivalence, and which need explicit effectuation-bound profiles? 3. How should canonicalization and semantic-version negotiation be expressed without encouraging generic but ambiguous action schemas? 4. Can RATS Evidence or Attestation Results establish properties of an enforcement sink without confusing platform state with proof of a particular effect? 5. Which guarantees require application-specific transaction semantics rather than a general Internet protocol? Das Expires 26 March 2027 [Page 27] Internet-Draft Execution-Finality Architecture September 2026 6. How should latency, availability, and assurance levels be reported so deployments can make comparable claims? 14. Possible Next Research Directions Sector-specific architectural blueprints: Develop concrete deployment models showing how a Finality Sink could operate inside specific high-criticality environments, for example at a SWIFT-connected payment execution gateway, a cloud infrastructure control plane, or an AWS IAM-governed privileged- action boundary. The objective would be to show exactly where verification occurs, what protected state is consulted, and how an unauthorized or substituted AI-generated action is prevented from becoming effective. Threat modeling of the Finality Sink: Examine the Finality Sink itself as a security-critical component. This should include bypass attempts, denial-of-service or flooding attacks, replay, malformed or deceptive requests, compromised upstream agents, state manipulation, privilege escalation, race conditions, and attempts to separate verification from the final state transition. The analysis should define how the enforcement boundary remains fail-closed and resistant to circumvention. Alignment with existing standards and frameworks: Map execution-finality functions against established NIST, ISO/ IEC, cybersecurity, AI-risk, and critical-infrastructure frameworks. The purpose would not be to claim that existing standards already require execution finality, but to identify where concepts such as access control, reference monitoring, least privilege, auditability, resilience, secure execution, risk management, and fail-safe operation could provide an integration path for execution-finality mechanisms. Adversarial harness expansion: Extend the existing adversarial test harness with dedicated restored-snapshot rollback tests, high-rate verification- exhaustion tests, resource-budget measurements, distributed consume-state failure cases, and provider-specific bypass-path experiments. The objective is to distinguish properties already demonstrated by the reference implementation from properties that require stronger deployment-specific evidence. Binding Representation profile prototyping: Develop interoperable experimental JSON and deterministic CBOR profiles for selected high-impact domains, beginning with payment execution and privileged cloud-control actions. Each profile should identify all consequence-relevant fields, define Das Expires 26 March 2027 [Page 28] Internet-Draft Execution-Finality Architecture September 2026 canonicalization and unknown-field behavior, specify protected- state generations and freshness, and include positive and adversarial test vectors. These directions are intended as research and deployment questions rather than claims of adoption, endorsement, or existing requirements by SWIFT, AWS, NIST, ISO/IEC, or any other named organization. 15. Security Considerations The Finality Sink is a high-value target. Compromise can authorize effects, suppress denials, falsify state, or issue misleading receipts. Implementations should minimize the trusted computing base, separate duties where appropriate, protect keys and state, authenticate updates, and support secure recovery and rotation. Replay protection must remain correct under concurrency, partition, restore, and rollback. Generation and rollback protections need to remain valid across crash recovery, backup restoration, migration, and replicated-state repair. Receipts do not prevent a consequence by themselves. A receipt is useful only when it is bound to an enforcement transition whose placement and integrity are within the relying party's threat model. Fail-open fallbacks, diagnostic endpoints, privileged repair paths, direct storage access, and alternate egress routes can defeat the architecture. They must be removed, equivalently mediated, or explicitly excluded from the claimed guarantee. 15.1. Specific Sink Attack and Failure Modes * *Snapshot Rollbacks:* Restoring old snapshots of protected storage can resurrect already-consumed or revoked authority. Deployments therefore need rollback-resistant protected storage, monotonic counters, generation fencing, or an equivalent mechanism that prevents restored state from silently reviving stale authority. * *Canonicalization Ambiguity:* If the Finality Sink interprets a consequence-relevant field differently from the downstream executor, an attacker may exploit the semantic difference even when the same bytes appear to have been validated. Profiles therefore need deterministic encodings, covered-field rules, semantic versions, and explicit rejection behavior for unknown, duplicate, aliased, normalized, or ambiguously transformed values. Das Expires 26 March 2027 [Page 29] Internet-Draft Execution-Finality Architecture September 2026 * *Verification Exhaustion:* The Finality Sink is a high-value availability target. An attacker may attempt to exhaust cryptographic verification, protected-state lookup, replay-state, or durable-commit resources. Deployments should use aggressive admission control, rate limiting, request shaping, quotas, and inexpensive pre-validation before expensive cryptographic or transactional work. These early controls must not replace the final protected execution decision. 16. Privacy Considerations Binding Representations and receipts may reveal destinations, amounts, recipients, content identifiers, purposes, or organizational policy. Deployments should minimize exposed fields, use keyed or domain-separated digests where appropriate, encrypt sensitive evidence, limit retention, and prevent cross-context correlation. Auditability does not require unrestricted observability. A verifier may need proof that mandatory checks occurred without receiving the underlying personal or confidential data. 17. IANA Considerations This document has no IANA actions. 18. Additional Disclosures and Implementation Resources *Related publications:* * From AI Hotlines to Execution Boundaries: A Sovereignty-Preserving Middle Ground for U.S.-China AI Safety (https://zenodo.org/ records/22897705). This publication discusses execution-finality architecture as a possible sovereignty-preserving technical layer for cross-jurisdictional AI safety and critical-system cooperation without requiring mutual trust in model internals. * The Internet Solved Communication. It Never Solved Authority. (https://zenodo.org/records/22082995) This publication provides the broader architectural disclosure separating computation, communication, authorization, and the final authority to produce an externally effective consequence. *Selected implementation and validation resources:* * Execution Handle, Exact-Act Binding, Sink Verification, Atomic Consumption, and Adversarial Test Harness (https://github.com/sangmdas/Execution-Handle-Exact-Act-Binding- Sink-Verification-Atomic-Consumption-Adversarial-Test-Harness). Das Expires 26 March 2027 [Page 30] Internet-Draft Execution-Finality Architecture September 2026 This repository exercises exact-act binding, sink verification, one-time consumption, canonicalization, replay, concurrency, crash, and bypass-related properties. * Preventing AI Hallucinations and Unauthorized Actions - Runnable Reference Implementation (https://github.com/sangmdas/Preventing- AI-Hallucinations-and-Unauthorized-Actions-Runnable-Reference- Implementation). This repository demonstrates Candidate Act handling, non-effective state, validation evidence, scoped execution handles, and Finality Sink verification for AI-generated actions. * Payment Execution Finality for Agentic API and Automated Payments - Runnable Reference Implementation (https://github.com/sangmdas/ Payment-Execution-Finality-for-Agentic-API-and-Automated-Payments- Runnable-Reference-Implementation). This repository provides a payment-domain example for exact beneficiary, amount, authorization, freshness, replay, and final execution control. * Execution Finality for GPU, AI Accelerators, and Confidential Workloads (https://github.com/sangmdas/Execution-Finality-for-GPU- AI-Accelerators-and-Confidential-Workloads). This repository provides a hardware and accelerator-oriented deployment reference for enforcing consequence control near compute, memory, egress, and confidential-workload boundaries. These references are supplied for transparency, reproducibility, and architectural context. Their inclusion does not imply IETF endorsement, standards-track adoption, production certification, or independent validation. Their presence does not alter the IETF Trust provisions applicable to this document and should not be interpreted as a software or patent license beyond the terms explicitly stated at each resource. Acknowledgements The author thanks reviewers who distinguished authorization of a request from control of the final externally effective act, and who emphasized the need to describe functional equivalence using established security, transaction, and control-system terminology. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Das Expires 26 March 2027 [Page 31] Internet-Draft Execution-Finality Architecture September 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Informative References [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . Author's Address Sangam Kumar Das Independent Researcher India Email: info@sangamdas.com Das Expires 26 March 2027 [Page 32]