c/ietf-wimse-ect
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a263d8c2018621af59a55ebf4e476d91f52650d4
ietf-wimse-ect/draft-nennemann-wimse-execution-context-00.txt

2969 lines
108 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
WIMSE C. Nennemann
Internet-Draft Independent Researcher
Intended status: Standards Track 24 February 2026
Expires: 28 August 2026
Execution Context Tokens for Distributed Agentic Workflows
draft-nennemann-wimse-execution-context-00
Abstract
This document defines Execution Context Tokens (ECTs), an extension
to the Workload Identity in Multi System Environments (WIMSE)
architecture for distributed agentic workflows in regulated
environments. ECTs provide cryptographic proof of task execution
order, policy enforcement decisions, and compliance state across
agent-to-agent communication. By extending WIMSE Workload Identity
Tokens with execution context claims in JSON Web Token (JWT) format,
this specification enables regulated systems to maintain structured
audit trails that support compliance verification. ECTs use a
directed acyclic graph (DAG) structure to represent task
dependencies, record policy evaluation outcomes at each decision
point, and integrate with WIMSE Workload Identity Tokens (WIT) and
Workload Proof Tokens (WPT) using the same signing model and
cryptographic primitives. A new HTTP header field, Execution-
Context, is defined for transporting ECTs alongside existing WIMSE
headers. ECTs are a technical building block that supports, but does
not by itself constitute, compliance with regulatory frameworks.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 August 2026.
Nennemann Expires 28 August 2026 [Page 1]
Internet-Draft WIMSE Execution Context February 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 5
1.3. Scope and Applicability . . . . . . . . . . . . . . . . . 5
1.4. Relationship to Regulatory Compliance . . . . . . . . . . 6
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6
3. WIMSE Architecture Integration . . . . . . . . . . . . . . . 7
3.1. WIMSE Foundation . . . . . . . . . . . . . . . . . . . . 7
3.2. Extension Model . . . . . . . . . . . . . . . . . . . . . 8
3.3. Integration Points . . . . . . . . . . . . . . . . . . . 8
4. Execution Context Token Format . . . . . . . . . . . . . . . 9
4.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Standard JWT Claims . . . . . . . . . . . . . . . . . 10
4.2.2. Execution Context . . . . . . . . . . . . . . . . . . 11
4.2.3. Policy Evaluation . . . . . . . . . . . . . . . . . . 12
4.2.4. Data Integrity . . . . . . . . . . . . . . . . . . . 13
4.2.5. Task Metadata . . . . . . . . . . . . . . . . . . . . 13
4.2.6. Compensation and Rollback . . . . . . . . . . . . . . 14
4.2.7. Extensions . . . . . . . . . . . . . . . . . . . . . 14
4.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 15
5. HTTP Header Transport . . . . . . . . . . . . . . . . . . . . 15
5.1. Execution-Context Header Field . . . . . . . . . . . . . 15
6. DAG Validation . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Validation Rules . . . . . . . . . . . . . . . . . . . . 16
6.3. DAG Validation Algorithm . . . . . . . . . . . . . . . . 17
7. Signature and Token Verification . . . . . . . . . . . . . . 19
7.1. Verification Procedure . . . . . . . . . . . . . . . . . 19
7.2. Verification Pseudocode . . . . . . . . . . . . . . . . . 20
8. Operational Modes . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Point-to-Point Mode . . . . . . . . . . . . . . . . . . . 22
Nennemann Expires 28 August 2026 [Page 2]
Internet-Draft WIMSE Execution Context February 2026
8.2. Deferred Ledger Mode . . . . . . . . . . . . . . . . . . 23
8.3. Full Ledger Mode . . . . . . . . . . . . . . . . . . . . 23
9. Audit Ledger Interface . . . . . . . . . . . . . . . . . . . 23
9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 23
9.2. Required Properties . . . . . . . . . . . . . . . . . . . 24
9.3. Ledger Entry Structure . . . . . . . . . . . . . . . . . 24
10. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Medical Device SDLC Workflow . . . . . . . . . . . . . . 25
10.1.1. FDA Audit with DAG Reconstruction . . . . . . . . . 26
10.2. Financial Trading Workflow . . . . . . . . . . . . . . . 27
10.3. Compensation and Rollback . . . . . . . . . . . . . . . 27
10.4. Autonomous Logistics Coordination . . . . . . . . . . . 28
11. Security Considerations . . . . . . . . . . . . . . . . . . . 29
11.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 29
11.2. Self-Assertion Limitation . . . . . . . . . . . . . . . 30
11.2.1. Witness Attestation Model . . . . . . . . . . . . . 30
11.3. Organizational Prerequisites . . . . . . . . . . . . . . 31
11.4. Signature Verification . . . . . . . . . . . . . . . . . 31
11.5. Replay Attack Prevention . . . . . . . . . . . . . . . . 32
11.6. Man-in-the-Middle Protection . . . . . . . . . . . . . . 32
11.7. Key Compromise . . . . . . . . . . . . . . . . . . . . . 32
11.8. Collusion and False Claims . . . . . . . . . . . . . . . 33
11.9. Denial of Service . . . . . . . . . . . . . . . . . . . 33
11.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 34
11.11. ECT Size Constraints . . . . . . . . . . . . . . . . . . 34
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34
12.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . 34
12.2. Data Minimization . . . . . . . . . . . . . . . . . . . 35
12.3. Storage and Access Control . . . . . . . . . . . . . . . 35
12.4. Regulatory Access . . . . . . . . . . . . . . . . . . . 35
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
13.1. Media Type Registration . . . . . . . . . . . . . . . . 35
13.2. HTTP Header Field Registration . . . . . . . . . . . . . 36
13.3. JWT Claims Registration . . . . . . . . . . . . . . . . 37
13.4. ECT Policy Decision Values Registry . . . . . . . . . . 38
13.5. ECT Regulated Domain Values Registry . . . . . . . . . . 39
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.1. Normative References . . . . . . . . . . . . . . . . . . 39
14.2. Informative References . . . . . . . . . . . . . . . . . 40
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 42
WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 42
OAuth 2.0 Token Exchange and the "act" Claim . . . . . . . . . 42
Transaction Tokens . . . . . . . . . . . . . . . . . . . . . . 43
Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 44
Blockchain and Distributed Ledgers . . . . . . . . . . . . . . 44
SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 44
W3C Verifiable Credentials . . . . . . . . . . . . . . . . . . 45
Implementation Guidance . . . . . . . . . . . . . . . . . . . . . 45
Nennemann Expires 28 August 2026 [Page 3]
Internet-Draft WIMSE Execution Context February 2026
Minimal Implementation . . . . . . . . . . . . . . . . . . . . 45
Storage Recommendations . . . . . . . . . . . . . . . . . . . . 45
Performance Considerations . . . . . . . . . . . . . . . . . . 45
Interoperability . . . . . . . . . . . . . . . . . . . . . . . 46
Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . . 46
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Example 1: Simple Two-Agent Workflow . . . . . . . . . . . . . 47
Example 2: Medical Device SDLC with Release Approval . . . . . 49
Example 3: Parallel Execution with Join . . . . . . . . . . . . 52
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 52
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction
1.1. Motivation
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 prove what
was done, what policy was applied, or whether compliance requirements
were satisfied at each decision point.
Regulated environments increasingly deploy autonomous agents that
coordinate across organizational boundaries. Multiple regulatory
frameworks motivate the need for structured execution records:
* The EU Artificial Intelligence Act [EU-AI-ACT] Article 12 requires
high-risk AI systems to be designed with capabilities enabling
automatic recording of events ("logs") while the system is
operating.
* The U.S. FDA 21 CFR Part 11 [FDA-21CFR11] requires computer-
generated, timestamped audit trails that independently record the
date, time, operator identity, and actions taken
(Section 11.10(e)).
* The Markets in Financial Instruments Directive (MiFID II)
[MIFID-II] requires firms to maintain records of transactions and
orders that are sufficient to enable supervisory authorities to
monitor compliance.
Nennemann Expires 28 August 2026 [Page 4]
Internet-Draft WIMSE Execution Context February 2026
* The Digital Operational Resilience Act (DORA) [DORA] Article 12
requires financial entities to have logging policies that record
ICT activities and anomalies.
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, in what order, and what policy was evaluated.
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.
1.2. Problem Statement
Three core gaps exist in current approaches to regulated agentic
systems:
1. 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, under Policy Y, producing Output Z."
2. No standard mechanism exists to record policy evaluation outcomes
at each decision point in a multi-agent workflow.
3. No mechanism exists to cryptographically link compensation and
rollback decisions to original actions.
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.
1.3. Scope and Applicability
This document defines:
* The Execution Context Token (ECT) format (Section 4)
* DAG structure for task dependency ordering (Section 6)
* Policy checkpoint recording (Section 4.2.3)
* Integration with the WIMSE identity framework (Section 3)
* An HTTP header for ECT transport (Section 5)
Nennemann Expires 28 August 2026 [Page 5]
Internet-Draft WIMSE Execution Context February 2026
* Operational modes including ledger-optional deployment (Section 8)
* Audit ledger interface requirements (Section 9)
The following are out of scope and are handled by WIMSE:
* Workload authentication and identity provisioning
* Key distribution and management
* Trust domain establishment and management
* Credential lifecycle management
1.4. Relationship to Regulatory Compliance
ECTs are a technical mechanism that can support compliance programs
by providing structured, cryptographically signed execution records.
ECTs do not by themselves constitute compliance with any regulatory
framework referenced in this document.
Compliance with each referenced regulation requires organizational
controls, policies, procedures, validation, and governance measures
beyond the scope of this specification. The regulatory references in
this document are intended to motivate the design requirements, not
to claim that implementing ECTs satisfies these regulations.
ECTs provide evidence of claimed execution ordering and policy
evaluation. They do not independently verify that the claimed
execution actually occurred as described, that the policy evaluation
was correct, or that 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.
2. Conventions and Definitions
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:
Agent: An autonomous workload, as defined by WIMSE
[I-D.ietf-wimse-arch], that executes tasks within a workflow.
Nennemann Expires 28 August 2026 [Page 6]
Internet-Draft WIMSE Execution Context February 2026
Task: A discrete unit of agent work that consumes inputs and
produces outputs.
Directed Acyclic Graph (DAG): A graph structure representing task
dependency ordering where edges are directed and no cycles exist.
Execution Context Token (ECT): A JSON Web Token [RFC7519] defined by
this specification that records task execution details and policy
evaluation outcomes.
Audit Ledger: An append-only, immutable log of all ECTs within a
workflow or set of workflows, used for regulatory audit and
compliance verification.
Policy Checkpoint: A point in a workflow where a policy evaluation
outcome is recorded within an ECT.
Workload Identity Token (WIT): A WIMSE credential proving a
workload's identity within a trust domain.
Workload Proof Token (WPT): A WIMSE proof-of-possession token used
for request-level authentication.
Trust Domain: A WIMSE concept representing an organizational
boundary with a shared identity issuer, corresponding to a SPIFFE
[SPIFFE] trust domain.
Witness: A third-party entity that observes and attests to the
execution of a task, providing additional accountability.
3. WIMSE Architecture Integration
3.1. WIMSE Foundation
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:
Nennemann Expires 28 August 2026 [Page 7]
Internet-Draft WIMSE Execution Context February 2026
* Recording what agents actually do with their authenticated
identity
* Recording policy evaluation outcomes at each hop
* Maintaining structured execution records
* Linking compensation or rollback actions to original tasks
3.2. Extension Model
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, |
| policy evaluated, outcome recorded" |
+--------------------------------------------------+
|
v
+--------------------------------------------------+
| Ledger Layer (Immutable Record) |
| "All ECTs appended to audit ledger" |
+--------------------------------------------------+
Figure 1: WIMSE Extension Architecture Layers
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.
3.3. Integration Points
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.
Nennemann Expires 28 August 2026 [Page 8]
Internet-Draft WIMSE Execution Context February 2026
* The ECT "iss" claim MUST use the WIMSE workload identifier format
(a SPIFFE ID [SPIFFE]).
* The ECT MUST be signed with the same private key used to generate
the agent's WPT.
* 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 three
tokens are carried in their respective HTTP header fields:
HTTP Request from Agent A to Agent B:
Workload-Identity: <WIT for Agent A>
Workload-Proof-Token: <WPT proving A controls key>
Execution-Context: <ECT recording what A did>
Figure 2: HTTP Header Stacking
The receiving agent (Agent B) verifies in order:
1. WIT and WPT (WIMSE layer): Proves who Agent A is and that the
request is authentic.
2. ECT (this extension): Records what Agent A did, what policy was
evaluated, and what precedent tasks exist.
3. Ledger: Appends the verified ECT to the audit ledger.
4. Execution Context Token Format
An Execution Context Token is a JSON Web Token (JWT) [RFC7519] signed
as a JSON Web Signature (JWS) [RFC7515] using the Compact
Serialization. JWS JSON Serialization MUST NOT be used for ECTs.
4.1. JOSE Header
The ECT JOSE header MUST contain the following parameters:
{
"alg": "ES256",
"typ": "wimse-exec+jwt",
"kid": "agent-a-key-id-123"
}
Figure 3: ECT JOSE Header Example
alg: REQUIRED. The digital signature algorithm used to sign the
Nennemann Expires 28 August 2026 [Page 9]
Internet-Draft WIMSE Execution Context February 2026
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.
typ: REQUIRED. MUST be set to "wimse-exec+jwt" to distinguish ECTs
from other JWT types, consistent with the WIMSE convention for
type parameter values.
kid: 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.
4.2. JWT Claims
The ECT payload contains both WIMSE-compatible standard JWT claims
and execution context claims defined by this specification.
4.2.1. Standard JWT Claims
The following standard JWT claims [RFC7519] MUST be present in every
ECT:
iss: REQUIRED. StringOrURI. The issuer of the ECT, which MUST be
the workload's SPIFFE ID in the format spiffe://<trust-
domain>/<path>. This MUST match the "sub" claim of the agent's
WIT.
sub: OPTIONAL. StringOrURI. The subject of the ECT. When present,
MUST equal the "iss" claim. This claim is included for
compatibility with JWT libraries and frameworks that expect a
"sub" claim to be present.
aud: 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.
Nennemann Expires 28 August 2026 [Page 10]
Internet-Draft WIMSE Execution Context February 2026
* *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.
iat: 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.
exp: 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.
The standard JWT "nbf" (Not Before) claim is not used in ECTs because
ECTs record completed actions and are valid immediately upon
issuance.
jti: REQUIRED. String. A unique identifier for the ECT in UUID
format [RFC9562]. Used for replay detection: receivers MUST
reject ECTs whose "jti" has already been seen within the
expiration window. The "jti" value MUST be unique across all ECTs
issued by the same agent.
4.2.2. Execution Context
The following claims are defined by this specification:
wid: OPTIONAL. String. A workflow identifier that groups related
ECTs into a single workflow. When present, MUST be a UUID
[RFC9562]. When absent, the "tid" uniqueness requirement applies
globally across the entire ledger.
tid: REQUIRED. String. A globally unique task identifier in UUID
format [RFC9562]. Each task MUST have a unique "tid" value. When
"wid" is present, uniqueness is scoped to the workflow; when "wid"
is absent, uniqueness MUST be enforced globally across the ledger.
exec_act: REQUIRED. String. The action or task type identifier
Nennemann Expires 28 August 2026 [Page 11]
Internet-Draft WIMSE Execution Context February 2026
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].
par: REQUIRED. Array of strings. Parent task identifiers
representing DAG dependencies. Each element MUST be a valid "tid"
from a previously executed task. An empty array indicates a root
task with no dependencies. A workflow MAY contain multiple root
tasks.
4.2.3. Policy Evaluation
The following claims record policy evaluation outcomes:
pol: REQUIRED. String. The identifier of the policy rule that was
evaluated for this task (e.g., "clinical_data_access_policy_v1").
pol_decision: REQUIRED. String. The result of the policy
evaluation. MUST be one of the values registered in the ECT
Policy Decision Values registry (Section 13.4). Initial values
are:
* "approved": The policy evaluation succeeded and the task was
authorized to proceed.
* "rejected": The policy evaluation failed. A "rejected" ECT
MUST still be appended to the audit ledger for accountability.
An ECT with "pol_decision" of "rejected" MAY appear as a parent
in the "par" array of a subsequent ECT, but only for
compensation, rollback, or remediation tasks. Agents MUST NOT
proceed with normal workflow execution based on a parent ECT
whose "pol_decision" is "rejected".
* "pending_human_review": The policy evaluation requires human
judgment before proceeding. Agents MUST NOT proceed with
dependent tasks until a subsequent ECT from a human reviewer
records an "approved" decision referencing this task as a
parent.
pol_enforcer: OPTIONAL. StringOrURI. The identity of the entity
(system or person) that evaluated the policy decision. When
present, SHOULD use SPIFFE ID format.
pol_timestamp: OPTIONAL. NumericDate. The time at which the policy
decision was made. When present, MUST be equal to or earlier than
the "iat" claim.
Nennemann Expires 28 August 2026 [Page 12]
Internet-Draft WIMSE Execution Context February 2026
This specification intentionally defines only the recording of policy
evaluation outcomes. The mechanisms by which policies are defined,
distributed to agents, and evaluated are out of scope. The "pol"
claim is an opaque identifier referencing an external policy; the
semantics and enforcement of that policy are determined by the
deployment environment. Implementations may use any policy engine or
framework (e.g., OPA/Rego, Cedar, XACML, or custom solutions)
provided that the evaluation outcome is faithfully recorded in the
ECT claims defined above.
4.2.4. Data Integrity
The following claims provide integrity verification for task inputs
and outputs without revealing the data itself:
inp_hash: OPTIONAL. String. A cryptographic hash of the input
data, formatted as "hash-algorithm:base64url-encoded-hash" (e.g.,
"sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The hash
algorithm identifier MUST be a lowercase value from the IANA Named
Information Hash Algorithm Registry (e.g., "sha-256", "sha-384",
"sha-512"). Implementations MUST support "sha-256" and SHOULD use
"sha-256" unless a stronger algorithm is required.
Implementations MUST NOT accept hash algorithms weaker than
SHA-256 (e.g., MD5, SHA-1). The hash MUST be computed over the
raw octets of the input data.
out_hash: OPTIONAL. String. A cryptographic hash of the output
data, using the same format and algorithm requirements as
"inp_hash".
inp_classification: OPTIONAL. String. The data sensitivity
classification of the input (e.g., "public", "confidential",
"restricted").
4.2.5. Task Metadata
The following claims provide additional context about task execution:
exec_time_ms: OPTIONAL. Integer. The execution duration of the
task in milliseconds. MUST be a non-negative integer.
regulated_domain: OPTIONAL. String. The regulatory domain
applicable to this task. Values MUST be registered in the ECT
Regulated Domain Values registry (Section 13.5).
model_version: OPTIONAL. String. The version identifier of the AI
or ML model used to perform the task, if applicable.
Nennemann Expires 28 August 2026 [Page 13]
Internet-Draft WIMSE Execution Context February 2026
witnessed_by: OPTIONAL. Array of StringOrURI. Identifiers of
third-party entities that the issuing agent claims observed or
attested to the execution of this task. When present, each
element SHOULD use SPIFFE ID format. Note that this claim is
self-asserted by the ECT issuer; witnesses listed here do not co-
sign this ECT. For stronger assurance, witnesses SHOULD submit
independent signed ECTs to the ledger attesting to their
observation (see Section 11.2.1). In regulated environments,
implementations SHOULD use witness attestation for critical
decision points to mitigate the risk of single-agent false claims.
See also Section 11.2 for the security implications of self-
asserted witness claims.
4.2.6. Compensation and Rollback
compensation_required: OPTIONAL. Boolean. Indicates whether this
task is a compensation or rollback action for a previous task.
compensation_reason: OPTIONAL. String. A human-readable reason for
the compensation action. MUST be present if
"compensation_required" is true. Values SHOULD use structured
identifiers (e.g., "policy_violation_in_parent_trade") rather than
free-form text to minimize the risk of embedding sensitive
information. See Section 12.2 for privacy guidance. If
"compensation_reason" is present, "compensation_required" MUST be
true.
Note: compensation ECTs reference historical parent tasks via the
"par" claim. The referenced 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 ledger.
4.2.7. Extensions
ext: OPTIONAL. Object. An extension object for domain-specific
claims not defined by this specification. Implementations that do
not understand extension claims MUST ignore them.
To avoid key collisions between different domains, extension key
names MUST use reverse domain notation (e.g.,
"com.example.custom_field"). Implementations MUST NOT use
unqualified key names within the "ext" object. 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.
Nennemann Expires 28 August 2026 [Page 14]
Internet-Draft WIMSE Execution Context February 2026
4.3. Complete ECT Example
The following is a complete ECT payload example:
{
"iss": "spiffe://example.com/agent/clinical",
"sub": "spiffe://example.com/agent/clinical",
"aud": "spiffe://example.com/agent/safety",
"iat": 1772064150,
"exp": 1772064750,
"jti": "7f3a8b2c-d1e4-4f56-9a0b-c3d4e5f6a7b8",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"tid": "550e8400-e29b-41d4-a716-446655440001",
"exec_act": "recommend_treatment",
"par": [],
"pol": "clinical_reasoning_policy_v2",
"pol_decision": "approved",
"pol_enforcer": "spiffe://example.com/policy/clinical-engine",
"pol_timestamp": 1772064145,
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"inp_classification": "confidential",
"exec_time_ms": 245,
"regulated_domain": "medtech",
"model_version": "clinical-reasoning-v4.2",
"witnessed_by": [
"spiffe://example.com/audit/observer-1"
]
}
Figure 4: Complete ECT Payload Example
5. HTTP Header Transport
5.1. Execution-Context Header Field
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.
Nennemann Expires 28 August 2026 [Page 15]
Internet-Draft WIMSE Execution Context February 2026
An agent sending a request to another agent includes the Execution-
Context header alongside the WIMSE Workload-Identity and Workload-
Proof-Token headers:
GET /api/safety-check HTTP/1.1
Host: safety-agent.example.com
Workload-Identity: eyJhbGci...WIT...
Workload-Proof-Token: eyJhbGci...WPT...
Execution-Context: eyJhbGci...ECT...
Figure 5: HTTP Request with ECT Header
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 7. 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.
6. DAG Validation
6.1. Overview
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 can be performed against an audit ledger (when
available) or against parent ECTs received inline via Execution-
Context headers (in point-to-point mode per Section 8). The
validation rules below use the term "ECT store" to refer to either
the ledger or the set of inline parent ECTs available to the
verifier.
6.2. Validation Rules
When receiving and verifying an ECT, implementations MUST perform the
following DAG validation steps:
Nennemann Expires 28 August 2026 [Page 16]
Internet-Draft WIMSE Execution Context February 2026
1. Task ID Uniqueness: The "tid" claim MUST be unique within the
applicable scope (the workflow identified by "wid", or the entire
ECT store if "wid" is absent). If a task with the same "tid"
already exists, the ECT MUST be rejected.
2. 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.
3. 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.
4. Acyclicity: Following the chain of parent references MUST NOT
lead back to the current task's "tid". If a cycle is detected,
the ECT MUST be rejected.
5. Parent Policy Decision: If any parent task has a "pol_decision"
of "rejected" or "pending_human_review", the current task's
"exec_act" MUST indicate a compensation, rollback, remediation,
or human review action. Implementations MUST NOT accept an ECT
representing normal workflow continuation when a parent's
"pol_decision" is not "approved", unless the current ECT has
"compensation_required" set to true.
6. 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.
6.3. DAG Validation Algorithm
The following pseudocode describes the DAG validation procedure:
Nennemann Expires 28 August 2026 [Page 17]
Internet-Draft WIMSE Execution Context February 2026
function validate_dag(ect, ect_store, clock_skew_tolerance):
// ect_store: ledger or local cache of verified ECTs
// Step 1: Uniqueness check
if ect_store.contains(ect.tid, ect.wid):
return error("Task ID already exists")
// Step 2: Parent existence and temporal ordering
for parent_id in ect.par:
parent = ect_store.get(parent_id)
if parent is null:
return error("Parent task not found: " + parent_id)
if parent.iat >= ect.iat + clock_skew_tolerance:
return error("Parent task not earlier than current")
// Step 3: Cycle detection (with traversal limit)
visited = set()
result = has_cycle(ect.tid, ect.par, ect_store, visited,
max_ancestor_limit)
if result is error or result is true:
return error("Circular dependency or depth limit exceeded")
return success
function has_cycle(target_tid, parent_ids, ect_store,
visited, max_depth):
if visited.size() >= max_depth:
return error("Maximum ancestor traversal limit exceeded")
for parent_id in parent_ids:
if parent_id == target_tid:
return true
if parent_id in visited:
continue
visited.add(parent_id)
parent = ect_store.get(parent_id)
if parent is not null:
result = has_cycle(target_tid, parent.par, ect_store,
visited, max_depth)
if result is error or result is true:
return result
return false
Figure 6: DAG Validation Pseudocode
The cycle detection traverses the ancestor graph rooted at the
current task's parents. The complexity is O(V) where V is the number
of ancestor nodes reachable from the current task's parent
references. For typical workflows with shallow DAGs, this is
efficient. To prevent denial-of-service via extremely deep or wide
Nennemann Expires 28 August 2026 [Page 18]
Internet-Draft WIMSE Execution Context February 2026
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.
Implementations SHOULD cache cycle detection results for previously
verified tasks to avoid redundant traversals.
7. Signature and Token Verification
7.1. Verification Procedure
When an agent receives an ECT, it MUST perform the following
verification steps in order:
1. Parse the JWS Compact Serialization to extract the JOSE header,
payload, and signature components per [RFC7515].
2. Verify that the "typ" header parameter is "wimse-exec+jwt".
3. Verify that the "alg" header parameter is not "none" and is not
a symmetric algorithm.
4. Verify the "kid" header parameter references a known, valid
public key from a WIT within the trust domain.
5. Retrieve the public key identified by "kid" and verify the JWS
signature per [RFC7515] Section 5.2.
6. 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).
7. Verify the "alg" header parameter matches the algorithm in the
corresponding WIT.
8. Verify the "iss" claim matches the "sub" claim of the WIT
associated with the "kid" public key.
9. 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".
10. Verify the "exp" claim indicates the ECT has not expired.
Nennemann Expires 28 August 2026 [Page 19]
Internet-Draft WIMSE Execution Context February 2026
11. 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).
12. Verify all required claims ("jti", "tid", "exec_act", "par",
"pol", "pol_decision") are present and well-formed.
13. Verify "pol_decision" is one of "approved", "rejected", or
"pending_human_review".
14. Perform DAG validation per Section 6.
15. If all checks pass and an audit ledger is available, the ECT
SHOULD be appended to the audit ledger. In point-to-point mode
(Section 8), the verified ECT is retained locally by the
receiving agent.
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 ledger, to
prevent information disclosure.
When ECT verification fails during HTTP request processing, the
receiving agent SHOULD respond with HTTP 403 (Forbidden) if the WIT
and WPT are 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.
7.2. Verification Pseudocode
function verify_ect(ect_jws, verifier_id,
trust_domain_keys, ledger):
// Parse JWS
(header, payload, signature) = parse_jws(ect_jws)
// Verify header
if header.typ != "wimse-exec+jwt":
return reject("Invalid typ parameter")
if header.alg == "none" or is_symmetric(header.alg):
return reject("Prohibited algorithm")
// Look up public key
public_key = trust_domain_keys.get(header.kid)
Nennemann Expires 28 August 2026 [Page 20]
Internet-Draft WIMSE Execution Context February 2026
if public_key is null:
return reject("Unknown key identifier")
// Verify signature
if not verify_jws_signature(header, payload,
signature, public_key):
return reject("Invalid signature")
// Verify key not revoked
if is_key_revoked(header.kid, trust_domain_keys):
return reject("Signing key has been revoked")
// Verify algorithm alignment
wit = get_wit_for_key(header.kid)
if header.alg != wit.alg:
return reject("Algorithm mismatch with WIT")
// Verify issuer matches WIT subject
if payload.iss != wit.sub:
return reject("Issuer does not match WIT subject")
// Verify audience
if verifier_id not in payload.aud:
return reject("ECT not intended for this recipient")
// Verify not expired
if payload.exp < current_time():
return reject("ECT has expired")
// Verify iat freshness (not too old, not in the future)
if payload.iat < current_time() - max_age_threshold:
return reject("ECT issued too long ago")
if payload.iat > current_time() + clock_skew_tolerance:
return reject("ECT issued in the future")
// Verify required claims
for claim in ["jti", "tid", "exec_act", "par",
"pol", "pol_decision"]:
if claim not in payload:
return reject("Missing required claim: " + claim)
// Validate pol_decision value
if payload.pol_decision not in
["approved", "rejected", "pending_human_review"]:
return reject("Invalid pol_decision value")
// Validate DAG (against ledger or inline parent ECTs)
result = validate_dag(payload, ect_store,
Nennemann Expires 28 August 2026 [Page 21]
Internet-Draft WIMSE Execution Context February 2026
clock_skew_tolerance)
if result is error:
return reject("DAG validation failed")
// All checks passed
if ledger is available:
ledger.append(payload)
else:
// Point-to-point mode: retain locally
local_ect_cache.store(payload)
return accept
Figure 7: ECT Verification Pseudocode
8. Operational Modes
ECTs can be deployed in three operational modes depending on the
availability and requirements of the deployment environment. All
modes use the same ECT format and verification procedure; they differ
in how parent ECTs are resolved during DAG validation and where
verified ECTs are stored.
8.1. Point-to-Point Mode
In point-to-point mode, agents pass parent ECTs directly to
downstream agents via multiple Execution-Context HTTP headers. No
centralized ledger is required. The receiving agent verifies each
parent ECT independently and validates the DAG against the set of
ECTs received in the request.
This mode is suitable for:
* Cross-organizational workflows where no shared ledger exists
* Lightweight deployments where infrastructure is constrained
* Early adoption scenarios before ledger infrastructure is available
Limitations of point-to-point mode:
* No persistent audit trail unless agents independently retain ECTs
* Global replay detection relies solely on "jti" caches at each
agent; there is no centralized "tid" uniqueness check
* The parent ECT chain grows with each hop, increasing HTTP header
size
Nennemann Expires 28 August 2026 [Page 22]
Internet-Draft WIMSE Execution Context February 2026
* Post-hoc audit reconstruction requires collecting ECTs from
multiple agents
Agents operating in point-to-point mode MUST retain verified parent
ECTs for at least the duration of the workflow to support DAG
validation of downstream requests. Agents SHOULD persist ECTs
locally for audit purposes even when no centralized ledger is
available.
8.2. Deferred Ledger Mode
In deferred ledger mode, agents create and verify ECTs in-flight
using point-to-point delivery, and submit collected ECTs to an audit
ledger after the workflow completes or at periodic intervals.
This mode decouples real-time workflow execution from ledger
availability. DAG validation during execution uses inline parent
ECTs; full DAG validation against the complete workflow is performed
at ledger submission time.
Agents MUST include all collected ECTs when submitting to the ledger.
The ledger MUST re-validate the complete DAG upon submission.
8.3. Full Ledger Mode
In full ledger mode, every verified ECT is immediately appended to an
audit ledger. DAG validation is performed against the ledger, which
serves as the authoritative ECT store. This is the RECOMMENDED mode
for regulated environments where persistent, centralized audit trails
are required.
9. Audit Ledger Interface
9.1. Overview
Use of an audit ledger is RECOMMENDED for regulated environments and
any deployment requiring persistent, centralized audit trails. ECTs
are designed to be recorded in an immutable audit ledger for
compliance verification and post-hoc analysis. This specification
defines the logical interface for the ledger but 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.
Nennemann Expires 28 August 2026 [Page 23]
Internet-Draft WIMSE Execution Context February 2026
9.2. Required Properties
An audit ledger implementation MUST provide:
1. Append-only semantics: Once an ECT is recorded, it MUST NOT be
modified or deleted.
2. Ordering: The ledger MUST maintain a total ordering of ECT
entries via a monotonically increasing sequence number.
3. Lookup by task ID: The ledger MUST support efficient retrieval of
ECT entries by "tid" value.
4. 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.
9.3. Ledger Entry Structure
Each ledger entry is a logical record containing:
{
"ledger_sequence": 42,
"task_id": "550e8400-e29b-41d4-a716-446655440001",
"agent_id": "spiffe://example.com/agent/clinical",
"action": "recommend_treatment",
"parents": [],
"ect_jws": "eyJhbGciOiJFUzI1NiIs...<complete JWS>",
"signature_verified": true,
"verification_timestamp": "2026-02-24T15:42:31.000Z",
"stored_timestamp": "2026-02-24T15:42:31.050Z"
}
Figure 8: Ledger Entry Example
The "ect_jws" field contains the full JWS Compact Serialization and
is the authoritative record. The other fields ("agent_id", "action",
"parents") are convenience indexes derived from the ECT payload; if
they disagree with the JWS payload, the JWS payload takes precedence.
Implementations SHOULD validate that convenience index fields match
the corresponding values in the JWS payload at write time to prevent
desynchronization between the authoritative JWS and the indexed
fields.
Nennemann Expires 28 August 2026 [Page 24]
Internet-Draft WIMSE Execution Context February 2026
10. Use Cases
This section describes representative use cases demonstrating how
ECTs provide execution records in regulated environments. These
examples demonstrate ECT mechanics; production deployments would
include additional domain-specific requirements beyond the scope of
this specification.
Note: task identifiers in this section are abbreviated for
readability. In production, all "tid" values are required to be
UUIDs per Section 4.2.2.
10.1. Medical Device SDLC Workflow
In a medical device software development lifecycle (SDLC), AI agents
assist across multiple phases from requirements analysis through
release approval. Regulatory frameworks including [FDA-21CFR11]
Section 11.10(e) and [EU-MDR] require audit trails documenting the
complete development process for software used in medical devices.
Agent A (Spec Reviewer):
tid: task-001 par: []
exec_act: review_requirements_spec
pol: spec_review_policy_v2 pol_decision: approved
Agent B (Code Generator):
tid: task-002 par: [task-001]
exec_act: implement_module
pol: coding_standards_v3 pol_decision: approved
Agent C (Test Agent):
tid: task-003 par: [task-002]
exec_act: execute_test_suite
pol: test_coverage_policy_v1 pol_decision: approved
Agent D (Build Agent):
tid: task-004 par: [task-003]
exec_act: build_release_artifact
pol: build_validation_v2 pol_decision: approved
Human Release Manager:
tid: task-005 par: [task-004]
exec_act: approve_release
pol: release_approval_policy pol_decision: approved
pol_enforcer: spiffe://meddev.example/human/release-mgr-42
witnessed_by: [spiffe://meddev.example/audit/qa-observer-1]
Figure 9: Medical Device SDLC Workflow
Nennemann Expires 28 August 2026 [Page 25]
Internet-Draft WIMSE Execution Context February 2026
ECTs record that requirements were reviewed before implementation
began, that tests were executed against the implemented code, that
the build artifact was validated, and that a human release manager
explicitly approved the release. The DAG structure ensures no phase
was skipped or reordered.
10.1.1. FDA Audit with DAG Reconstruction
During a regulatory audit, an FDA reviewer requests evidence of the
development process for a specific software release. The auditing
authority retrieves all ECTs sharing the same workflow identifier
("wid") from the audit ledger and reconstructs the complete DAG:
task-001 (review_requirements_spec)
|
v
task-002 (implement_module)
|
v
task-003 (execute_test_suite)
|
v
task-004 (build_release_artifact)
|
v
task-005 (approve_release) [human, witnessed]
Figure 10: Reconstructed DAG for FDA Audit
The reconstructed DAG provides cryptographic evidence that:
* Each phase was executed by an identified and authenticated agent.
* Policy checkpoints were evaluated at every phase transition.
* The execution sequence was maintained (no step was bypassed).
* A human-in-the-loop approved the final release, with independent
witness attestation.
* Timestamps and execution durations are recorded for each step.
This can contribute to compliance with:
* [FDA-21CFR11] Section 11.10(e): Computer-generated audit trails
that record the date, time, and identity of the operator.
Nennemann Expires 28 August 2026 [Page 26]
Internet-Draft WIMSE Execution Context February 2026
* [EU-MDR] Annex II: Technical documentation traceability for the
software development lifecycle.
* [EU-AI-ACT] Article 12: Automatic logging capabilities for high-
risk AI systems involved in the development process.
* [EU-AI-ACT] Article 14: ECTs can record evidence that human
oversight events occurred during the release process.
10.2. Financial Trading Workflow
In a financial trading workflow, agents perform risk assessment,
compliance verification, and trade execution. The DAG structure
records that compliance checks were evaluated before trade execution.
Agent A (Risk Assessment):
tid: task-001 par: []
exec_act: calculate_risk_exposure
pol: risk_limits_policy_v2 pol_decision: approved
Agent B (Compliance):
tid: task-002 par: [task-001]
exec_act: verify_compliance
pol: compliance_check_v1 pol_decision: approved
Agent C (Execution):
tid: task-003 par: [task-002]
exec_act: execute_trade
pol: execution_policy_v3 pol_decision: approved
Figure 11: Financial Trading Workflow
This can contribute to compliance with:
* [MIFID-II]: ECTs provide cryptographic records of the execution
sequence that can support transaction audit requirements.
* [DORA] Article 12: ECTs contribute to ICT activity logging.
* [EU-AI-ACT] Article 12: Logging of decisions made by AI-driven
systems.
10.3. Compensation and Rollback
When a compliance violation is discovered after execution, ECTs
provide a mechanism to record authorized compensation actions with a
cryptographic link to the original task:
Nennemann Expires 28 August 2026 [Page 27]
Internet-Draft WIMSE Execution Context February 2026
{
"iss": "spiffe://bank.example/agent/operations",
"sub": "spiffe://bank.example/agent/operations",
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772150550,
"exp": 1772151150,
"jti": "e4f5a6b7-c8d9-0123-ef01-234567890abc",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"tid": "550e8400-e29b-41d4-a716-446655440099",
"exec_act": "initiate_trade_rollback",
"par": ["550e8400-e29b-41d4-a716-446655440003"],
"pol": "compensation_policy_v1",
"pol_decision": "approved",
"pol_enforcer": "spiffe://bank.example/human/compliance-officer",
"compensation_required": true,
"compensation_reason": "policy_violation_in_parent_trade"
}
Figure 12: Compensation ECT Example
The "par" claim links the compensation action to the original trade,
creating an auditable chain from execution through violation
discovery to remediation.
10.4. Autonomous Logistics Coordination
In a logistics workflow, multiple compliance checks complete before
shipment commitment. The DAG structure records that all required
checks were completed:
Nennemann Expires 28 August 2026 [Page 28]
Internet-Draft WIMSE Execution Context February 2026
Agent A (Route Planning):
tid: task-001 par: []
exec_act: plan_route
pol: route_policy_v1 pol_decision: approved
Agent B (Customs):
tid: task-002 par: [task-001]
exec_act: validate_customs
pol: customs_policy_v2 pol_decision: approved
Agent C (Safety):
tid: task-003 par: [task-001]
exec_act: verify_cargo_safety
pol: safety_policy_v1 pol_decision: approved
Agent D (Payment):
tid: task-004 par: [task-002, task-003]
exec_act: authorize_payment
pol: payment_policy_v3 pol_decision: approved
System (Commitment):
tid: task-005 par: [task-004]
exec_act: commit_shipment
pol: commitment_policy_v1 pol_decision: approved
Figure 13: Logistics Workflow with Parallel Tasks
Note that tasks 002 and 003 both depend only on task-001 and can
execute in parallel. Task 004 depends on both, demonstrating the
DAG's ability to represent parallel execution with a join point.
11. Security Considerations
This section addresses security considerations following the guidance
in [RFC3552].
11.1. Threat Model
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.
Nennemann Expires 28 August 2026 [Page 29]
Internet-Draft WIMSE Execution Context February 2026
* Time manipulator: An entity attempting to manipulate timestamps to
alter perceived execution ordering.
11.2. Self-Assertion Limitation
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., setting
"pol_decision" to "approved" without actually evaluating the policy).
ECTs do not independently verify that:
* The claimed execution actually occurred as described
* The policy evaluation was correctly performed
* 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. To mitigate single-agent false claims, regulated
environments SHOULD use the "witnessed_by" mechanism to include
independent third-party observers at critical decision points.
However, the "witnessed_by" claim is self-asserted by the ECT issuer:
the listed witnesses do not co-sign the ECT and there is no
cryptographic proof within a single ECT that the witnesses actually
observed the task. An issuing agent could list witnesses that did
not participate.
11.2.1. Witness Attestation Model
To address the self-assertion limitation of the "witnessed_by" claim,
witnesses SHOULD submit their own independent signed ECTs to the
audit ledger attesting to the observed task. A witness attestation
ECT:
* MUST set "iss" to the witness's own workload identity.
* MUST set "exec_act" to "witness_attestation" (or a domain-
specific equivalent).
* MUST include the observed task's "tid" in the "par" array, linking
the attestation to the original task.
* MUST set "pol_decision" to "approved" to indicate the witness
confirms the observation.
Nennemann Expires 28 August 2026 [Page 30]
Internet-Draft WIMSE Execution Context February 2026
When a task's "witnessed_by" claim lists one or more witnesses,
auditors SHOULD verify that corresponding witness attestation ECTs
exist in the ledger for each listed witness. A mismatch between the
"witnessed_by" list and the set of independent witness ECTs in the
ledger SHOULD be flagged during audit review.
This model converts witness attestation from a self-asserted claim to
a cryptographically verifiable property of the ledger: the witness
independently signs their own ECT using their own key, and the ledger
records both the original task ECT and the witness attestation ECTs.
11.3. Organizational Prerequisites
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.
* Policy lifecycle management: Policy identifiers in ECTs map to
actual, validated policy rules.
* Agent deployment governance: Agents are deployed and maintained in
a manner that preserves their integrity.
11.4. Signature Verification
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
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.
Nennemann Expires 28 August 2026 [Page 31]
Internet-Draft WIMSE Execution Context February 2026
11.5. Replay Attack Prevention
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.
11.6. Man-in-the-Middle Protection
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
and under what policy.
11.7. Key Compromise
If an agent's private key is compromised, an attacker can forge ECTs
that appear to originate from that agent. To mitigate this risk:
* Implementations SHOULD use short-lived keys and rotate them
frequently (hours to days, not months).
* Private keys SHOULD be stored in Hardware Security Modules (HSMs)
or equivalent secure key storage.
* Trust domains MUST support rapid key revocation.
Nennemann Expires 28 August 2026 [Page 32]
Internet-Draft WIMSE Execution Context February 2026
* Upon suspected compromise, the trust domain MUST revoke the
compromised key and issue a new WIT with a fresh key pair.
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.
11.8. Collusion and False Claims
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:
* Independent ledger maintenance: The ledger SHOULD be maintained by
an entity independent of the workflow agents.
* Witness attestation: Using the "witnessed_by" claim to include
independent third-party observers.
* Cross-verification: Multiple independent ledger replicas can be
compared for consistency.
* Out-of-band audit: External auditors periodically verify ledger
contents against expected workflow patterns.
11.9. Denial of Service
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.
Nennemann Expires 28 August 2026 [Page 33]
Internet-Draft WIMSE Execution Context February 2026
11.10. Timestamp Accuracy
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.
11.11. ECT Size Constraints
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.7).
12. Privacy Considerations
12.1. Data Exposure in ECTs
ECTs necessarily reveal:
* Agent identities ("iss", "aud") for accountability purposes
* Action descriptions ("exec_act") for audit trail completeness
* Policy evaluation outcomes ("pol", "pol_decision") for compliance
verification
* Timestamps ("iat", "exp") for temporal ordering
ECTs are designed to NOT reveal:
* Actual input or output data values (replaced with cryptographic
hashes via "inp_hash" and "out_hash")
* Internal computation details or intermediate steps
Nennemann Expires 28 August 2026 [Page 34]
Internet-Draft WIMSE Execution Context February 2026
* Proprietary algorithms or intellectual property
* Personally identifiable information (PII)
12.2. Data Minimization
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. The
"pol" claim SHOULD reference policy identifiers rather than embedding
policy content.
The "compensation_reason" claim (Section 4.2.6) deserves particular
attention: because it is human-readable and may describe the
circumstances of a failure or policy violation, it risks exposing
sensitive operational details. Implementations SHOULD use short,
structured reason codes (e.g., "policy_violation_in_parent_trade")
rather than free-form natural language explanations. Implementers
SHOULD review "compensation_reason" values for potential information
leakage before deploying to production.
12.3. Storage and Access Control
ECTs stored in audit ledgers SHOULD be access-controlled so that only
authorized auditors and regulators can read them. Implementations
SHOULD consider encryption at rest for ledger storage containing
sensitive regulatory data.
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.
12.4. Regulatory Access
ECTs are designed for interpretation by qualified human auditors and
regulators. ECTs provide structural records of execution ordering
and policy evaluation; they are not intended for public disclosure.
13. IANA Considerations
13.1. Media Type Registration
This document requests registration of the following media type in
the "Media Types" registry maintained by IANA:
Type name: application
Nennemann Expires 28 August 2026 [Page 35]
Internet-Draft WIMSE Execution Context February 2026
Subtype name: wimse-exec+jwt
Required parameters: none
Optional parameters: none
Encoding considerations: 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.
Security considerations: See the Security Considerations section of
this document.
Interoperability considerations: none
Published specification: This document
Applications that use this media type: Applications that implement
regulated agentic workflows requiring execution context tracing
and audit trails.
Additional information: Magic number(s): none File extension(s):
none Macintosh file type code(s): none
Person and email address to contact for further information: Christi
an Nennemann, ietf@nennemann.de
Intended usage: COMMON
Restrictions on usage: none
Author: Christian Nennemann
Change controller: IETF
13.2. HTTP Header Field Registration
This document requests registration of the following header field in
the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
maintained by IANA:
Field name: Execution-Context
Status: permanent
Specification document: This document, Section 5
Nennemann Expires 28 August 2026 [Page 36]
Internet-Draft WIMSE Execution Context February 2026
13.3. JWT Claims Registration
This document requests registration of the following claims in the
"JSON Web Token Claims" registry maintained by IANA:
+=======================+=================+============+===========+
| Claim Name | Claim | Change | Reference |
| | Description | Controller | |
+=======================+=================+============+===========+
| wid | Workflow | IETF | Section |
| | Identifier | | 4.2.2 |
+-----------------------+-----------------+------------+-----------+
| tid | Task Identifier | IETF | Section |
| | | | 4.2.2 |
+-----------------------+-----------------+------------+-----------+
| exec_act | Action/Task | IETF | Section |
| | Type | | 4.2.2 |
+-----------------------+-----------------+------------+-----------+
| par | Parent Task | IETF | Section |
| | Identifiers | | 4.2.2 |
+-----------------------+-----------------+------------+-----------+
| pol | Policy Rule | IETF | Section |
| | Identifier | | 4.2.3 |
+-----------------------+-----------------+------------+-----------+
| pol_decision | Policy Decision | IETF | Section |
| | Result | | 4.2.3 |
+-----------------------+-----------------+------------+-----------+
| pol_enforcer | Policy Enforcer | IETF | Section |
| | Identity | | 4.2.3 |
+-----------------------+-----------------+------------+-----------+
| pol_timestamp | Policy Decision | IETF | Section |
| | Timestamp | | 4.2.3 |
+-----------------------+-----------------+------------+-----------+
| inp_hash | Input Data Hash | IETF | Section |
| | | | 4.2.4 |
+-----------------------+-----------------+------------+-----------+
| out_hash | Output Data | IETF | Section |
| | Hash | | 4.2.4 |
+-----------------------+-----------------+------------+-----------+
| inp_classification | Input Data | IETF | Section |
| | Classification | | 4.2.4 |
+-----------------------+-----------------+------------+-----------+
| exec_time_ms | Execution Time | IETF | Section |
| | (ms) | | 4.2.5 |
+-----------------------+-----------------+------------+-----------+
| witnessed_by | Witness | IETF | Section |
| | Identities | | 4.2.5 |
+-----------------------+-----------------+------------+-----------+
Nennemann Expires 28 August 2026 [Page 37]
Internet-Draft WIMSE Execution Context February 2026
| regulated_domain | Regulatory | IETF | Section |
| | Domain | | 4.2.5 |
+-----------------------+-----------------+------------+-----------+
| model_version | AI/ML Model | IETF | Section |
| | Version | | 4.2.5 |
+-----------------------+-----------------+------------+-----------+
| compensation_required | Compensation | IETF | Section |
| | Flag | | 4.2.6 |
+-----------------------+-----------------+------------+-----------+
| compensation_reason | Compensation | IETF | Section |
| | Reason | | 4.2.6 |
+-----------------------+-----------------+------------+-----------+
| ext | Extension | IETF | Section |
| | Object | | 4.2.7 |
+-----------------------+-----------------+------------+-----------+
Table 1: JWT Claims Registrations
13.4. ECT Policy Decision Values Registry
This document establishes the "ECT Policy Decision Values" registry
under the "JSON Web Token (JWT)" group. Registration policy is
Specification Required per [RFC8126].
The initial contents of the registry are:
+======================+===================+============+===========+
| Value | Description | Change | Reference |
| | | Controller | |
+======================+===================+============+===========+
| approved | Policy | IETF | Section |
| | evaluation | | 4.2.3 |
| | succeeded | | |
+----------------------+-------------------+------------+-----------+
| rejected | Policy | IETF | Section |
| | evaluation | | 4.2.3 |
| | failed | | |
+----------------------+-------------------+------------+-----------+
| pending_human_review | Awaiting | IETF | Section |
| | human | | 4.2.3 |
| | judgment | | |
+----------------------+-------------------+------------+-----------+
Table 2: ECT Policy Decision Values
Nennemann Expires 28 August 2026 [Page 38]
Internet-Draft WIMSE Execution Context February 2026
13.5. ECT Regulated Domain Values Registry
This document establishes the "ECT Regulated Domain Values" registry
under the "JSON Web Token (JWT)" group. Registration policy is
Specification Required per [RFC8126].
The initial contents of the registry are:
+==========+====================+===================+===========+
| Value | Description | Change Controller | Reference |
+==========+====================+===================+===========+
| medtech | Medical technology | IETF | Section |
| | and devices | | 4.2.5 |
+----------+--------------------+-------------------+-----------+
| finance | Financial services | IETF | Section |
| | and trading | | 4.2.5 |
+----------+--------------------+-------------------+-----------+
| military | Military and | IETF | Section |
| | defense | | 4.2.5 |
+----------+--------------------+-------------------+-----------+
Table 3: ECT Regulated Domain Values
14. References
14.1. Normative References
[I-D.ietf-wimse-arch]
Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
"Workload Identity in a Multi System Environment (WIMSE)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-wimse-arch-06, 30 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
arch-06>.
[I-D.ietf-wimse-s2s-protocol]
Campbell, B., Salowey, J. A., Schwenkschuster, A., and Y.
Sheffer, "WIMSE Workload-to-Workload Authentication", Work
in Progress, Internet-Draft, draft-ietf-wimse-s2s-
protocol-07, 16 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
s2s-protocol-07>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Nennemann Expires 28 August 2026 [Page 39]
Internet-Draft WIMSE Execution Context February 2026
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/rfc/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/rfc/rfc9562>.
14.2. Informative References
[DORA] European Parliament and Council of the European Union,
"Regulation (EU) 2022/2554 on digital operational
resilience for the financial sector (DORA)", 14 December
2022, <https://eur-lex.europa.eu/eli/reg/2022/2554>.
[EU-AI-ACT]
European Parliament and Council of the European Union,
"Regulation (EU) 2024/1689 of the European Parliament and
of the Council laying down harmonised rules on artificial
intelligence (Artificial Intelligence Act)", 13 June 2024,
<https://eur-lex.europa.eu/eli/reg/2024/1689>.
Nennemann Expires 28 August 2026 [Page 40]
Internet-Draft WIMSE Execution Context February 2026
[EU-MDR] European Parliament and Council of the European Union,
"Regulation (EU) 2017/745 on medical devices (MDR)", 5
April 2017, <https://eur-lex.europa.eu/eli/reg/2017/745>.
[FDA-21CFR11]
U.S. Food and Drug Administration, "Title 21, Code of
Federal Regulations, Part 11: Electronic Records;
Electronic Signatures", <https://www.ecfr.gov/current/
title-21/chapter-I/subchapter-A/part-11>.
[I-D.ietf-oauth-transaction-tokens]
Tulshibagwale, A., Fletcher, G., and P. Kasselman,
"Transaction Tokens", Work in Progress, Internet-Draft,
draft-ietf-oauth-transaction-tokens-07, 24 January 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
transaction-tokens-07>.
[I-D.ietf-scitt-architecture]
Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", Work in Progress,
Internet-Draft, draft-ietf-scitt-architecture-22, 10
October 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-scitt-architecture-22>.
[I-D.ni-wimse-ai-agent-identity]
Yuan, N. and P. C. Liu, "WIMSE Applicability for AI
Agents", Work in Progress, Internet-Draft, draft-ni-wimse-
ai-agent-identity-01, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ni-wimse-ai-
agent-identity-01>.
[I-D.oauth-transaction-tokens-for-agents]
Raut, A., "Transaction Tokens For Agents", Work in
Progress, Internet-Draft, draft-oauth-transaction-tokens-
for-agents-04, 10 February 2026,
<https://datatracker.ietf.org/doc/html/draft-oauth-
transaction-tokens-for-agents-04>.
[MIFID-II] European Parliament and Council of the European Union,
"Directive 2014/65/EU of the European Parliament and of
the Council on markets in financial instruments (MiFID
II)", 15 May 2014,
<https://eur-lex.europa.eu/eli/dir/2014/65>.
Nennemann Expires 28 August 2026 [Page 41]
Internet-Draft WIMSE Execution Context February 2026
[OPENTELEMETRY]
Cloud Native Computing Foundation, "OpenTelemetry
Specification",
<https://opentelemetry.io/docs/specs/otel/>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/rfc/rfc3552>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/rfc/rfc8693>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.
[SPIFFE] "Secure Production Identity Framework for Everyone
(SPIFFE)",
<https://spiffe.io/docs/latest/spiffe-about/overview/>.
Related Work
WIMSE Workload Identity
The WIMSE architecture [I-D.ietf-wimse-arch] and service-to- service
protocol [I-D.ietf-wimse-s2s-protocol] provide the identity
foundation upon which ECTs are built. WIT/WPT answer "who is this
agent?" and "does it control the claimed key?" while ECTs record
"what did this agent do?" and "what policy was evaluated?" Together
they form an identity-plus-accountability framework for regulated
agentic systems.
OAuth 2.0 Token Exchange and the "act" Claim
[RFC8693] defines the OAuth 2.0 Token Exchange protocol and registers
the "act" (Actor) claim in the JWT Claims registry. The "act" claim
creates nested JSON objects representing a delegation chain: "who is
acting on behalf of whom." While the nesting superficially resembles
a chain, it is strictly linear (each "act" object contains at most
one nested "act"), represents authorization delegation rather than
task execution, and carries no task identifiers, policy decisions, or
input/output integrity data. The "act" chain cannot represent
branching (fan-out) or convergence (fan-in) and therefore cannot form
a DAG.
Nennemann Expires 28 August 2026 [Page 42]
Internet-Draft WIMSE Execution Context February 2026
ECTs intentionally use the distinct claim name "exec_act" for the
action/task type to avoid collision with the "act" claim. The two
concepts are orthogonal: "act" records "who authorized whom," ECTs
record "what was done, in what order, with what policy outcomes."
Transaction Tokens
OAuth Transaction Tokens [I-D.ietf-oauth-transaction-tokens]
propagate authorization context across workload call chains. The
Txn-Token "req_wl" claim accumulates a comma-separated list of
workloads that requested replacement tokens, which is the closest
existing mechanism to call-chain recording.
However, "req_wl" cannot form a DAG because:
* It is linear: a comma-separated string with no branching or
merging representation. When a workload fans out to multiple
downstream services, each receives the same "req_wl" value and the
branching is invisible.
* It is incomplete: only workloads that request a replacement token
from the Transaction Token Service appear in "req_wl"; workloads
that forward the token unchanged are not recorded.
* It carries no task-level granularity, no parent references, no
policy evaluation outcomes, and no execution content.
Extensions for agentic use cases
([I-D.oauth-transaction-tokens-for-agents]) add agent identity and
constraints ("agentic_ctx") but no execution ordering or DAG
structure.
ECTs and Transaction Tokens are complementary: a Txn-Token propagates
authorization context ("this request is authorized for scope X on
behalf of user Y"), while an ECT records execution accountability
("task T was performed, depending on tasks P1 and P2, with policy Z
evaluated and approved"). An agent request could carry both a Txn-
Token for authorization and an ECT for execution recording. The WPT
"tth" claim defined in [I-D.ietf-wimse-s2s-protocol] can hash-bind a
WPT to a co-present Txn-Token; a similar binding mechanism for ECTs
is a potential future extension.
Nennemann Expires 28 August 2026 [Page 43]
Internet-Draft WIMSE Execution Context February 2026
Distributed Tracing (OpenTelemetry)
OpenTelemetry [OPENTELEMETRY] and similar distributed tracing systems
provide observability for debugging and monitoring. ECTs differ in
several important ways: ECTs are cryptographically signed per-task
with the agent's private key; ECTs are tamper-evident through JWS
signatures; ECTs enforce DAG validation rules; and ECTs are designed
for regulatory audit rather than operational monitoring.
OpenTelemetry data is typically controlled by the platform operator
and can be modified or deleted without detection. ECTs and
distributed traces are complementary: traces provide observability
while ECTs provide signed execution records. ECTs may reference
OpenTelemetry trace identifiers in the "ext" claim for correlation.
Blockchain and Distributed Ledgers
Both ECTs and blockchain systems provide immutable records. This
specification intentionally defines only the ECT token format and is
agnostic to the storage mechanism. ECTs can be stored in append-only
logs, databases with cryptographic commitments, blockchain networks,
or any storage providing the required properties defined in
Section 9.
SCITT (Supply Chain Integrity, Transparency, and Trust)
The SCITT architecture [I-D.ietf-scitt-architecture] defines a
framework for creating transparent and auditable supply chain records
through Transparency Services, Signed Statements, and Receipts. ECTs
and SCITT are naturally complementary: the ECT "wid" (Workflow
Identifier) claim can serve as a correlation identifier referenced in
SCITT Signed Statements, linking a complete ECT audit trail to a
supply chain transparency record. For example, in a regulated
manufacturing workflow, each agent step produces an ECT (recording
what was done, by whom, under what policy), while the overall
workflow identified by "wid" is registered as a SCITT Signed
Statement on a Transparency Service. This enables auditors to verify
both the individual execution steps (via ECT DAG validation) and the
end-to-end supply chain integrity (via SCITT Receipts) using the
"wid" as the shared correlation point. The "ext" claim in ECTs
(Section 4.2.2) can carry SCITT-specific metadata such as
Transparency Service identifiers or Receipt references for tighter
integration.
Nennemann Expires 28 August 2026 [Page 44]
Internet-Draft WIMSE Execution Context February 2026
W3C Verifiable Credentials
W3C Verifiable Credentials represent claims about subjects (e.g.,
identity, qualifications). ECTs represent execution records of
actions (what happened, in what order, under what policy). While
both use JWT/JWS as a serialization format, their semantics and use
cases are distinct.
Implementation Guidance
Minimal Implementation
A minimal conforming implementation needs to:
1. Create JWTs with all required claims ("iss", "aud", "iat", "exp",
"jti", "tid", "exec_act", "par", "pol", "pol_decision").
2. Sign ECTs with the agent's private key using an algorithm
matching the WIT (ES256 recommended).
3. Verify ECT signatures against WIT public keys.
4. Perform DAG validation (parent existence, temporal ordering,
cycle detection).
5. Store verified ECTs (append to audit ledger in full ledger mode,
or retain locally in point-to-point mode per Section 8).
Storage Recommendations
* Append-only log: Simplest approach; immutability by design.
* Database with hash chains: Periodic cryptographic commitments over
batches of entries.
* Distributed ledger: Maximum immutability guarantees for cross-
organizational audit.
* Hybrid: Hot storage in a database, cold archive in immutable
storage.
Performance Considerations
* ES256 signature verification: approximately 1ms per ECT on modern
hardware.
* DAG validation: O(V) where V is the number of reachable ancestor
nodes (typically small for shallow workflows).
Nennemann Expires 28 August 2026 [Page 45]
Internet-Draft WIMSE Execution Context February 2026
* JSON serialization: sub-millisecond per ECT.
* Total per-request overhead: approximately 5-10ms, acceptable for
regulated workflows where correctness is prioritized over latency.
Interoperability
Implementations are expected to use established JWT/JWS libraries
(JOSE) for token creation and verification. Custom cryptographic
implementations are strongly discouraged. Implementations are
expected to be tested against multiple JWT libraries to ensure
interoperability.
Regulatory Compliance Mapping
The following table summarizes how ECTs can contribute to compliance
with various regulatory frameworks. ECTs are a technical building
block; achieving compliance requires additional organizational
measures beyond this specification.
Nennemann Expires 28 August 2026 [Page 46]
Internet-Draft WIMSE Execution Context February 2026
+============+========================+==========================+
| Regulation | Requirement | ECT Contribution |
+============+========================+==========================+
| FDA 21 CFR | Audit trails recording | Cryptographic signatures |
| Part 11 | date, time, operator, | and append-only ledger |
| | actions (11.10(e)) | contribute to audit |
| | | trail requirements |
+------------+------------------------+--------------------------+
| EU MDR | Technical | ECTs provide signed |
| | documentation | records of AI-assisted |
| | traceability (Annex | decision sequences |
| | II) | |
+------------+------------------------+--------------------------+
| EU AI Act | Automatic logging | ECTs contribute |
| Art. 12 | capabilities for high- | cryptographic activity |
| | risk AI | logging |
+------------+------------------------+--------------------------+
| EU AI Act | Human oversight | ECTs can record evidence |
| Art. 14 | capability | that human oversight |
| | | events occurred |
+------------+------------------------+--------------------------+
| MiFID II | Transaction records | ECTs provide |
| | for supervisory | cryptographic execution |
| | authorities | sequence records |
+------------+------------------------+--------------------------+
| DORA Art. | ICT activity logging | ECT ledger contributes |
| 12 | policies | to ICT activity audit |
| | | trail |
+------------+------------------------+--------------------------+
Table 4: Regulatory Compliance Mapping
Examples
Example 1: Simple Two-Agent Workflow
Agent A executes a data retrieval task and sends the ECT to Agent B:
ECT JOSE Header:
{
"alg": "ES256",
"typ": "wimse-exec+jwt",
"kid": "agent-a-key-2026-02"
}
ECT Payload:
Nennemann Expires 28 August 2026 [Page 47]
Internet-Draft WIMSE Execution Context February 2026
{
"iss": "spiffe://example.com/agent/data-retrieval",
"sub": "spiffe://example.com/agent/data-retrieval",
"aud": "spiffe://example.com/agent/validator",
"iat": 1772064150,
"exp": 1772064750,
"jti": "1a2b3c4d-e5f6-7890-abcd-ef0123456701",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"tid": "550e8400-e29b-41d4-a716-446655440001",
"exec_act": "fetch_patient_data",
"par": [],
"pol": "clinical_data_access_policy_v1",
"pol_decision": "approved",
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"exec_time_ms": 142,
"regulated_domain": "medtech"
}
Agent B receives the ECT, verifies it, executes a validation task,
and creates its own ECT:
{
"iss": "spiffe://example.com/agent/validator",
"sub": "spiffe://example.com/agent/validator",
"aud": "spiffe://example.com/system/ledger",
"iat": 1772064160,
"exp": 1772064760,
"jti": "2b3c4d5e-f6a7-8901-bcde-f01234567802",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"tid": "550e8400-e29b-41d4-a716-446655440002",
"exec_act": "validate_safety",
"par": ["550e8400-e29b-41d4-a716-446655440001"],
"pol": "safety_validation_policy_v2",
"pol_decision": "approved",
"exec_time_ms": 89,
"regulated_domain": "medtech"
}
The resulting DAG:
task-...-0001 (fetch_patient_data)
|
v
task-...-0002 (validate_safety)
Nennemann Expires 28 August 2026 [Page 48]
Internet-Draft WIMSE Execution Context February 2026
Example 2: Medical Device SDLC with Release Approval
A multi-step medical device software lifecycle workflow with
autonomous agents and human release approval:
Task 1 (Spec Review Agent):
{
"iss": "spiffe://meddev.example/agent/spec-reviewer",
"sub": "spiffe://meddev.example/agent/spec-reviewer",
"aud": "spiffe://meddev.example/agent/code-gen",
"iat": 1772064150,
"exp": 1772064750,
"jti": "3c4d5e6f-a7b8-9012-cdef-012345678903",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000001",
"exec_act": "review_requirements_spec",
"par": [],
"pol": "spec_review_policy_v2",
"pol_decision": "approved",
"regulated_domain": "medtech",
"model_version": "spec-review-v3.1",
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
}
Task 2 (Code Generation Agent):
{
"iss": "spiffe://meddev.example/agent/code-gen",
"sub": "spiffe://meddev.example/agent/code-gen",
"aud": "spiffe://meddev.example/agent/test-runner",
"iat": 1772064200,
"exp": 1772064800,
"jti": "4d5e6f7a-b8c9-0123-def0-123456789004",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000002",
"exec_act": "implement_module",
"par": ["a1b2c3d4-0001-0000-0000-000000000001"],
"pol": "coding_standards_v3",
"pol_decision": "approved",
"regulated_domain": "medtech",
"model_version": "codegen-v2.4"
}
Task 3 (Autonomous Test Agent):
Nennemann Expires 28 August 2026 [Page 49]
Internet-Draft WIMSE Execution Context February 2026
{
"iss": "spiffe://meddev.example/agent/test-runner",
"sub": "spiffe://meddev.example/agent/test-runner",
"aud": "spiffe://meddev.example/agent/build",
"iat": 1772064260,
"exp": 1772064860,
"jti": "5e6f7a8b-c9d0-1234-ef01-234567890005",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000003",
"exec_act": "execute_test_suite",
"par": ["a1b2c3d4-0001-0000-0000-000000000002"],
"pol": "test_coverage_policy_v1",
"pol_decision": "approved",
"regulated_domain": "medtech",
"exec_time_ms": 4523
}
Task 4 (Build Agent):
{
"iss": "spiffe://meddev.example/agent/build",
"sub": "spiffe://meddev.example/agent/build",
"aud": "spiffe://meddev.example/human/release-mgr-42",
"iat": 1772064310,
"exp": 1772064910,
"jti": "6f7a8b9c-d0e1-2345-f012-345678900006",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000004",
"exec_act": "build_release_artifact",
"par": ["a1b2c3d4-0001-0000-0000-000000000003"],
"pol": "build_validation_v2",
"pol_decision": "approved",
"regulated_domain": "medtech",
"out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc"
}
Task 5 (Human Release Manager Approval):
Nennemann Expires 28 August 2026 [Page 50]
Internet-Draft WIMSE Execution Context February 2026
{
"iss": "spiffe://meddev.example/human/release-mgr-42",
"sub": "spiffe://meddev.example/human/release-mgr-42",
"aud": "spiffe://meddev.example/system/ledger",
"iat": 1772064510,
"exp": 1772065110,
"jti": "7a8b9c0d-e1f2-3456-0123-456789000007",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000005",
"exec_act": "approve_release",
"par": ["a1b2c3d4-0001-0000-0000-000000000004"],
"pol": "release_approval_policy",
"pol_decision": "approved",
"pol_enforcer": "spiffe://meddev.example/human/release-mgr-42",
"witnessed_by": [
"spiffe://meddev.example/audit/qa-observer-1"
],
"regulated_domain": "medtech"
}
The resulting DAG records the complete SDLC: spec review preceded
implementation, implementation preceded testing, testing preceded
build, and a human release manager approved the final release with
independent witness attestation.
task-...-0001 (review_requirements_spec)
|
v
task-...-0002 (implement_module)
|
v
task-...-0003 (execute_test_suite)
|
v
task-...-0004 (build_release_artifact)
|
v
task-...-0005 (approve_release) [human, witnessed]
An FDA auditor reconstructs this DAG by querying the audit ledger for
all ECTs with wid "c2d3e4f5-a6b7-8901-cdef-012345678901" and
verifying each signature. The DAG provides cryptographic evidence
that the SDLC followed the prescribed process with human oversight at
the release gate.
Nennemann Expires 28 August 2026 [Page 51]
Internet-Draft WIMSE Execution Context February 2026
Example 3: Parallel Execution with Join
A workflow where two tasks execute in parallel and a third task
depends on both:
task-...-0001 (assess_risk)
| \
v v
task-...-0002 task-...-0003
(check (verify
compliance) liquidity)
| /
v v
task-...-0004 (execute_trade)
Task 004 ECT payload:
{
"iss": "spiffe://bank.example/agent/execution",
"sub": "spiffe://bank.example/agent/execution",
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772064250,
"exp": 1772064850,
"jti": "8b9c0d1e-f2a3-4567-1234-567890000008",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"tid": "f1e2d3c4-0004-0000-0000-000000000004",
"exec_act": "execute_trade",
"par": [
"f1e2d3c4-0002-0000-0000-000000000002",
"f1e2d3c4-0003-0000-0000-000000000003"
],
"pol": "trade_execution_policy_v3",
"pol_decision": "approved",
"regulated_domain": "finance"
}
The "par" array with two entries records that both compliance
checking and liquidity verification were completed before trade
execution.
Acknowledgments
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.
Nennemann Expires 28 August 2026 [Page 52]
Internet-Draft WIMSE Execution Context February 2026
Author's Address
Christian Nennemann
Independent Researcher
Email: ietf@nennemann.de
Nennemann Expires 28 August 2026 [Page 53]
Reference in New Issue View Git Blame Copy Permalink