Reduce scope and tighten framing for submission readiness

- Remove Operational Modes section (point-to-point, deferred,
  full ledger) to reduce surface area for a -00 submission
- Trim Ledger Interface to essential properties only, remove
  ledger entry JSON example
- Condense regulatory motivation in Introduction to 2 sentences
  with forward reference to compliance mapping table
- Reframe "cryptographic proof" to "signed, structured records"
  in abstract and introduction to accurately reflect self-assertion
- Make WPT co-presence RECOMMENDED rather than assumed, hedging
  against s2s-protocol evolution; ECT is independently verifiable
  via WIT public key
- Fix broken reference: draft-oauth-transaction-tokens-for-agents
  (not an ietf- WG draft)
- Add jti to all JSON examples (required claim was missing from 9
  of 10 examples)
- Clean up dangling cross-references to removed sections

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

draft-nennemann-wimse-execution-context-00.md

@@ -87,17 +87,18 @@ informative:
 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
+environments.  ECTs provide signed, structured records of task
+execution order, policy evaluation outcomes, 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,
+point, and integrate with WIMSE Workload Identity Tokens (WIT)
+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
@@ -118,32 +119,16 @@ 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
+accountability.  Knowing who performed an action does not record
 what was done, what policy was applied, or whether compliance
-requirements were satisfied at each decision point.
+requirements were evaluated 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.
-
-- The Digital Operational Resilience Act (DORA) {{DORA}} Article 12
-  requires financial entities to have logging policies that record
-  ICT activities and anomalies.
+frameworks — including {{EU-AI-ACT}}, {{FDA-21CFR11}}, {{MIFID-II}},
+and {{DORA}} — require structured, auditable records of automated
+decision-making and execution (see {{table-regulatory}} for a
+detailed mapping).
 
 This document defines an extension to the WIMSE architecture that
 addresses the gap between workload identity and execution
@@ -186,8 +171,6 @@ This document defines:
 - Integration with the WIMSE identity framework
   ({{wimse-integration}})
 - An HTTP header for ECT transport ({{http-header}})
-- Operational modes including ledger-optional deployment
-  ({{operational-modes}})
 - Audit ledger interface requirements ({{ledger-interface}})
 
 The following are out of scope and are handled by WIMSE:
@@ -330,27 +313,34 @@ following mechanisms:
 - 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 MUST be signed with the same private key associated
+  with the agent's WIT.
 
 - 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:
+When an agent makes an HTTP request to another agent, the
+Execution-Context header is carried alongside WIMSE identity
+headers:
 
 ~~~ ascii-art
 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>
 ~~~
 {: #fig-http-headers title="HTTP Header Stacking"}
 
+When a Workload Proof Token (WPT) is available per
+{{I-D.ietf-wimse-s2s-protocol}}, agents SHOULD include it
+alongside the WIT and ECT.  ECT verification does not depend
+on the presence of a WPT; the ECT is independently verifiable
+via the WIT public key.
+
 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.
+1.  WIT (WIMSE layer): Verifies Agent A's identity within the
+    trust domain.  WPT verification, if present, per
+    {{I-D.ietf-wimse-s2s-protocol}}.
 
 2.  ECT (this extension): Records what Agent A did, what policy was
     evaluated, and what precedent tasks exist.
@@ -699,13 +689,12 @@ parts separated by period (".") characters.
 
 An agent sending a request to another agent includes the
 Execution-Context header alongside the WIMSE Workload-Identity
-and Workload-Proof-Token headers:
+header:
 
 ~~~
 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...
 ~~~
 {: #fig-http-example title="HTTP Request with ECT Header"}
@@ -733,12 +722,8 @@ 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
-{{operational-modes}}).  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.
+DAG validation is performed against the audit ledger, which
+serves as the authoritative store of previously verified ECTs.
 
 ## Validation Rules
 
@@ -790,15 +775,14 @@ the following DAG validation steps:
 The following pseudocode describes the DAG validation procedure:
 
 ~~~ pseudocode
-function validate_dag(ect, ect_store, clock_skew_tolerance):
-  // ect_store: ledger or local cache of verified ECTs
+function validate_dag(ect, ledger, clock_skew_tolerance):
   // Step 1: Uniqueness check
-  if ect_store.contains(ect.jti, ect.wid):
+  if ledger.contains(ect.jti, ect.wid):
     return error("ECT ID already exists")
 
   // Step 2: Parent existence and temporal ordering
   for parent_id in ect.par:
-    parent = ect_store.get(parent_id)
+    parent = ledger.get(parent_id)
     if parent is null:
       return error("Parent task not found: " + parent_id)
     if parent.iat >= ect.iat + clock_skew_tolerance:
@@ -806,14 +790,14 @@ function validate_dag(ect, ect_store, clock_skew_tolerance):
 
   // Step 3: Cycle detection (with traversal limit)
   visited = set()
-  result = has_cycle(ect.jti, ect.par, ect_store, visited,
+  result = has_cycle(ect.jti, ect.par, ledger, 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_jti, parent_ids, ect_store,
+function has_cycle(target_jti, parent_ids, ledger,
                    visited, max_depth):
   if visited.size() >= max_depth:
     return error("Maximum ancestor traversal limit exceeded")
@@ -823,9 +807,9 @@ function has_cycle(target_jti, parent_ids, ect_store,
     if parent_id in visited:
       continue
     visited.add(parent_id)
-    parent = ect_store.get(parent_id)
+    parent = ledger.get(parent_id)
     if parent is not null:
-      result = has_cycle(target_jti, parent.par, ect_store,
+      result = has_cycle(target_jti, parent.par, ledger,
                           visited, max_depth)
       if result is error or result is true:
         return result
@@ -901,10 +885,8 @@ verification steps in order:
 
 14. Perform DAG validation per {{dag-validation}}.
 
-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 ({{operational-modes}}), the verified ECT is retained
-    locally by the receiving agent.
+15. If all checks pass, the ECT MUST be appended to the audit
+    ledger.
 
 If any verification step fails, the ECT MUST be rejected and the
 failure MUST be logged for audit purposes.  Error messages
@@ -913,7 +895,7 @@ 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
+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
@@ -986,100 +968,27 @@ function verify_ect(ect_jws, verifier_id,
       return reject("Invalid pol_decision value")
 
   // Validate DAG (against ledger or inline parent ECTs)
-  result = validate_dag(payload, ect_store,
+  result = validate_dag(payload, ledger,
                          clock_skew_tolerance)
   if result is error:
     return reject("DAG validation failed")
 
-  // All checks passed
-  if ledger is available:
+  // All checks passed; append to ledger
   ledger.append(payload)
-  else:
-    // Point-to-point mode: retain locally
-    local_ect_cache.store(payload)
   return accept
 ~~~
 {: #fig-verification title="ECT Verification Pseudocode"}
 
-# Operational Modes {#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.
-
-## Point-to-Point Mode {#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 "jti" uniqueness check
-- The parent ECT chain grows with each hop, increasing HTTP
-  header size
-- 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.
-
-## Deferred Ledger Mode {#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.
-
-## Full Ledger Mode {#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.
-
 # Audit Ledger Interface {#ledger-interface}
 
-## 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
+defines required properties 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.
 
-## Required Properties
-
 An audit ledger implementation MUST provide:
 
 1.  Append-only semantics: Once an ECT is recorded, it MUST NOT be
@@ -1088,7 +997,7 @@ An audit ledger implementation MUST provide:
 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
+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
@@ -1098,34 +1007,6 @@ An audit ledger implementation MUST provide:
 The ledger SHOULD be maintained by an entity independent of the
 workflow agents to reduce the risk of collusion.
 
-## Ledger Entry Structure
-
-Each ledger entry is a logical record containing:
-
-~~~json
-{
-  "ledger_sequence": 42,
-  "ect_jti": "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"
-}
-~~~
-{: #fig-ledger-entry title="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.
-
 # Use Cases {#use-cases}
 
 This section describes representative use cases demonstrating how
@@ -1368,7 +1249,7 @@ 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
+there is no cryptographic evidence within a single ECT that the
 witnesses actually observed the task.  An issuing agent could
 list witnesses that did not participate.
 
@@ -1872,9 +1753,7 @@ A minimal conforming implementation needs to:
 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
-    {{operational-modes}}).
+5.  Append verified ECTs to the audit ledger.
 
 ## Storage Recommendations
 {:numbered="false"}