c/ietf-wimse-ect
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Implement peer review feedback for draft-nennemann-wimse-ect-00

Browse Source 
Address 11 items from peer review:
- Fix area designation from Security to ART (WIMSE is in ART area)
- Switch inp_hash/out_hash to fixed SHA-256 without algorithm prefix,
  matching DPoP (RFC 9449) and WIMSE WPT tth claim patterns
- Add partial DAG verification guidance for unavailable parents
- Add DAG integrity attacks subsection (false parents, pruning, shadow DAGs)
- Add privilege escalation subsection (ECTs are not authorization)
- Add revocation propagation semantics through the DAG
- Add W3C PROV Data Model to Related Work
- Strengthen Txn-Token differentiation with fan-in/convergence bullet
- Add explicit token binding paragraph to replay prevention
- Switch verification step 3 to algorithm allowlist model
- Add par/ext claim naming justification notes

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Christian Nennemann
2026-02-25 21:59:16 +01:00
parent 1385ec8af1
commit ff795c72e6
4 changed files with 1194 additions and 661 deletions
Download Patch File Download Diff File Expand all files Collapse all files

594
draft-nennemann-wimse-ect-00.txt
View File

@@ -77,35 +77,35 @@ Table of Contents
3. WIMSE Architecture Integration . . . . . . . . . . . . . . . 5
3.1. WIMSE Foundation . . . . . . . . . . . . . . . . . . . . 5
3.2. Extension Model . . . . . . . . . . . . . . . . . . . . . 6
3.3. Integration Points . . . . . . . . . . . . . . . . . . . 6
4. Execution Context Token Format . . . . . . . . . . . . . . . 7
3.3. Integration Points . . . . . . . . . . . . . . . . . . . 7
4. Execution Context Token Format . . . . . . . . . . . . . . . 8
4.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Standard JWT Claims . . . . . . . . . . . . . . . . . 8
4.2.2. Execution Context . . . . . . . . . . . . . . . . . . 10
4.2.3. Data Integrity . . . . . . . . . . . . . . . . . . . 10
4.2.4. Extensions . . . . . . . . . . . . . . . . . . . . . 10
4.2.4. Extensions . . . . . . . . . . . . . . . . . . . . . 11
4.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 11
5. HTTP Header Transport . . . . . . . . . . . . . . . . . . . . 11
5.1. Execution-Context Header Field . . . . . . . . . . . . . 11
5. HTTP Header Transport . . . . . . . . . . . . . . . . . . . . 12
5.1. Execution-Context Header Field . . . . . . . . . . . . . 12
6. DAG Validation . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Validation Rules . . . . . . . . . . . . . . . . . . . . 12
7. Signature and Token Verification . . . . . . . . . . . . . . 13
7.1. Verification Procedure . . . . . . . . . . . . . . . . . 13
6.2. Validation Rules . . . . . . . . . . . . . . . . . . . . 13
6.3. Handling Unavailable Parent ECTs . . . . . . . . . . . . 13
7. Signature and Token Verification . . . . . . . . . . . . . . 14
7.1. Verification Procedure . . . . . . . . . . . . . . . . . 14
8. Audit Ledger Interface . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Self-Assertion Limitation . . . . . . . . . . . . . . . . 16
9.3. Organizational Prerequisites . . . . . . . . . . . . . . 16
9.4. Signature Verification . . . . . . . . . . . . . . . . . 16
9.3. Organizational Prerequisites . . . . . . . . . . . . . . 17
9.4. Signature Verification . . . . . . . . . . . . . . . . . 17
9.5. Replay Attack Prevention . . . . . . . . . . . . . . . . 17
9.6. Man-in-the-Middle Protection . . . . . . . . . . . . . . 17
9.7. Key Compromise . . . . . . . . . . . . . . . . . . . . . 17
9.8. Collusion and False Claims . . . . . . . . . . . . . . . 18
9.9. Denial of Service . . . . . . . . . . . . . . . . . . . . 18
9.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 18
9.11. ECT Size Constraints . . . . . . . . . . . . . . . . . . 19
9.6. Man-in-the-Middle Protection . . . . . . . . . . . . . . 18
9.7. Key Compromise . . . . . . . . . . . . . . . . . . . . . 18
9.8. Collusion and False Claims . . . . . . . . . . . . . . . 19
9.9. DAG Integrity Attacks . . . . . . . . . . . . . . . . . . 19
9.10. Privilege Escalation via ECTs . . . . . . . . . . . . . . 20
@@ -114,27 +114,31 @@ Nennemann Expires 29 August 2026 [Page 2]
Internet-Draft WIMSE Execution Context February 2026
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
10.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . 19
10.2. Data Minimization . . . . . . . . . . . . . . . . . . . 20
10.3. Storage and Access Control . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11.1. Media Type Registration . . . . . . . . . . . . . . . . 20
11.2. HTTP Header Field Registration . . . . . . . . . . . . . 21
11.3. JWT Claims Registration . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 23
Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Cross-Organization Financial Trading . . . . . . . . . . . . . 25
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 26
WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 26
OAuth 2.0 Token Exchange and the "act" Claim . . . . . . . . . 26
Transaction Tokens . . . . . . . . . . . . . . . . . . . . . . 26
Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 27
SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28
9.11. Denial of Service . . . . . . . . . . . . . . . . . . . . 20
9.12. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 20
9.13. ECT Size Constraints . . . . . . . . . . . . . . . . . . 21
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
10.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . 21
10.2. Data Minimization . . . . . . . . . . . . . . . . . . . 22
10.3. Storage and Access Control . . . . . . . . . . . . . . . 22
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11.1. Media Type Registration . . . . . . . . . . . . . . . . 22
11.2. HTTP Header Field Registration . . . . . . . . . . . . . 23
11.3. JWT Claims Registration . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 25
Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Cross-Organization Financial Trading . . . . . . . . . . . . . 27
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 28
WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 28
OAuth 2.0 Token Exchange and the "act" Claim . . . . . . . . . 28
Transaction Tokens . . . . . . . . . . . . . . . . . . . . . . 29
Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 30
W3C Provenance Data Model (PROV) . . . . . . . . . . . . . . . 30
SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 30
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction
@@ -156,10 +160,6 @@ Internet-Draft WIMSE Execution Context February 2026
healthcare, finance, and logistics require structured, auditable
records of automated decision-making and execution.
This document defines an extension to the WIMSE architecture that
addresses the gap between workload identity and execution
accountability. WIMSE authenticates agents; this extension records
what they did and in what order.
@@ -170,6 +170,11 @@ Nennemann Expires 29 August 2026 [Page 3]
Internet-Draft WIMSE Execution Context February 2026
This document defines an extension to the WIMSE architecture that
addresses the gap between workload identity and execution
accountability. WIMSE authenticates agents; this extension records
what they did and in what order.
As identified in [I-D.ni-wimse-ai-agent-identity], call context in
agentic workflows needs to be visible and preserved. ECTs provide a
mechanism to address this requirement with cryptographic assurances.
@@ -213,11 +218,6 @@ Internet-Draft WIMSE Execution Context February 2026
* Workload authentication and identity provisioning
* Key distribution and management
* Trust domain establishment and management
* Credential lifecycle management
@@ -226,6 +226,12 @@ Nennemann Expires 29 August 2026 [Page 4]
Internet-Draft WIMSE Execution Context February 2026
* Key distribution and management
* Trust domain establishment and management
* Credential lifecycle management
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -267,12 +273,6 @@ Internet-Draft WIMSE Execution Context February 2026
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")
@@ -282,6 +282,12 @@ Nennemann Expires 29 August 2026 [Page 5]
Internet-Draft WIMSE Execution Context February 2026
* 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]
@@ -325,12 +331,6 @@ Internet-Draft WIMSE Execution Context February 2026
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:
Nennemann Expires 29 August 2026 [Page 6]
@@ -338,6 +338,11 @@ Nennemann Expires 29 August 2026 [Page 6]
Internet-Draft WIMSE Execution Context February 2026
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.
@@ -376,12 +381,7 @@ Internet-Draft WIMSE Execution Context February 2026
3. Ledger (if deployed): 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]. 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.
@@ -394,6 +394,13 @@ Nennemann Expires 29 August 2026 [Page 7]
Internet-Draft WIMSE Execution Context February 2026
4. 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.
4.1. JOSE Header
The ECT JOSE header MUST contain the following parameters:
@@ -432,6 +439,17 @@ Internet-Draft WIMSE Execution Context February 2026
ECT:
iss: REQUIRED. StringOrURI. A URI identifying the issuer of the
Nennemann Expires 29 August 2026 [Page 8]
Internet-Draft WIMSE Execution Context February 2026
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
@@ -443,13 +461,6 @@ Internet-Draft WIMSE Execution Context February 2026
identifiers of all entities that will verify the ECT. In practice
this means:
Nennemann Expires 29 August 2026 [Page 8]
Internet-Draft WIMSE Execution Context February 2026
* *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
@@ -487,6 +498,14 @@ Internet-Draft WIMSE Execution Context February 2026
issuance.
jti: REQUIRED. String. A globally unique identifier for both the
Nennemann Expires 29 August 2026 [Page 9]
Internet-Draft WIMSE Execution Context February 2026
ECT and the task it records, in UUID format [RFC9562]. Since each
ECT represents exactly one task, "jti" serves as both the token
identifier (for replay detection) and the task identifier (for DAG
@@ -496,16 +515,6 @@ Internet-Draft WIMSE Execution Context February 2026
is absent, uniqueness MUST be enforced globally across the ECT
store.
Nennemann Expires 29 August 2026 [Page 9]
Internet-Draft WIMSE Execution Context February 2026
4.2.2. Execution Context
The following claims are defined by this specification:
@@ -526,33 +535,24 @@ Internet-Draft WIMSE Execution Context February 2026
root task with no dependencies. A workflow MAY contain multiple
root tasks. Parent ECTs may have passed their own "exp" time; ECT
expiration applies to the verification window of the ECT itself,
not to its validity as a parent reference in the ECT store.
not to its validity as a parent reference in the ECT store. Note:
"par" is not a registered JWT claim and does not conflict with
OAuth Pushed Authorization Requests (RFC 9126), which defines an
endpoint, not a token claim.
4.2.3. Data Integrity
The following claims provide integrity verification for task inputs
and outputs without revealing the data itself:
inp_hash: OPTIONAL. String. A cryptographic hash of the input
data, formatted as "hash-algorithm:base64url-encoded-hash" (e.g.,
"sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The hash
algorithm identifier MUST be a lowercase value from the IANA Named
Information Hash Algorithm Registry (e.g., "sha-256", "sha-384",
"sha-512"). Implementations MUST support "sha-256" and SHOULD use
"sha-256" unless a stronger algorithm is required.
Implementations MUST NOT accept hash algorithms weaker than
SHA-256 (e.g., MD5, SHA-1). The hash MUST be computed over the
raw octets of the input data.
inp_hash: OPTIONAL. String. The base64url encoding (without
padding) of the SHA-256 hash of the input data, computed over the
raw octets of the input. This follows the same fixed-algorithm
pattern used by the DPoP "ath" claim [RFC9449] and the WIMSE WPT
"tth" claim [I-D.ietf-wimse-s2s-protocol]: SHA-256 is the
mandatory algorithm with no algorithm prefix in the value.
out_hash: OPTIONAL. String. A cryptographic hash of the output
data, using the same format and algorithm requirements as
"inp_hash".
4.2.4. Extensions
ext: OPTIONAL. Object. An extension object for domain-specific
claims not defined by this specification. Implementations that do
not understand extension claims MUST ignore them.
out_hash: OPTIONAL. String. The base64url encoding (without
@@ -562,6 +562,18 @@ Nennemann Expires 29 August 2026 [Page 10]
Internet-Draft WIMSE Execution Context February 2026
padding) of the SHA-256 hash of the output data, using the same
format as "inp_hash".
4.2.4. Extensions
ext: OPTIONAL. Object. A general-purpose extension object for
domain-specific claims not defined by this specification. The
short name "ext" follows the JWT convention of concise claim names
and is chosen over alternatives like "extensions" for compactness.
Implementations that do not understand extension claims MUST
ignore them.
To avoid key collisions between different domains, extension key
names SHOULD use reverse domain notation (e.g.,
"com.example.custom_field") to avoid collisions between independently
@@ -589,12 +601,23 @@ Internet-Draft WIMSE Execution Context February 2026
"exec_act": "recommend_treatment",
"par": [],
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
"inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"ext": {
"com.example.trace_id": "abc123"
}
}
Figure 4: Complete ECT Payload Example
Nennemann Expires 29 August 2026 [Page 11]
Internet-Draft WIMSE Execution Context February 2026
5. HTTP Header Transport
5.1. Execution-Context Header Field
@@ -609,15 +632,6 @@ 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 header:
Nennemann Expires 29 August 2026 [Page 11]
Internet-Draft WIMSE Execution Context February 2026
GET /api/safety-check HTTP/1.1
Host: safety-agent.example.com
Workload-Identity: eyJhbGci...WIT...
@@ -649,6 +663,17 @@ Internet-Draft WIMSE Execution Context February 2026
DAG validation is performed against the ECT store — either an audit
ledger or the set of parent ECTs received inline.
Nennemann Expires 29 August 2026 [Page 12]
Internet-Draft WIMSE Execution Context February 2026
6.2. Validation Rules
When receiving and verifying an ECT, implementations MUST perform the
@@ -665,15 +690,6 @@ Internet-Draft WIMSE Execution Context February 2026
verified parent ECT). If any parent task is not found, the ECT
MUST be rejected.
Nennemann Expires 29 August 2026 [Page 12]
Internet-Draft WIMSE Execution Context February 2026
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).
@@ -698,6 +714,35 @@ Internet-Draft WIMSE Execution Context February 2026
(RECOMMENDED: 10000 nodes). If the limit is reached before cycle
detection completes, the ECT SHOULD be rejected.
6.3. Handling Unavailable Parent ECTs
In distributed deployments, a parent ECT referenced in the "par"
array may not yet be available in the local ECT store at the time of
validation — for example, due to replication lag in a distributed
ledger or out-of-order message delivery.
Implementations MUST distinguish between two cases:
Nennemann Expires 29 August 2026 [Page 13]
Internet-Draft WIMSE Execution Context February 2026
1. Parent not found and definitively absent: The parent "jti" does
not exist in any accessible ECT store. The ECT MUST be rejected.
2. Parent not yet available: The parent "jti" is not present locally
but may arrive due to known replication delays. Implementations
MAY defer validation for a bounded period (RECOMMENDED: no more
than 60 seconds).
Deferred ECTs MUST NOT be treated as verified until all parent
references are resolved. If any parent reference remains unresolved
after the deferral period or after the ECT's own "exp" time
(whichever comes first), the ECT MUST be rejected.
7. Signature and Token Verification
7.1. Verification Procedure
@@ -710,8 +755,12 @@ Internet-Draft WIMSE Execution Context February 2026
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.
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.
@@ -719,17 +768,6 @@ Internet-Draft WIMSE Execution Context February 2026
5. Retrieve the public key identified by "kid" and verify the JWS
signature per [RFC7515] Section 5.2.
Nennemann Expires 29 August 2026 [Page 13]
Internet-Draft WIMSE Execution Context February 2026
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
@@ -739,6 +777,15 @@ Internet-Draft WIMSE Execution Context February 2026
7. Verify the "alg" header parameter matches the algorithm in the
corresponding WIT.
Nennemann Expires 29 August 2026 [Page 14]
Internet-Draft WIMSE Execution Context February 2026
8. Verify the "iss" claim matches the "sub" claim of the WIT
associated with the "kid" public key.
@@ -778,14 +825,6 @@ Internet-Draft WIMSE Execution Context February 2026
step failed. The receiving agent MUST NOT process the requested
action when ECT verification fails.
Nennemann Expires 29 August 2026 [Page 14]
Internet-Draft WIMSE Execution Context February 2026
8. Audit Ledger Interface
ECTs MAY be recorded in an immutable audit ledger for compliance
@@ -796,6 +835,13 @@ Internet-Draft WIMSE Execution Context February 2026
cryptographic commitment schemes, distributed ledgers, or any storage
mechanism that provides the required properties.
Nennemann Expires 29 August 2026 [Page 15]
Internet-Draft WIMSE Execution Context February 2026
When an audit ledger is deployed, the implementation MUST provide:
1. Append-only semantics: Once an ECT is recorded, it MUST NOT be
@@ -835,13 +881,6 @@ Internet-Draft WIMSE Execution Context February 2026
* Time manipulator: An entity attempting to manipulate timestamps to
alter perceived execution ordering.
Nennemann Expires 29 August 2026 [Page 15]
Internet-Draft WIMSE Execution Context February 2026
9.2. Self-Assertion Limitation
ECTs are self-asserted by the executing agent. The agent claims what
@@ -851,6 +890,14 @@ Internet-Draft WIMSE Execution Context February 2026
ECTs do not independently verify that:
Nennemann Expires 29 August 2026 [Page 16]
Internet-Draft WIMSE Execution Context February 2026
* The claimed execution actually occurred as described
* The input/output hashes correspond to the actual data processed
@@ -889,15 +936,6 @@ Internet-Draft WIMSE Execution Context February 2026
revoked, the ECT MUST be rejected entirely and the failure MUST be
logged.
Nennemann Expires 29 August 2026 [Page 16]
Internet-Draft WIMSE Execution Context February 2026
Implementations MUST use established JWS libraries and MUST NOT
implement custom signature verification.
@@ -909,6 +947,13 @@ Internet-Draft WIMSE Execution Context February 2026
rejected by Agent C. The "iat" claim enables receivers to reject
ECTs that are too old, even if not yet expired.
Nennemann Expires 29 August 2026 [Page 17]
Internet-Draft WIMSE Execution Context February 2026
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.
@@ -917,6 +962,12 @@ Internet-Draft WIMSE Execution Context February 2026
to detect replayed ECTs within the expiration window. An ECT with a
duplicate "jti" value MUST be rejected.
Additionally, each ECT is cryptographically bound to the issuing
agent via the JOSE "kid" parameter, which references the agent's WIT
public key. Verifiers MUST confirm that the "kid" resolves to the
"iss" agent's key (step 8 in Section 7), preventing one agent from
replaying another agent's ECT as its own.
9.6. Man-in-the-Middle Protection
ECTs do not replace transport-layer security. ECTs MUST be
@@ -947,21 +998,33 @@ Internet-Draft WIMSE Execution Context February 2026
* Trust domains MUST support rapid key revocation.
* Upon suspected compromise, the trust domain MUST revoke the
compromised key and issue a new WIT with a fresh key pair.
Nennemann Expires 29 August 2026 [Page 17]
Nennemann Expires 29 August 2026 [Page 18]
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.
ECT revocation does not propagate through the DAG. If a parent ECT's
signing key is later revoked, child ECTs that were verified and
recorded before that revocation remain valid — they captured a
legitimate execution record at the time of issuance. However,
auditors reviewing a workflow SHOULD flag any ECT in the DAG whose
signing key was subsequently revoked, so that the scope of a
potential compromise can be assessed. New ECTs MUST NOT be created
with a "par" reference to an ECT whose signing key is known to be
revoked at creation time.
9.8. Collusion and False Claims
A single malicious agent cannot forge parent task references because
@@ -980,7 +1043,56 @@ Internet-Draft WIMSE Execution Context February 2026
* Out-of-band audit: External auditors periodically verify ledger
contents against expected workflow patterns.
9.9. Denial of Service
9.9. DAG Integrity Attacks
Because the DAG structure is the primary mechanism for establishing
execution ordering, attackers may attempt to manipulate it:
* False parent references: A malicious agent creates an ECT that
references parent tasks from an unrelated workflow, inserting
itself into a legitimate execution history. DAG validation
(Section 6) mitigates this by requiring parent existence in the
ECT store, and the "wid" claim scopes parent references to a
single workflow when present.
* Parent omission (pruning): An agent deliberately omits one or more
actual parent dependencies from the "par" array to hide that
certain tasks influenced its output. Because ECTs are self-
Nennemann Expires 29 August 2026 [Page 19]
Internet-Draft WIMSE Execution Context February 2026
asserted (Section 9.2), no mechanism can force an agent to declare
all dependencies. External auditors can detect omission by
comparing the declared DAG against expected workflow patterns.
* Shadow DAGs: Multiple colluding agents fabricate an entire
execution history by creating a sequence of ECTs with mutual
parent references. Independent ledger maintenance and cross-
verification (see Section 9.8 above) are the primary mitigations.
Verifiers SHOULD validate that the declared "wid" of parent ECTs
matches the "wid" of the child ECT, rejecting cross-workflow parent
references unless explicitly permitted by deployment policy.
9.10. 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. The
"par" claim demonstrates that predecessor tasks were recorded, not
that the current agent is authorized to act on their outputs.
Authorization decisions MUST remain with the identity and
authorization layer (WIT, WPT, and deployment policy). As noted in
[I-D.ni-wimse-ai-agent-identity], AI intermediaries introduce novel
escalation vectors; ECTs MUST NOT be used to circumvent authorization
boundaries.
9.11. Denial of Service
ECT signature verification is computationally inexpensive
(approximately 1ms per ECT on modern hardware for ES256). DAG
@@ -993,7 +1105,7 @@ Internet-Draft WIMSE Execution Context February 2026
performed after signature verification to avoid wasting resources on
unsigned or incorrectly signed tokens.
9.10. Timestamp Accuracy
9.12. Timestamp Accuracy
ECTs rely on timestamps ("iat", "exp") for temporal ordering. Clock
skew between agents can lead to incorrect ordering judgments.
@@ -1005,7 +1117,7 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 29 August 2026 [Page 18]
Nennemann Expires 29 August 2026 [Page 20]
Internet-Draft WIMSE Execution Context February 2026
@@ -1019,7 +1131,7 @@ Internet-Draft WIMSE Execution Context February 2026
The temporal ordering check in DAG validation incorporates the clock
skew tolerance to account for minor clock differences between agents.
9.11. ECT Size Constraints
9.13. 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
@@ -1061,7 +1173,7 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 29 August 2026 [Page 19]
Nennemann Expires 29 August 2026 [Page 21]
Internet-Draft WIMSE Execution Context February 2026
@@ -1117,7 +1229,7 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 29 August 2026 [Page 20]
Nennemann Expires 29 August 2026 [Page 22]
Internet-Draft WIMSE Execution Context February 2026
@@ -1173,7 +1285,7 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 29 August 2026 [Page 21]
Nennemann Expires 29 August 2026 [Page 23]
Internet-Draft WIMSE Execution Context February 2026
@@ -1229,7 +1341,7 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 29 August 2026 [Page 22]
Nennemann Expires 29 August 2026 [Page 24]
Internet-Draft WIMSE Execution Context February 2026
@@ -1285,7 +1397,7 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 29 August 2026 [Page 23]
Nennemann Expires 29 August 2026 [Page 25]
Internet-Draft WIMSE Execution Context February 2026
@@ -1323,6 +1435,11 @@ Internet-Draft WIMSE Execution Context February 2026
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.
[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/>.
@@ -1332,20 +1449,19 @@ 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 4.2.2.
Nennemann Expires 29 August 2026 [Page 24]
Nennemann Expires 29 August 2026 [Page 26]
Internet-Draft WIMSE Execution Context February 2026
Note: task identifiers in this section are abbreviated for
readability. In production, all "jti" values are required to be
UUIDs per Section 4.2.2.
Cross-Organization Financial Trading
In a cross-organization trading workflow, an investment bank's agents
@@ -1381,6 +1497,23 @@ Cross-Organization Financial Trading
The resulting DAG:
Nennemann Expires 29 August 2026 [Page 27]
Internet-Draft WIMSE Execution Context February 2026
task-001 (analyze_portfolio_risk) task-002 (assess_credit_rating)
[bank.example] [ratings.example]
\ /
@@ -1394,14 +1527,6 @@ Cross-Organization Financial Trading
Figure 7: Cross-Organization DAG
Nennemann Expires 29 August 2026 [Page 25]
Internet-Draft WIMSE Execution Context February 2026
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
@@ -1435,6 +1560,16 @@ OAuth 2.0 Token Exchange and the "act" Claim
concepts are orthogonal: "act" records "who authorized whom," ECTs
record "what was done, in what order."
Nennemann Expires 29 August 2026 [Page 28]
Internet-Draft WIMSE Execution Context February 2026
Transaction Tokens
OAuth Transaction Tokens [I-D.ietf-oauth-transaction-tokens]
@@ -1450,14 +1585,6 @@ Transaction Tokens
downstream services, each receives the same "req_wl" value and the
branching is invisible.
Nennemann Expires 29 August 2026 [Page 26]
Internet-Draft WIMSE Execution Context February 2026
* 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.
@@ -1465,6 +1592,10 @@ 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
@@ -1480,6 +1611,21 @@ Internet-Draft WIMSE Execution Context February 2026
Txn-Token; a similar binding mechanism for ECTs is a potential future
extension.
Nennemann Expires 29 August 2026 [Page 29]
Internet-Draft WIMSE Execution Context February 2026
Distributed Tracing (OpenTelemetry)
OpenTelemetry [OPENTELEMETRY] and similar distributed tracing systems
@@ -1494,6 +1640,18 @@ Distributed Tracing (OpenTelemetry)
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.
SCITT (Supply Chain Integrity, Transparency, and Trust)
The SCITT architecture [I-D.ietf-scitt-architecture] defines a
@@ -1502,18 +1660,6 @@ SCITT (Supply Chain Integrity, Transparency, and Trust)
correlation identifier in SCITT Signed Statements, linking an ECT
audit trail to a supply chain transparency record.
Nennemann Expires 29 August 2026 [Page 27]
Internet-Draft WIMSE Execution Context February 2026
Acknowledgments
The author thanks the WIMSE working group for their foundational work
@@ -1531,38 +1677,4 @@ Author's Address
Nennemann Expires 29 August 2026 [Page 28]
Nennemann Expires 29 August 2026 [Page 30]