| Internet-Draft | -WIMSE Execution Context | -February 2026 | -
| Nennemann | -Expires 29 August 2026 | -[Page] | -
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.¶
-- 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 29 August 2026.¶
-- 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.¶
-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:¶
-The following are out of scope and are handled by WIMSE:¶
- -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", -"MAY", and "OPTIONAL" in this document are to be interpreted as -described in BCP 14 [RFC2119] [RFC8174] when, and only when, they -appear in all capitals, as shown here.¶
-The following terms are used in this document:¶
-An autonomous workload, as defined by WIMSE -[I-D.ietf-wimse-arch], that executes tasks within a workflow.¶
-A discrete unit of agent work that consumes inputs and produces -outputs.¶
-A graph structure representing task dependency ordering where -edges are directed and no cycles exist.¶
-A JSON Web Token [RFC7519] defined by this specification that -records task execution details.¶
-An append-only, immutable log of all ECTs within a workflow or -set of workflows, used for audit and verification.¶
-A WIMSE credential proving a workload's identity within a trust -domain.¶
-A WIMSE proof-of-possession token used for request-level -authentication.¶
-A WIMSE concept representing an organizational boundary with a -shared identity issuer, corresponding to a SPIFFE [SPIFFE] -trust domain.¶
-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:¶
-
-{
- "alg": "ES256",
- "typ": "wimse-exec+jwt",
- "kid": "agent-a-key-id-123"
-}
-
-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.¶
-REQUIRED. MUST be set to "wimse-exec+jwt" to distinguish ECTs -from other JWT types, consistent with the WIMSE convention for -type parameter values.¶
-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.¶
-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. 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.¶
-REQUIRED. NumericDate. The expiration time of the ECT. -Implementations SHOULD set this to 5 to 15 minutes after "iat".¶
-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 -ECTs into a single workflow. When present, MUST be a UUID -[RFC9562].¶
-REQUIRED. String. The action or task type identifier describing -what the agent performed (e.g., "process_payment", -"validate_safety"). This claim name avoids collision with the -"act" (Actor) claim registered by [RFC8693].¶
-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.¶
-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. 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 -the SHA-256 hash of the output data, using the same format as -"inp_hash".¶
-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.¶
-The following is a complete ECT payload example:¶
-
-{
- "iss": "spiffe://example.com/agent/clinical",
- "aud": "spiffe://example.com/agent/safety",
- "iat": 1772064150,
- "exp": 1772064750,
- "jti": "550e8400-e29b-41d4-a716-446655440001",
-
- "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
- "exec_act": "recommend_treatment",
- "par": [],
-
- "inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
- "out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
-
- "ext": {
- "com.example.trace_id": "abc123"
- }
-}
-
-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 -Execution-Context header alongside the WIMSE Workload-Identity -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 -Workload-Identity: eyJhbGci...WIT... -Execution-Context: eyJhbGci...ECT... --
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 -MUST individually verify each ECT per the procedure in -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.¶
-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.¶
-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.¶
-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
-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 -lead back to the current ECT's "jti". If a cycle is detected, -the ECT MUST be rejected.¶
-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.¶
-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].¶
-Verify that the "typ" header parameter is "wimse-exec+jwt".¶
-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.¶
-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.¶
-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).¶
-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 "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".¶
-Verify the "exp" claim indicates the ECT has not expired.¶
-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).¶
-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 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 -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.¶
-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.¶
-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.¶
-Integrity verification: The ledger SHOULD provide a mechanism -to verify that no entries have been tampered with (e.g., -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 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 -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:¶
-The claimed execution actually occurred as described¶
-The input/output hashes correspond to the actual data processed¶
-The agent faithfully performed the stated action¶
-The trustworthiness of ECT claims depends on the trustworthiness -of the signing agent and the integrity of the broader deployment -environment. ECTs provide a technical mechanism for execution -recording; they do not by themselves satisfy any specific -regulatory compliance requirement.¶
-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 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.¶
-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 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. Mitigations:¶
-Implementations SHOULD use short-lived keys and rotate them -frequently.¶
-Private keys SHOULD be stored in hardware security modules or -equivalent secure key storage.¶
-Trust domains MUST support rapid key revocation.¶
-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 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:¶
-The ledger SHOULD be maintained by an entity independent of the -workflow agents.¶
-Multiple independent ledger replicas can be compared for -consistency.¶
-External auditors can compare the declared DAG against expected -workflow patterns.¶
-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.¶
-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. Authorization decisions MUST remain with the identity and -authorization layer (WIT, WPT, and deployment policy).¶
-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.¶
-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.¶
-Implementations SHOULD limit the "par" array to a maximum of -256 entries. See Section 3.2.4 for "ext" size limits.¶
-ECTs necessarily reveal:¶
-Agent identities ("iss", "aud") for accountability purposes¶
-Action descriptions ("exec_act") for audit trail completeness¶
-Timestamps ("iat", "exp") for temporal ordering¶
-ECTs are designed to NOT reveal:¶
- -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 3.2.4) deserve particular -attention: human-readable values risk exposing sensitive operational -details. See Section 3.2.4 for guidance on using -structured identifiers.¶
-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) -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.¶
-This document requests registration of the following media type -in the "Media Types" registry maintained by IANA:¶
-application¶
-wimse-exec+jwt¶
-none¶
-none¶
-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.¶
-See the Security Considerations section of this document.¶
-none¶
-This document¶
-Applications that implement agentic workflows requiring execution -context tracing and audit trails.¶
-Magic number(s): none -File extension(s): none -Macintosh file type code(s): none¶
-Christian Nennemann, ietf@nennemann.de¶
-COMMON¶
-none¶
-Christian Nennemann¶
-IETF¶
-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:¶
-| Claim Name | -Claim Description | -Change Controller | -Reference | -
|---|---|---|---|
| wid | -Workflow Identifier | -IETF | -- Section 3.2.2 - | -
| exec_act | -Action/Task Type | -IETF | -- Section 3.2.2 - | -
| par | -Parent Task Identifiers | -IETF | -- Section 3.2.2 - | -
| inp_hash | -Input Data Hash | -IETF | -- Section 3.2.3 - | -
| out_hash | -Output Data Hash | -IETF | -- Section 3.2.3 - | -
| ext | -Extension Object | -IETF | -- Section 3.2.4 - | -
This section describes a representative use case demonstrating how -ECTs provide structured execution records.¶
-Note: task identifiers in this section are abbreviated for -readability. In production, all "jti" values are required to be -UUIDs per Section 3.2.2.¶
-In a cross-organization trading workflow, an investment bank's -agents coordinate with an external credit rating agency. The -agents operate in separate trust domains with a federation -relationship. The DAG records that independent assessments from -both organizations were completed before trade execution.¶
--Trust Domain: bank.example - Agent A1 (Portfolio Risk): - jti: task-001 par: [] - iss: spiffe://bank.example/agent/risk - exec_act: analyze_portfolio_risk - -Trust Domain: ratings.example (external) - Agent B1 (Credit Rating): - jti: task-002 par: [] - iss: spiffe://ratings.example/agent/credit - exec_act: assess_credit_rating - -Trust Domain: bank.example - Agent A2 (Compliance): - jti: task-003 par: [task-001, task-002] - iss: spiffe://bank.example/agent/compliance - exec_act: verify_trade_compliance - - Agent A3 (Execution): - jti: task-004 par: [task-003] - iss: spiffe://bank.example/agent/execution - exec_act: execute_trade --
The resulting DAG:¶
--task-001 (analyze_portfolio_risk) task-002 (assess_credit_rating) - [bank.example] [ratings.example] - \ / - v v - task-003 (verify_trade_compliance) - [bank.example] - | - v - task-004 (execute_trade) - [bank.example] --
Task 003 has two parents from different trust domains, -demonstrating cross-organizational fan-in. The compliance agent -verifies both parent ECTs — one signed by a local key and one by -a federated key from the rating agency's trust domain.¶
-The author thanks the WIMSE working group for their foundational -work on workload identity in multi-system environments. The -concepts of Workload Identity Tokens and Workload Proof Tokens -provide the identity foundation upon which execution context -tracing is built.¶
-