| Internet-Draft | Execution-Finality Architecture | September 2026 |
| Das | Expires 25 March 2027 | [Page] |
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.¶
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.¶
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 (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.¶
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.¶
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.¶
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.¶
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.
| Traditional component or combination | What it normally establishes | What still has to be established |
|---|---|---|
| Authentication or workload identity | Who or which workload is making a request | Whether the exact act becoming effective is currently permitted |
| OAuth token, scope, RAR, or sender constraint | Delegated authority, authorization details, or possession by the intended presenter | Exact consequence reconstruction, current-state revalidation, one-time consumption, and atomic effectuation |
| API gateway or policy enforcement point | Policy enforcement at an ingress or service boundary | Whether downstream transformation, queues, retries, storage, alternate egress, and administrative paths remain completely mediated |
| Remote attestation or trusted execution evidence | Evidence that a component is in an appraised operating state | Evidence that this exact act was checked against current authority and coupled to its consequence |
| Database transaction or atomic commit | Atomicity and durability for participating state changes | Whether the transaction includes authorization consumption and the actual external consequence, with no unmediated side effect |
| Idempotency or duplicate suppression | Repeated requests with a recognized key do not create repeated processing | Whether the key is bound to the authorized exact act and cannot be substituted, reset, or bypassed |
| Audit log, SIEM, or post-event monitoring | Detection, investigation, or accountability after processing | Prevention of an unauthorized effect and unambiguous crash-time outcome recovery |
| Safety interlock or reference monitor | Mandatory mediation within its defined scope | Whether its scope covers every consequence path and whether it binds current authority to the exact semantic act |
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.¶
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.¶
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.¶
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.¶
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)
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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:¶
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.¶
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 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.¶
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.¶
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 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.¶
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.¶
The Workload Identity in Multi-System Environments (WIMSE) 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.¶
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.¶
The Web Bot Authentication (webbotauth) 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.¶
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), 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:¶
This list identifies research intersections, not endorsement, charter acceptance, or a claim that any named research group is the correct final home.¶
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:¶
Dispatch should test whether existing protocols already provide functional equivalence in a given application before creating new protocol machinery.¶
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.¶
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.¶
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.¶
Profiles should specify which guarantees are local assertions and which can be verified across an organizational boundary.¶
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.¶
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.¶
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.¶
This document has no IANA actions.¶
Broad architectural disclosure: The Internet Solved Communication. It Never Solved Authority.¶
Adversarial implementation reference: Execution Handle, Exact-Act Binding, Sink Verification, Atomic Consumption, and 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.¶
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.¶