Network Working Group S. K. Das Internet-Draft Independent Researcher Intended status: Informational 21 September 2026 Expires: 25 March 2027 Execution-Finality Architecture for AI and Autonomous Critical Systems draft-das-execution-finality-deployment-00 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 25 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 25 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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 25 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. Problems That Are Often Harder Than Latency . . . . . . . . . 14 7. Relationship to Existing IETF Mechanisms and Communities . . 15 7.1. FAQ: If OAuth Is Enforced at the Final Effectuation Boundary, Is That the Same Architecture? . . . . . . . . 15 7.2. OAuth and Fine-Grained Authorization . . . . . . . . . . 16 7.3. HTTP Preconditions . . . . . . . . . . . . . . . . . . . 16 7.4. Remote Attestation . . . . . . . . . . . . . . . . . . . 17 7.5. COSE and Protected Objects . . . . . . . . . . . . . . . 17 7.6. WIMSE and Workload-to-Workload Paths . . . . . . . . . . 17 7.7. Web Bot Auth and Automated Web Clients . . . . . . . . . 18 7.8. IRTF and the Internet Research Community . . . . . . . . 18 7.9. Cross-Area Dispatch and Possible Work Products . . . . . 19 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Automated Payment . . . . . . . . . . . . . . . . . . . . 20 8.2. Message or File SEND . . . . . . . . . . . . . . . . . . 20 8.3. Physical or Infrastructure Actuation . . . . . . . . . . 20 9. Illustrative Deployment Profiles . . . . . . . . . . . . . . 20 10. Open Questions for IETF Discussion . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 14. Additional Disclosures and Implementation Resources . . . . . 22 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 Normative References . . . . . . . . . . . . . . . . . . . . . . 23 Informative References . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 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. Das Expires 25 March 2027 [Page 3] Internet-Draft Execution-Finality Architecture September 2026 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. 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. Das Expires 25 March 2027 [Page 4] Internet-Draft Execution-Finality Architecture September 2026 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, 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. Das Expires 25 March 2027 [Page 5] Internet-Draft Execution-Finality Architecture September 2026 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 25 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 25 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 25 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 25 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 25 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 25 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 25 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 25 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. 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. Das Expires 25 March 2027 [Page 14] Internet-Draft Execution-Finality Architecture September 2026 Assurance evidence: A relying party needs evidence of the sink's placement and behavior, not merely evidence that an upstream service issued an authorization. 7. Relationship to Existing IETF Mechanisms and Communities 7.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 25 March 2027 [Page 15] 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. 7.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. 7.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 25 March 2027 [Page 16] Internet-Draft Execution-Finality Architecture September 2026 7.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. 7.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. 7.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 25 March 2027 [Page 17] 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. 7.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. 7.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 25 March 2027 [Page 18] 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. 7.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 25 March 2027 [Page 19] Internet-Draft Execution-Finality Architecture September 2026 8. Examples 8.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. 8.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. 8.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. 9. 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 25 March 2027 [Page 20] 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. 10. 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? 6. How should latency, availability, and assurance levels be reported so deployments can make comparable claims? 11. 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. Das Expires 25 March 2027 [Page 21] Internet-Draft Execution-Finality Architecture September 2026 Canonicalization ambiguity can allow two components to sign and execute different interpretations. Profiles must define deterministic encodings, covered fields, semantic versions, and rejection behavior for unknown or duplicate values. Replay protection must remain correct under concurrency, partition, restore, and rollback. Restoring an old snapshot of protected state can resurrect consumed or revoked authority; monotonic generation or rollback-resistant storage may be required. 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. Denial of service is a relevant threat because an attacker may exhaust verification, replay-state, or durable-commit resources. Rate limiting and admission control should occur before expensive work, but early filtering must not replace the final protected decision. 12. 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. 13. IANA Considerations This document has no IANA actions. 14. Additional Disclosures and Implementation Resources Broad architectural disclosure: The Internet Solved Communication. It Never Solved Authority. (https://zenodo.org/records/22082995) Das Expires 25 March 2027 [Page 22] Internet-Draft Execution-Finality Architecture September 2026 Adversarial implementation reference: 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) These references are supplied for transparency and reproducibility. 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, . [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, . Das Expires 25 March 2027 [Page 23] Internet-Draft Execution-Finality Architecture September 2026 [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 25 March 2027 [Page 24]