| Internet-Draft | Attestation-Bound Execution Finality | September 2026 |
| Das | Expires 8 March 2027 | [Page] |
Remote attestation can establish evidence about the hardware, firmware, software, configuration, and execution environment associated with a workload. In heterogeneous confidential-computing environments, this trust assessment can extend across CPUs, confidential virtual machines, GPUs, AI accelerators, DPUs, SmartNICs, and other trusted execution components.¶
An increasingly important class of workloads, however, does not merely compute data. AI agents and autonomous workloads can generate consequential operations such as API invocations, storage mutations, network configuration changes, infrastructure-control commands, financial instructions, device operations, and cross-workload requests.¶
An acceptable Attestation Result supplies trust information to a Relying Party; it is not, without an application-defined authorization step, a decision on the admissibility of each operation later emitted by the attested workload.¶
This document describes an attestation-bound execution-finality architecture in which a consequential operation first exists as a Candidate Act in a non-effective state. Before that act can acquire external effect, its relevant parameters are cryptographically bound to validation context that can include Attestation Results, workload identity, execution context, policy, authorization scope, freshness information, and other application-specific evidence.¶
A designated Finality Sink verifies the required binding at or before the boundary at which the Candidate Act would first acquire external effect.¶
The resulting separation is between appraisal of the execution environment and authorization of a concrete operation at its effectuation boundary.¶
The architecture is intended to complement, rather than replace, Remote ATtestation procedureS (RATS), Entity Attestation Token (EAT) [RFC9711], workload-identity systems, confidential computing, Trusted Execution Environments (TEEs), accelerator attestation, and existing authorization mechanisms.¶
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 5 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.¶
Modern computing systems increasingly combine heterogeneous execution components.¶
A single workload may involve:¶
a CPU;¶
a confidential virtual machine;¶
one or more GPUs or other AI accelerators;¶
a DPU or SmartNIC;¶
containerized or orchestrated workloads;¶
workload-identity credentials;¶
service-mesh components;¶
remote storage;¶
external APIs;¶
high-speed accelerator fabrics;¶
Ethernet or InfiniBand networks; and¶
cloud or hyperscale control-plane infrastructure.¶
Remote attestation provides mechanisms through which claims about such environments can be appraised.¶
The RATS architecture [RFC9334] defines Evidence, Verifiers, Attestation Results, and Relying Parties. A Relying Party can use Attestation Results when making application-specific decisions, including authorization decisions.¶
Composite attestation further permits trust assessments to incorporate multiple components of a heterogeneous confidential-computing environment.¶
These mechanisms answer an important question: what properties can a relying party establish about the environment involved in computation?¶
A distinct question becomes increasingly important as workloads become agentic: what causes one specific operation produced by that workload to become externally effective?¶
Consider an attested AI workload that generates:¶
POST /payment destination = account-B amount = 50000 currency = USD
Attestation may establish important properties of the execution components. Whether the operation above is admissible remains an application-specific decision that can depend on its method, target, arguments, current policy, and resource state.¶
The same observation applies to an AI workload generating:¶
DELETE production-database
or:¶
modify_firewall(rule-X)
or:¶
deploy(image-Y, production)
or:¶
send(message-M, recipient-R)
or:¶
open_valve(device-D, 80-percent)
or:¶
transfer_control(workload-A, workload-B)
The environment may be fully attested and operating as expected. This document addresses a later transition:¶
computation of a proposed operation; and¶
acquisition of authority by that operation to produce an external consequence.¶
This document calls the second transition execution finality.¶
The architecture therefore separates:¶
Computation
|
v
Candidate Act
|
| non-effective
v
Validation / authorization binding
|
v
Finality Sink
|
| effective
v
External Effect
The design does not require a particular CPU, GPU, accelerator, TEE, cloud platform, network fabric, or authorization protocol.¶
This document describes an architecture for binding a consequential Candidate Act to validation evidence before that act acquires external effect.¶
The architecture applies to environments including, but not limited to:¶
confidential AI inference;¶
GPU and AI-accelerator workloads;¶
confidential virtual machines;¶
CPU-GPU composite trusted environments;¶
cloud and hyperscale AI infrastructure;¶
DPUs and SmartNICs;¶
workload-to-workload operations;¶
agentic AI systems;¶
service meshes;¶
API gateways;¶
storage systems;¶
cloud control planes;¶
network control planes;¶
distributed computing infrastructure; and¶
edge and device execution.¶
This is an architectural document, not a Candidate Act encoding or execution-authorization protocol. It neither changes RATS roles nor defines application policy, accelerator behavior, or transport operation. Validation may use hardware-protected or software enforcement, and the validating function may be colocated with or separated from the effectuation boundary.¶
The following are explicitly outside the scope of this architecture.¶
This architecture does not redefine Evidence, Verifiers, Attestation Results, or the Relying Party model defined by RATS.¶
Attestation Results can instead become inputs to execution-finality validation.¶
This document does not assert that remote attestation is incomplete for its defined purpose.¶
Rather, it addresses an additional lifecycle stage: binding relevant trust and authorization information to a concrete consequential operation.¶
Existing identity and authorization mechanisms can provide inputs to the architecture.¶
A workload credential, access token, workload identity, proof token, authorization detail, or other credential can form part of the validation context.¶
A deployment may use:¶
a TEE;¶
secure enclave;¶
HSM;¶
TPM-backed environment;¶
confidential VM;¶
DPU;¶
SmartNIC;¶
kernel enforcement;¶
hypervisor;¶
trusted gateway; or¶
combinations of these mechanisms.¶
The required property is enforcement of the non-effective-to-effective transition, not a particular implementation technology.¶
A Candidate Act is a concrete operation that has been generated, selected, prepared, or requested but has not yet been permitted to acquire the external consequence represented by that operation.¶
Examples include:¶
HTTP method + URI + body RPC method + arguments payment destination + amount database operation + object network-control operation + parameters device command + target + state cloud operation + resource identifier
A Candidate Act is not merely an abstract user intent.¶
It represents the concrete operation proposed for effectuation.¶
A Non-Effective State is a state in which a Candidate Act may be:¶
generated;¶
parsed;¶
transformed;¶
queued;¶
simulated;¶
inspected;¶
hashed;¶
signed; or¶
validated,¶
but cannot yet cause the protected external consequence.¶
This property is central to execution finality.¶
Validation that occurs after an irreversible external effect does not provide the same property.¶
An Execution-Finality Validator (EFV) is a logical component that evaluates a Candidate Act together with relevant validation inputs.¶
Inputs can include:¶
Attestation Results;¶
workload identity;¶
calling identity;¶
target identity;¶
execution context;¶
authorization scope;¶
policy;¶
jurisdictional information;¶
resource state;¶
operation arguments;¶
time;¶
nonce;¶
sequence state;¶
replay state;¶
risk state; and¶
application-specific conditions.¶
An EFV may be implemented using a protected execution environment, trusted service, DPU, HSM, enclave, kernel component, gateway, or other enforcement-capable mechanism.¶
Protected Validation Evidence (PVE) is evidence produced after validation of a particular Candidate Act.¶
PVE binds the authorization decision to the act or to a canonical representation of the act.¶
PVE is not intended to be general bearer authority for unrelated operations.¶
An Execution Handle (EH) is an optional scoped authorization artifact derived from successful validation.¶
An EH can authorize execution of the corresponding Candidate Act subject to constraints encoded directly or cryptographically referenced by the handle.¶
An EH SHOULD be:¶
A Finality Sink is the logical boundary at which a Candidate Act would first acquire the protected external effect.¶
A Finality Sink verifies, reconstructs, or otherwise establishes the required validation state before permitting that transition.¶
Examples include:¶
an API gateway;¶
database commit boundary;¶
storage controller;¶
cloud-control-plane endpoint;¶
payment execution service;¶
network egress gateway;¶
DPU;¶
SmartNIC;¶
hypervisor;¶
operating-system kernel;¶
service-mesh proxy;¶
industrial controller;¶
messaging service; or¶
receiving workload.¶
A Finality Sink is a logical function.¶
It need not be a separate physical device.¶
The basic architecture is:¶
+-----------------------+
| Workload / AI Agent |
+-----------+-----------+
|
| generates
v
+---------------+
| Candidate Act |
+-------+-------+
|
NON-EFFECTIVE
|
v
+---------------------------------------+
| Execution-Finality Validator |
| |
| Inputs may include: |
| |
| - Attestation Result |
| - workload identity |
| - execution context |
| - policy |
| - Candidate Act parameters |
| - target identity |
| - freshness / nonce |
| - authorization scope |
+------------------+--------------------+
|
validation success
|
v
+----------------------+
| PVE / Execution |
| Handle |
+----------+-----------+
|
v
+---------------+
| Finality Sink |
+-------+-------+
|
EFFECTIVE
|
v
+----------------+
| External Effect|
+----------------+
The principal security property is that the protected external effect is dependent upon successful finality verification.¶
The invariant is that effectuation through a protected path depends on successful verification of authorization bound to the security-relevant content of the Candidate Act. Neither the request representation nor an Attestation Result functions as unrestricted authority for a materially different act.¶
Attestation information can form part of the authorization context.¶
Conceptually:¶
Attestation Result
+
Workload Identity
+
Candidate Act
+
Policy / Context
|
v
Execution-Finality Validation
|
v
Act-Bound PVE / EH
The binding can be constructed over a canonical representation:¶
act_digest =
HASH(canonical_candidate_act)
Validation evidence can then conceptually bind:¶
validation_binding = {
act_digest,
workload_identity,
attestation_reference,
target,
authorization_scope,
issued_at,
expires_at,
nonce,
policy_reference
}
This document does not mandate this encoding.¶
The important property is that authorization of Candidate Act A cannot normally be reused to effect Candidate Act B where B differs in a security-relevant parameter.¶
For example:¶
authorized:
transfer(
destination = A,
amount = 100
)
must not silently become authority for:¶
transfer(
destination = B,
amount = 100000
)
because the workload identity and execution environment remain unchanged.¶
Consider the following lifecycle:¶
T0 workload environment is attested T1 Relying Party accepts Attestation Result T2 workload processes external data T3 model generates Candidate Act A T4 external context changes T5 model generates Candidate Act B T6 operation reaches consequential system
An Attestation Result can remain highly valuable throughout this lifecycle.¶
However, the authorization question at T6 may depend on information not represented solely by the fact that the environment was successfully attested at T0.¶
For example:¶
the exact operation;¶
destination;¶
amount;¶
requested resource;¶
caller;¶
current policy;¶
tenant;¶
target;¶
time;¶
current system state; or¶
authorization scope.¶
Execution-finality binding therefore allows attestation to remain an important trust input while independently binding authority to the concrete consequential operation.¶
[RFC9334] defines a Relying Party as an entity that consumes Attestation Results and applies an appraisal policy for Attestation Results.¶
The Relying Party may make application-specific decisions, including authorization decisions.¶
This architecture is compatible with that model.¶
An implementation can model the Execution-Finality Validator as, or as part of, a Relying Party.¶
For example:¶
Attester
|
| Evidence
v
Verifier
|
| Attestation Result
v
Execution-Finality Validator / Relying Party
|
| act-bound validation
v
Finality Sink
The proposed extension is therefore not:¶
RATS cannot authorize
but:¶
RATS Attestation Result
|
v
application-specific appraisal
|
+
concrete Candidate Act
|
v
act-bound finality authorization
This allows existing RATS mechanisms to participate without making the Attestation Result itself a universal execution credential.¶
Modern confidential workloads can span multiple independently attestable components.¶
For example:¶
+------------------------------------------+ | Confidential VM | | | | CPU TEE | | | | | +------ Confidential GPU | | | | | +------ DPU / SmartNIC | | | +------------------------------------------+
Composite attestation can establish properties across those components.¶
Execution finality addresses the later transition:¶
composite trusted environment
|
v
compute
|
v
Candidate Act
|
v
act-specific validation
|
v
Finality Sink
|
v
external effect
This permits a system to benefit from heterogeneous attestation while avoiding an assumption that all outputs subsequently emitted by that environment necessarily carry identical authority.¶
An AI inference workload executes using an accelerator.¶
The accelerator produces model output that an agent framework interprets as:¶
tool = cloud.compute.delete_instance
arguments = {
instance: "production-47"
}
The output is first represented as:¶
CandidateAct {
action: "cloud.compute.delete_instance",
resource: "production-47"
}
It remains non-effective.¶
The validator evaluates:¶
workload identity + accelerator / platform Attestation Result + requested action + resource + tenant + policy + freshness
If permitted, the validator produces validation evidence bound to:¶
HASH(
"cloud.compute.delete_instance"
||
"production-47"
)
The cloud-control endpoint acts as the Finality Sink.¶
Without acceptable evidence for that Candidate Act, the deletion is not performed.¶
The accelerator remains responsible for computation.¶
The Finality Sink remains responsible for consequence.¶
A hyperscale deployment can place the architecture across existing infrastructure.¶
Example:¶
+-------------+
| AI workload |
+------+------+
|
v
+-------------+
| GPU cluster |
+------+------+
|
| Candidate Act
v
+------------------+
| DPU / SmartNIC |
| or local gateway |
+--------+---------+
|
| validated operation
v
+------------------+
| Data-center |
| network fabric |
+--------+---------+
|
v
+------------------+
| Service / API / |
| storage endpoint |
| Finality Sink |
+--------+---------+
|
v
External Effect
Other deployments may place validation at an API gateway:¶
GPU workload
|
Candidate Act
|
network fabric
|
API gateway
[EFV + Finality Sink]
|
backend
or at the destination:¶
GPU workload
|
Candidate Act + PVE
|
network
|
destination service
[Finality Sink]
The architecture therefore does not require adding validation processing to each accelerator interconnect packet.¶
DPUs and SmartNICs provide a particularly useful implementation location where infrastructure operators wish to separate application computation from enforcement.¶
Conceptually:¶
Host CPU / GPU
|
Candidate Act
|
v
+----------------------+
| DPU / SmartNIC |
| |
| finality verification|
+----------+-----------+
|
authorized
|
v
network egress
Such a design can provide a hardware-separated enforcement point without requiring modifications to the model or accelerator instruction stream.¶
However, this architecture does not require that a DPU or SmartNIC perform this function.¶
Execution finality is independent of network bandwidth and transport technology.¶
A Candidate Act can traverse:¶
PCIe;¶
accelerator interconnects;¶
Ethernet;¶
InfiniBand;¶
optical networks;¶
service meshes;¶
QUIC;¶
HTTP;¶
RPC protocols; or¶
other transports.¶
The fabric answers whether information can be moved.¶
Execution finality answers whether the consequential operation represented by that information is permitted to acquire effect.¶
Accordingly, the architecture does not require per-packet authorization of ordinary data-plane traffic.¶
Validation can occur only at security-relevant consequence boundaries.¶
Workload identity establishes who or what a workload represents.¶
Execution finality addresses what a particular workload instance is permitted to cause through a particular Candidate Act.¶
The relationship can therefore be expressed as:¶
Workload identity
|
+-------------------+
|
v
Candidate Act
|
v
act authorization
|
v
external effect
A workload identity authenticates a workload principal; the authorization decision remains scoped to the requested operation and resource.¶
Conversely, an execution-finality system benefits from strong workload identity because the authorization evidence can be bound to the workload that generated or requested the operation.¶
The architecture can therefore consume workload identities and workload credentials defined by systems such as WIMSE [WIMSE].¶
Where a cryptographic digest is used to bind authorization to a Candidate Act, security-relevant fields need a deterministic representation.¶
For an HTTP operation this may include:¶
method scheme authority target path selected headers body digest target identity
For an RPC operation:¶
service method canonical arguments target
For an infrastructure operation:¶
operation identifier resource identifier parameters tenant target environment
An implementation must ensure that semantically different acts cannot acquire the same authorization through ambiguous canonicalization.¶
The exact canonicalization profile is protocol specific and is outside the scope of this document.¶
Validation evidence should be bounded in time or transaction context when stale authorization would create security risk.¶
Possible mechanisms include:¶
expiry timestamps;¶
nonces;¶
challenge values;¶
sequence numbers;¶
monotonic counters;¶
transaction identifiers; or¶
freshness claims inherited from an underlying protocol.¶
Long-lived execution evidence can undermine the act-specific property if it can be replayed outside its intended context.¶
An attacker able to replay previously valid execution evidence may attempt to reproduce a consequential operation.¶
A deployment can mitigate this by binding validation evidence to one or more of:¶
act digest transaction identifier nonce target audience execution epoch expiry sequence value single-use state
A Finality Sink may maintain replay state where required.¶
A conventional bearer credential can confer authority primarily through possession.¶
For high-consequence execution, a deployment may require stronger binding.¶
An Execution Handle can therefore be bound to:¶
Candidate Act digest;¶
workload key;¶
workload identifier;¶
attested execution context;¶
target;¶
channel;¶
proof-of-possession key;¶
transaction identifier; or¶
combinations thereof.¶
The goal is to prevent extraction of a valid authorization artifact from becoming general reusable authority.¶
The Finality Sink should be located at a boundary where bypass would otherwise permit the protected external effect.¶
Possible boundaries include:¶
AI tool invocation gateway API ingress API egress database commit storage mutation cloud control plane DPU SmartNIC kernel hypervisor device controller payment processor receiving workload
A system can contain multiple Finality Sinks for different consequence classes.¶
For example:¶
AI agent
|
Candidate Acts
_________|_________
| | |
v v v
payment storage network
sink sink sink
The term Finality Sink describes a logical enforcement boundary.¶
Existing infrastructure can implement the function.¶
Examples include:¶
an API gateway that verifies an act-bound proof;¶
a database server that refuses mutation without corresponding authorization evidence;¶
a DPU that prevents unauthorized control traffic from leaving a host;¶
a hypervisor that mediates device operations;¶
an operating-system service that validates privileged actions;¶
a receiving workload that verifies proof before acting.¶
A deployment therefore does not necessarily introduce an additional network hop.¶
A practical deployment should avoid placing expensive operations on every consequential hot path.¶
The architecture permits separation between:¶
Cold-path operations¶
attestation verification;¶
endorsement retrieval;¶
certificate-chain processing;¶
policy distribution;¶
reference-value processing; and¶
long-lived trust-context establishment.¶
and:¶
Hot-path operations¶
Candidate Act digest computation;¶
freshness verification;¶
context lookup;¶
policy decision;¶
proof verification; and¶
finality enforcement.¶
For example:¶
COLD PATH
GPU / CVM attestation
|
v
Verifier
|
Attestation Result
|
cached trust context
|
+--------------------+
|
v
HOT PATH
AI output -> Candidate Act
|
v
lookup trust context
|
act-specific validation
|
v
Finality Sink
This allows expensive attestation operations to remain outside the per-act path where policy permits.¶
Execution-finality enforcement does not require immediate modification of all applications.¶
A sidecar, gateway, DPU, service-mesh proxy, reverse proxy, API-management layer, or workload wrapper can mediate protected operations.¶
Example:¶
Legacy AI application
|
| ordinary API request
v
+-----------------------+
| Finality sidecar |
| |
| creates Candidate Act |
| validates / obtains |
| PVE |
+-----------+-----------+
|
v
external API
This permits incremental deployment.¶
If required validation fails, the Candidate Act remains non-effective.¶
Where policy requires an acceptable Attestation Result and no acceptable result exists, validation fails.¶
Expired evidence is rejected where freshness is required.¶
If security-relevant Candidate Act parameters change after validation, the original validation binding no longer authorizes the modified act.¶
The architecture is intended to address threats including:¶
an AI workload generating an operation outside intended authority;¶
manipulation of Candidate Act parameters after validation;¶
replay of prior authorization evidence;¶
use of trusted-workload credentials for unauthorized operations;¶
propagation of general bearer authority through multiple workloads;¶
compromise of an application component outside a protected validation boundary;¶
confusion between attested execution and act authorization; and¶
bypass of the intended consequence-enforcement boundary.¶
The architecture does not guarantee correctness of the underlying policy.¶
It also does not prevent compromise of every component if the Finality Sink itself is fully compromised.¶
Execution-finality systems create a security dependency on correct identification of the consequence boundary.¶
If an attacker can bypass the Finality Sink and reach another path capable of producing the same external effect, technical non-effectiveness is not established.¶
Implementations therefore need to identify all relevant effectuation paths.¶
Validation evidence should bind all security-relevant fields of a Candidate Act.¶
Failure to bind a relevant argument can permit substitution attacks.¶
For example, binding:¶
operation = "transfer"
without binding:¶
destination amount currency
would normally provide inadequate protection for a payment operation.¶
Attestation Results should not be interpreted beyond their defined semantics.¶
A successful Attestation Result does not establish properties that were not measured, claimed, or appraised.¶
Likewise, execution-finality validation does not establish that an AI model's reasoning is correct. It establishes only that the defined conditions for permitting a particular act were satisfied.¶
Implementations should protect validator signing keys and other execution-authority material.¶
Where possible, execution evidence should use proof-of-possession, audience restriction, act binding, freshness, or equivalent mechanisms instead of unrestricted bearer semantics.¶
Candidate Acts can contain sensitive information.¶
Validation systems should avoid exposing unnecessary operation parameters.¶
Where practical, deployments can validate cryptographic commitments or digests instead of transmitting full Candidate Act contents to unrelated components.¶
Attestation information can also reveal platform characteristics.¶
Existing RATS privacy guidance remains applicable.¶
Implementations should minimize correlation identifiers and avoid creating unnecessarily persistent identifiers for AI workloads or users.¶
Consider a tenant running an AI agent inside a confidential VM with confidential accelerators.¶
The environment is remotely attested.¶
CPU/CVM Evidence
+
GPU Evidence
|
v
Composite Attestation
|
v
Attestation Result
The AI workload subsequently generates:¶
Candidate Act: POST /v1/infrastructure/deploy tenant = T1 image = model-service-v4 environment = production region = R1
The operation remains non-effective.¶
The validator evaluates:¶
Candidate Act
+
Attestation Result
+
workload identity
+
tenant authorization
+
deployment policy
+
freshness
Successful validation produces evidence bound to the exact deployment request.¶
The cloud control-plane API acts as the Finality Sink.¶
Only after verification does:¶
Candidate Act
become:¶
Effective Deployment
The confidential-computing environment establishes trust in computation.¶
Execution finality establishes the controlled transition from computation to consequence.¶
A GPU-hosted autonomous workload generates requests that leave a server.¶
The host architecture provides a DPU-controlled network path.¶
+-----------------------+
| CPU + GPU |
| |
| AI workload |
+-----------+-----------+
|
Candidate Act
|
v
+-----------------------+
| DPU |
| |
| finality verification |
+-----------+-----------+
|
authorized
|
v
data-center fabric
For protected operation classes, the DPU can require acceptable execution evidence before permitting the operation to reach its external destination.¶
Normal network traffic does not need to be subjected to this mechanism unless policy classifies it as consequential.¶
An AI task can cross multiple workloads:¶
User | v Agent A | v Planner B | v Tool Broker C | v Service D
Identity and trust can be propagated through the chain.¶
However, the final consequential operation may depend on arguments generated only near the end of the workflow.¶
Execution finality permits the final concrete operation to be validated independently of the fact that earlier workloads were authenticated or attested.¶
authenticated chain
|
v
concrete Candidate Act
|
v
final act-specific validation
|
v
external consequence
Future protocol work based on this architecture should support interoperability between:¶
Attestation Result producers;¶
workload-identity systems;¶
execution-finality validators;¶
AI runtimes;¶
gateways;¶
DPUs;¶
SmartNICs;¶
confidential-computing platforms; and¶
Finality Sinks.¶
A protocol profile would need to define at least:¶
Candidate Act identification;¶
canonicalization;¶
act digest representation;¶
validation-evidence format;¶
workload binding;¶
attestation binding;¶
audience or target binding;¶
freshness;¶
replay protection;¶
error handling; and¶
cryptographic algorithm negotiation.¶
These details are intentionally left for subsequent protocol documents.¶
A future protocol could use a flow similar to:¶
Workload EFV Finality Sink | | | | Candidate Act | | |------------------>| | | | | | validation context / attestation | | | | | | | |<------------------| | | PVE / EH | | | | | Candidate Act + PVE/EH | |------------------------------------------>| | | | verify act | | binding | | | | effectuate | | |
Another deployment may have the Finality Sink request validation directly:¶
Workload Finality Sink EFV | | | | Candidate Act | | |------------------>| | | | validation request | | |-------------------->| | | | | | validation result | | |<--------------------| | | | | | effectuate |
The architecture permits both models.¶
This section defines one deliberately narrow profile that can be implemented to test the architectural invariant. It is not a general Candidate Act format and does not register a new token type. Its purpose is to make the proposal falsifiable, permit independent implementations to exercise the same processing steps, and identify which parts require subsequent standardization.¶
The proof of concept protects one HTTP operation:¶
POST https://payments.example/transfer
Content-Type: application/json
{"destination":"account-B","amount":100,"currency":"USD"}
The API gateway is the Finality Sink. The downstream payment test service is reachable only through that gateway. The service performs no real financial transfer; it records an accepted test operation.¶
The proof of concept represents the security-relevant operation as the following CBOR map. Integer labels are used only for this experimental profile:¶
candidate-act = {
1: 1, ; profile version
2: "POST", ; uppercase HTTP method
3: tstr, ; lowercase authority
4: tstr, ; normalized absolute path
5: bstr .size 32, ; SHA-256 of request body bytes
6: tstr, ; intended Finality Sink identifier
7: tstr ; transaction identifier
}
The body is serialized as UTF-8 JSON using the fixed member order and no insignificant whitespace shown in the test vector. This restriction is suitable only for the proof of concept; a reusable HTTP profile would need a complete content canonicalization rule.¶
The Candidate Act is encoded using the deterministic-encoding requirements of [RFC8949]. The act digest is:¶
act_digest = SHA-256(deterministic-CBOR(candidate-act))
The gateway reconstructs the Candidate Act from the received request rather than trusting a digest supplied by the workload. Any change to the method, authority, path, body bytes, audience, or transaction identifier therefore changes the reconstructed act or its digest.¶
The EFV consumes one valid EAT conforming to [RFC9711] or an Attestation Result produced by a configured Verifier from that EAT. The proof-of-concept configuration identifies the accepted EAT profile, trust anchor, required claims, freshness rule, and appraisal policy. Accepting a syntactically valid token without applying that profile and policy is an error.¶
After successful appraisal, the EFV derives:¶
attestation_context_id =
SHA-256(verifier_identifier || appraisal_result_bytes)
The byte encoding and semantics of appraisal_result_bytes are fixed by the proof-of-concept configuration. The Execution Handle carries this derived identifier, not the original Evidence, so that the gateway need not repeat full Evidence appraisal on the per-operation path.¶
Following successful appraisal and operation-specific policy evaluation, the EFV issues a COSE_Sign1 object as specified by [RFC9052]. Its payload is the deterministic CBOR encoding of:¶
execution-handle = {
1: 1, ; profile version
2: bstr .size 32, ; act_digest
3: tstr, ; workload identity
4: bstr .size 32, ; attestation_context_id
5: tstr, ; Finality Sink audience
6: uint, ; issued-at, epoch seconds
7: uint, ; expiry, epoch seconds
8: bstr, ; unpredictable nonce
9: tstr ; transaction identifier
}
The protected COSE header contains the algorithm identifier and a key identifier. The initial proof of concept uses one mandatory signing algorithm selected in its published implementation manifest. Algorithm agility and negotiation are outside this experimental profile. The EFV signing key is distinct from an Attester key, and possession of an EAT does not permit issuance of an Execution Handle.¶
For the protected endpoint, the gateway MUST reject the request unless all of the following checks succeed:¶
An Execution Handle is present in the configured request field.¶
The COSE_Sign1 structure and EFV signature are valid under a configured key.¶
The profile version and signing algorithm are accepted.¶
The audience equals the gateway's configured Finality Sink identifier.¶
The current time is within the issued-at and expiry interval.¶
The transaction identifier in the handle equals the transaction identifier used to reconstruct the request.¶
The gateway reconstructs and deterministically encodes the Candidate Act, and its SHA-256 digest equals act_digest in the handle.¶
The nonce has not previously been consumed for that EFV and audience.¶
The gateway MUST record the nonce as consumed atomically with release of the request to the test service. A failed check produces no downstream request. The proof of concept distinguishes malformed credentials, invalid authorization, expired authorization, act mismatch, and replay in internal logs; an external deployment may intentionally return less specific errors.¶
A published implementation of this profile includes reproducible input bytes, deterministic Candidate Act bytes, act digests, COSE_Sign1 bytes, public verification keys, and expected results for at least the following cases:¶
| Case | Variation | Expected result |
|---|---|---|
| V1 | Exact request and unused valid handle | Accepted once |
| V2 | Missing handle | Rejected |
| V3 | Amount changed from 100 to 100000 | Act mismatch |
| V4 | Destination changed | Act mismatch |
| V5 | Method or path changed | Act mismatch |
| V6 | Expired handle | Rejected |
| V7 | Second use of the V1 handle | Replay rejected |
| V8 | Different Finality Sink audience | Rejected |
| V9 | Modified COSE payload or signature | Rejected |
| V10 | Unacceptable or stale EAT at issuance | No handle issued |
Performance claims require measured results. A proof-of-concept report therefore records software version, hardware, operating system, cryptographic algorithm, key type, gateway topology, replay-store implementation, concurrency, request-body size, sample count, and warm-up procedure.¶
The report separately measures:¶
cold-path EAT verification and appraisal;¶
Candidate Act construction and digest computation;¶
Execution Handle issuance;¶
gateway signature, binding, freshness, and replay verification;¶
end-to-end protected-request latency; and¶
the same request through the gateway without finality processing as the baseline.¶
Results are reported as throughput and latency distributions including median, 95th percentile, and 99th percentile, rather than as an unsupported single latency value.¶
At publication of this version of the document, this section specifies a reproducible proof-of-concept target. It does not claim that interoperable code, completed test-vector byte strings, or measured latency results have already been published. Such artifacts should be referenced here only after they are publicly available and independently reproducible.¶
AI runtimes increasingly translate generated output into API, control-plane, and storage operations. Infrastructure may already provide several sources of identity and appraisal information:¶
CPU attestation GPU attestation confidential VMs accelerator isolation DPU isolation workload identity service identity
The proposal defines how those inputs can participate in an operation-specific authorization decision whose verification is enforced at the relevant effectuation boundary:¶
a consequential output remains non-effective until the authorization required for that exact operation is established at its consequence boundary.
This is an application of attestation and workload identity to consequence-bearing operations; it is not a claim that the underlying attestation mechanisms are deficient.¶
Deployments should classify operations according to consequence.¶
It is neither necessary nor desirable to apply expensive finality processing to every tensor operation, memory transaction, or network packet.¶
Instead, enforcement can occur at semantically meaningful boundaries such as:¶
create delete transfer deploy publish send commit open release modify authorize
This permits high-throughput accelerator and network fabrics to operate normally while protected consequences receive stronger authorization semantics.¶
A common concern with additional authorization boundaries is latency.¶
This architecture permits several optimizations.¶
First, full attestation verification can occur on the cold path.¶
Second, Attestation Results or derived trust context can be cached according to their security properties.¶
Third, Candidate Act validation can use compact digests instead of transmitting large model outputs.¶
Fourth, validation can be colocated with a DPU, gateway, service mesh, kernel component, API endpoint, or target workload.¶
Fifth, a Finality Sink can perform local cryptographic verification without a new network round trip where appropriate.¶
Accordingly, the architecture does not require remote attestation to be repeated for every model output.¶
The following questions are intentionally left open for IETF discussion:¶
Should an act-bound execution authorization be represented as a profile of an existing token format or as a new artifact?¶
Which Candidate Act canonicalizations are sufficiently generic for reuse?¶
Should the Attestation Result be carried directly, referenced by digest, or represented through derived trust context?¶
How should workload identity and proof-of-possession credentials be bound to execution-finality evidence?¶
Which components naturally perform the Finality Sink role in cloud and accelerator environments?¶
Can existing RATS conceptual messages be profiled for this use case without creating a new protocol?¶
Which parts belong in RATS and which are better handled by WIMSE or application-specific authorization protocols?¶
How should multi-verifier and composite-attestation results be represented in act-specific validation?¶
How should the architecture handle long-running agentic workflows in which authorization context changes between planning and execution?¶
Which mechanisms provide the lowest-latency implementation in GPU, DPU, SmartNIC, service-mesh, and hyperscaler environments?¶
This document has no IANA actions.¶
Future protocol specifications based on this architecture may require registration of media types, token claims, CBOR labels, HTTP fields, or other protocol identifiers.¶
The complete transition can be summarized as:¶
TRUST PLANE
Evidence / Attestation
|
v
Verifier
|
v
Attestation Result
|
|
v
COMPUTE PLANE
CPU / GPU / NPU /
accelerator / AI
|
v
computation
|
v
Candidate Act
|
NON-EFFECTIVE
|
v
AUTHORITY PLANE
workload identity
+
attestation context
+
Candidate Act
+
policy
|
v
Execution-Finality Validator
|
v
act-bound PVE / EH
|
v
FINALITY PLANE
Finality Sink
|
v
EXTERNAL EFFECT
The principal distinction is:¶
ENVIRONMENT APPRAISAL
+
WORKLOAD AUTHENTICATION
+
OPERATION-SPECIFIC POLICY
|
v
ACT-BOUND AUTHORIZATION
|
v
VERIFICATION AT EFFECTUATION BOUNDARY
This document explores a narrow interoperability question:¶
How can a Relying Party's appraisal input and an authenticated workload identity be incorporated into authorization evidence for one canonically represented operation, with verification enforced before the protected effect is committed?¶
The mechanism is intended to reuse existing attestation and identity infrastructure rather than replace it.¶
This appendix addresses technical questions likely to arise when considering attestation-bound execution finality in relation to RATS, WIMSE, confidential computing, AI accelerators, DPUs, SmartNICs, and hyperscale infrastructure.¶
Question¶
RFC 9334 already states that a Relying Party can consume an Attestation Result and use its own appraisal policy to make an application-specific authorization decision. Why is another execution-finality architecture necessary?¶
Answer¶
The proposed architecture does not change that RATS property.¶
A RATS Relying Party can absolutely decide whether an Attester should be allowed to perform an operation.¶
The narrower problem addressed here is whether the result of that decision is cryptographically and operationally bound to the exact consequential operation that eventually reaches the effectuation boundary.¶
The distinction is:¶
RATS: Evidence | Verifier | Attestation Result | Relying Party | application-specific decision
The proposed execution-finality composition adds:¶
Attestation Result
+
Candidate Act
+
workload identity
+
policy/context
|
v
act-specific authorization
|
v
protected act binding
|
v
Finality Sink
|
v
External Effect
The additional property is end-to-end correspondence: the operation evaluated by the authorization function is the operation accepted at the protected effectuation boundary, including its security-relevant arguments.¶
A RATS Relying Party can be the Execution-Finality Validator, the Finality Sink, or both.¶
The terminology is therefore intended to specialize an application of RATS rather than introduce an alternative attestation architecture.¶
RATS relevance: direct. RFC 9334 already provides the Attester, Verifier, Attestation Result, Relying Party, Evidence, and appraisal concepts needed as inputs.¶
WIMSE relevance: workload identity can provide the authenticated workload identity used in the Relying Party's act-specific decision.¶
Question¶
RATS already has Attestation Results for Secure Interactions. Why is an additional mechanism necessary?¶
Answer¶
AR4SI is highly complementary.¶
AR4SI describes reusable information that allows a Relying Party to evaluate properties such as identity, trustworthiness, and freshness and then determine whether secure interaction should be allowed.¶
Execution finality applies a distinct authorization decision to operations within an accepted secure interaction when their consequence, target, or arguments require different policy treatment.¶
For example, an attested AI workload might be permitted to communicate with a cloud-control service.¶
During the same authenticated interaction it could generate:¶
GET /instances
followed later by:¶
DELETE /instances/production-47
The secure-interaction trust state can remain valid for both messages while the authorization requirements differ substantially.¶
Execution finality therefore permits:¶
AR4SI trust information
|
v
persistent/cached trust context
|
+------------------+
|
Candidate Act A
|
authorization
|
Finality
and independently:¶
same trust context
|
+------------------+
|
Candidate Act B
|
different decision
There is no requirement to repeat hardware attestation for every operation.¶
RATS relevance: AR4SI can provide reusable trustworthiness inputs to the execution-finality validator. Current AR4SI work explicitly focuses on information provided to Relying Parties for decisions about secure interaction.¶
WIMSE relevance: the authenticated workload associated with the secure interaction can be identified using WIMSE credentials while individual operations receive independent authorization.¶
Question¶
A confidential workload may already produce composite attestation covering a CPU TEE, confidential VM, and confidential GPU. Why is Candidate Act validation separate?¶
Answer¶
Composite attestation and Candidate Act validation operate at different semantic layers.¶
For example:¶
Intel TDX Evidence
+
Confidential GPU Evidence
|
v
Composite appraisal
|
v
Attestation Result
can establish properties of the combined confidential-computing environment.¶
That result becomes an input to:¶
Attestation Result
+
Candidate Act
+
workload identity
+
authorization context
|
v
Execution-Finality Decision
A stable composite appraisal can be reused while individual operations receive different authorization outcomes.¶
For example:¶
Act 1 = read object X Act 2 = modify object X Act 3 = delete object X Act 4 = transmit object X to workload Y
The attested environment can remain identical.¶
The authorization decision need not.¶
The referenced TDX+C-GPU Attestation Result profile [TDX-CGPU-EAR] illustrates a composite appraisal input that could be consumed by the proposed authorization flow.¶
The architecture also accommodates multiple Verifiers:¶
CPU Verifier --------\
\
GPU Verifier ----------> composed trust result
/
DPU Verifier --------/
|
v
Candidate Act
|
finality
Current RATS work is separately examining multiple-Verifier topologies.¶
RATS relevance: composite and multi-Verifier Attestation Results can feed finality validation.¶
WIMSE relevance: after platform trust is established, WIMSE identifies the software workload operating inside that trusted environment.¶
Question¶
Would an accelerator implementation need to be redesigned to support this architecture?¶
Answer¶
No. The proposed enforcement occurs after an application has formed a consequence-bearing operation; it does not alter tensor execution, instruction sets, matrix engines, or accelerator scheduling.¶
The architecture separates:¶
COMPUTATION
tensor operation
matrix multiplication
inference
model execution
|
v
Candidate Act
from:¶
AUTHORITY
Candidate Act
|
validation
|
Finality Sink
|
external effect
A deployment could therefore use an existing confidential accelerator unchanged.¶
The enforcement component might instead reside in:¶
confidential VM DPU SmartNIC host TEE kernel hypervisor API gateway service mesh destination service
Chip vendors could nevertheless integrate the function more deeply if desired.¶
For example, a future DPU could provide a protected finality-verification primitive, or an accelerator runtime could expose an attested binding between a model workload and Candidate Act digest.¶
Those are implementation optimizations, not architectural requirements.¶
RATS relevance: existing accelerator Evidence remains reusable.¶
WIMSE relevance: workload-level identity remains independent of accelerator instruction-set design.¶
Question¶
If a workload possesses a valid WIMSE Workload Identity Token or Workload Identity Certificate, why does it need another authorization step?¶
Answer¶
Because identity and authority are distinct.¶
The current WIMSE architecture itself makes this distinction explicitly: authenticating a workload establishes control of credentials but is not sufficient by itself to determine whether that workload may access a resource or perform an action. The authorization decision additionally considers the operation, resource, policy, and relevant security context.¶
Execution finality extends that logic to the effectuation boundary.¶
For example:¶
WIT: workload = ai-agent-47
can authenticate the workload.¶
But the following operations are not equivalent:¶
read(database-A)
delete(database-A)
copy(database-A, external-domain-B)
The proposed composition becomes:¶
WIMSE identity
+
Candidate Act
+
RATS trust state
+
policy
|
v
act-specific decision
|
v
Finality Sink
Therefore, WIMSE answers primarily: which workload is presenting this credential, and can it prove possession? While execution finality asks: may this exact consequential operation become effective at this boundary under the current identity, trust, policy and context?¶
RATS relevance: supplies trustworthy execution-state information.¶
WIMSE relevance: supplies workload identity and proof-of-possession foundations.¶
Question¶
Why not mint a narrowly scoped OAuth token after the concrete request has been generated?¶
Answer¶
That can be a valid implementation mechanism.¶
This architecture should not claim otherwise.¶
An OAuth authorization server could issue a sufficiently narrow per-operation credential containing or referencing:¶
actor resource operation arguments audience expiration transaction identifier
If the Resource Server verifies it against the exact operation, then such a token could implement part of execution finality.¶
The architectural question is broader: what invariant must be preserved regardless of the authorization artifact chosen?¶
The proposed invariant is:¶
Candidate Act
|
| remains non-effective
v
act-bound authorization
|
v
mandatory verification
at consequence boundary
|
v
external effect
Therefore an OAuth Transaction Token, capability, COSE object, HTTP Message Signature, WIMSE proof token, or another mechanism may become a concrete encoding.¶
The document intentionally separates the finality invariant from the credential format.¶
RATS relevance: attestation state can contribute to the authorization inputs used when minting or validating such an artifact.¶
WIMSE relevance: WIMSE workload credentials can identify the actor requesting the transaction-specific authority.¶
Question¶
If the validator returns an Execution Handle, an attacker could steal it and replay it. How is this different from an ordinary bearer credential?¶
Answer¶
The Execution Handle should not be defined as unrestricted bearer authority.¶
It should be bound to security-relevant context.¶
For example:¶
EH = Sign {
act_digest,
workload_id,
target,
audience,
transaction_id,
nonce,
expiry,
policy_context,
proof_key
}
A stolen EH should therefore fail when presented with:¶
different Candidate Act different workload different target different proof key different transaction expired freshness state
Where possible, implementations should use proof-of-possession rather than possession alone.¶
Conceptually, possession of the EH does not equal authority.¶
Instead:¶
EH
+
correct Candidate Act
+
correct presenter
+
correct target
+
fresh context
=
usable execution authority
An implementation may omit a separate Execution Handle entirely and have the Finality Sink query the validator directly.¶
The architecture depends on the binding, not on the existence of a new token.¶
RATS relevance: attested keys or key-binding mechanisms can strengthen the identity of the presenter.¶
WIMSE relevance: WIMSE credentials already bind workload identity to cryptographic key material and therefore provide useful proof-of-possession foundations.¶
Question¶
If the AI runtime creates one representation but the destination interprets another representation, how can the authorization binding be trusted?¶
Answer¶
This is one of the most important protocol-design problems.¶
The authorization must bind to the representation that determines the protected consequence.¶
For an HTTP operation, security-relevant material might include:¶
method authority path selected headers body target resource
For an RPC:¶
service method arguments target
For a cloud-control operation:¶
operation resource ID tenant region parameters
The document should therefore require an application-specific Candidate Act Canonicalization Profile.¶
A generic formula might be:¶
act_digest =
HASH(
profile_identifier ||
canonical_candidate_act
)
The profile identifier prevents the same byte sequence from being interpreted under two incompatible canonicalization rules.¶
Any security-relevant field that is interpreted by the Finality Sink must either:¶
be contained in the canonical Candidate Act; or¶
be independently constrained by the authorization context.¶
Otherwise parameter substitution is possible.¶
The Finality Sink is ultimately authoritative regarding which canonical representation corresponds to the consequence it performs.¶
RATS relevance: RATS does not need to define HTTP, RPC, payment, or cloud-operation canonicalization.¶
WIMSE relevance: WIMSE identifies the initiating workload; application profiles define the operation being authorized.¶
Question¶
Is "non-effective state" merely policy terminology? What prevents a compromised workload from bypassing validation and directly executing the operation?¶
Answer¶
The non-effective state must be enforced by architecture, not simply declared in metadata.¶
For a protected consequence, every path capable of producing that consequence must pass a trusted enforcement boundary.¶
For example:¶
AI workload
|
Candidate Act
|
X--------------------> protected service
| direct path blocked
|
v
Finality Sink
|
v
protected service
Possible mechanisms include:¶
DPU-enforced egress kernel mediation hypervisor mediation API-gateway enforcement service-mesh enforcement database commit enforcement destination-side verification capability-required API TEE-mediated system call
If an attacker can bypass the Finality Sink and cause the same protected consequence through another path, then technical non-effectiveness has not been achieved.¶
That should be stated explicitly as a security requirement: for a consequence claimed to be protected by execution finality, there MUST NOT exist an unmediated effectuation path available to the protected workload.¶
This is the strongest distinction between an execution-finality architecture and a system that merely generates audit evidence.¶
RATS relevance: RATS establishes trust-related facts; it does not automatically create this topology.¶
WIMSE relevance: WIMSE can authenticate workloads traversing the enforced path, but workload identity alone does not remove bypass paths.¶
Question¶
What prevents the operation from changing after it is validated but before the Finality Sink executes it?¶
Answer¶
The Finality Sink must verify the same security-relevant Candidate Act that was authorized.¶
Suppose:¶
A = canonical Candidate Act H = HASH(A)
The validator authorizes H.¶
At finality:¶
H' = HASH(received Candidate Act)
The Sink requires:¶
H' == H
together with verification of the authorization evidence.¶
Therefore:¶
validation
|
v
Act A
|
attacker changes amount
|
v
Act A'
|
HASH(A') != authorized HASH(A)
|
v
DENY
For state-dependent operations, binding only the request may still be insufficient.¶
The decision may need to include:¶
resource version transaction epoch policy version expected state sequence number
or the Finality Sink may need to re-evaluate those conditions atomically with effectuation.¶
The strongest implementation is therefore: verify, consume authorization, and effectuate within one trusted transactional boundary.¶
RATS relevance: freshness and Attestation Result applicability remain relevant but are not substitutes for operation-level TOCTOU protection.¶
WIMSE relevance: workload identity remains bound to the operation but does not itself guarantee immutability of operation parameters.¶
Question¶
Distributed systems legitimately retry requests. How can replay protection distinguish malicious replay from safe retry?¶
Answer¶
Replay resistance should not simply mean "reject the same bytes twice."¶
The Finality Sink can use an idempotency or transaction model.¶
For example:¶
transaction_id = 7F29... act_digest = H(A) max_effects = 1 expiry = T
The Sink maintains:¶
(transaction_id, act_digest) -> state
with states such as:¶
UNUSED IN_PROGRESS COMMITTED FAILED_RETRYABLE EXPIRED
A network retry of a committed transaction can return the existing result without repeating the consequence.¶
A different Candidate Act presented with the same transaction identifier is rejected.¶
For operations legitimately allowing multiple effects, the authorization can specify:¶
max_uses sequence range rate limit resource set
The exact semantics remain application-specific.¶
RATS relevance: RATS already treats freshness and result lifetime as important properties. RFC 9334 distinguishes generation, appraisal, operation, and expiry events.¶
WIMSE relevance: workload authentication identifies who is retrying; finality state determines whether the consequence may occur again.¶
Question¶
Large inference clusters can issue enormous numbers of operations. Does execution finality place remote attestation or expensive cryptography on every request?¶
Answer¶
No.¶
The architecture should explicitly separate the cold path from the hot path.¶
COLD PATH
CPU/GPU/DPU Evidence
|
v
attestation verification
|
v
Attestation Result
|
v
cached trust context
Then:¶
HOT PATH
Candidate Act
|
digest
|
policy/context lookup
|
compact authorization
|
Finality Sink verification
Expensive endorsement retrieval, certificate-chain processing, reference-value evaluation, and composite attestation need not be performed for every Candidate Act.¶
Furthermore, not every AI output requires execution finality.¶
A deployment might classify:¶
ordinary inference output -> no finality processing read-only query -> lightweight policy financial transfer -> finality protected production deployment -> finality protected network reconfiguration -> finality protected external message publication -> finality protected
A DPU, SmartNIC, local gateway, or destination endpoint could verify compact proofs locally without another network round trip.¶
Thus execution finality is intended to operate at semantic consequence boundaries, not tensor-operation, packet, or memory-operation granularity.¶
RATS relevance: reusable Attestation Results make cold-path/hot-path separation possible.¶
WIMSE relevance: short-lived workload credentials and proof-of-possession can also be reused across many individual authorized operations.¶
Question¶
In an agentic workflow, one workload may plan, another may transform arguments, another may broker the tool call, and a fourth may execute it. Which workload is actually authorized?¶
Answer¶
The architecture should not require the initial workload identity to be treated as authority for all descendants.¶
Consider:¶
Agent A | Planner B | Tool Broker C | Execution Service D
Several identities can contribute to the decision:¶
initiating principal delegated subject Agent A workload identity Planner B identity Broker C identity Execution Service identity
However, finality is associated with the concrete operation presented at the consequence boundary.¶
For example:¶
Agent A: "pay approved invoice" Planner B: selects supplier Broker C: constructs: amount = 8,430 currency = EUR destination = account-X Finality Sink: authorizes the concrete transaction
The final authorization can carry or reference provenance from earlier workloads while remaining bound to the final Candidate Act.¶
This avoids treating transitive authentication as transitive unlimited authority.¶
RATS relevance: different components in the chain may themselves have separate attestation states or Verifiers.¶
WIMSE relevance: this is strongly aligned with WIMSE because the working group addresses workload identity in multi-service and multi-system environments. Its current architecture is specifically concerned with workload-to-workload authentication and authorization in distributed environments.¶
Execution finality provides a possible terminal enforcement semantic:¶
authenticated workload chain
|
v
concrete Candidate Act
|
v
act-specific authority
|
v
Finality Sink
Question¶
There is already an individual Internet-Draft describing Signed Authorization-Evidence Records for WIMSE-authorized AI agent actions. It cryptographically commits to canonical request bytes before dispatch. Isn't that the same mechanism?¶
Answer¶
This is a serious overlap question and should be addressed explicitly.¶
The current authorization-evidence draft defines a signed Permit recording a pre-execution authorization decision, binds it to canonical request bytes, and uses a Closure Record to bind to the dispatched request digest. The current revision also describes composition with OAuth, HTTP Message Signatures, WIMSE identity, and transaction-token context.¶
Therefore the proposed execution-finality draft should not claim novelty merely because it authorizes before dispatch, hashes the concrete request, or creates signed authorization evidence.¶
Those mechanisms are already being discussed.¶
The narrower proposed distinction is the architectural enforcement property: Permit/evidence exists does not equal external consequence is technically dependent on verification of that evidence.¶
Execution finality requires identifying an effectuation boundary and making successful verification load-bearing for the consequence:¶
Candidate Act
|
authorization
|
PVE / Permit / other artifact
|
v
FINALITY SINK
|
verification required
|
v
External Effect
If the destination may execute the request without verifying the required act-bound authority, the deployment does not satisfy the proposed execution-finality property.¶
Accordingly, the existing WIMSE Permit could potentially be used as one PVE representation rather than treated as a competing mechanism.¶
The proposed architecture should therefore ask whether existing WIMSE authorization evidence can become a required execution dependency at the destination or infrastructure effectuation boundary.¶
That is a substantially more constructive standards relationship.¶
RATS relevance: attestation context can become one input into issuance or validation of the Permit/finality artifact.¶
WIMSE relevance: extremely direct; WIMSE credentials, workload identity, and existing authorization-evidence work can potentially provide several protocol components rather than being reinvented.¶
Question¶
RATS already has an individual draft on composing application-layer Action Evidence Packages with platform attestation. Why isn't Candidate Act plus attestation just the same idea?¶
Answer¶
This is the other comparison the document should confront directly.¶
The current RATS AEP composition work describes cryptographically binding application-layer action records and outcomes to platform Evidence so that Verifiers and Relying Parties can reason jointly about platform state and what an automated system reports it did.¶
It includes action digests, outcome digests, authority references, freshness considerations, and substitution tests.¶
That means the proposed draft should not position action evidence plus remote attestation as a new concept by itself.¶
The strongest distinction is temporal and architectural.¶
Action evidence can answer questions such as: what action was reported, under what authority, on what attested platform, and what outcome was recorded?¶
Execution finality asks: could the protected external effect have happened without successful verification of the required authorization binding?¶
This produces two different security properties.¶
Evidence property:¶
Action | v record / digest / attestation | v verifiable evidence
Execution-finality property:¶
Candidate Act
|
NON-EFFECTIVE
|
v
authorization + validation
|
v
Finality Sink
|
mandatory verification
|
v
EFFECT
The current AEP draft itself notes that a reported outcome remains an application-layer claim unless independently observable effect evidence exists, and that platform binding does not by itself prove the truth of the external effect.¶
This gives the execution-finality proposal a useful boundary: evidence about an action is not necessarily the same security property as technical dependency of the action upon authorization.¶
The two could also be composed:¶
RATS
|
platform Evidence
|
Attestation Result
|
v
Candidate Act
|
validation
|
v
Finality Sink
|
v
External Effect
|
v
AEP
|
auditable evidence
This is potentially stronger than trying to replace the AEP work.¶
RATS relevance: RATS establishes and composes trustworthy evidence about execution environments and increasingly about richer attestation contexts.¶
WIMSE relevance: WIMSE identifies and authenticates the workloads participating in the action chain.¶
Execution-finality contribution: defines the protected transition from a proposed operation to an externally effective operation and requires the authorization state to be load-bearing at that transition.¶
The three layers can be summarized as follows:¶
+--------------------------------------------------+
| RATS |
| |
| What can be established about the platform, |
| environment, component, or Attester? |
| |
| Evidence -> Verifier -> Attestation Result |
+--------------------------+-----------------------+
|
v
+--------------------------------------------------+
| WIMSE |
| |
| Which workload is participating? |
| Can it prove possession of its identity key? |
| What trust domain does it belong to? |
| |
| Workload Identifier |
| WIT / WIC |
| workload-to-workload authentication |
+--------------------------+-----------------------+
|
v
+--------------------------------------------------+
| EXECUTION FINALITY |
| |
| What exact operation is proposed? |
| Is it authorized under the current identity, |
| attestation, policy and context? |
| |
| Can it acquire external effect without passing |
| the designated enforcement boundary? |
| |
| Candidate Act |
| | |
| v |
| act-bound validation |
| | |
| v |
| Finality Sink |
| | |
| v |
| External Effect |
+--------------------------------------------------+
The architecture therefore does not propose RATS versus execution finality, or WIMSE versus execution finality.¶
It proposes the possible composition:¶
RATS
"Can this execution context be trusted?"
|
v
WIMSE
"Which workload is acting?"
|
v
ACT-SPECIFIC AUTHORIZATION
"Is this exact operation permitted?"
|
v
EXECUTION FINALITY
"Has the required authorization become
technically load-bearing before consequence?"
|
v
EXTERNAL EFFECT
The core architectural invariant is end-to-end correspondence between the operation evaluated by the authorization function and the operation presented for effectuation. Environment appraisal and workload authentication are inputs to that decision, not substitutes for the act-specific decision.¶
For protected consequence classes, the Candidate Act remains non-effective until evidence authorizing its security-relevant content is verified at the boundary where the protected effect would be committed.¶