This document defines Execution Context Tokens (ECTs), an extension -to the Workload Identity in Multi System Environments (WIMSE) -architecture for distributed agentic workflows. ECTs provide -signed, structured records of task execution order across -agent-to-agent communication. By extending WIMSE Workload Identity -Tokens with execution context claims in JSON Web Token (JWT) -format, this specification enables systems to maintain structured -audit trails of agent execution. ECTs use a directed acyclic -graph (DAG) structure to represent task dependencies and integrate -with WIMSE Workload Identity Tokens (WIT) using the same signing -model and cryptographic primitives. A new HTTP header field, -Execution-Context, is defined for transporting ECTs alongside -existing WIMSE headers.¶
+This document defines Execution Context Tokens (ECTs), a JWT-based +extension to the WIMSE architecture that records task execution +across distributed agentic workflows. Each ECT is a signed record +of a single task, linked to predecessor tasks through a directed +acyclic graph (DAG). ECTs reuse the WIMSE signing model and are +transported in a new Execution-Context HTTP header field alongside +existing WIMSE identity headers.¶
The Workload Identity in Multi System Environments (WIMSE) -framework [I-D.ietf-wimse-arch] provides robust workload -authentication through Workload Identity Tokens (WIT) and Workload -Proof Tokens (WPT). The WIMSE service-to-service protocol -[I-D.ietf-wimse-s2s-protocol] defines how workloads authenticate -each other across call chains using the Workload-Identity and -Workload-Proof-Token HTTP headers.¶
-However, workload identity alone does not address execution -accountability. Knowing who performed an action does not record -what was done or in what order.¶
-Regulated environments increasingly deploy autonomous agents that -coordinate across organizational boundaries. Domains such as -healthcare, finance, and logistics require structured, auditable -records of automated decision-making and execution.¶
-This document defines an extension to the WIMSE architecture that -addresses the gap between workload identity and execution -accountability. WIMSE authenticates agents; this extension records -what they did and in what order.¶
-As identified in [I-D.ni-wimse-ai-agent-identity], call context -in agentic workflows needs to be visible and preserved. ECTs -provide a mechanism to address this requirement with cryptographic -assurances.¶
-Three core gaps exist in current approaches to regulated agentic -systems:¶
-WIMSE authenticates agents but does not record what they -actually did. A WIT proves "Agent A is authorized" but not -"Agent A executed Task X, producing Output Z."¶
-No standard mechanism exists to cryptographically order and -link task execution across a multi-agent workflow.¶
-No mechanism exists to reconstruct the complete execution -history of a distributed workflow for audit purposes.¶
-Existing observability tools such as distributed tracing -[OPENTELEMETRY] provide visibility for debugging and monitoring -but do not provide cryptographic assurances. Tracing data is not -cryptographically signed, not tamper-evident, and not designed for -regulatory audit scenarios.¶
-The WIMSE framework [I-D.ietf-wimse-arch] and its service-to- +service protocol [I-D.ietf-wimse-s2s-protocol] authenticate +workloads across call chains but do not record what those +workloads actually did. This document defines Execution Context +Tokens (ECTs), a JWT-based extension that fills the gap between +workload identity and execution accountability. Each ECT is a +signed record of a single task, linked to predecessor tasks +through a directed acyclic graph (DAG).¶
This document defines:¶
+This document defines:¶
The following are out of scope and are handled by WIMSE:¶
+The following are out of scope and are handled by WIMSE:¶
Workload authentication and identity provisioning¶
+Workload authentication and identity provisioning¶
Key distribution and management¶
+Key distribution and management¶
Trust domain establishment and management¶
+Trust domain establishment and management¶
Credential lifecycle management¶
+Credential lifecycle management¶
The WIMSE architecture [I-D.ietf-wimse-arch] defines:¶
-Workload Identity Tokens (WIT) that prove a workload's identity -within a trust domain ("I am Agent X in trust domain Y")¶
-Workload Proof Tokens (WPT) that prove possession of the private -key associated with a WIT ("I control the key for Agent X")¶
-Multi-hop authentication via the service-to-service protocol -[I-D.ietf-wimse-s2s-protocol]¶
-The following execution accountability needs are complementary to -the WIMSE scope and are not addressed by workload identity alone:¶
- -ECTs extend WIMSE by adding an execution accountability layer -between the identity layer and the application layer:¶
--+--------------------------------------------------+ -| WIMSE Layer (Identity) | -| WIT: "I am Agent X (spiffe://td/agent/x)" | -| WPT: "I prove I control the key for Agent X" | -+--------------------------------------------------+ - | - v -+--------------------------------------------------+ -| ECT Layer (Execution Accountability) [This Spec]| -| ECT: "Task executed, dependencies met, | -| inputs/outputs hashed" | -+--------------------------------------------------+ - | - v -+--------------------------------------------------+ -| Optional: Audit Ledger (Immutable Record) | -| "ECTs MAY be appended to an audit ledger" | -+--------------------------------------------------+ --
This extension reuses the WIMSE signing model, extends JWT claims -using standard JWT extensibility [RFC7519], and maintains WIMSE -concepts including trust domains and workload identifiers.¶
-An ECT integrates with the WIMSE identity framework through the -following mechanisms:¶
-The ECT JOSE header "kid" parameter MUST reference the public -key identifier from the agent's WIT.¶
-In WIMSE deployments, the ECT "iss" claim SHOULD use the WIMSE -workload identifier format (a SPIFFE ID [SPIFFE]).¶
-The ECT MUST be signed with the same private key associated -with the agent's WIT.¶
-The ECT signing algorithm (JOSE header "alg" parameter) MUST -match the algorithm used in the corresponding WIT.¶
-When an agent makes an HTTP request to another agent, the -Execution-Context header is carried alongside WIMSE identity -headers:¶
--HTTP Request from Agent A to Agent B: - Workload-Identity: <WIT for Agent A> - Execution-Context: <ECT recording what A did> --
When a Workload Proof Token (WPT) is available per -[I-D.ietf-wimse-s2s-protocol], agents SHOULD include it -alongside the WIT and ECT. ECT verification does not depend -on the presence of a WPT; the ECT is independently verifiable -via the WIT public key.¶
-The receiving agent (Agent B) verifies in order:¶
-WIT (WIMSE layer): Verifies Agent A's identity within the -trust domain. WPT verification, if present, per -[I-D.ietf-wimse-s2s-protocol].¶
-ECT (this extension): Records what Agent A did and what -precedent tasks exist.¶
-Ledger (if deployed): Appends the verified ECT to the audit -ledger.¶
-An Execution Context Token is a JSON Web Token (JWT) [RFC7519] +
An Execution Context Token is a JSON Web Token (JWT) [RFC7519]
signed as a JSON Web Signature (JWS) [RFC7515]. ECTs MUST use
JWS Compact Serialization (the base64url-encoded
header.payload.signature format) so that they can be carried in
-a single HTTP header value.¶
ECTs reuse the WIMSE signing model. The ECT MUST be signed with +the same private key associated with the agent's WIT. The JOSE +header "kid" parameter MUST reference the public key identifier +from the agent's WIT, and the "alg" parameter MUST match the +algorithm used in the corresponding WIT. In WIMSE deployments, +the ECT "iss" claim SHOULD use the WIMSE workload identifier +format (a SPIFFE ID [SPIFFE]).¶
The ECT JOSE header MUST contain the following parameters:¶
+The ECT JOSE header MUST contain the following parameters:¶
{
"alg": "ES256",
@@ -1886,245 +1643,189 @@ a single HTTP header value.¶
}
REQUIRED. The digital signature algorithm used to sign the ECT. +
REQUIRED. The digital signature algorithm used to sign the ECT. MUST match the algorithm in the corresponding WIT. Implementations MUST support ES256 [RFC7518]. The "alg" value MUST NOT be "none". Symmetric algorithms (e.g., HS256, HS384, HS512) MUST NOT be used, as ECTs require asymmetric -signatures for non-repudiation.¶
+signatures for non-repudiation.¶REQUIRED. MUST be set to "wimse-exec+jwt" to distinguish ECTs +
REQUIRED. MUST be set to "wimse-exec+jwt" to distinguish ECTs from other JWT types, consistent with the WIMSE convention for -type parameter values.¶
+type parameter values.¶REQUIRED. The key identifier referencing the public key from +
REQUIRED. The key identifier referencing the public key from the agent's WIT [RFC7517]. Used by verifiers to look up the -correct public key for signature verification.¶
+correct public key for signature verification.¶The ECT payload contains both WIMSE-compatible standard JWT claims -and execution context claims defined by this specification.¶
The following standard JWT claims [RFC7519] MUST be present in -every ECT:¶
-REQUIRED. StringOrURI. A URI identifying the issuer of the +
An ECT MUST contain the following standard JWT claims [RFC7519]:¶
+REQUIRED. StringOrURI. A URI identifying the issuer of the
ECT. In WIMSE deployments, this SHOULD be the workload's
SPIFFE ID in the format spiffe://<trust-domain>/<path>,
matching the "sub" claim of the agent's WIT. Non-WIMSE
deployments MAY use other URI schemes (e.g., HTTPS URLs or
-URN:UUID identifiers).¶
REQUIRED. StringOrURI or array of StringOrURI. The intended -recipient(s) of the ECT. Because ECTs serve as both inter-agent -messages and audit records, the "aud" claim SHOULD contain the -identifiers of all entities that will verify the ECT. In -practice this means:¶
-Point-to-point delivery: when an ECT is sent from one -agent to a single next agent, "aud" contains that agent's -workload identity. The receiving agent verifies the ECT and -forwards it to the ledger on behalf of the issuer.¶
-Direct-to-ledger submission: when an ECT is submitted -directly to the audit ledger (e.g., after a join or at -workflow completion), "aud" contains the ledger's identity.¶
-Multi-audience: when an ECT must be verified by both the -next agent and the ledger independently, "aud" MUST be an -array containing both identifiers (e.g., -["spiffe://example.com/agent/next", -"spiffe://example.com/system/ledger"]). Each verifier checks -that its own identity appears in the array.¶
-In multi-parent (join) scenarios where a task depends on ECTs -from multiple parent agents, the joining agent creates a new ECT -with the parent task IDs in "par". The "aud" of this new ECT -is set according to the rules above based on where the ECT will -be delivered — it is independent of the "aud" values in the -parent ECTs.¶
+REQUIRED. StringOrURI or array of StringOrURI. The intended +recipient(s) of the ECT. The "aud" claim SHOULD contain the +identifiers of all entities that will verify the ECT. When +an ECT must be verified by both the next agent and the audit +ledger independently, "aud" MUST be an array containing both +identifiers. Each verifier checks that its own identity +appears in "aud".¶
REQUIRED. NumericDate. The time at which the ECT was issued. -The ECT records a completed action, so the "iat" value reflects -when the record was created, not when task execution began.¶
+REQUIRED. NumericDate. The time at which the ECT was issued.¶
REQUIRED. NumericDate. The expiration time of the ECT. -Implementations SHOULD set this to 5 to 15 minutes after "iat" -to limit the replay window while allowing for reasonable clock -skew and processing time.¶
+REQUIRED. NumericDate. The expiration time of the ECT. +Implementations SHOULD set this to 5 to 15 minutes after "iat".¶
The standard JWT "nbf" (Not Before) claim is not used in ECTs -because ECTs record completed actions and are valid immediately -upon issuance.¶
-REQUIRED. String. A globally unique identifier for both the -ECT and the task it records, in UUID format [RFC9562]. Since -each ECT represents exactly one task, "jti" serves as both the -token identifier (for replay detection) and the task identifier -(for DAG parent references in "par"). Receivers MUST reject -ECTs whose "jti" has already been seen within the expiration -window. When "wid" is present, uniqueness is scoped to the -workflow; when "wid" is absent, uniqueness MUST be enforced -globally across the ECT store.¶
+ +REQUIRED. String. A unique identifier for both the ECT and +the task it records, in UUID format [RFC9562]. The "jti" +serves as both the token identifier (for replay detection) and +the task identifier (for DAG parent references in "par"). +Receivers MUST reject ECTs whose "jti" has already been seen +within the expiration window. When "wid" is present, +uniqueness is scoped to the workflow; when "wid" is absent, +uniqueness MUST be enforced globally across the ECT store.¶
The following claims are defined by this specification:¶
-OPTIONAL. String. A workflow identifier that groups related +
The following claims are defined by this specification:¶
+OPTIONAL. String. A workflow identifier that groups related ECTs into a single workflow. When present, MUST be a UUID -[RFC9562].¶
+[RFC9562].¶REQUIRED. String. The action or task type identifier describing +
REQUIRED. String. The action or task type identifier describing what the agent performed (e.g., "process_payment", -"validate_safety", "calculate_dosage"). Note: this claim is -intentionally named "exec_act" rather than "act" to avoid -collision with the "act" (Actor) claim registered by -[RFC8693].¶
+"validate_safety"). This claim name avoids collision with the +"act" (Actor) claim registered by [RFC8693].¶REQUIRED. Array of strings. Parent task identifiers +
REQUIRED. Array of strings. Parent task identifiers representing DAG dependencies. Each element MUST be the "jti" value of a previously verified ECT. An empty array indicates a root task with no dependencies. A workflow MAY contain -multiple root tasks. Parent ECTs may have passed their own -"exp" time; ECT expiration applies to the verification window -of the ECT itself, not to its validity as a parent reference -in the ECT store. Note: "par" is not a registered JWT claim -and does not conflict with OAuth Pushed Authorization Requests -(RFC 9126), which defines an endpoint, not a token claim.¶
+multiple root tasks.¶The following claims provide integrity verification for task -inputs and outputs without revealing the data itself:¶
-OPTIONAL. String. The base64url encoding (without padding) of +
The following claims provide integrity verification for task +inputs and outputs without revealing the data itself:¶
+OPTIONAL. String. The base64url encoding (without padding) of the SHA-256 hash of the input data, computed over the raw octets -of the input. This follows the same fixed-algorithm pattern -used by the DPoP "ath" claim [RFC9449] and the WIMSE WPT -"tth" claim [I-D.ietf-wimse-s2s-protocol]: SHA-256 is the -mandatory algorithm with no algorithm prefix in the value.¶
+of the input. SHA-256 is the mandatory algorithm with no +algorithm prefix in the value, consistent with [RFC9449] and +[I-D.ietf-wimse-s2s-protocol].¶OPTIONAL. String. The base64url encoding (without padding) of +
OPTIONAL. String. The base64url encoding (without padding) of the SHA-256 hash of the output data, using the same format as -"inp_hash".¶
+"inp_hash".¶OPTIONAL. Object. A general-purpose extension object for -domain-specific claims not defined by this specification. The -short name "ext" follows the JWT convention of concise claim -names and is chosen over alternatives like "extensions" for -compactness. Implementations that do not understand extension -claims MUST ignore them.¶
+OPTIONAL. Object. A general-purpose extension object for +domain-specific claims not defined by this specification. +Implementations that do not understand extension claims MUST +ignore them. Extension key names SHOULD use reverse domain +notation (e.g., "com.example.custom_field") to avoid +collisions. The serialized "ext" object SHOULD NOT exceed +4096 bytes and SHOULD NOT exceed a nesting depth of 5 levels.¶
To avoid key collisions between different domains, extension -key names SHOULD use reverse domain notation (e.g., -"com.example.custom_field") to avoid collisions between -independently developed extensions. To prevent abuse and -excessive token size, the serialized JSON representation of -the "ext" object SHOULD NOT exceed 4096 bytes, and the JSON -nesting depth within the "ext" object SHOULD NOT exceed 5 -levels. Implementations SHOULD reject ECTs whose "ext" claim -exceeds these limits.¶
-Extension keys for domain-specific use cases MAY be defined in -future documents.¶
The following is a complete ECT payload example:¶
+The following is a complete ECT payload example:¶
{
"iss": "spiffe://example.com/agent/clinical",
@@ -2146,7 +1847,7 @@ future documents.¶
}
This specification defines the Execution-Context HTTP header field -[RFC9110] for transporting ECTs between agents.¶
-The header field value is the ECT in JWS Compact Serialization +
This specification defines the Execution-Context HTTP header field +[RFC9110] for transporting ECTs between agents.¶
+The header field value is the ECT in JWS Compact Serialization format [RFC7515]. The value consists of three Base64url-encoded -parts separated by period (".") characters.¶
-An agent sending a request to another agent includes the +parts separated by period (".") characters.¶
+An agent sending a request to another agent includes the Execution-Context header alongside the WIMSE Workload-Identity -header:¶
+header. When a Workload Proof Token (WPT) is available per +[I-D.ietf-wimse-s2s-protocol], agents SHOULD include it +alongside the WIT and ECT.¶GET /api/safety-check HTTP/1.1 Host: safety-agent.example.com @@ -2182,67 +1885,51 @@ Workload-Identity: eyJhbGci...WIT... Execution-Context: eyJhbGci...ECT...
When multiple parent tasks contribute context to a single request, +
When multiple parent tasks contribute context to a single request, multiple Execution-Context header field lines MAY be included, each -carrying a separate ECT in JWS Compact Serialization format.¶
-When a receiver processes multiple Execution-Context headers, it +carrying a separate ECT in JWS Compact Serialization format.¶
+When a receiver processes multiple Execution-Context headers, it MUST individually verify each ECT per the procedure in -Section 7. If any single ECT fails verification, the +Section 6. If any single ECT fails verification, the receiver MUST reject the entire request. The set of verified parent task IDs across all received ECTs represents the complete set of parent dependencies available for the receiving agent's -subsequent ECT.¶
+subsequent ECT.¶ECTs form a Directed Acyclic Graph (DAG) where each task -references its parent tasks via the "par" claim. This structure -provides a cryptographically signed record of execution ordering, -enabling auditors to reconstruct the complete workflow and verify -that required predecessor tasks were recorded before dependent -tasks.¶
-DAG validation is performed against the ECT store — either an -audit ledger or the set of parent ECTs received inline.¶
-When receiving and verifying an ECT, implementations MUST perform -the following DAG validation steps:¶
-Task ID Uniqueness: The "jti" claim MUST be unique within the +
ECTs form a Directed Acyclic Graph (DAG) where each task +references its parent tasks via the "par" claim. DAG validation +is performed against the ECT store — either an audit ledger or +the set of parent ECTs received inline.¶
+When receiving and verifying an ECT, implementations MUST perform +the following DAG validation steps:¶
+Task ID Uniqueness: The "jti" claim MUST be unique within the applicable scope (the workflow identified by "wid", or the entire ECT store if "wid" is absent). If an ECT with the same -"jti" already exists, the ECT MUST be rejected.¶
+"jti" already exists, the ECT MUST be rejected.¶Parent Existence: Every task identifier listed in the "par" +
Parent Existence: Every task identifier listed in the "par" array MUST correspond to a task that is available in the ECT store (either previously recorded in the ledger or received inline as a verified parent ECT). If any parent task is not -found, the ECT MUST be rejected.¶
+found, the ECT MUST be rejected.¶Temporal Ordering: The "iat" value of every parent task MUST NOT be greater than the "iat" value of the current task plus a +
Temporal Ordering: The "iat" value of every parent task MUST NOT be greater than the "iat" value of the current task plus a
configurable clock skew tolerance (RECOMMENDED: 30 seconds).
That is, for each parent: parent.iat < child.iat +
clock_skew_tolerance. The tolerance accounts for clock skew
@@ -2250,715 +1937,557 @@ between agents; it does not guarantee strict causal ordering
from timestamps alone. Causal ordering is primarily enforced
by the DAG structure (parent existence in the ECT store), not by
timestamps. If any parent task violates this constraint, the
-ECT MUST be rejected.¶
Acyclicity: Following the chain of parent references MUST NOT +
Acyclicity: Following the chain of parent references MUST NOT lead back to the current ECT's "jti". If a cycle is detected, -the ECT MUST be rejected.¶
+the ECT MUST be rejected.¶Trust Domain Consistency: Parent tasks SHOULD belong to the +
Trust Domain Consistency: Parent tasks SHOULD belong to the same trust domain or to a trust domain with which a federation -relationship has been established.¶
+relationship has been established.¶To prevent denial-of-service via extremely deep or wide DAGs, +
To prevent denial-of-service via extremely deep or wide DAGs, implementations SHOULD enforce a maximum ancestor traversal limit (RECOMMENDED: 10000 nodes). If the limit is reached before cycle -detection completes, the ECT SHOULD be rejected.¶
-In distributed deployments, a parent ECT may not yet be available +locally due to replication lag. Implementations MAY defer +validation to allow parent ECTs to arrive, but MUST NOT treat +the ECT as verified until all parent references are resolved.¶
When an agent receives an ECT, it MUST perform the following -verification steps in order:¶
-Parse the JWS Compact Serialization to extract the JOSE header, -payload, and signature components per [RFC7515].¶
+When an agent receives an ECT, it MUST perform the following +verification steps in order:¶
+Parse the JWS Compact Serialization to extract the JOSE header, +payload, and signature components per [RFC7515].¶
Verify that the "typ" header parameter is "wimse-exec+jwt".¶
+Verify that the "typ" header parameter is "wimse-exec+jwt".¶
Verify that the "alg" header parameter appears in the +
Verify that the "alg" header parameter appears in the verifier's configured allowlist of accepted signing algorithms. The allowlist MUST NOT include "none" or any symmetric algorithm (e.g., HS256, HS384, HS512). Implementations MUST include ES256 in the allowlist; additional asymmetric algorithms -MAY be included per deployment policy.¶
+MAY be included per deployment policy.¶Verify the "kid" header parameter references a known, valid -public key from a WIT within the trust domain.¶
+Verify the "kid" header parameter references a known, valid +public key from a WIT within the trust domain.¶
Retrieve the public key identified by "kid" and verify the JWS -signature per [RFC7515] Section 5.2.¶
+Retrieve the public key identified by "kid" and verify the JWS +signature per [RFC7515] Section 5.2.¶
Verify that the signing key identified by "kid" has not been +
Verify that the signing key identified by "kid" has not been revoked within the trust domain. Implementations MUST check the key's revocation status using the trust domain's key lifecycle mechanism (e.g., certificate revocation list, OCSP, -or SPIFFE trust bundle updates).¶
+or SPIFFE trust bundle updates).¶Verify the "alg" header parameter matches the algorithm in the -corresponding WIT.¶
+Verify the "alg" header parameter matches the algorithm in the +corresponding WIT.¶
Verify the "iss" claim matches the "sub" claim of the WIT -associated with the "kid" public key.¶
+Verify the "iss" claim matches the "sub" claim of the WIT +associated with the "kid" public key.¶
Verify the "aud" claim contains the verifier's own workload +
Verify the "aud" claim contains the verifier's own workload identity. When "aud" is an array, it is sufficient that the verifier's identity appears as one element; the presence of other audience values does not cause verification failure. When the verifier is the audit ledger, the ledger's own -identity MUST appear in "aud".¶
+identity MUST appear in "aud".¶Verify the "exp" claim indicates the ECT has not expired.¶
+Verify the "exp" claim indicates the ECT has not expired.¶
Verify the "iat" claim is not unreasonably far in the past +
Verify the "iat" claim is not unreasonably far in the past (implementation-specific threshold, RECOMMENDED maximum of 15 minutes) and is not unreasonably far in the future (RECOMMENDED: no more than 30 seconds ahead of the -verifier's current time, to account for clock skew).¶
+verifier's current time, to account for clock skew).¶Verify all required claims ("jti", "exec_act", "par") are -present and well-formed.¶
+Verify all required claims ("jti", "exec_act", "par") are +present and well-formed.¶
If all checks pass and an audit ledger is deployed, the ECT -SHOULD be appended to the ledger.¶
+If all checks pass and an audit ledger is deployed, the ECT +SHOULD be appended to the ledger.¶
If any verification step fails, the ECT MUST be rejected and the +
If any verification step fails, the ECT MUST be rejected and the failure MUST be logged for audit purposes. Error messages SHOULD NOT reveal whether specific parent task IDs exist in the -ECT store, to prevent information disclosure.¶
-When ECT verification fails during HTTP request processing, the +ECT store, to prevent information disclosure.¶
+When ECT verification fails during HTTP request processing, the receiving agent SHOULD respond with HTTP 403 (Forbidden) if the WIT is valid but the ECT is invalid, and HTTP 401 (Unauthorized) if the ECT signature verification fails. The response body SHOULD include a generic error indicator without revealing which specific verification step failed. The receiving agent MUST NOT process the requested action when ECT verification -fails.¶
+fails.¶ECTs MAY be recorded in an immutable audit ledger for compliance +
ECTs MAY be recorded in an immutable audit ledger for compliance verification and post-hoc analysis. A ledger is RECOMMENDED for regulated environments but is not required for point-to-point operation. This specification does not mandate a specific storage technology. Implementations MAY use append-only logs, databases with cryptographic commitment schemes, distributed ledgers, or -any storage mechanism that provides the required properties.¶
-When an audit ledger is deployed, the implementation MUST provide:¶
-Append-only semantics: Once an ECT is recorded, it MUST NOT be -modified or deleted.¶
+any storage mechanism that provides the required properties.¶ +When an audit ledger is deployed, the implementation MUST provide:¶
+Append-only semantics: Once an ECT is recorded, it MUST NOT be +modified or deleted.¶
Ordering: The ledger MUST maintain a total ordering of ECT -entries via a monotonically increasing sequence number.¶
+Ordering: The ledger MUST maintain a total ordering of ECT +entries via a monotonically increasing sequence number.¶
Lookup by ECT ID: The ledger MUST support efficient retrieval -of ECT entries by "jti" value.¶
+Lookup by ECT ID: The ledger MUST support efficient retrieval +of ECT entries by "jti" value.¶
Integrity verification: The ledger SHOULD provide a mechanism +
Integrity verification: The ledger SHOULD provide a mechanism to verify that no entries have been tampered with (e.g., -hash chains or Merkle trees).¶
+hash chains or Merkle trees).¶The ledger SHOULD be maintained by an entity independent of the -workflow agents to reduce the risk of collusion.¶
+The ledger SHOULD be maintained by an entity independent of the +workflow agents to reduce the risk of collusion.¶
This section addresses security considerations following the -guidance in [RFC3552].¶
The following threat actors are considered:¶
-Malicious agent (insider threat): An agent within the trust -domain that intentionally creates false ECT claims.¶
-Compromised agent (external attacker): An agent whose private -key has been obtained by an external attacker.¶
-Ledger tamperer: An entity attempting to modify or delete ledger -entries after they have been recorded.¶
-Time manipulator: An entity attempting to manipulate timestamps -to alter perceived execution ordering.¶
-The threat model considers: (1) a malicious agent that creates +false ECT claims, (2) an agent whose private key has been +compromised, (3) a ledger tamperer attempting to modify recorded +entries, and (4) a time manipulator altering timestamps to affect +perceived ordering.¶
ECTs are self-asserted by the executing agent. The agent claims +
ECTs are self-asserted by the executing agent. The agent claims what it did, and this claim is signed with its private key. A compromised or malicious agent could create ECTs with false claims -(e.g., claiming an action was performed when it was not).¶
-ECTs do not independently verify that:¶
+(e.g., claiming an action was performed when it was not).¶ +ECTs do not independently verify that:¶
The claimed execution actually occurred as described¶
+The claimed execution actually occurred as described¶
The input/output hashes correspond to the actual data processed¶
+The input/output hashes correspond to the actual data processed¶
The agent faithfully performed the stated action¶
+The agent faithfully performed the stated action¶
The trustworthiness of ECT claims depends on the trustworthiness +
The trustworthiness of ECT claims depends on the trustworthiness of the signing agent and the integrity of the broader deployment -environment.¶
-ECTs operate within a broader trust framework. The guarantees -provided by ECTs are only meaningful when the following -organizational controls are in place:¶
-Key management governance: Controls over who provisions agent -keys and how keys are protected.¶
-Ledger integrity governance: The ledger is maintained by an -entity independent of the workflow agents.¶
-Agent deployment governance: Agents are deployed and maintained -in a manner that preserves their integrity.¶
-ECTs MUST be signed with the agent's private key using JWS +
ECTs MUST be signed with the agent's private key using JWS [RFC7515]. The signature algorithm MUST match the algorithm specified in the agent's WIT. Receivers MUST verify the ECT signature against the WIT public key before processing any claims. Receivers MUST verify that the signing key has not been revoked within the trust domain (see step 6 in -Section 7).¶
-If signature verification fails or if the signing key has been +Section 6).¶
+If signature verification fails or if the signing key has been revoked, the ECT MUST be rejected entirely and the failure MUST -be logged.¶
-Implementations MUST use established JWS libraries and MUST NOT -implement custom signature verification.¶
+be logged.¶ +Implementations MUST use established JWS libraries and MUST NOT +implement custom signature verification.¶
ECTs include short expiration times (RECOMMENDED: 5-15 minutes) to -limit the window for replay attacks. The "aud" claim restricts -replay to unintended recipients: an ECT intended for Agent B -will be rejected by Agent C. The "iat" claim enables receivers to -reject ECTs that are too old, even if not yet expired.¶
-The DAG structure provides additional replay protection: an ECT -referencing parent tasks that already have a recorded child task -with the same action can be flagged as a potential replay.¶
-Implementations MUST maintain a cache of recently-seen "jti" -values to detect replayed ECTs within the expiration window. -An ECT with a duplicate "jti" value MUST be rejected.¶
-Additionally, each ECT is cryptographically bound to the issuing -agent via the JOSE "kid" parameter, which references the agent's -WIT public key. Verifiers MUST confirm that the "kid" resolves -to the "iss" agent's key (step 8 in Section 7), preventing -one agent from replaying another agent's ECT as its own.¶
+ECTs include short expiration times (RECOMMENDED: 5-15 minutes) +and audience restriction via "aud" to limit replay attacks. +Implementations MUST maintain a cache of recently-seen "jti" +values and MUST reject ECTs with duplicate "jti" values. Each +ECT is cryptographically bound to the issuing agent via "kid"; +verifiers MUST confirm that "kid" resolves to the "iss" agent's +key (step 8 in Section 6).¶
ECTs do not replace transport-layer security. ECTs MUST be -transmitted over TLS or mTLS connections. When used with the WIMSE -service-to-service protocol [I-D.ietf-wimse-s2s-protocol], -transport security is already established. HTTP Message Signatures -[RFC9421] provide an alternative channel binding mechanism.¶
-The defense-in-depth model provides:¶
-TLS/mTLS (transport layer): Prevents network-level tampering.¶
-WIT/WPT (WIMSE identity layer): Proves agent identity and -request authorization.¶
-ECT (execution accountability layer): Records what the agent did.¶
-ECTs MUST be transmitted over TLS or mTLS connections. When used +with [I-D.ietf-wimse-s2s-protocol], transport security is +already established.¶
If an agent's private key is compromised, an attacker can forge -ECTs that appear to originate from that agent. To mitigate this -risk:¶
+If an agent's private key is compromised, an attacker can forge +ECTs that appear to originate from that agent. Mitigations:¶
Implementations SHOULD use short-lived keys and rotate them -frequently (hours to days, not months).¶
+Implementations SHOULD use short-lived keys and rotate them +frequently.¶
Private keys SHOULD be stored in Hardware Security Modules (HSMs) -or equivalent secure key storage.¶
+Private keys SHOULD be stored in hardware security modules or +equivalent secure key storage.¶
Trust domains MUST support rapid key revocation.¶
-Upon suspected compromise, the trust domain MUST revoke the -compromised key and issue a new WIT with a fresh key pair.¶
+Trust domains MUST support rapid key revocation.¶
ECTs signed with a compromised key that were recorded in the -ledger before revocation remain valid historical records but SHOULD -be flagged in the ledger as "signed with subsequently revoked key" -for audit purposes.¶
-ECT revocation does not propagate through the DAG. If a parent -ECT's signing key is later revoked, child ECTs that were verified -and recorded before that revocation remain valid — they captured -a legitimate execution record at the time of issuance. However, -auditors reviewing a workflow SHOULD flag any ECT in the DAG -whose signing key was subsequently revoked, so that the scope of -a potential compromise can be assessed. New ECTs MUST NOT be -created with a "par" reference to an ECT whose signing key is -known to be revoked at creation time.¶
+ECTs recorded before key revocation remain valid historical +records but SHOULD be flagged for audit purposes. New ECTs +MUST NOT reference a parent ECT whose signing key is known to +be revoked at creation time.¶
A single malicious agent cannot forge parent task references -because DAG validation requires parent tasks to exist in the -ledger. However, multiple colluding agents could potentially -create a false execution history if they control the ledger.¶
-Mitigations include:¶
+A single malicious agent cannot forge parent task references +because DAG validation requires parent tasks to exist in the ECT +store. However, multiple colluding agents could create a false +execution history. Additionally, a malicious agent may omit +actual parent dependencies from "par" to hide influences on its +output; because ECTs are self-asserted +(Section 8.2), no mechanism can force complete +dependency declaration.¶
+Mitigations include:¶
Independent ledger maintenance: The ledger SHOULD be maintained -by an entity independent of the workflow agents.¶
+The ledger SHOULD be maintained by an entity independent of the +workflow agents.¶
Cross-verification: Multiple independent ledger replicas can be -compared for consistency.¶
+Multiple independent ledger replicas can be compared for +consistency.¶
Out-of-band audit: External auditors periodically verify ledger -contents against expected workflow patterns.¶
+External auditors can compare the declared DAG against expected +workflow patterns.¶
Because the DAG structure is the primary mechanism for establishing -execution ordering, attackers may attempt to manipulate it:¶
-False parent references: A malicious agent creates an ECT that -references parent tasks from an unrelated workflow, inserting -itself into a legitimate execution history. DAG validation -(Section 6) mitigates this by requiring parent existence -in the ECT store, and the "wid" claim scopes parent references -to a single workflow when present.¶
-Parent omission (pruning): An agent deliberately omits one or -more actual parent dependencies from the "par" array to hide -that certain tasks influenced its output. Because ECTs are -self-asserted (Section 9.2), no mechanism can -force an agent to declare all dependencies. External auditors -can detect omission by comparing the declared DAG against -expected workflow patterns.¶
-Shadow DAGs: Multiple colluding agents fabricate an entire -execution history by creating a sequence of ECTs with mutual -parent references. Independent ledger maintenance and -cross-verification (see Section 9.8 above) -are the primary mitigations.¶
-Verifiers SHOULD validate that the declared "wid" of parent ECTs +
Verifiers SHOULD validate that the declared "wid" of parent ECTs matches the "wid" of the child ECT, rejecting cross-workflow parent references unless explicitly permitted by deployment -policy.¶
+policy.¶ECTs record execution history; they do not convey authorization. +
ECTs record execution history; they do not convey authorization. Verifiers MUST NOT interpret the presence of an ECT, or a particular set of parent references in "par", as an authorization -grant. The "par" claim demonstrates that predecessor tasks were -recorded, not that the current agent is authorized to act on -their outputs. Authorization decisions MUST remain with the -identity and authorization layer (WIT, WPT, and deployment -policy). As noted in [I-D.ni-wimse-ai-agent-identity], -AI intermediaries introduce novel escalation vectors; ECTs -MUST NOT be used to circumvent authorization boundaries.¶
+grant. Authorization decisions MUST remain with the identity and +authorization layer (WIT, WPT, and deployment policy).¶ECT signature verification is computationally inexpensive -(approximately 1ms per ECT on modern hardware for ES256). DAG -validation complexity is O(V) where V is the number of ancestor -nodes reachable from the parent references; for typical shallow -DAGs this is efficient.¶
-Implementations SHOULD apply rate limiting at the API layer to -prevent excessive ECT submissions. DAG validation SHOULD be -performed after signature verification to avoid wasting resources -on unsigned or incorrectly signed tokens.¶
+Implementations SHOULD apply rate limiting to prevent excessive +ECT submissions. DAG validation SHOULD be performed after +signature verification to avoid wasting resources on unsigned +tokens.¶
ECTs rely on timestamps ("iat", "exp") for temporal ordering. -Clock skew between agents can lead to incorrect ordering -judgments. Implementations SHOULD use synchronized time sources -(e.g., NTP) and SHOULD allow a configurable clock skew tolerance -(RECOMMENDED: 30 seconds).¶
-Cross-organizational deployments where agents span multiple trust -domains with independent time sources MAY require a higher clock -skew tolerance. Deployments using trust domain federation SHOULD -document their configured clock skew tolerance value and SHOULD -ensure all participating trust domains agree on a common tolerance.¶
-The temporal ordering check in DAG validation incorporates the -clock skew tolerance to account for minor clock differences -between agents.¶
+Implementations SHOULD use synchronized time sources (e.g., NTP) +and SHOULD allow a configurable clock skew tolerance (RECOMMENDED: +30 seconds). Cross-organizational deployments MAY require a +higher tolerance and SHOULD document the configured value.¶
ECTs with many parent tasks or large extension objects can -increase HTTP header size. Implementations SHOULD limit the "par" -array to a maximum of 256 entries. Workflows requiring more -parent references SHOULD introduce intermediate aggregation -tasks. The "ext" object SHOULD NOT exceed 4096 bytes when -serialized as JSON and SHOULD NOT exceed a nesting depth of -5 levels (see also Section 4.2.4).¶
+Implementations SHOULD limit the "par" array to a maximum of +256 entries. See Section 3.2.4 for "ext" size limits.¶
ECTs necessarily reveal:¶
+ECTs necessarily reveal:¶
Agent identities ("iss", "aud") for accountability purposes¶
+Agent identities ("iss", "aud") for accountability purposes¶
Action descriptions ("exec_act") for audit trail completeness¶
+Action descriptions ("exec_act") for audit trail completeness¶
Timestamps ("iat", "exp") for temporal ordering¶
+Timestamps ("iat", "exp") for temporal ordering¶
ECTs are designed to NOT reveal:¶
+ECTs are designed to NOT reveal:¶
Actual input or output data values (replaced with cryptographic -hashes via "inp_hash" and "out_hash")¶
+Actual input or output data values (replaced with cryptographic +hashes via "inp_hash" and "out_hash")¶
Internal computation details or intermediate steps¶
+Internal computation details or intermediate steps¶
Proprietary algorithms or intellectual property¶
+Proprietary algorithms or intellectual property¶
Personally identifiable information (PII)¶
+Personally identifiable information (PII)¶
Implementations SHOULD minimize the information included in ECTs. +
Implementations SHOULD minimize the information included in ECTs. The "exec_act" claim SHOULD use structured identifiers (e.g., "process_payment") rather than natural language descriptions. -Extension keys in "ext" (Section 4.2.4) deserve particular +Extension keys in "ext" (Section 3.2.4) deserve particular attention: human-readable values risk exposing sensitive operational -details. See Section 4.2.4 for guidance on using -structured identifiers.¶
+details. See Section 3.2.4 for guidance on using +structured identifiers.¶ECTs stored in audit ledgers SHOULD be access-controlled so that +
ECTs stored in audit ledgers SHOULD be access-controlled so that only authorized auditors can read them. Implementations SHOULD consider encryption at rest for ledger storage. ECTs provide structural records of execution ordering; they are not intended -for public disclosure.¶
-Full input and output data (corresponding to the hashes in ECTs) +for public disclosure.¶
+Full input and output data (corresponding to the hashes in ECTs) SHOULD be stored separately from the ledger with additional access controls, since auditors may need to verify hash correctness but -general access to the data values is not needed.¶
+general access to the data values is not needed.¶This document requests registration of the following media type -in the "Media Types" registry maintained by IANA:¶
-application¶
+This document requests registration of the following media type +in the "Media Types" registry maintained by IANA:¶
+application¶
wimse-exec+jwt¶
+wimse-exec+jwt¶
none¶
+none¶
none¶
+none¶
8bit; an ECT is a JWT that is a JWS using the Compact +
8bit; an ECT is a JWT that is a JWS using the Compact Serialization, which is a sequence of Base64url-encoded values -separated by period characters.¶
+separated by period characters.¶See the Security Considerations section of this document.¶
+See the Security Considerations section of this document.¶
none¶
+none¶
This document¶
+This document¶
Applications that implement agentic workflows requiring execution -context tracing and audit trails.¶
+Applications that implement agentic workflows requiring execution +context tracing and audit trails.¶
Magic number(s): none +
Magic number(s): none File extension(s): none -Macintosh file type code(s): none¶
+Macintosh file type code(s): none¶Christian Nennemann, ietf@nennemann.de¶
+Christian Nennemann, ietf@nennemann.de¶
COMMON¶
+COMMON¶
none¶
+none¶
Christian Nennemann¶
+Christian Nennemann¶
IETF¶
+IETF¶
This document requests registration of the following header field +
This document requests registration of the following header field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" -maintained by IANA:¶
-This document requests registration of the following claims in -the "JSON Web Token Claims" registry maintained by IANA:¶
+This document requests registration of the following claims in +the "JSON Web Token Claims" registry maintained by IANA:¶