Christian Nennemann
821a7f4570
ECTs can now be deployed without a centralized ledger. Three modes are defined: point-to-point (agents pass parent ECTs inline via HTTP headers), deferred ledger (collect ECTs in-flight, submit later), and full ledger (immediate append, RECOMMENDED for regulated environments). DAG validation is generalized to work against an "ECT store" which can be either a ledger or the set of inline parent ECTs received in the request. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2913 lines
107 KiB
Plaintext
2913 lines
107 KiB
Plaintext
|
||
|
||
|
||
|
||
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. WIMSE-Compatible Claims . . . . . . . . . . . . . . . 10
|
||
4.2.2. Execution Context Claims . . . . . . . . . . . . . . 11
|
||
4.2.3. Policy Claims . . . . . . . . . . . . . . . . . . . . 12
|
||
4.2.4. Data Integrity Claims . . . . . . . . . . . . . . . . 13
|
||
4.2.5. Operational Claims . . . . . . . . . . . . . . . . . 13
|
||
4.2.6. Witness Claims . . . . . . . . . . . . . . . . . . . 14
|
||
4.2.7. Compensation Claims . . . . . . . . . . . . . . . . . 14
|
||
4.2.8. Extension Claims . . . . . . . . . . . . . . . . . . 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
|
||
|
||
|
||
|
||
Nennemann Expires 28 August 2026 [Page 2]
|
||
|
||
Internet-Draft WIMSE Execution Context February 2026
|
||
|
||
|
||
8.1. Point-to-Point Mode . . . . . . . . . . . . . . . . . . . 22
|
||
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) . . . . . . . . . . . . . . 43
|
||
Blockchain and Distributed Ledgers . . . . . . . . . . . . . . 44
|
||
SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 44
|
||
W3C Verifiable Credentials . . . . . . . . . . . . . . . . . . 44
|
||
|
||
|
||
|
||
Nennemann Expires 28 August 2026 [Page 3]
|
||
|
||
Internet-Draft WIMSE Execution Context February 2026
|
||
|
||
|
||
Implementation Guidance . . . . . . . . . . . . . . . . . . . . . 44
|
||
Minimal Implementation . . . . . . . . . . . . . . . . . . . . 44
|
||
Storage Recommendations . . . . . . . . . . . . . . . . . . . . 45
|
||
Performance Considerations . . . . . . . . . . . . . . . . . . 45
|
||
Interoperability . . . . . . . . . . . . . . . . . . . . . . . 45
|
||
Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . . 46
|
||
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
|
||
Example 1: Simple Two-Agent Workflow . . . . . . . . . . . . . 46
|
||
Example 2: Medical Device SDLC with Release Approval . . . . . 48
|
||
Example 3: Parallel Execution with Join . . . . . . . . . . . . 51
|
||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 52
|
||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 52
|
||
|
||
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. WIMSE-Compatible 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 Claims
|
||
|
||
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 Claims
|
||
|
||
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 Claims
|
||
|
||
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. Operational Claims
|
||
|
||
The following claims provide additional operational context:
|
||
|
||
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
|
||
|
||
|
||
4.2.6. Witness Claims
|
||
|
||
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.7. Compensation Claims
|
||
|
||
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.8. Extension Claims
|
||
|
||
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.8).
|
||
|
||
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.7) 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.6 |
|
||
+-----------------------+-----------------+------------+-----------+
|
||
|
||
|
||
|
||
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.7 |
|
||
+-----------------------+-----------------+------------+-----------+
|
||
| compensation_reason | Compensation | IETF | Section |
|
||
| | Reason | | 4.2.7 |
|
||
+-----------------------+-----------------+------------+-----------+
|
||
| ext | Extension | IETF | Section |
|
||
| | Object | | 4.2.8 |
|
||
+-----------------------+-----------------+------------+-----------+
|
||
|
||
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-oauth-transaction-tokens-for-agents]
|
||
"*** BROKEN REFERENCE ***".
|
||
|
||
[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>.
|
||
|
||
[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>.
|
||
|
||
[OPENTELEMETRY]
|
||
Cloud Native Computing Foundation, "OpenTelemetry
|
||
Specification",
|
||
<https://opentelemetry.io/docs/specs/otel/>.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Nennemann Expires 28 August 2026 [Page 41]
|
||
|
||
Internet-Draft WIMSE Execution Context February 2026
|
||
|
||
|
||
[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.
|
||
|
||
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."
|
||
|
||
|
||
|
||
|
||
Nennemann Expires 28 August 2026 [Page 42]
|
||
|
||
Internet-Draft WIMSE Execution Context February 2026
|
||
|
||
|
||
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.ietf-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.
|
||
|
||
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
|
||
|
||
|
||
|
||
Nennemann Expires 28 August 2026 [Page 43]
|
||
|
||
Internet-Draft WIMSE Execution Context February 2026
|
||
|
||
|
||
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.
|
||
|
||
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").
|
||
|
||
|
||
|
||
Nennemann Expires 28 August 2026 [Page 44]
|
||
|
||
Internet-Draft WIMSE Execution Context February 2026
|
||
|
||
|
||
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).
|
||
|
||
* 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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Nennemann Expires 28 August 2026 [Page 45]
|
||
|
||
Internet-Draft WIMSE Execution Context February 2026
|
||
|
||
|
||
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.
|
||
|
||
+============+========================+==========================+
|
||
| 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:
|
||
|
||
|
||
|
||
|
||
|
||
Nennemann Expires 28 August 2026 [Page 46]
|
||
|
||
Internet-Draft WIMSE Execution Context February 2026
|
||
|
||
|
||
{
|
||
"alg": "ES256",
|
||
"typ": "wimse-exec+jwt",
|
||
"kid": "agent-a-key-2026-02"
|
||
}
|
||
|
||
ECT Payload:
|
||
|
||
{
|
||
"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:
|
||
|
||
|
||
|
||
Nennemann Expires 28 August 2026 [Page 47]
|
||
|
||
Internet-Draft WIMSE Execution Context February 2026
|
||
|
||
|
||
task-...-0001 (fetch_patient_data)
|
||
|
|
||
v
|
||
task-...-0002 (validate_safety)
|
||
|
||
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):
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Nennemann Expires 28 August 2026 [Page 48]
|
||
|
||
Internet-Draft WIMSE Execution Context February 2026
|
||
|
||
|
||
{
|
||
"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):
|
||
|
||
{
|
||
"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):
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Nennemann Expires 28 August 2026 [Page 49]
|
||
|
||
Internet-Draft WIMSE Execution Context February 2026
|
||
|
||
|
||
{
|
||
"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):
|
||
|
||
{
|
||
"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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Nennemann Expires 28 August 2026 [Page 50]
|
||
|
||
Internet-Draft WIMSE Execution Context February 2026
|
||
|
||
|
||
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.
|
||
|
||
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:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Nennemann Expires 28 August 2026 [Page 51]
|
||
|
||
Internet-Draft WIMSE Execution Context February 2026
|
||
|
||
|
||
{
|
||
"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.
|
||
|
||
Author's Address
|
||
|
||
Christian Nennemann
|
||
Independent Researcher
|
||
Email: ietf@nennemann.de
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Nennemann Expires 28 August 2026 [Page 52]
|