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

1289 lines
47 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
WIMSE C. Nennemann
Internet-Draft Independent Researcher
Intended status: Standards Track 25 February 2026
Expires: 29 August 2026
Execution Context Tokens for Distributed Agentic Workflows
draft-nennemann-wimse-ect-00
Abstract
This document defines Execution Context Tokens (ECTs), a JWT-based
extension to the WIMSE architecture that records task execution
across distributed agentic workflows. Each ECT is a signed record of
a single task, linked to predecessor tasks through a directed acyclic
graph (DAG). ECTs reuse the WIMSE signing model and are transported
in a new Execution-Context HTTP header field alongside existing WIMSE
identity headers.
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 29 August 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Nennemann Expires 29 August 2026 [Page 1]
Internet-Draft WIMSE Execution Context February 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope and Applicability . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Execution Context Token Format . . . . . . . . . . . . . . . 4
3.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Standard JWT Claims . . . . . . . . . . . . . . . . . 5
3.2.2. Execution Context . . . . . . . . . . . . . . . . . . 6
3.2.3. Data Integrity . . . . . . . . . . . . . . . . . . . 6
3.2.4. Extensions . . . . . . . . . . . . . . . . . . . . . 7
3.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 7
4. HTTP Header Transport . . . . . . . . . . . . . . . . . . . . 7
4.1. Execution-Context Header Field . . . . . . . . . . . . . 8
5. DAG Validation . . . . . . . . . . . . . . . . . . . . . . . 8
6. Signature and Token Verification . . . . . . . . . . . . . . 9
6.1. Verification Procedure . . . . . . . . . . . . . . . . . 9
7. Audit Ledger Interface . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Self-Assertion Limitation . . . . . . . . . . . . . . . . 12
8.3. Signature Verification . . . . . . . . . . . . . . . . . 12
8.4. Replay Attack Prevention . . . . . . . . . . . . . . . . 13
8.5. Man-in-the-Middle Protection . . . . . . . . . . . . . . 13
8.6. Key Compromise . . . . . . . . . . . . . . . . . . . . . 13
8.7. Collusion and DAG Integrity . . . . . . . . . . . . . . . 13
8.8. Privilege Escalation via ECTs . . . . . . . . . . . . . . 14
8.9. Denial of Service . . . . . . . . . . . . . . . . . . . . 14
8.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 14
8.11. ECT Size Constraints . . . . . . . . . . . . . . . . . . 14
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
9.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . . 14
9.2. Data Minimization . . . . . . . . . . . . . . . . . . . . 15
9.3. Storage and Access Control . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10.1. Media Type Registration . . . . . . . . . . . . . . . . 15
10.2. HTTP Header Field Registration . . . . . . . . . . . . . 16
10.3. JWT Claims Registration . . . . . . . . . . . . . . . . 16
Nennemann Expires 29 August 2026 [Page 2]
Internet-Draft WIMSE Execution Context February 2026
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 18
Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Cross-Organization Financial Trading . . . . . . . . . . . . . 19
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 21
WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 21
OAuth 2.0 Token Exchange and the "act" Claim . . . . . . . . . 21
Transaction Tokens . . . . . . . . . . . . . . . . . . . . . . 21
Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 22
W3C Provenance Data Model (PROV) . . . . . . . . . . . . . . . 22
SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 23
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
The WIMSE framework [I-D.ietf-wimse-arch] and its service-to- service
protocol [I-D.ietf-wimse-s2s-protocol] authenticate workloads across
call chains but do not record what those workloads actually did.
This document defines Execution Context Tokens (ECTs), a JWT-based
extension that fills the gap between workload identity and execution
accountability. Each ECT is a signed record of a single task, linked
to predecessor tasks through a directed acyclic graph (DAG).
1.1. Scope and Applicability
This document defines:
* The Execution Context Token (ECT) format (Section 3)
* DAG structure for task dependency ordering (Section 5)
* An HTTP header for ECT transport (Section 4)
* Audit ledger interface requirements (Section 7)
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
Nennemann Expires 29 August 2026 [Page 3]
Internet-Draft WIMSE Execution Context February 2026
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.
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.
Audit Ledger: An append-only, immutable log of all ECTs within a
workflow or set of workflows, used for audit and verification.
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.
3. Execution Context Token Format
An Execution Context Token is a JSON Web Token (JWT) [RFC7519] signed
as a JSON Web Signature (JWS) [RFC7515]. ECTs MUST use JWS Compact
Serialization (the base64url-encoded header.payload.signature format)
so that they can be carried in a single HTTP header value.
Nennemann Expires 29 August 2026 [Page 4]
Internet-Draft WIMSE Execution Context February 2026
ECTs reuse the WIMSE signing model. The ECT MUST be signed with the
same private key associated with the agent's WIT. The JOSE header
"kid" parameter MUST reference the public key identifier from the
agent's WIT, and the "alg" parameter MUST match the algorithm used in
the corresponding WIT. In WIMSE deployments, the ECT "iss" claim
SHOULD use the WIMSE workload identifier format (a SPIFFE ID
[SPIFFE]).
3.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 1: ECT JOSE Header Example
alg: REQUIRED. The digital signature algorithm used to sign the
ECT. MUST match the algorithm in the corresponding WIT.
Implementations MUST support ES256 [RFC7518]. The "alg" value
MUST NOT be "none". Symmetric algorithms (e.g., HS256, HS384,
HS512) MUST NOT be used, as ECTs require asymmetric signatures for
non-repudiation.
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.
3.2. JWT Claims
3.2.1. Standard JWT Claims
An ECT MUST contain the following standard JWT claims [RFC7519]:
iss: REQUIRED. StringOrURI. A URI identifying the issuer of the
ECT. In WIMSE deployments, this SHOULD be the workload's SPIFFE
ID in the format spiffe://<trust-domain>/<path>, matching the
"sub" claim of the agent's WIT. Non-WIMSE deployments MAY use
other URI schemes (e.g., HTTPS URLs or URN:UUID identifiers).
aud: REQUIRED. StringOrURI or array of StringOrURI. The intended
Nennemann Expires 29 August 2026 [Page 5]
Internet-Draft WIMSE Execution Context February 2026
recipient(s) of the ECT. The "aud" claim SHOULD contain the
identifiers of all entities that will verify the ECT. When an ECT
must be verified by both the next agent and the audit ledger
independently, "aud" MUST be an array containing both identifiers.
Each verifier checks that its own identity appears in "aud".
iat: REQUIRED. NumericDate. The time at which the ECT was issued.
exp: REQUIRED. NumericDate. The expiration time of the ECT.
Implementations SHOULD set this to 5 to 15 minutes after "iat".
jti: REQUIRED. String. A unique identifier for both the ECT and
the task it records, in UUID format [RFC9562]. The "jti" serves
as both the token identifier (for replay detection) and the task
identifier (for DAG parent references in "par"). Receivers MUST
reject ECTs whose "jti" has already been seen within the
expiration window. When "wid" is present, uniqueness is scoped to
the workflow; when "wid" is absent, uniqueness MUST be enforced
globally across the ECT store.
3.2.2. Execution Context
The following claims are defined by this specification:
wid: OPTIONAL. String. A workflow identifier that groups related
ECTs into a single workflow. When present, MUST be a UUID
[RFC9562].
exec_act: REQUIRED. String. The action or task type identifier
describing what the agent performed (e.g., "process_payment",
"validate_safety"). This claim name avoids collision with the
"act" (Actor) claim registered by [RFC8693].
par: REQUIRED. Array of strings. Parent task identifiers
representing DAG dependencies. Each element MUST be the "jti"
value of a previously verified ECT. An empty array indicates a
root task with no dependencies. A workflow MAY contain multiple
root tasks.
3.2.3. Data Integrity
The following claims provide integrity verification for task inputs
and outputs without revealing the data itself:
inp_hash: OPTIONAL. String. The base64url encoding (without
Nennemann Expires 29 August 2026 [Page 6]
Internet-Draft WIMSE Execution Context February 2026
padding) of the SHA-256 hash of the input data, computed over the
raw octets of the input. SHA-256 is the mandatory algorithm with
no algorithm prefix in the value, consistent with [RFC9449] and
[I-D.ietf-wimse-s2s-protocol].
out_hash: OPTIONAL. String. The base64url encoding (without
padding) of the SHA-256 hash of the output data, using the same
format as "inp_hash".
3.2.4. Extensions
ext: OPTIONAL. Object. A general-purpose extension object for
domain-specific claims not defined by this specification.
Implementations that do not understand extension claims MUST
ignore them. Extension key names SHOULD use reverse domain
notation (e.g., "com.example.custom_field") to avoid collisions.
The serialized "ext" object SHOULD NOT exceed 4096 bytes and
SHOULD NOT exceed a nesting depth of 5 levels.
3.3. Complete ECT Example
The following is a complete ECT payload example:
{
"iss": "spiffe://example.com/agent/clinical",
"aud": "spiffe://example.com/agent/safety",
"iat": 1772064150,
"exp": 1772064750,
"jti": "550e8400-e29b-41d4-a716-446655440001",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"exec_act": "recommend_treatment",
"par": [],
"inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"ext": {
"com.example.trace_id": "abc123"
}
}
Figure 2: Complete ECT Payload Example
4. HTTP Header Transport
Nennemann Expires 29 August 2026 [Page 7]
Internet-Draft WIMSE Execution Context February 2026
4.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.
An agent sending a request to another agent includes the Execution-
Context header alongside the WIMSE Workload-Identity header. When a
Workload Proof Token (WPT) is available per
[I-D.ietf-wimse-s2s-protocol], agents SHOULD include it alongside the
WIT and ECT.
GET /api/safety-check HTTP/1.1
Host: safety-agent.example.com
Workload-Identity: eyJhbGci...WIT...
Execution-Context: eyJhbGci...ECT...
Figure 3: 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 6. If any
single ECT fails verification, the receiver MUST reject the entire
request. The set of verified parent task IDs across all received
ECTs represents the complete set of parent dependencies available for
the receiving agent's subsequent ECT.
5. DAG Validation
ECTs form a Directed Acyclic Graph (DAG) where each task references
its parent tasks via the "par" claim. DAG validation is performed
against the ECT store — either an audit ledger or the set of parent
ECTs received inline.
When receiving and verifying an ECT, implementations MUST perform the
following DAG validation steps:
1. Task ID Uniqueness: The "jti" claim MUST be unique within the
applicable scope (the workflow identified by "wid", or the entire
ECT store if "wid" is absent). If an ECT with the same "jti"
already exists, the ECT MUST be rejected.
Nennemann Expires 29 August 2026 [Page 8]
Internet-Draft WIMSE Execution Context February 2026
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 ECT's "jti". If a cycle is detected,
the ECT MUST be rejected.
5. Trust Domain Consistency: Parent tasks SHOULD belong to the same
trust domain or to a trust domain with which a federation
relationship has been established.
To prevent denial-of-service via extremely deep or wide DAGs,
implementations SHOULD enforce a maximum ancestor traversal limit
(RECOMMENDED: 10000 nodes). If the limit is reached before cycle
detection completes, the ECT SHOULD be rejected.
In distributed deployments, a parent ECT may not yet be available
locally due to replication lag. Implementations MAY defer validation
to allow parent ECTs to arrive, but MUST NOT treat the ECT as
verified until all parent references are resolved.
6. Signature and Token Verification
6.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".
Nennemann Expires 29 August 2026 [Page 9]
Internet-Draft WIMSE Execution Context February 2026
3. Verify that the "alg" header parameter appears in the verifier's
configured allowlist of accepted signing algorithms. The
allowlist MUST NOT include "none" or any symmetric algorithm
(e.g., HS256, HS384, HS512). Implementations MUST include ES256
in the allowlist; additional asymmetric algorithms MAY be
included per deployment policy.
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.
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", "exec_act", "par") are
present and well-formed.
13. Perform DAG validation per Section 5.
14. If all checks pass and an audit ledger is deployed, the ECT
SHOULD be appended to the ledger.
Nennemann Expires 29 August 2026 [Page 10]
Internet-Draft WIMSE Execution Context February 2026
If any verification step fails, the ECT MUST be rejected and the
failure MUST be logged for audit purposes. Error messages SHOULD NOT
reveal whether specific parent task IDs exist in the ECT store, to
prevent information disclosure.
When ECT verification fails during HTTP request processing, the
receiving agent SHOULD respond with HTTP 403 (Forbidden) if the WIT
is valid but the ECT is invalid, and HTTP 401 (Unauthorized) if the
ECT signature verification fails. The response body SHOULD include a
generic error indicator without revealing which specific verification
step failed. The receiving agent MUST NOT process the requested
action when ECT verification fails.
7. Audit Ledger Interface
ECTs MAY be recorded in an immutable audit ledger for compliance
verification and post-hoc analysis. A ledger is RECOMMENDED for
regulated environments but is not required for point-to-point
operation. This specification does not mandate a specific storage
technology. Implementations MAY use append-only logs, databases with
cryptographic commitment schemes, distributed ledgers, or any storage
mechanism that provides the required properties.
When an audit ledger is deployed, the implementation MUST provide:
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 ECT ID: The ledger MUST support efficient retrieval of
ECT entries by "jti" 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.
8. Security Considerations
Nennemann Expires 29 August 2026 [Page 11]
Internet-Draft WIMSE Execution Context February 2026
8.1. Threat Model
The threat model considers: (1) a malicious agent that creates false
ECT claims, (2) an agent whose private key has been compromised, (3)
a ledger tamperer attempting to modify recorded entries, and (4) a
time manipulator altering timestamps to affect perceived ordering.
8.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.,
claiming an action was performed when it was not).
ECTs do not independently verify that:
* The claimed execution actually occurred as described
* The input/output hashes correspond to the actual data processed
* The agent faithfully performed the stated action
The trustworthiness of ECT claims depends on the trustworthiness of
the signing agent and the integrity of the broader deployment
environment. ECTs provide a technical mechanism for execution
recording; they do not by themselves satisfy any specific regulatory
compliance requirement.
8.3. 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 6).
If signature verification fails or if the signing key has been
revoked, the ECT MUST be rejected entirely and the failure MUST be
logged.
Implementations MUST use established JWS libraries and MUST NOT
implement custom signature verification.
Nennemann Expires 29 August 2026 [Page 12]
Internet-Draft WIMSE Execution Context February 2026
8.4. Replay Attack Prevention
ECTs include short expiration times (RECOMMENDED: 5-15 minutes) and
audience restriction via "aud" to limit replay attacks.
Implementations MUST maintain a cache of recently-seen "jti" values
and MUST reject ECTs with duplicate "jti" values. Each ECT is
cryptographically bound to the issuing agent via "kid"; verifiers
MUST confirm that "kid" resolves to the "iss" agent's key (step 8 in
Section 6).
8.5. Man-in-the-Middle Protection
ECTs MUST be transmitted over TLS or mTLS connections. When used
with [I-D.ietf-wimse-s2s-protocol], transport security is already
established.
8.6. Key Compromise
If an agent's private key is compromised, an attacker can forge ECTs
that appear to originate from that agent. Mitigations:
* Implementations SHOULD use short-lived keys and rotate them
frequently.
* Private keys SHOULD be stored in hardware security modules or
equivalent secure key storage.
* Trust domains MUST support rapid key revocation.
ECTs recorded before key revocation remain valid historical records
but SHOULD be flagged for audit purposes. New ECTs MUST NOT
reference a parent ECT whose signing key is known to be revoked at
creation time.
8.7. Collusion and DAG Integrity
A single malicious agent cannot forge parent task references because
DAG validation requires parent tasks to exist in the ECT store.
However, multiple colluding agents could create a false execution
history. Additionally, a malicious agent may omit actual parent
dependencies from "par" to hide influences on its output; because
ECTs are self-asserted (Section 8.2), no mechanism can force complete
dependency declaration.
Mitigations include:
* The ledger SHOULD be maintained by an entity independent of the
workflow agents.
Nennemann Expires 29 August 2026 [Page 13]
Internet-Draft WIMSE Execution Context February 2026
* Multiple independent ledger replicas can be compared for
consistency.
* External auditors can compare the declared DAG against expected
workflow patterns.
Verifiers SHOULD validate that the declared "wid" of parent ECTs
matches the "wid" of the child ECT, rejecting cross-workflow parent
references unless explicitly permitted by deployment policy.
8.8. Privilege Escalation via ECTs
ECTs record execution history; they do not convey authorization.
Verifiers MUST NOT interpret the presence of an ECT, or a particular
set of parent references in "par", as an authorization grant.
Authorization decisions MUST remain with the identity and
authorization layer (WIT, WPT, and deployment policy).
8.9. Denial of Service
Implementations SHOULD apply rate limiting to prevent excessive ECT
submissions. DAG validation SHOULD be performed after signature
verification to avoid wasting resources on unsigned tokens.
8.10. Timestamp Accuracy
Implementations SHOULD use synchronized time sources (e.g., NTP) and
SHOULD allow a configurable clock skew tolerance (RECOMMENDED: 30
seconds). Cross-organizational deployments MAY require a higher
tolerance and SHOULD document the configured value.
8.11. ECT Size Constraints
Implementations SHOULD limit the "par" array to a maximum of 256
entries. See Section 3.2.4 for "ext" size limits.
9. Privacy Considerations
9.1. Data Exposure in ECTs
ECTs necessarily reveal:
* Agent identities ("iss", "aud") for accountability purposes
* Action descriptions ("exec_act") for audit trail completeness
* Timestamps ("iat", "exp") for temporal ordering
Nennemann Expires 29 August 2026 [Page 14]
Internet-Draft WIMSE Execution Context February 2026
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
* Proprietary algorithms or intellectual property
* Personally identifiable information (PII)
9.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.
Extension keys in "ext" (Section 3.2.4) deserve particular attention:
human-readable values risk exposing sensitive operational details.
See Section 3.2.4 for guidance on using structured identifiers.
9.3. Storage and Access Control
ECTs stored in audit ledgers SHOULD be access-controlled so that only
authorized auditors can read them. Implementations SHOULD consider
encryption at rest for ledger storage. ECTs provide structural
records of execution ordering; they are not intended for public
disclosure.
Full input and output data (corresponding to the hashes in ECTs)
SHOULD be stored separately from the ledger with additional access
controls, since auditors may need to verify hash correctness but
general access to the data values is not needed.
10. IANA Considerations
10.1. Media Type Registration
This document requests registration of the following media type in
the "Media Types" registry maintained by IANA:
Type name: application
Subtype name: wimse-exec+jwt
Required parameters: none
Optional parameters: none
Nennemann Expires 29 August 2026 [Page 15]
Internet-Draft WIMSE Execution Context February 2026
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
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
10.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 4
10.3. JWT Claims Registration
This document requests registration of the following claims in the
"JSON Web Token Claims" registry maintained by IANA:
Nennemann Expires 29 August 2026 [Page 16]
Internet-Draft WIMSE Execution Context February 2026
+============+=====================+===================+===========+
| Claim Name | Claim Description | Change Controller | Reference |
+============+=====================+===================+===========+
| wid | Workflow Identifier | IETF | Section |
| | | | 3.2.2 |
+------------+---------------------+-------------------+-----------+
| exec_act | Action/Task Type | IETF | Section |
| | | | 3.2.2 |
+------------+---------------------+-------------------+-----------+
| par | Parent Task | IETF | Section |
| | Identifiers | | 3.2.2 |
+------------+---------------------+-------------------+-----------+
| inp_hash | Input Data Hash | IETF | Section |
| | | | 3.2.3 |
+------------+---------------------+-------------------+-----------+
| out_hash | Output Data Hash | IETF | Section |
| | | | 3.2.3 |
+------------+---------------------+-------------------+-----------+
| ext | Extension Object | IETF | Section |
| | | | 3.2.4 |
+------------+---------------------+-------------------+-----------+
Table 1: JWT Claims Registrations
11. References
11.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 29 August 2026 [Page 17]
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>.
[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>.
11.2. Informative References
[I-D.ietf-oauth-transaction-tokens]
Tulshibagwale, A., Fletcher, G., and P. Kasselman,
"Transaction Tokens", Work in Progress, Internet-Draft,
draft-ietf-oauth-transaction-tokens-07, 24 January 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
transaction-tokens-07>.
[I-D.ietf-scitt-architecture]
Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", Work in Progress,
Internet-Draft, draft-ietf-scitt-architecture-22, 10
October 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-scitt-architecture-22>.
Nennemann Expires 29 August 2026 [Page 18]
Internet-Draft WIMSE Execution Context February 2026
[I-D.oauth-transaction-tokens-for-agents]
Raut, A., "Transaction Tokens For Agents", Work in
Progress, Internet-Draft, draft-oauth-transaction-tokens-
for-agents-04, 10 February 2026,
<https://datatracker.ietf.org/doc/html/draft-oauth-
transaction-tokens-for-agents-04>.
[OPENTELEMETRY]
Cloud Native Computing Foundation, "OpenTelemetry
Specification",
<https://opentelemetry.io/docs/specs/otel/>.
[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>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.
[SPIFFE] "Secure Production Identity Framework for Everyone
(SPIFFE)",
<https://spiffe.io/docs/latest/spiffe-about/overview/>.
Use Cases
This section describes a representative use case demonstrating how
ECTs provide structured execution records.
Note: task identifiers in this section are abbreviated for
readability. In production, all "jti" values are required to be
UUIDs per Section 3.2.2.
Cross-Organization Financial Trading
In a cross-organization trading workflow, an investment bank's agents
coordinate with an external credit rating agency. The agents operate
in separate trust domains with a federation relationship. The DAG
records that independent assessments from both organizations were
completed before trade execution.
Nennemann Expires 29 August 2026 [Page 19]
Internet-Draft WIMSE Execution Context February 2026
Trust Domain: bank.example
Agent A1 (Portfolio Risk):
jti: task-001 par: []
iss: spiffe://bank.example/agent/risk
exec_act: analyze_portfolio_risk
Trust Domain: ratings.example (external)
Agent B1 (Credit Rating):
jti: task-002 par: []
iss: spiffe://ratings.example/agent/credit
exec_act: assess_credit_rating
Trust Domain: bank.example
Agent A2 (Compliance):
jti: task-003 par: [task-001, task-002]
iss: spiffe://bank.example/agent/compliance
exec_act: verify_trade_compliance
Agent A3 (Execution):
jti: task-004 par: [task-003]
iss: spiffe://bank.example/agent/execution
exec_act: execute_trade
Figure 4: Cross-Organization Trading Workflow
The resulting DAG:
task-001 (analyze_portfolio_risk) task-002 (assess_credit_rating)
[bank.example] [ratings.example]
\ /
v v
task-003 (verify_trade_compliance)
[bank.example]
|
v
task-004 (execute_trade)
[bank.example]
Figure 5: Cross-Organization DAG
Task 003 has two parents from different trust domains, demonstrating
cross-organizational fan-in. The compliance agent verifies both
parent ECTs — one signed by a local key and one by a federated key
from the rating agency's trust domain.
Nennemann Expires 29 August 2026 [Page 20]
Internet-Draft WIMSE Execution Context February 2026
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?" 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 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."
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.
Nennemann Expires 29 August 2026 [Page 21]
Internet-Draft WIMSE Execution Context February 2026
* It carries no task-level granularity, no parent references, and no
execution content.
* It cannot represent convergence (fan-in): when two independent
paths must both complete before a dependent task proceeds, a
linear "req_wl" string cannot express that relationship.
Extensions for agentic use cases
([I-D.oauth-transaction-tokens-for-agents]) add agent identity and
constraints ("agentic_ctx") but no execution ordering or DAG
structure.
ECTs and Transaction Tokens are complementary: a Txn-Token propagates
authorization context ("this request is authorized for scope X on
behalf of user Y"), while an ECT records execution accountability
("task T was performed, depending on tasks P1 and P2"). 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
while ECTs provide signed execution records. ECTs may reference
OpenTelemetry trace identifiers in the "ext" claim for correlation.
W3C Provenance Data Model (PROV)
The W3C PROV Data Model defines an Entity-Activity-Agent ontology for
representing provenance information. PROV's concepts map closely to
ECT structures: PROV Activities correspond to ECT tasks, PROV Agents
correspond to WIMSE workloads, and PROV's "wasInformedBy" relation
corresponds to ECT "par" references. However, PROV uses RDF/OWL
ontologies designed for post-hoc documentation, while ECTs are
runtime-embeddable JWT tokens with cryptographic signatures. ECT
audit data could be exported to PROV format for interoperability with
provenance-aware systems.
Nennemann Expires 29 August 2026 [Page 22]
Internet-Draft WIMSE Execution Context February 2026
SCITT (Supply Chain Integrity, Transparency, and Trust)
The SCITT architecture [I-D.ietf-scitt-architecture] defines a
framework for transparent and auditable supply chain records. ECTs
and SCITT are complementary: the ECT "wid" claim can serve as a
correlation identifier in SCITT Signed Statements, linking an ECT
audit trail to a supply chain transparency record.
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 29 August 2026 [Page 23]
Reference in New Issue View Git Blame Copy Permalink