From 821a7f4570d964109203be70b85bc781c76519a1 Mon Sep 17 00:00:00 2001 From: Christian Nennemann Date: Tue, 24 Feb 2026 20:59:49 +0100 Subject: [PATCH] Add ledger-optional operational modes (point-to-point, deferred, full) ECTs can now be deployed without a centralized ledger. Three modes are defined: point-to-point (agents pass parent ECTs inline via HTTP headers), deferred ledger (collect ECTs in-flight, submit later), and full ledger (immediate append, RECOMMENDED for regulated environments). DAG validation is generalized to work against an "ECT store" which can be either a ledger or the set of inline parent ECTs received in the request. Co-Authored-By: Claude Opus 4.6 --- ...-nennemann-wimse-execution-context-00.html | 1241 ++++++++------- draft-nennemann-wimse-execution-context-00.md | 194 ++- ...t-nennemann-wimse-execution-context-00.txt | 970 +++++++----- ...t-nennemann-wimse-execution-context-00.xml | 1338 ++++++++++------- 4 files changed, 2241 insertions(+), 1502 deletions(-) diff --git a/draft-nennemann-wimse-execution-context-00.html b/draft-nennemann-wimse-execution-context-00.html index eb55c17..3cb16b6 100644 --- a/draft-nennemann-wimse-execution-context-00.html +++ b/draft-nennemann-wimse-execution-context-00.html @@ -1447,194 +1447,211 @@ regulatory frameworks.

  • -

    8.  Audit Ledger Interface

    +

    8.  Operational Modes

  • -

    9.  Use Cases

    +

    9.  Audit Ledger Interface

  • -

    10. Security Considerations

    +

    10. Use Cases

  • -

    11. Privacy Considerations

    +

    11. Security Considerations

  • -

    12. IANA Considerations

    +

    12. Privacy Considerations

  • -

    13. References

    +

    13. IANA Considerations

  • -

    Related Work

    +

    14. References

  • -

    Implementation Guidance

    +

    Related Work

  • -

    Regulatory Compliance Mapping

    -
    • -
  • -

    Examples

    +

    Implementation Guidance

    +
    • +
  • +

    Regulatory Compliance Mapping

  • -

    Acknowledgments

    +

    Examples

    +
  • -

    Author's Address

    +

    Acknowledgments

    +
    • +
  • +

    Author's Address

    • @@ -1752,7 +1769,11 @@ regulatory audit scenarios.

    An HTTP header for ECT transport (Section 5)

  • -

    Audit ledger interface requirements (Section 8)

    +

    Operational modes including ledger-optional deployment +(Section 8)

    +
    • +
  • +

    Audit ledger interface requirements (Section 9)

    • The following are out of scope and are handled by WIMSE:

    @@ -2236,7 +2257,7 @@ evaluated for this task (e.g.,

    REQUIRED. String. The result of the policy evaluation. MUST be one of the values registered in the ECT Policy Decision -Values registry (Section 12.4). Initial values +Values registry (Section 13.4). Initial values are:

    model_version:
    @@ -2368,10 +2389,10 @@ use SPIFFE ID format. Note that this claim is self-asserted by the ECT issuer; witnesses listed here do not co-sign this ECT. For stronger assurance, witnesses SHOULD submit independent signed ECTs to the ledger attesting to their observation (see -Section 10.2.1). In regulated environments, +Section 11.2.1). In regulated environments, implementations SHOULD use witness attestation for critical decision points to mitigate the risk of single-agent false -claims. See also Section 10.2 for the security +claims. See also Section 11.2 for the security implications of self-asserted witness claims.

    @@ -2397,7 +2418,7 @@ action. MUST be present if "compensation_required" i Values SHOULD use structured identifiers (e.g., "policy_violation_in_parent_trade") rather than free-form text to minimize the risk of embedding sensitive information. See -Section 11.2 for privacy guidance. +Section 12.2 for privacy guidance. If "compensation_reason" is present, "compensation_required" MUST be true.

    @@ -2549,6 +2570,12 @@ provides a cryptographically signed record of execution ordering, enabling auditors to reconstruct the complete workflow and verify that required predecessor tasks were recorded before dependent tasks.

    +

    DAG validation can be performed against an audit ledger (when +available) or against parent ECTs received inline via +Execution-Context headers (in point-to-point mode per +Section 8). The validation rules below use the term +"ECT store" to refer to either the ledger or the set of inline +parent ECTs available to the verifier.

    @@ -2562,14 +2589,15 @@ the following DAG validation steps:

    Task ID Uniqueness: The "tid" claim MUST be unique within the applicable scope (the workflow identified by "wid", or the -entire ledger if "wid" is absent). If a task with the same +entire ECT store if "wid" is absent). If a task with the same "tid" already exists, the ECT MUST be rejected.

  • Parent Existence: Every task identifier listed in the "par" -array MUST correspond to a task that has been previously -recorded in the ledger. If any parent task is not found, the -ECT MUST be rejected.

    +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.

  • Temporal Ordering: The "iat" value of every parent task MUST NOT be greater than the "iat" value of the current task plus a @@ -2578,7 +2606,7 @@ 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 ledger), not by +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.

    • @@ -2614,14 +2642,15 @@ relationship has been established. 
    -function validate_dag(ect, ledger, clock_skew_tolerance):
+function validate_dag(ect, ect_store, clock_skew_tolerance):
+  // ect_store: ledger or local cache of verified ECTs
   // Step 1: Uniqueness check
-  if ledger.contains(ect.tid, ect.wid):
-    return error("Task ID already exists in ledger")
+  if ect_store.contains(ect.tid, ect.wid):
+    return error("Task ID already exists")
 
   // Step 2: Parent existence and temporal ordering
   for parent_id in ect.par:
-    parent = ledger.get(parent_id)
+    parent = ect_store.get(parent_id)
     if parent is null:
       return error("Parent task not found: " + parent_id)
     if parent.iat >= ect.iat + clock_skew_tolerance:
@@ -2629,15 +2658,15 @@ function validate_dag(ect, ledger, clock_skew_tolerance):
 
   // Step 3: Cycle detection (with traversal limit)
   visited = set()
-  result = has_cycle(ect.tid, ect.par, ledger, visited,
+  result = has_cycle(ect.tid, ect.par, ect_store, visited,
                       max_ancestor_limit)
   if result is error or result is true:
     return error("Circular dependency or depth limit exceeded")
 
   return success
 
-function has_cycle(target_tid, parent_ids, ledger, visited,
-                   max_depth):
+function has_cycle(target_tid, parent_ids, ect_store,
+                   visited, max_depth):
   if visited.size() >= max_depth:
     return error("Maximum ancestor traversal limit exceeded")
   for parent_id in parent_ids:
@@ -2646,9 +2675,9 @@ function has_cycle(target_tid, parent_ids, ledger, visited,
     if parent_id in visited:
       continue
     visited.add(parent_id)
-    parent = ledger.get(parent_id)
+    parent = ect_store.get(parent_id)
     if parent is not null:
-      result = has_cycle(target_tid, parent.par, ledger,
+      result = has_cycle(target_tid, parent.par, ect_store,
                           visited, max_depth)
       if result is error or result is true:
         return result
@@ -2750,8 +2779,10 @@ verifier's current time, to account for clock skew).Perform DAG validation per Section 6.
    
 
           
  • 
-            
    If all checks pass, the ECT MUST be appended to the audit
-ledger.
    
+            
    If all checks pass and an audit ledger is available, the ECT
+SHOULD be appended to the audit ledger.  In point-to-point
+mode (Section 8), the verified ECT is retained
+locally by the receiving agent.
    
 
    • 
         
 
    If any verification step fails, the ECT MUST be rejected and the
@@ -2837,14 +2868,18 @@ function verify_ect(ect_jws, verifier_id,
      ["approved", "rejected", "pending_human_review"]:
     return reject("Invalid pol_decision value")
 
-  // Validate DAG
-  result = validate_dag(payload, ledger,
+  // Validate DAG (against ledger or inline parent ECTs)
+  result = validate_dag(payload, ect_store,
                          clock_skew_tolerance)
   if result is error:
     return reject("DAG validation failed")
 
-  // All checks passed; append to ledger
-  ledger.append(payload)
+  // All checks passed
+  if ledger is available:
+    ledger.append(payload)
+  else:
+    // Point-to-point mode: retain locally
+    local_ect_cache.store(payload)
   return accept
    @@ -2856,63 +2891,155 @@ function verify_ect(ect_jws, verifier_id,
    -
    +
    +

    +8. Operational Modes +

    +

    ECTs can be deployed in three operational modes depending on the +availability and requirements of the deployment environment. All +modes use the same ECT format and verification procedure; they +differ in how parent ECTs are resolved during DAG validation and +where verified ECTs are stored.

    +
    +
    +

    +8.1. Point-to-Point Mode +

    +

    In point-to-point mode, agents pass parent ECTs directly to +downstream agents via multiple Execution-Context HTTP headers. +No centralized ledger is required. The receiving agent verifies +each parent ECT independently and validates the DAG against the +set of ECTs received in the request.

    +

    This mode is suitable for:

    +
      +
    • +

      Cross-organizational workflows where no shared ledger exists

      +
      • +
    • +

      Lightweight deployments where infrastructure is constrained

      +
      • +
    • +

      Early adoption scenarios before ledger infrastructure is +available

      +
      • +
    +

    Limitations of point-to-point mode:

    +
      +
    • +

      No persistent audit trail unless agents independently retain +ECTs

      +
      • +
    • +

      Global replay detection relies solely on "jti" caches at each +agent; there is no centralized "tid" uniqueness check

      +
      • +
    • +

      The parent ECT chain grows with each hop, increasing HTTP +header size

      +
      • +
    • +

      Post-hoc audit reconstruction requires collecting ECTs from +multiple agents

      +
      • +
    +

    Agents operating in point-to-point mode MUST retain verified +parent ECTs for at least the duration of the workflow to support +DAG validation of downstream requests. Agents SHOULD persist +ECTs locally for audit purposes even when no centralized ledger +is available.

    +
    +
    +
    +
    +

    +8.2. Deferred Ledger Mode +

    +

    In deferred ledger mode, agents create and verify ECTs in-flight +using point-to-point delivery, and submit collected ECTs to an +audit ledger after the workflow completes or at periodic intervals.

    +

    This mode decouples real-time workflow execution from ledger +availability. DAG validation during execution uses inline parent +ECTs; full DAG validation against the complete workflow is +performed at ledger submission time.

    +

    Agents MUST include all collected ECTs when submitting to the +ledger. The ledger MUST re-validate the complete DAG upon +submission.

    +
    +
    +
    +
    +

    +8.3. Full Ledger Mode +

    +

    In full ledger mode, every verified ECT is immediately appended +to an audit ledger. DAG validation is performed against the +ledger, which serves as the authoritative ECT store. This is +the RECOMMENDED mode for regulated environments where persistent, +centralized audit trails are required.

    +
    +
    +
    +
    +
    +

    -8. Audit Ledger Interface +9. Audit Ledger Interface

    -
    +

    -8.1. Overview +9.1. Overview

    -

    ECTs are designed to be recorded in an immutable audit ledger for +

    Use of an audit ledger is RECOMMENDED for regulated environments +and any deployment requiring persistent, centralized audit trails. +ECTs are designed to be recorded in an immutable audit ledger for compliance verification and post-hoc analysis. This specification defines the logical interface for the ledger but does not mandate a specific storage technology. Implementations MAY use append-only logs, databases with cryptographic commitment schemes, distributed ledgers, or any storage mechanism that provides the -required properties.

    +required properties.

    -
    +

    -8.2. Required Properties +9.2. Required Properties

    -

    An audit ledger implementation MUST provide:

    -
      -
    1. -

      Append-only semantics: Once an ECT is recorded, it MUST NOT be -modified or deleted.

      +

      An audit ledger implementation MUST provide:

      +
        +
      1. +

        Append-only semantics: Once an ECT is recorded, it MUST NOT be +modified or deleted.

        2. -
      2. -

        Ordering: The ledger MUST maintain a total ordering of ECT -entries via a monotonically increasing sequence number.

        +
      3. +

        Ordering: The ledger MUST maintain a total ordering of ECT +entries via a monotonically increasing sequence number.

        4. -
      4. -

        Lookup by task ID: The ledger MUST support efficient retrieval -of ECT entries by "tid" value.

        +
      5. +

        Lookup by task ID: The ledger MUST support efficient retrieval +of ECT entries by "tid" value.

        6. -
      6. -

        Integrity verification: The ledger SHOULD provide a mechanism +

      7. +

        Integrity verification: The ledger SHOULD provide a mechanism to verify that no entries have been tampered with (e.g., -hash chains or Merkle trees).

        +hash chains or Merkle trees).

      -

      The ledger SHOULD be maintained by an entity independent of the -workflow agents to reduce the risk of collusion.

      +

      The ledger SHOULD be maintained by an entity independent of the +workflow agents to reduce the risk of collusion.

    -
    +

    -8.3. Ledger Entry Structure +9.3. Ledger Entry Structure

    -

    Each ledger entry is a logical record containing:

    +

    Each ledger entry is a logical record containing:

    -
    + 
     {
   "ledger_sequence": 42,
@@ -2931,45 +3058,45 @@ workflow agents to reduce the risk of collusion.Ledger Entry Example
    -

    The "ect_jws" field contains the full JWS Compact Serialization +

    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.

    +the authoritative JWS and the indexed fields.

    -
    +

    -9. Use Cases +10. Use Cases

    -

    This section describes representative use cases demonstrating how +

    This section describes representative use cases demonstrating how ECTs provide execution records in regulated environments. These examples demonstrate ECT mechanics; production deployments would include additional domain-specific requirements beyond the scope -of this specification.

    -

    Note: task identifiers in this section are abbreviated for +of this specification.

    +

    Note: task identifiers in this section are abbreviated for readability. In production, all "tid" values are required to be -UUIDs per Section 4.2.2.

    +UUIDs per Section 4.2.2.

    -
    +

    -9.1. Medical Device SDLC Workflow +10.1. Medical Device SDLC Workflow

    -

    In a medical device software development lifecycle (SDLC), +

    In a medical device software development lifecycle (SDLC), AI agents assist across multiple phases from requirements analysis through release approval. Regulatory frameworks including [FDA-21CFR11] Section 11.10(e) and [EU-MDR] require audit trails documenting the complete development process for -software used in medical devices.

    +software used in medical devices.

    -
    + 
     Agent A (Spec Reviewer):
   tid: task-001    par: []
@@ -3003,24 +3130,24 @@ Human Release Manager:
 Medical Device SDLC Workflow
    -

    ECTs record that requirements were reviewed before implementation +

    ECTs record that requirements were reviewed before implementation began, that tests were executed against the implemented code, that the build artifact was validated, and that a human release manager explicitly approved the release. The DAG structure ensures no -phase was skipped or reordered.

    +phase was skipped or reordered.

    -
    +

    -9.1.1. FDA Audit with DAG Reconstruction +10.1.1. FDA Audit with DAG Reconstruction

    -

    During a regulatory audit, an FDA reviewer requests evidence of +

    During a regulatory audit, an FDA reviewer requests evidence of the development process for a specific software release. The auditing authority retrieves all ECTs sharing the same workflow identifier ("wid") from the audit ledger and reconstructs the -complete DAG:

    +complete DAG:

    -
    + 
     task-001 (review_requirements_spec)
   |
@@ -3041,42 +3168,42 @@ task-005 (approve_release) [human, witnessed]
 Reconstructed DAG for FDA Audit
    -

    The reconstructed DAG provides cryptographic evidence that:

    +

    The reconstructed DAG provides cryptographic evidence that:

      -
    • -

      Each phase was executed by an identified and authenticated agent.

      +
    • +

      Each phase was executed by an identified and authenticated agent.

      • -
    • -

      Policy checkpoints were evaluated at every phase transition.

      +
    • +

      Policy checkpoints were evaluated at every phase transition.

      • -
    • -

      The execution sequence was maintained (no step was bypassed).

      +
    • +

      The execution sequence was maintained (no step was bypassed).

      • -
    • -

      A human-in-the-loop approved the final release, with independent -witness attestation.

      +
    • +

      A human-in-the-loop approved the final release, with independent +witness attestation.

      • -
    • -

      Timestamps and execution durations are recorded for each step.

      +
    • +

      Timestamps and execution durations are recorded for each step.

    -

    This can contribute to compliance with:

    +

    This can contribute to compliance with:

      -
    • -

      [FDA-21CFR11] Section 11.10(e): Computer-generated audit trails -that record the date, time, and identity of the operator.

      +
    • +

      [FDA-21CFR11] Section 11.10(e): Computer-generated audit trails +that record the date, time, and identity of the operator.

      • -
    • -

      [EU-MDR] Annex II: Technical documentation traceability for the -software development lifecycle.

      +
    • +

      [EU-MDR] Annex II: Technical documentation traceability for the +software development lifecycle.

      • -
    • -

      [EU-AI-ACT] Article 12: Automatic logging capabilities for -high-risk AI systems involved in the development process.

      +
    • +

      [EU-AI-ACT] Article 12: Automatic logging capabilities for +high-risk AI systems involved in the development process.

      • -
    • -

      [EU-AI-ACT] Article 14: ECTs can record evidence that human -oversight events occurred during the release process.

      +
    • +

      [EU-AI-ACT] Article 14: ECTs can record evidence that human +oversight events occurred during the release process.

    @@ -3084,17 +3211,17 @@ oversight events occurred during the release process. -
    +

    -9.2. Financial Trading Workflow +10.2. Financial Trading Workflow

    -

    In a financial trading workflow, agents perform risk assessment, +

    In a financial trading workflow, agents perform risk assessment, compliance verification, and trade execution. The DAG structure records that compliance checks were evaluated before trade -execution.

    +execution.

    -
    + 
     Agent A (Risk Assessment):
   tid: task-001    par: []
@@ -3116,33 +3243,33 @@ Agent C (Execution):
 Financial Trading Workflow
    -

    This can contribute to compliance with:

    +

    This can contribute to compliance with:

      -
    • -

      [MIFID-II]: ECTs provide cryptographic records of the execution -sequence that can support transaction audit requirements.

      +
    • +

      [MIFID-II]: ECTs provide cryptographic records of the execution +sequence that can support transaction audit requirements.

      • -
    • -

      [DORA] Article 12: ECTs contribute to ICT activity logging.

      +
    • +

      [DORA] Article 12: ECTs contribute to ICT activity logging.

      • -
    • -

      [EU-AI-ACT] Article 12: Logging of decisions made by AI-driven -systems.

      +
    • +

      [EU-AI-ACT] Article 12: Logging of decisions made by AI-driven +systems.

    -
    +

    -9.3. Compensation and Rollback +10.3. Compensation and Rollback

    -

    When a compliance violation is discovered after execution, ECTs +

    When a compliance violation is discovered after execution, ECTs provide a mechanism to record authorized compensation actions with -a cryptographic link to the original task:

    +a cryptographic link to the original task:

    -
    + 
     {
   "iss": "spiffe://bank.example/agent/operations",
@@ -3150,6 +3277,7 @@ a cryptographic link to the original task:Compensation ECT Example
    -

    The "par" claim links the compensation action to the original +

    The "par" claim links the compensation action to the original trade, creating an auditable chain from execution through -violation discovery to remediation.

    +violation discovery to remediation.

    -
    +

    -9.4. Autonomous Logistics Coordination +10.4. Autonomous Logistics Coordination

    -

    In a logistics workflow, multiple compliance checks complete +

    In a logistics workflow, multiple compliance checks complete before shipment commitment. The DAG structure records that all -required checks were completed:

    +required checks were completed:

    -
    + 
     Agent A (Route Planning):
   tid: task-001    par: []
@@ -3213,72 +3341,72 @@ System (Commitment):
 Logistics Workflow with Parallel Tasks
    -

    Note that tasks 002 and 003 both depend only on task-001 and can +

    Note that tasks 002 and 003 both depend only on task-001 and can execute in parallel. Task 004 depends on both, demonstrating the -DAG's ability to represent parallel execution with a join point.

    +DAG's ability to represent parallel execution with a join point.

    -
    +

    -10. Security Considerations +11. Security Considerations

    -

    This section addresses security considerations following the -guidance in [RFC3552].

    +

    This section addresses security considerations following the +guidance in [RFC3552].

    -
    +

    -10.1. Threat Model +11.1. Threat Model

    -

    The following threat actors are considered:

    +

    The following threat actors are considered:

      -
    • -

      Malicious agent (insider threat): An agent within the trust -domain that intentionally creates false ECT claims.

      +
    • +

      Malicious agent (insider threat): An agent within the trust +domain that intentionally creates false ECT claims.

      • -
    • -

      Compromised agent (external attacker): An agent whose private -key has been obtained by an external attacker.

      +
    • +

      Compromised agent (external attacker): An agent whose private +key has been obtained by an external attacker.

      • -
    • -

      Ledger tamperer: An entity attempting to modify or delete ledger -entries after they have been recorded.

      +
    • +

      Ledger tamperer: An entity attempting to modify or delete ledger +entries after they have been recorded.

      • -
    • -

      Time manipulator: An entity attempting to manipulate timestamps -to alter perceived execution ordering.

      +
    • +

      Time manipulator: An entity attempting to manipulate timestamps +to alter perceived execution ordering.

    -
    +

    -10.2. Self-Assertion Limitation +11.2. Self-Assertion Limitation

    -

    ECTs are self-asserted by the executing agent. The agent claims +

    ECTs are self-asserted by the executing agent. The agent claims what it did, and this claim is signed with its private key. A compromised or malicious agent could create ECTs with false claims (e.g., setting "pol_decision" to "approved" without actually -evaluating the policy).

    -

    ECTs do not independently verify that:

    +evaluating the policy).

    +

    ECTs do not independently verify that:

      -
    • -

      The claimed execution actually occurred as described

      +
    • +

      The claimed execution actually occurred as described

      • -
    • -

      The policy evaluation was correctly performed

      +
    • +

      The policy evaluation was correctly performed

      • -
    • -

      The input/output hashes correspond to the actual data processed

      +
    • +

      The input/output hashes correspond to the actual data processed

      • -
    • -

      The agent faithfully performed the stated action

      +
    • +

      The agent faithfully performed the stated action

    -

    The trustworthiness of ECT claims depends on the trustworthiness +

    The trustworthiness of ECT claims depends on the trustworthiness of the signing agent. To mitigate single-agent false claims, regulated environments SHOULD use the "witnessed_by" mechanism to include independent third-party observers at critical decision @@ -3286,306 +3414,306 @@ points. However, the "witnessed_by" claim is self-asserted by the ECT issuer: the listed witnesses do not co-sign the ECT and there is no cryptographic proof within a single ECT that the witnesses actually observed the task. An issuing agent could -list witnesses that did not participate.

    +list witnesses that did not participate.

    -
    +

    -10.2.1. Witness Attestation Model +11.2.1. Witness Attestation Model

    -

    To address the self-assertion limitation of the "witnessed_by" +

    To address the self-assertion limitation of the "witnessed_by" claim, witnesses SHOULD submit their own independent signed ECTs to the audit ledger attesting to the observed task. A witness -attestation ECT:

    +attestation ECT:

      -
    • -

      MUST set "iss" to the witness's own workload identity.

      +
    • +

      MUST set "iss" to the witness's own workload identity.

      • -
    • -

      MUST set "exec_act" to "witness_attestation" (or a domain- -specific equivalent).

      +
    • +

      MUST set "exec_act" to "witness_attestation" (or a domain- +specific equivalent).

      • -
    • -

      MUST include the observed task's "tid" in the "par" array, -linking the attestation to the original task.

      +
    • +

      MUST include the observed task's "tid" in the "par" array, +linking the attestation to the original task.

      • -
    • -

      MUST set "pol_decision" to "approved" to indicate the witness -confirms the observation.

      +
    • +

      MUST set "pol_decision" to "approved" to indicate the witness +confirms the observation.

    -

    When a task's "witnessed_by" claim lists one or more witnesses, +

    When a task's "witnessed_by" claim lists one or more witnesses, auditors SHOULD verify that corresponding witness attestation ECTs exist in the ledger for each listed witness. A mismatch between the "witnessed_by" list and the set of independent witness -ECTs in the ledger SHOULD be flagged during audit review.

    -

    This model converts witness attestation from a self-asserted claim +ECTs in the ledger SHOULD be flagged during audit review.

    +

    This model converts witness attestation from a self-asserted claim to a cryptographically verifiable property of the ledger: the witness independently signs their own ECT using their own key, and the ledger records both the original task ECT and the witness -attestation ECTs.

    +attestation ECTs.

    -
    +

    -10.3. Organizational Prerequisites +11.3. Organizational Prerequisites

    -

    ECTs operate within a broader trust framework. The guarantees +

    ECTs operate within a broader trust framework. The guarantees provided by ECTs are only meaningful when the following -organizational controls are in place:

    +organizational controls are in place:

      -
    • -

      Key management governance: Controls over who provisions agent -keys and how keys are protected.

      +
    • +

      Key management governance: Controls over who provisions agent +keys and how keys are protected.

      • -
    • -

      Ledger integrity governance: The ledger is maintained by an -entity independent of the workflow agents.

      +
    • +

      Ledger integrity governance: The ledger is maintained by an +entity independent of the workflow agents.

      • -
    • -

      Policy lifecycle management: Policy identifiers in ECTs map to -actual, validated policy rules.

      +
    • +

      Policy lifecycle management: Policy identifiers in ECTs map to +actual, validated policy rules.

      • -
    • -

      Agent deployment governance: Agents are deployed and maintained -in a manner that preserves their integrity.

      +
    • +

      Agent deployment governance: Agents are deployed and maintained +in a manner that preserves their integrity.

    -
    +

    -10.4. Signature Verification +11.4. Signature Verification

    -

    ECTs MUST be signed with the agent's private key using JWS +

    ECTs MUST be signed with the agent's private key using JWS [RFC7515]. The signature algorithm MUST match the algorithm specified in the agent's WIT. Receivers MUST verify the ECT signature against the WIT public key before processing any claims. Receivers MUST verify that the signing key has not been revoked within the trust domain (see step 6 in -Section 7).

    -

    If signature verification fails or if the signing key has been +Section 7).

    +

    If signature verification fails or if the signing key has been revoked, the ECT MUST be rejected entirely and the failure MUST -be logged.

    -

    Implementations MUST use established JWS libraries and MUST NOT -implement custom signature verification.

    +be logged.

    +

    Implementations MUST use established JWS libraries and MUST NOT +implement custom signature verification.

    -
    +

    -10.5. Replay Attack Prevention +11.5. Replay Attack Prevention

    -

    ECTs include short expiration times (RECOMMENDED: 5-15 minutes) to +

    ECTs include short expiration times (RECOMMENDED: 5-15 minutes) to limit the window for replay attacks. The "aud" claim restricts replay to unintended recipients: an ECT intended for Agent B will be rejected by Agent C. The "iat" claim enables receivers to -reject ECTs that are too old, even if not yet expired.

    -

    The DAG structure provides additional replay protection: an ECT +reject ECTs that are too old, even if not yet expired.

    +

    The DAG structure provides additional replay protection: an ECT referencing parent tasks that already have a recorded child task -with the same action can be flagged as a potential replay.

    -

    Implementations MUST maintain a cache of recently-seen "jti" +with the same action can be flagged as a potential replay.

    +

    Implementations MUST maintain a cache of recently-seen "jti" values to detect replayed ECTs within the expiration window. -An ECT with a duplicate "jti" value MUST be rejected.

    +An ECT with a duplicate "jti" value MUST be rejected.

    -
    +

    -10.6. Man-in-the-Middle Protection +11.6. Man-in-the-Middle Protection

    -

    ECTs do not replace transport-layer security. ECTs MUST be +

    ECTs do not replace transport-layer security. ECTs MUST be transmitted over TLS or mTLS connections. When used with the WIMSE service-to-service protocol [I-D.ietf-wimse-s2s-protocol], transport security is already established. HTTP Message Signatures -[RFC9421] provide an alternative channel binding mechanism.

    -

    The defense-in-depth model provides:

    +[RFC9421] provide an alternative channel binding mechanism.

    +

    The defense-in-depth model provides:

      -
    • -

      TLS/mTLS (transport layer): Prevents network-level tampering.

      +
    • +

      TLS/mTLS (transport layer): Prevents network-level tampering.

      • -
    • -

      WIT/WPT (WIMSE identity layer): Proves agent identity and -request authorization.

      +
    • +

      WIT/WPT (WIMSE identity layer): Proves agent identity and +request authorization.

      • -
    • -

      ECT (execution accountability layer): Records what the agent did -and under what policy.

      +
    • +

      ECT (execution accountability layer): Records what the agent did +and under what policy.

    -
    +

    -10.7. Key Compromise +11.7. Key Compromise

    -

    If an agent's private key is compromised, an attacker can forge +

    If an agent's private key is compromised, an attacker can forge ECTs that appear to originate from that agent. To mitigate this -risk:

    +risk:

      -
    • -

      Implementations SHOULD use short-lived keys and rotate them -frequently (hours to days, not months).

      +
    • +

      Implementations SHOULD use short-lived keys and rotate them +frequently (hours to days, not months).

      • -
    • -

      Private keys SHOULD be stored in Hardware Security Modules (HSMs) -or equivalent secure key storage.

      +
    • +

      Private keys SHOULD be stored in Hardware Security Modules (HSMs) +or equivalent secure key storage.

      • -
    • -

      Trust domains MUST support rapid key revocation.

      +
    • +

      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.

      +
    • +

      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 +

    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.

    +for audit purposes.

    -
    +

    -10.8. Collusion and False Claims +11.8. Collusion and False Claims

    -

    A single malicious agent cannot forge parent task references +

    A single malicious agent cannot forge parent task references because DAG validation requires parent tasks to exist in the ledger. However, multiple colluding agents could potentially -create a false execution history if they control the ledger.

    -

    Mitigations include:

    +create a false execution history if they control the ledger.

    +

    Mitigations include:

      -
    • -

      Independent ledger maintenance: The ledger SHOULD be maintained -by an entity independent of the workflow agents.

      +
    • +

      Independent ledger maintenance: The ledger SHOULD be maintained +by an entity independent of the workflow agents.

      • -
    • -

      Witness attestation: Using the "witnessed_by" claim to include -independent third-party observers.

      +
    • +

      Witness attestation: Using the "witnessed_by" claim to include +independent third-party observers.

      • -
    • -

      Cross-verification: Multiple independent ledger replicas can be -compared for consistency.

      +
    • +

      Cross-verification: Multiple independent ledger replicas can be +compared for consistency.

      • -
    • -

      Out-of-band audit: External auditors periodically verify ledger -contents against expected workflow patterns.

      +
    • +

      Out-of-band audit: External auditors periodically verify ledger +contents against expected workflow patterns.

    -
    +

    -10.9. Denial of Service +11.9. Denial of Service

    -

    ECT signature verification is computationally inexpensive +

    ECT signature verification is computationally inexpensive (approximately 1ms per ECT on modern hardware for ES256). DAG validation complexity is O(V) where V is the number of ancestor nodes reachable from the parent references; for typical shallow -DAGs this is efficient.

    -

    Implementations SHOULD apply rate limiting at the API layer to +DAGs this is efficient.

    +

    Implementations SHOULD apply rate limiting at the API layer to prevent excessive ECT submissions. DAG validation SHOULD be performed after signature verification to avoid wasting resources -on unsigned or incorrectly signed tokens.

    +on unsigned or incorrectly signed tokens.

    -
    +

    -10.10. Timestamp Accuracy +11.10. Timestamp Accuracy

    -

    ECTs rely on timestamps ("iat", "exp") for temporal ordering. +

    ECTs rely on timestamps ("iat", "exp") for temporal ordering. Clock skew between agents can lead to incorrect ordering judgments. Implementations SHOULD use synchronized time sources (e.g., NTP) and SHOULD allow a configurable clock skew tolerance -(RECOMMENDED: 30 seconds).

    -

    Cross-organizational deployments where agents span multiple trust +(RECOMMENDED: 30 seconds).

    +

    Cross-organizational deployments where agents span multiple trust domains with independent time sources MAY require a higher clock skew tolerance. Deployments using trust domain federation SHOULD document their configured clock skew tolerance value and SHOULD -ensure all participating trust domains agree on a common tolerance.

    -

    The temporal ordering check in DAG validation incorporates the +ensure all participating trust domains agree on a common tolerance.

    +

    The temporal ordering check in DAG validation incorporates the clock skew tolerance to account for minor clock differences -between agents.

    +between agents.

    -
    +

    -10.11. ECT Size Constraints +11.11. ECT Size Constraints

    -

    ECTs with many parent tasks or large extension objects can +

    ECTs with many parent tasks or large extension objects can increase HTTP header size. Implementations SHOULD limit the "par" array to a maximum of 256 entries. Workflows requiring more parent references SHOULD introduce intermediate aggregation tasks. The "ext" object SHOULD NOT exceed 4096 bytes when serialized as JSON and SHOULD NOT exceed a nesting depth of -5 levels (see also Section 4.2.8).

    +5 levels (see also Section 4.2.8).

    -
    +

    -11. Privacy Considerations +12. Privacy Considerations

    -
    +

    -11.1. Data Exposure in ECTs +12.1. Data Exposure in ECTs

    -

    ECTs necessarily reveal:

    +

    ECTs necessarily reveal:

      -
    • -

      Agent identities ("iss", "aud") for accountability purposes

      +
    • +

      Agent identities ("iss", "aud") for accountability purposes

      • -
    • -

      Action descriptions ("exec_act") for audit trail completeness

      +
    • +

      Action descriptions ("exec_act") for audit trail completeness

      • -
    • -

      Policy evaluation outcomes ("pol", "pol_decision") for -compliance verification

      +
    • +

      Policy evaluation outcomes ("pol", "pol_decision") for +compliance verification

      • -
    • -

      Timestamps ("iat", "exp") for temporal ordering

      +
    • +

      Timestamps ("iat", "exp") for temporal ordering

    -

    ECTs are designed to NOT reveal:

    +

    ECTs are designed to NOT reveal:

      -
    • -

      Actual input or output data values (replaced with cryptographic -hashes via "inp_hash" and "out_hash")

      +
    • +

      Actual input or output data values (replaced with cryptographic +hashes via "inp_hash" and "out_hash")

      • -
    • -

      Internal computation details or intermediate steps

      +
    • +

      Internal computation details or intermediate steps

      • -
    • -

      Proprietary algorithms or intellectual property

      +
    • +

      Proprietary algorithms or intellectual property

      • -
    • -

      Personally identifiable information (PII)

      +
    • +

      Personally identifiable information (PII)

    -
    +

    -11.2. Data Minimization +12.2. Data Minimization

    -

    Implementations SHOULD minimize the information included in ECTs. +

    Implementations SHOULD minimize the information included in ECTs. The "exec_act" claim SHOULD use structured identifiers (e.g., "process_payment") rather than natural language descriptions. The "pol" claim SHOULD reference policy identifiers rather than -embedding policy content.

    -

    The "compensation_reason" claim (Section 4.2.7) +embedding policy content.

    +

    The "compensation_reason" claim (Section 4.2.7) deserves particular attention: because it is human-readable and may describe the circumstances of a failure or policy violation, it risks exposing sensitive operational details. Implementations @@ -3593,167 +3721,167 @@ it risks exposing sensitive operational details. Implementations "policy_violation_in_parent_trade") rather than free-form natural language explanations. Implementers SHOULD review "compensation_reason" values for potential information leakage -before deploying to production.

    +before deploying to production.

    -
    +

    -11.3. Storage and Access Control +12.3. Storage and Access Control

    -

    ECTs stored in audit ledgers SHOULD be access-controlled so that +

    ECTs stored in audit ledgers SHOULD be access-controlled so that only authorized auditors and regulators can read them. Implementations SHOULD consider encryption at rest for ledger -storage containing sensitive regulatory data.

    -

    Full input and output data (corresponding to the hashes in ECTs) +storage containing sensitive regulatory data.

    +

    Full input and output data (corresponding to the hashes in ECTs) SHOULD be stored separately from the ledger with additional access controls, since auditors may need to verify hash correctness but -general access to the data values is not needed.

    +general access to the data values is not needed.

    -
    +

    -11.4. Regulatory Access +12.4. Regulatory Access

    -

    ECTs are designed for interpretation by qualified human auditors +

    ECTs are designed for interpretation by qualified human auditors and regulators. ECTs provide structural records of execution ordering and policy evaluation; they are not intended for public -disclosure.

    +disclosure.

    -
    +

    -12. IANA Considerations +13. IANA Considerations

    -
    +

    -12.1. Media Type Registration +13.1. Media Type Registration

    -

    This document requests registration of the following media type -in the "Media Types" registry maintained by IANA:

    -
    -
    Type name:
    -
    -

    application

    +

    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

    +
    Subtype name:
    +
    +

    wimse-exec+jwt

    -
    Required parameters:
    -
    -

    none

    +
    Required parameters:
    +
    +

    none

    -
    Optional parameters:
    -
    -

    none

    +
    Optional parameters:
    +
    +

    none

    -
    Encoding considerations:
    -
    -

    8bit; an ECT is a JWT that is a JWS using the Compact +

    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.

    +separated by period characters.

    -
    Security considerations:
    -
    -

    See the Security Considerations section of this document.

    +
    Security considerations:
    +
    +

    See the Security Considerations section of this document.

    -
    Interoperability considerations:
    -
    -

    none

    +
    Interoperability considerations:
    +
    +

    none

    -
    Published specification:
    -
    -

    This document

    +
    Published specification:
    +
    +

    This document

    -
    Applications that use this media type:
    -
    -

    Applications that implement regulated agentic workflows requiring -execution context tracing and audit trails.

    +
    Applications that use this media type:
    +
    +

    Applications that implement regulated agentic workflows requiring +execution context tracing and audit trails.

    -
    Additional information:
    -
    -

    Magic number(s): none +

    Additional information:
    +
    +

    Magic number(s): none File extension(s): none -Macintosh file type code(s): none

    +Macintosh file type code(s): none

    -
    Person and email address to contact for further information:
    -
    -

    Christian Nennemann, ietf@nennemann.de

    +
    Person and email address to contact for further information:
    +
    +

    Christian Nennemann, ietf@nennemann.de

    -
    Intended usage:
    -
    -

    COMMON

    +
    Intended usage:
    +
    +

    COMMON

    -
    Restrictions on usage:
    -
    -

    none

    +
    Restrictions on usage:
    +
    +

    none

    -
    Author:
    -
    -

    Christian Nennemann

    +
    Author:
    +
    +

    Christian Nennemann

    -
    Change controller:
    -
    -

    IETF

    +
    Change controller:
    +
    +

    IETF

    -
    +

    -12.2. HTTP Header Field Registration +13.2. HTTP Header Field Registration

    -

    This document requests registration of the following header field +

    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

    +maintained by IANA:

    +
    +
    Field name:
    +
    +

    Execution-Context

    -
    Status:
    -
    -

    permanent

    +
    Status:
    +
    +

    permanent

    -
    Specification document:
    -
    -

    This document, Section 5

    +
    Specification document:
    +
    +

    This document, Section 5

    -
    +

    -12.3. JWT Claims Registration +13.3. JWT Claims Registration

    -

    This document requests registration of the following claims in -the "JSON Web Token Claims" registry maintained by IANA:

    +

    This document requests registration of the following claims in +the "JSON Web Token Claims" registry maintained by IANA:

    @@ -3919,14 +4047,14 @@ the "JSON Web Token Claims" registry maintained by IANA: -
    +

    -12.4. ECT Policy Decision Values Registry +13.4. ECT Policy Decision Values Registry

    -

    This document establishes the "ECT Policy Decision Values" +

    This document establishes the "ECT Policy Decision Values" registry under the "JSON Web Token (JWT)" group. Registration -policy is Specification Required per [RFC8126].

    -

    The initial contents of the registry are:

    +policy is Specification Required per [RFC8126].

    +

    The initial contents of the registry are:

    @@ -3972,14 +4100,14 @@ policy is Specification Required per [
    -
    +

    -12.5. ECT Regulated Domain Values Registry +13.5. ECT Regulated Domain Values Registry

    -

    This document establishes the "ECT Regulated Domain Values" +

    This document establishes the "ECT Regulated Domain Values" registry under the "JSON Web Token (JWT)" group. Registration -policy is Specification Required per [RFC8126].

    -

    The initial contents of the registry are:

    +policy is Specification Required per [RFC8126].

    +

    The initial contents of the registry are:

    @@ -4027,14 +4155,14 @@ policy is Specification Required per [
    -
    +

    -13. References +14. References

    -
    +

    -13.1. Normative References +14.1. Normative References

    [I-D.ietf-wimse-arch]
    @@ -4085,9 +4213,9 @@ policy is Specification Required per [
    -
    +

    -13.2. Informative References +14.2. Informative References

    [DORA]
    @@ -4106,6 +4234,14 @@ policy is Specification Required per [ U.S. Food and Drug Administration, "Title 21, Code of Federal Regulations, Part 11: Electronic Records; Electronic Signatures", <https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11>.
    +
    [I-D.ietf-oauth-transaction-tokens]
    +
    +Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-07>.
    +
    +
    [I-D.ietf-oauth-transaction-tokens-for-agents]
    +
    +"*** BROKEN REFERENCE ***".
    +
    [I-D.ietf-scitt-architecture]
    Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture-22, , <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-22>.
    @@ -4162,26 +4298,79 @@ evaluated?" Together they form an identity-plus-accountability framework for regulated agentic systems.

    -
    +
    -

    -OAuth 2.0 Token Exchange +

    +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. -ECTs intentionally use the distinct claim name "exec_act" for the -action/task type to avoid collision with the "act" claim. -Transaction tokens in OAuth establish API authorization context; -ECTs serve the complementary purpose of recording execution -accountability across multi-step workflows.

    +The "act" claim creates nested JSON objects representing a +delegation chain: "who is acting on behalf of whom." While +the nesting superficially resembles a chain, it is strictly +linear (each "act" object contains at most one nested "act"), +represents authorization delegation rather than task execution, +and carries no task identifiers, policy decisions, or +input/output integrity data. The "act" chain cannot represent +branching (fan-out) or convergence (fan-in) and therefore +cannot form a DAG.

    +

    ECTs intentionally use the distinct claim name "exec_act" for the +action/task type to avoid collision with the "act" claim. The +two concepts are orthogonal: "act" records "who authorized whom," +ECTs record "what was done, in what order, with what policy +outcomes."

    +
    +
    +
    +
    +

    +Transaction Tokens +

    +

    OAuth Transaction Tokens [I-D.ietf-oauth-transaction-tokens] +propagate authorization context across workload call chains. +The Txn-Token "req_wl" claim accumulates a comma-separated list +of workloads that requested replacement tokens, which is the +closest existing mechanism to call-chain recording.

    +

    However, "req_wl" cannot form a DAG because:

    +
      +
    • +

      It is linear: a comma-separated string with no branching or +merging representation. When a workload fans out to multiple +downstream services, each receives the same "req_wl" value and +the branching is invisible.

      +
      • +
    • +

      It is incomplete: only workloads that request a replacement +token from the Transaction Token Service appear in "req_wl"; +workloads that forward the token unchanged are not recorded.

      +
      • +
    • +

      It carries no task-level granularity, no parent references, +no policy evaluation outcomes, and no execution content.

      +
      • +
    +

    Extensions for agentic use cases +([I-D.ietf-oauth-transaction-tokens-for-agents]) add agent +identity and constraints ("agentic_ctx") but no execution +ordering or DAG structure.

    +

    ECTs and Transaction Tokens are complementary: a Txn-Token +propagates authorization context ("this request is authorized +for scope X on behalf of user Y"), while an ECT records +execution accountability ("task T was performed, depending on +tasks P1 and P2, with policy Z evaluated and approved"). An +agent request could carry both a Txn-Token for authorization +and an ECT for execution recording. The WPT "tth" claim +defined in [I-D.ietf-wimse-s2s-protocol] can hash-bind a +WPT to a co-present Txn-Token; a similar binding mechanism +for ECTs is a potential future extension.

    -
    +

    Distributed Tracing (OpenTelemetry)

    -

    OpenTelemetry [OPENTELEMETRY] and similar distributed tracing +

    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 @@ -4192,28 +4381,28 @@ 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.

    +claim for correlation.

    -
    +

    Blockchain and Distributed Ledgers

    -

    Both ECTs and blockchain systems provide immutable records. This +

    Both ECTs and blockchain systems provide immutable records. This specification intentionally defines only the ECT token format and is agnostic to the storage mechanism. ECTs can be stored in append-only logs, databases with cryptographic commitments, blockchain networks, or any storage providing the required -properties defined in Section 8.

    +properties defined in Section 9.

    -
    +

    SCITT (Supply Chain Integrity, Transparency, and Trust)

    -

    The SCITT architecture [I-D.ietf-scitt-architecture] defines a +

    The SCITT architecture [I-D.ietf-scitt-architecture] defines a framework for creating transparent and auditable supply chain records through Transparency Services, Signed Statements, and Receipts. ECTs and SCITT are naturally complementary: the ECT @@ -4229,19 +4418,19 @@ steps (via ECT DAG validation) and the end-to-end supply chain integrity (via SCITT Receipts) using the "wid" as the shared correlation point. The "ext" claim in ECTs (Section 4.2.2) can carry SCITT-specific metadata such as Transparency Service -identifiers or Receipt references for tighter integration.

    +identifiers or Receipt references for tighter integration.

    -
    +

    W3C Verifiable Credentials

    -

    W3C Verifiable Credentials represent claims about subjects (e.g., +

    W3C Verifiable Credentials represent claims about subjects (e.g., identity, qualifications). ECTs represent execution records of actions (what happened, in what order, under what policy). While both use JWT/JWS as a serialization format, their semantics and -use cases are distinct.

    +use cases are distinct.

    @@ -4275,7 +4464,9 @@ matching the WIT (ES256 recommended).

  • -

    Append verified ECTs to an audit ledger.

    +

    Store verified ECTs (append to audit ledger in full ledger +mode, or retain locally in point-to-point mode per +Section 8).

    • @@ -4432,6 +4623,7 @@ Agent B:

    "aud": "spiffe://example.com/agent/validator", "iat": 1772064150, "exp": 1772064750, + "jti": "1a2b3c4d-e5f6-7890-abcd-ef0123456701", "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", "tid": "550e8400-e29b-41d4-a716-446655440001", "exec_act": "fetch_patient_data", @@ -4455,6 +4647,7 @@ task, and creates its own ECT:= ect.iat + clock_skew_tolerance: @@ -791,15 +804,15 @@ function validate_dag(ect, ledger, clock_skew_tolerance): // Step 3: Cycle detection (with traversal limit) visited = set() - result = has_cycle(ect.tid, ect.par, ledger, visited, + result = has_cycle(ect.tid, ect.par, ect_store, visited, max_ancestor_limit) if result is error or result is true: return error("Circular dependency or depth limit exceeded") return success -function has_cycle(target_tid, parent_ids, ledger, visited, - max_depth): +function has_cycle(target_tid, parent_ids, ect_store, + visited, max_depth): if visited.size() >= max_depth: return error("Maximum ancestor traversal limit exceeded") for parent_id in parent_ids: @@ -808,9 +821,9 @@ function has_cycle(target_tid, parent_ids, ledger, visited, if parent_id in visited: continue visited.add(parent_id) - parent = ledger.get(parent_id) + parent = ect_store.get(parent_id) if parent is not null: - result = has_cycle(target_tid, parent.par, ledger, + result = has_cycle(target_tid, parent.par, ect_store, visited, max_depth) if result is error or result is true: return result @@ -885,8 +898,10 @@ verification steps in order: 14. Perform DAG validation per {{dag-validation}}. -15. If all checks pass, the ECT MUST be appended to the audit - ledger. +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. If any verification step fails, the ECT MUST be rejected and the failure MUST be logged for audit purposes. Error messages @@ -965,22 +980,91 @@ function verify_ect(ect_jws, verifier_id, ["approved", "rejected", "pending_human_review"]: return reject("Invalid pol_decision value") - // Validate DAG - result = validate_dag(payload, ledger, + // Validate DAG (against ledger or inline parent ECTs) + result = validate_dag(payload, ect_store, clock_skew_tolerance) if result is error: return reject("DAG validation failed") - // All checks passed; append to ledger - ledger.append(payload) + // All checks passed + if ledger is available: + 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 "tid" 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 @@ -1185,6 +1269,7 @@ a cryptographic link to the original task: "aud": "spiffe://bank.example/system/ledger", "iat": 1772150550, "exp": 1772151150, + "jti": "e4f5a6b7-c8d9-0123-ef01-234567890abc", "wid": "d3e4f5a6-b7c8-9012-def0-123456789012", "tid": "550e8400-e29b-41d4-a716-446655440099", "exec_act": "initiate_trade_rollback", @@ -1654,16 +1739,63 @@ ECTs record "what did this agent do?" and "what policy was evaluated?" Together they form an identity-plus-accountability framework for regulated agentic systems. -## OAuth 2.0 Token Exchange +## OAuth 2.0 Token Exchange and the "act" Claim {:numbered="false"} {{RFC8693}} defines the OAuth 2.0 Token Exchange protocol and registers the "act" (Actor) claim in the JWT Claims registry. +The "act" claim creates nested JSON objects representing a +delegation chain: "who is acting on behalf of whom." While +the nesting superficially resembles a chain, it is strictly +linear (each "act" object contains at most one nested "act"), +represents authorization delegation rather than task execution, +and carries no task identifiers, policy decisions, or +input/output integrity data. The "act" chain cannot represent +branching (fan-out) or convergence (fan-in) and therefore +cannot form a DAG. + ECTs intentionally use the distinct claim name "exec_act" for the -action/task type to avoid collision with the "act" claim. -Transaction tokens in OAuth establish API authorization context; -ECTs serve the complementary purpose of recording execution -accountability across multi-step workflows. +action/task type to avoid collision with the "act" claim. The +two concepts are orthogonal: "act" records "who authorized whom," +ECTs record "what was done, in what order, with what policy +outcomes." + +## Transaction Tokens +{:numbered="false"} + +OAuth Transaction Tokens {{I-D.ietf-oauth-transaction-tokens}} +propagate authorization context across workload call chains. +The Txn-Token "req_wl" claim accumulates a comma-separated list +of workloads that requested replacement tokens, which is the +closest existing mechanism to call-chain recording. + +However, "req_wl" cannot form a DAG because: + +- It is linear: a comma-separated string with no branching or + merging representation. When a workload fans out to multiple + downstream services, each receives the same "req_wl" value and + the branching is invisible. +- It is incomplete: only workloads that request a replacement + token from the Transaction Token Service appear in "req_wl"; + workloads that forward the token unchanged are not recorded. +- It carries no task-level granularity, no parent references, + no policy evaluation outcomes, and no execution content. + +Extensions for agentic use cases +({{I-D.ietf-oauth-transaction-tokens-for-agents}}) add agent +identity and constraints ("agentic_ctx") but no execution +ordering or DAG structure. + +ECTs and Transaction Tokens are complementary: a Txn-Token +propagates authorization context ("this request is authorized +for scope X on behalf of user Y"), while an ECT records +execution accountability ("task T was performed, depending on +tasks P1 and P2, with policy Z evaluated and approved"). An +agent request could carry both a Txn-Token for authorization +and an ECT for execution recording. The WPT "tth" claim +defined in {{I-D.ietf-wimse-s2s-protocol}} can hash-bind a +WPT to a co-present Txn-Token; a similar binding mechanism +for ECTs is a potential future extension. ## Distributed Tracing (OpenTelemetry) {:numbered="false"} @@ -1737,7 +1869,9 @@ 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. Append verified ECTs to an audit ledger. +5. Store verified ECTs (append to audit ledger in full ledger + mode, or retain locally in point-to-point mode per + {{operational-modes}}). ## Storage Recommendations {:numbered="false"} @@ -1817,6 +1951,7 @@ ECT Payload: "aud": "spiffe://example.com/agent/validator", "iat": 1772064150, "exp": 1772064750, + "jti": "1a2b3c4d-e5f6-7890-abcd-ef0123456701", "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", "tid": "550e8400-e29b-41d4-a716-446655440001", "exec_act": "fetch_patient_data", @@ -1840,6 +1975,7 @@ task, and creates its own ECT: "aud": "spiffe://example.com/system/ledger", "iat": 1772064160, "exp": 1772064760, + "jti": "2b3c4d5e-f6a7-8901-bcde-f01234567802", "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", "tid": "550e8400-e29b-41d4-a716-446655440002", "exec_act": "validate_safety", @@ -1875,6 +2011,7 @@ Task 1 (Spec Review Agent): "aud": "spiffe://meddev.example/agent/code-gen", "iat": 1772064150, "exp": 1772064750, + "jti": "3c4d5e6f-a7b8-9012-cdef-012345678903", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "tid": "a1b2c3d4-0001-0000-0000-000000000001", "exec_act": "review_requirements_spec", @@ -1897,6 +2034,7 @@ Task 2 (Code Generation Agent): "aud": "spiffe://meddev.example/agent/test-runner", "iat": 1772064200, "exp": 1772064800, + "jti": "4d5e6f7a-b8c9-0123-def0-123456789004", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "tid": "a1b2c3d4-0001-0000-0000-000000000002", "exec_act": "implement_module", @@ -1917,6 +2055,7 @@ Task 3 (Autonomous Test Agent): "aud": "spiffe://meddev.example/agent/build", "iat": 1772064260, "exp": 1772064860, + "jti": "5e6f7a8b-c9d0-1234-ef01-234567890005", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "tid": "a1b2c3d4-0001-0000-0000-000000000003", "exec_act": "execute_test_suite", @@ -1937,6 +2076,7 @@ Task 4 (Build Agent): "aud": "spiffe://meddev.example/human/release-mgr-42", "iat": 1772064310, "exp": 1772064910, + "jti": "6f7a8b9c-d0e1-2345-f012-345678900006", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "tid": "a1b2c3d4-0001-0000-0000-000000000004", "exec_act": "build_release_artifact", @@ -1957,6 +2097,7 @@ Task 5 (Human Release Manager Approval): "aud": "spiffe://meddev.example/system/ledger", "iat": 1772064510, "exp": 1772065110, + "jti": "7a8b9c0d-e1f2-3456-0123-456789000007", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "tid": "a1b2c3d4-0001-0000-0000-000000000005", "exec_act": "approve_release", @@ -2025,6 +2166,7 @@ Task 004 ECT payload: "aud": "spiffe://bank.example/system/ledger", "iat": 1772064250, "exp": 1772064850, + "jti": "8b9c0d1e-f2a3-4567-1234-567890000008", "wid": "d3e4f5a6-b7c8-9012-def0-123456789012", "tid": "f1e2d3c4-0004-0000-0000-000000000004", "exec_act": "execute_trade", diff --git a/draft-nennemann-wimse-execution-context-00.txt b/draft-nennemann-wimse-execution-context-00.txt index 199e333..d19f891 100644 --- a/draft-nennemann-wimse-execution-context-00.txt +++ b/draft-nennemann-wimse-execution-context-00.txt @@ -92,10 +92,10 @@ Table of Contents 4.2.3. Policy Claims . . . . . . . . . . . . . . . . . . . . 12 4.2.4. Data Integrity Claims . . . . . . . . . . . . . . . . 13 4.2.5. Operational Claims . . . . . . . . . . . . . . . . . 13 - 4.2.6. Witness Claims . . . . . . . . . . . . . . . . . . . 13 + 4.2.6. Witness Claims . . . . . . . . . . . . . . . . . . . 14 4.2.7. Compensation Claims . . . . . . . . . . . . . . . . . 14 4.2.8. Extension Claims . . . . . . . . . . . . . . . . . . 14 - 4.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 14 + 4.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 15 5. HTTP Header Transport . . . . . . . . . . . . . . . . . . . . 15 5.1. Execution-Context Header Field . . . . . . . . . . . . . 15 6. DAG Validation . . . . . . . . . . . . . . . . . . . . . . . 16 @@ -105,7 +105,7 @@ Table of Contents 7. Signature and Token Verification . . . . . . . . . . . . . . 19 7.1. Verification Procedure . . . . . . . . . . . . . . . . . 19 7.2. Verification Pseudocode . . . . . . . . . . . . . . . . . 20 - 8. Audit Ledger Interface . . . . . . . . . . . . . . . . . . . 22 + 8. Operational Modes . . . . . . . . . . . . . . . . . . . . . . 22 @@ -114,54 +114,54 @@ Nennemann Expires 28 August 2026 [Page 2] Internet-Draft WIMSE Execution Context February 2026 - 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 22 - 8.2. Required Properties . . . . . . . . . . . . . . . . . . . 22 - 8.3. Ledger Entry Structure . . . . . . . . . . . . . . . . . 22 - 9. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 9.1. Medical Device SDLC Workflow . . . . . . . . . . . . . . 23 - 9.1.1. FDA Audit with DAG Reconstruction . . . . . . . . . . 24 - 9.2. Financial Trading Workflow . . . . . . . . . . . . . . . 25 - 9.3. Compensation and Rollback . . . . . . . . . . . . . . . . 26 - 9.4. Autonomous Logistics Coordination . . . . . . . . . . . . 27 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 - 10.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 28 - 10.2. Self-Assertion Limitation . . . . . . . . . . . . . . . 29 - 10.2.1. Witness Attestation Model . . . . . . . . . . . . . 29 - 10.3. Organizational Prerequisites . . . . . . . . . . . . . . 30 - 10.4. Signature Verification . . . . . . . . . . . . . . . . . 30 - 10.5. Replay Attack Prevention . . . . . . . . . . . . . . . . 31 - 10.6. Man-in-the-Middle Protection . . . . . . . . . . . . . . 31 - 10.7. Key Compromise . . . . . . . . . . . . . . . . . . . . . 31 - 10.8. Collusion and False Claims . . . . . . . . . . . . . . . 32 - 10.9. Denial of Service . . . . . . . . . . . . . . . . . . . 32 - 10.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 33 - 10.11. ECT Size Constraints . . . . . . . . . . . . . . . . . . 33 - 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 - 11.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . 33 - 11.2. Data Minimization . . . . . . . . . . . . . . . . . . . 34 - 11.3. Storage and Access Control . . . . . . . . . . . . . . . 34 - 11.4. Regulatory Access . . . . . . . . . . . . . . . . . . . 34 - 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 - 12.1. Media Type Registration . . . . . . . . . . . . . . . . 34 - 12.2. HTTP Header Field Registration . . . . . . . . . . . . . 35 - 12.3. JWT Claims Registration . . . . . . . . . . . . . . . . 36 - 12.4. ECT Policy Decision Values Registry . . . . . . . . . . 37 - 12.5. ECT Regulated Domain Values Registry . . . . . . . . . . 38 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 38 - 13.2. Informative References . . . . . . . . . . . . . . . . . 39 - Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 41 - WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 41 - OAuth 2.0 Token Exchange . . . . . . . . . . . . . . . . . . . 41 - Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 41 - Blockchain and Distributed Ledgers . . . . . . . . . . . . . . 42 - SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 42 - W3C Verifiable Credentials . . . . . . . . . . . . . . . . . . 42 - Implementation Guidance . . . . . . . . . . . . . . . . . . . . . 42 - Minimal Implementation . . . . . . . . . . . . . . . . . . . . 42 - Storage Recommendations . . . . . . . . . . . . . . . . . . . . 43 - Performance Considerations . . . . . . . . . . . . . . . . . . 43 - Interoperability . . . . . . . . . . . . . . . . . . . . . . . 43 + 8.1. Point-to-Point Mode . . . . . . . . . . . . . . . . . . . 22 + 8.2. Deferred Ledger Mode . . . . . . . . . . . . . . . . . . 23 + 8.3. Full Ledger Mode . . . . . . . . . . . . . . . . . . . . 23 + 9. Audit Ledger Interface . . . . . . . . . . . . . . . . . . . 23 + 9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 23 + 9.2. Required Properties . . . . . . . . . . . . . . . . . . . 24 + 9.3. Ledger Entry Structure . . . . . . . . . . . . . . . . . 24 + 10. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 10.1. Medical Device SDLC Workflow . . . . . . . . . . . . . . 25 + 10.1.1. FDA Audit with DAG Reconstruction . . . . . . . . . 26 + 10.2. Financial Trading Workflow . . . . . . . . . . . . . . . 27 + 10.3. Compensation and Rollback . . . . . . . . . . . . . . . 27 + 10.4. Autonomous Logistics Coordination . . . . . . . . . . . 28 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 + 11.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 29 + 11.2. Self-Assertion Limitation . . . . . . . . . . . . . . . 30 + 11.2.1. Witness Attestation Model . . . . . . . . . . . . . 30 + 11.3. Organizational Prerequisites . . . . . . . . . . . . . . 31 + 11.4. Signature Verification . . . . . . . . . . . . . . . . . 31 + 11.5. Replay Attack Prevention . . . . . . . . . . . . . . . . 32 + 11.6. Man-in-the-Middle Protection . . . . . . . . . . . . . . 32 + 11.7. Key Compromise . . . . . . . . . . . . . . . . . . . . . 32 + 11.8. Collusion and False Claims . . . . . . . . . . . . . . . 33 + 11.9. Denial of Service . . . . . . . . . . . . . . . . . . . 33 + 11.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 34 + 11.11. ECT Size Constraints . . . . . . . . . . . . . . . . . . 34 + 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34 + 12.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . 34 + 12.2. Data Minimization . . . . . . . . . . . . . . . . . . . 35 + 12.3. Storage and Access Control . . . . . . . . . . . . . . . 35 + 12.4. Regulatory Access . . . . . . . . . . . . . . . . . . . 35 + 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 + 13.1. Media Type Registration . . . . . . . . . . . . . . . . 35 + 13.2. HTTP Header Field Registration . . . . . . . . . . . . . 36 + 13.3. JWT Claims Registration . . . . . . . . . . . . . . . . 37 + 13.4. ECT Policy Decision Values Registry . . . . . . . . . . 38 + 13.5. ECT Regulated Domain Values Registry . . . . . . . . . . 39 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 39 + 14.2. Informative References . . . . . . . . . . . . . . . . . 40 + Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 42 + WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 42 + OAuth 2.0 Token Exchange and the "act" Claim . . . . . . . . . 42 + Transaction Tokens . . . . . . . . . . . . . . . . . . . . . . 43 + Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 43 + Blockchain and Distributed Ledgers . . . . . . . . . . . . . . 44 + SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 44 + W3C Verifiable Credentials . . . . . . . . . . . . . . . . . . 44 @@ -170,13 +170,18 @@ Nennemann Expires 28 August 2026 [Page 3] Internet-Draft WIMSE Execution Context February 2026 - Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . . 43 - Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 - Example 1: Simple Two-Agent Workflow . . . . . . . . . . . . . 44 - Example 2: Medical Device SDLC with Release Approval . . . . . 45 - Example 3: Parallel Execution with Join . . . . . . . . . . . . 48 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49 + Implementation Guidance . . . . . . . . . . . . . . . . . . . . . 44 + Minimal Implementation . . . . . . . . . . . . . . . . . . . . 44 + Storage Recommendations . . . . . . . . . . . . . . . . . . . . 45 + Performance Considerations . . . . . . . . . . . . . . . . . . 45 + Interoperability . . . . . . . . . . . . . . . . . . . . . . . 45 + Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . . 46 + Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 + Example 1: Simple Two-Agent Workflow . . . . . . . . . . . . . 46 + Example 2: Medical Device SDLC with Release Approval . . . . . 48 + Example 3: Parallel Execution with Join . . . . . . . . . . . . 51 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 52 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 52 1. Introduction @@ -213,11 +218,6 @@ Internet-Draft WIMSE Execution Context February 2026 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. - - @@ -226,6 +226,10 @@ Nennemann Expires 28 August 2026 [Page 4] Internet-Draft WIMSE Execution Context February 2026 + * The Digital Operational Resilience Act (DORA) [DORA] Article 12 + requires financial entities to have logging policies that record + ICT activities and anomalies. + This document defines an extension to the WIMSE architecture that addresses the gap between workload identity and execution accountability. WIMSE authenticates agents; this extension records @@ -270,10 +274,6 @@ Internet-Draft WIMSE Execution Context February 2026 * An HTTP header for ECT transport (Section 5) - * Audit ledger interface requirements (Section 8) - - The following are out of scope and are handled by WIMSE: - @@ -282,6 +282,12 @@ Nennemann Expires 28 August 2026 [Page 5] Internet-Draft WIMSE Execution Context February 2026 + * Operational modes including ledger-optional deployment (Section 8) + + * Audit ledger interface requirements (Section 9) + + The following are out of scope and are handled by WIMSE: + * Workload authentication and identity provisioning * Key distribution and management @@ -324,12 +330,6 @@ Internet-Draft WIMSE Execution Context February 2026 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. - @@ -338,6 +338,12 @@ Nennemann Expires 28 August 2026 [Page 6] Internet-Draft WIMSE Execution Context February 2026 + Task: A discrete unit of agent work that consumes inputs and + produces outputs. + + Directed Acyclic Graph (DAG): A graph structure representing task + dependency ordering where edges are directed and no cycles exist. + Execution Context Token (ECT): A JSON Web Token [RFC7519] defined by this specification that records task execution details and policy evaluation outcomes. @@ -380,12 +386,6 @@ Internet-Draft WIMSE Execution Context February 2026 The following execution accountability needs are complementary to the WIMSE scope and are not addressed by workload identity alone: - * Recording what agents actually do with their authenticated - identity - - * Recording policy evaluation outcomes at each hop - - * Maintaining structured execution records @@ -394,6 +394,13 @@ Nennemann Expires 28 August 2026 [Page 7] Internet-Draft WIMSE Execution Context February 2026 + * Recording what agents actually do with their authenticated + identity + + * Recording policy evaluation outcomes at each hop + + * Maintaining structured execution records + * Linking compensation or rollback actions to original tasks 3.2. Extension Model @@ -434,6 +441,15 @@ Internet-Draft WIMSE Execution Context February 2026 * The ECT JOSE header "kid" parameter MUST reference the public key identifier from the agent's WIT. + + + + +Nennemann Expires 28 August 2026 [Page 8] + +Internet-Draft WIMSE Execution Context February 2026 + + * The ECT "iss" claim MUST use the WIMSE workload identifier format (a SPIFFE ID [SPIFFE]). @@ -443,13 +459,6 @@ Internet-Draft WIMSE Execution Context February 2026 * The ECT signing algorithm (JOSE header "alg" parameter) MUST match the algorithm used in the corresponding WIT. - - -Nennemann Expires 28 August 2026 [Page 8] - -Internet-Draft WIMSE Execution Context February 2026 - - When an agent makes an HTTP request to another agent, the three tokens are carried in their respective HTTP header fields: @@ -489,6 +498,14 @@ Internet-Draft WIMSE Execution Context February 2026 Figure 3: ECT JOSE Header Example alg: REQUIRED. The digital signature algorithm used to sign the + + + +Nennemann Expires 28 August 2026 [Page 9] + +Internet-Draft WIMSE Execution Context February 2026 + + ECT. MUST match the algorithm in the corresponding WIT. Implementations MUST support ES256 [RFC7518]. The "alg" value MUST NOT be "none". Symmetric algorithms (e.g., HS256, HS384, @@ -499,13 +516,6 @@ Internet-Draft WIMSE Execution Context February 2026 from other JWT types, consistent with the WIMSE convention for type parameter values. - - -Nennemann Expires 28 August 2026 [Page 9] - -Internet-Draft WIMSE Execution Context February 2026 - - 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. @@ -545,16 +555,6 @@ Internet-Draft WIMSE Execution Context February 2026 directly to the audit ledger (e.g., after a join or at workflow completion), "aud" contains the ledger's identity. - * *Multi-audience*: when an ECT must be verified by both the next - agent and the ledger independently, "aud" MUST be an array - containing both identifiers (e.g., - ["spiffe://example.com/agent/next", - "spiffe://example.com/system/ledger"]). Each verifier checks - that its own identity appears in the array. - - - - Nennemann Expires 28 August 2026 [Page 10] @@ -562,6 +562,13 @@ Nennemann Expires 28 August 2026 [Page 10] Internet-Draft WIMSE Execution Context February 2026 + * *Multi-audience*: when an ECT must be verified by both the next + agent and the ledger independently, "aud" MUST be an array + containing both identifiers (e.g., + ["spiffe://example.com/agent/next", + "spiffe://example.com/system/ledger"]). Each verifier checks + that its own identity appears in the array. + In multi-parent (join) scenarios where a task depends on ECTs from multiple parent agents, the joining agent creates a new ECT with the parent task IDs in "par". The "aud" of this new ECT is set @@ -603,13 +610,6 @@ Internet-Draft WIMSE Execution Context February 2026 is absent, uniqueness MUST be enforced globally across the ledger. exec_act: REQUIRED. String. The action or task type identifier - describing what the agent performed (e.g., "process_payment", - "validate_safety", "calculate_dosage"). Note: this claim is - intentionally named "exec_act" rather than "act" to avoid - collision with the "act" (Actor) claim registered by [RFC8693]. - - par: REQUIRED. Array of strings. Parent task identifiers - @@ -618,6 +618,12 @@ Nennemann Expires 28 August 2026 [Page 11] Internet-Draft WIMSE Execution Context February 2026 + describing what the agent performed (e.g., "process_payment", + "validate_safety", "calculate_dosage"). Note: this claim is + intentionally named "exec_act" rather than "act" to avoid + collision with the "act" (Actor) claim registered by [RFC8693]. + + par: REQUIRED. Array of strings. Parent task identifiers representing DAG dependencies. Each element MUST be a valid "tid" from a previously executed task. An empty array indicates a root task with no dependencies. A workflow MAY contain multiple root @@ -632,7 +638,7 @@ Internet-Draft WIMSE Execution Context February 2026 pol_decision: REQUIRED. String. The result of the policy evaluation. MUST be one of the values registered in the ECT - Policy Decision Values registry (Section 12.4). Initial values + Policy Decision Values registry (Section 13.4). Initial values are: * "approved": The policy evaluation succeeded and the task was @@ -660,12 +666,6 @@ Internet-Draft WIMSE Execution Context February 2026 decision was made. When present, MUST be equal to or earlier than the "iat" claim. - This specification intentionally defines only the recording of policy - evaluation outcomes. The mechanisms by which policies are defined, - distributed to agents, and evaluated are out of scope. The "pol" - claim is an opaque identifier referencing an external policy; the - semantics and enforcement of that policy are determined by the - deployment environment. Implementations may use any policy engine or @@ -674,6 +674,12 @@ Nennemann Expires 28 August 2026 [Page 12] Internet-Draft WIMSE Execution Context February 2026 + This specification intentionally defines only the recording of policy + evaluation outcomes. The mechanisms by which policies are defined, + distributed to agents, and evaluated are out of scope. The "pol" + claim is an opaque identifier referencing an external policy; the + semantics and enforcement of that policy are determined by the + deployment environment. Implementations may use any policy engine or framework (e.g., OPA/Rego, Cedar, XACML, or custom solutions) provided that the evaluation outcome is faithfully recorded in the ECT claims defined above. @@ -711,17 +717,11 @@ Internet-Draft WIMSE Execution Context February 2026 regulated_domain: OPTIONAL. String. The regulatory domain applicable to this task. Values MUST be registered in the ECT - Regulated Domain Values registry (Section 12.5). + Regulated Domain Values registry (Section 13.5). model_version: OPTIONAL. String. The version identifier of the AI or ML model used to perform the task, if applicable. -4.2.6. Witness Claims - - witnessed_by: OPTIONAL. Array of StringOrURI. Identifiers of - third-party entities that the issuing agent claims observed or - attested to the execution of this task. When present, each - element SHOULD use SPIFFE ID format. Note that this claim is @@ -730,13 +730,19 @@ Nennemann Expires 28 August 2026 [Page 13] Internet-Draft WIMSE Execution Context February 2026 +4.2.6. Witness Claims + + witnessed_by: OPTIONAL. Array of StringOrURI. Identifiers of + third-party entities that the issuing agent claims observed or + attested to the execution of this task. When present, each + element SHOULD use SPIFFE ID format. Note that this claim is self-asserted by the ECT issuer; witnesses listed here do not co- sign this ECT. For stronger assurance, witnesses SHOULD submit independent signed ECTs to the ledger attesting to their - observation (see Section 10.2.1). In regulated environments, + observation (see Section 11.2.1). In regulated environments, implementations SHOULD use witness attestation for critical decision points to mitigate the risk of single-agent false claims. - See also Section 10.2 for the security implications of self- + See also Section 11.2 for the security implications of self- asserted witness claims. 4.2.7. Compensation Claims @@ -749,7 +755,7 @@ Internet-Draft WIMSE Execution Context February 2026 "compensation_required" is true. Values SHOULD use structured identifiers (e.g., "policy_violation_in_parent_trade") rather than free-form text to minimize the risk of embedding sensitive - information. See Section 11.2 for privacy guidance. If + information. See Section 12.2 for privacy guidance. If "compensation_reason" is present, "compensation_required" MUST be true. @@ -773,12 +779,6 @@ Internet-Draft WIMSE Execution Context February 2026 within the "ext" object SHOULD NOT exceed 5 levels. Implementations SHOULD reject ECTs whose "ext" claim exceeds these limits. -4.3. Complete ECT Example - - The following is a complete ECT payload example: - - - Nennemann Expires 28 August 2026 [Page 14] @@ -786,6 +786,10 @@ Nennemann Expires 28 August 2026 [Page 14] Internet-Draft WIMSE Execution Context February 2026 +4.3. Complete ECT Example + + The following is a complete ECT payload example: + { "iss": "spiffe://example.com/agent/clinical", "sub": "spiffe://example.com/agent/clinical", @@ -829,10 +833,6 @@ Internet-Draft WIMSE Execution Context February 2026 [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 and Workload- - Proof-Token headers: - @@ -842,6 +842,10 @@ Nennemann Expires 28 August 2026 [Page 15] Internet-Draft WIMSE Execution Context February 2026 + An agent sending a request to another agent includes the Execution- + Context header alongside the WIMSE Workload-Identity and Workload- + Proof-Token headers: + GET /api/safety-check HTTP/1.1 Host: safety-agent.example.com Workload-Identity: eyJhbGci...WIT... @@ -871,25 +875,21 @@ Internet-Draft WIMSE Execution Context February 2026 auditors to reconstruct the complete workflow and verify that required predecessor tasks were recorded before dependent tasks. + DAG validation can be performed against an audit ledger (when + available) or against parent ECTs received inline via Execution- + Context headers (in point-to-point mode per Section 8). The + validation rules below use the term "ECT store" to refer to either + the ledger or the set of inline parent ECTs available to the + verifier. + 6.2. Validation Rules When receiving and verifying an ECT, implementations MUST perform the following DAG validation steps: - 1. Task ID Uniqueness: The "tid" claim MUST be unique within the - applicable scope (the workflow identified by "wid", or the entire - ledger if "wid" is absent). If a task with the same "tid" - already exists, the ECT MUST be rejected. - 2. Parent Existence: Every task identifier listed in the "par" array - MUST correspond to a task that has been previously recorded in - the ledger. 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 + + @@ -898,10 +898,25 @@ Nennemann Expires 28 August 2026 [Page 16] Internet-Draft WIMSE Execution Context February 2026 + 1. Task ID Uniqueness: The "tid" claim MUST be unique within the + applicable scope (the workflow identified by "wid", or the entire + ECT store if "wid" is absent). If a task with the same "tid" + already exists, the ECT MUST be rejected. + + 2. Parent Existence: Every task identifier listed in the "par" array + MUST correspond to a task that is available in the ECT store + (either previously recorded in the ledger or received inline as a + verified parent ECT). If any parent task is not found, the ECT + MUST be rejected. + + 3. Temporal Ordering: The "iat" value of every parent task MUST NOT + be greater than the "iat" value of the current task plus a + configurable clock skew tolerance (RECOMMENDED: 30 seconds). + That is, for each parent: parent.iat < child.iat + clock_skew_tolerance. The tolerance accounts for clock skew between agents; it does not guarantee strict causal ordering from timestamps alone. Causal ordering is primarily enforced by the - DAG structure (parent existence in the ledger), not by + DAG structure (parent existence in the ECT store), not by timestamps. If any parent task violates this constraint, the ECT MUST be rejected. @@ -929,21 +944,6 @@ Internet-Draft WIMSE Execution Context February 2026 - - - - - - - - - - - - - - - @@ -954,14 +954,15 @@ Nennemann Expires 28 August 2026 [Page 17] Internet-Draft WIMSE Execution Context February 2026 - function validate_dag(ect, ledger, clock_skew_tolerance): + function validate_dag(ect, ect_store, clock_skew_tolerance): + // ect_store: ledger or local cache of verified ECTs // Step 1: Uniqueness check - if ledger.contains(ect.tid, ect.wid): - return error("Task ID already exists in ledger") + if ect_store.contains(ect.tid, ect.wid): + return error("Task ID already exists") // Step 2: Parent existence and temporal ordering for parent_id in ect.par: - parent = ledger.get(parent_id) + parent = ect_store.get(parent_id) if parent is null: return error("Parent task not found: " + parent_id) if parent.iat >= ect.iat + clock_skew_tolerance: @@ -969,15 +970,15 @@ Internet-Draft WIMSE Execution Context February 2026 // Step 3: Cycle detection (with traversal limit) visited = set() - result = has_cycle(ect.tid, ect.par, ledger, visited, + result = has_cycle(ect.tid, ect.par, ect_store, visited, max_ancestor_limit) if result is error or result is true: return error("Circular dependency or depth limit exceeded") return success - function has_cycle(target_tid, parent_ids, ledger, visited, - max_depth): + function has_cycle(target_tid, parent_ids, ect_store, + visited, max_depth): if visited.size() >= max_depth: return error("Maximum ancestor traversal limit exceeded") for parent_id in parent_ids: @@ -986,9 +987,9 @@ Internet-Draft WIMSE Execution Context February 2026 if parent_id in visited: continue visited.add(parent_id) - parent = ledger.get(parent_id) + parent = ect_store.get(parent_id) if parent is not null: - result = has_cycle(target_tid, parent.par, ledger, + result = has_cycle(target_tid, parent.par, ect_store, visited, max_depth) if result is error or result is true: return result @@ -1001,7 +1002,6 @@ Internet-Draft WIMSE Execution Context February 2026 of ancestor nodes reachable from the current task's parent references. For typical workflows with shallow DAGs, this is efficient. To prevent denial-of-service via extremely deep or wide - DAGs, implementations SHOULD enforce a maximum ancestor traversal @@ -1010,6 +1010,7 @@ Nennemann Expires 28 August 2026 [Page 18] Internet-Draft WIMSE Execution Context February 2026 + DAGs, implementations SHOULD enforce a maximum ancestor traversal limit (RECOMMENDED: 10000 nodes). If the limit is reached before cycle detection completes, the ECT SHOULD be rejected. Implementations SHOULD cache cycle detection results for previously @@ -1060,7 +1061,6 @@ Internet-Draft WIMSE Execution Context February 2026 - Nennemann Expires 28 August 2026 [Page 19] Internet-Draft WIMSE Execution Context February 2026 @@ -1080,8 +1080,10 @@ Internet-Draft WIMSE Execution Context February 2026 14. Perform DAG validation per Section 6. - 15. If all checks pass, the ECT MUST be appended to the audit - ledger. + 15. If all checks pass and an audit ledger is available, the ECT + SHOULD be appended to the audit ledger. In point-to-point mode + (Section 8), the verified ECT is retained locally by the + receiving agent. If any verification step fails, the ECT MUST be rejected and the failure MUST be logged for audit purposes. Error messages SHOULD NOT @@ -1112,8 +1114,6 @@ Internet-Draft WIMSE Execution Context February 2026 // Look up public key public_key = trust_domain_keys.get(header.kid) - if public_key is null: - return reject("Unknown key identifier") @@ -1122,6 +1122,9 @@ Nennemann Expires 28 August 2026 [Page 20] Internet-Draft WIMSE Execution Context February 2026 + if public_key is null: + return reject("Unknown key identifier") + // Verify signature if not verify_jws_signature(header, payload, signature, public_key): @@ -1165,11 +1168,8 @@ Internet-Draft WIMSE Execution Context February 2026 ["approved", "rejected", "pending_human_review"]: return reject("Invalid pol_decision value") - // Validate DAG - result = validate_dag(payload, ledger, - clock_skew_tolerance) - if result is error: - return reject("DAG validation failed") + // Validate DAG (against ledger or inline parent ECTs) + result = validate_dag(payload, ect_store, @@ -1178,17 +1178,100 @@ Nennemann Expires 28 August 2026 [Page 21] Internet-Draft WIMSE Execution Context February 2026 - // All checks passed; append to ledger - ledger.append(payload) + clock_skew_tolerance) + if result is error: + return reject("DAG validation failed") + + // All checks passed + if ledger is available: + ledger.append(payload) + else: + // Point-to-point mode: retain locally + local_ect_cache.store(payload) return accept Figure 7: ECT Verification Pseudocode -8. Audit Ledger Interface +8. Operational Modes -8.1. Overview + 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. - ECTs are designed to be recorded in an immutable audit ledger for +8.1. Point-to-Point Mode + + In point-to-point mode, agents pass parent ECTs directly to + downstream agents via multiple Execution-Context HTTP headers. No + centralized ledger is required. The receiving agent verifies each + parent ECT independently and validates the DAG against the set of + ECTs received in the request. + + This mode is suitable for: + + * Cross-organizational workflows where no shared ledger exists + + * Lightweight deployments where infrastructure is constrained + + * Early adoption scenarios before ledger infrastructure is available + + Limitations of point-to-point mode: + + * No persistent audit trail unless agents independently retain ECTs + + * Global replay detection relies solely on "jti" caches at each + agent; there is no centralized "tid" uniqueness check + + * The parent ECT chain grows with each hop, increasing HTTP header + size + + + + +Nennemann Expires 28 August 2026 [Page 22] + +Internet-Draft WIMSE Execution Context February 2026 + + + * Post-hoc audit reconstruction requires collecting ECTs from + multiple agents + + Agents operating in point-to-point mode MUST retain verified parent + ECTs for at least the duration of the workflow to support DAG + validation of downstream requests. Agents SHOULD persist ECTs + locally for audit purposes even when no centralized ledger is + available. + +8.2. Deferred Ledger Mode + + In deferred ledger mode, agents create and verify ECTs in-flight + using point-to-point delivery, and submit collected ECTs to an audit + ledger after the workflow completes or at periodic intervals. + + This mode decouples real-time workflow execution from ledger + availability. DAG validation during execution uses inline parent + ECTs; full DAG validation against the complete workflow is performed + at ledger submission time. + + Agents MUST include all collected ECTs when submitting to the ledger. + The ledger MUST re-validate the complete DAG upon submission. + +8.3. Full Ledger Mode + + In full ledger mode, every verified ECT is immediately appended to an + audit ledger. DAG validation is performed against the ledger, which + serves as the authoritative ECT store. This is the RECOMMENDED mode + for regulated environments where persistent, centralized audit trails + are required. + +9. Audit Ledger Interface + +9.1. Overview + + Use of an audit ledger is RECOMMENDED for regulated environments and + any deployment requiring persistent, centralized audit trails. ECTs + are designed to be recorded in an immutable audit ledger for compliance verification and post-hoc analysis. This specification defines the logical interface for the ledger but does not mandate a specific storage technology. Implementations MAY use append-only @@ -1196,7 +1279,18 @@ Internet-Draft WIMSE Execution Context February 2026 ledgers, or any storage mechanism that provides the required properties. -8.2. Required Properties + + + + + + +Nennemann Expires 28 August 2026 [Page 23] + +Internet-Draft WIMSE Execution Context February 2026 + + +9.2. Required Properties An audit ledger implementation MUST provide: @@ -1216,24 +1310,10 @@ Internet-Draft WIMSE Execution Context February 2026 The ledger SHOULD be maintained by an entity independent of the workflow agents to reduce the risk of collusion. -8.3. Ledger Entry Structure +9.3. Ledger Entry Structure Each ledger entry is a logical record containing: - - - - - - - - - -Nennemann Expires 28 August 2026 [Page 22] - -Internet-Draft WIMSE Execution Context February 2026 - - { "ledger_sequence": 42, "task_id": "550e8400-e29b-41d4-a716-446655440001", @@ -1257,7 +1337,16 @@ Internet-Draft WIMSE Execution Context February 2026 desynchronization between the authoritative JWS and the indexed fields. -9. Use Cases + + + + +Nennemann Expires 28 August 2026 [Page 24] + +Internet-Draft WIMSE Execution Context February 2026 + + +10. Use Cases This section describes representative use cases demonstrating how ECTs provide execution records in regulated environments. These @@ -1269,7 +1358,7 @@ Internet-Draft WIMSE Execution Context February 2026 readability. In production, all "tid" values are required to be UUIDs per Section 4.2.2. -9.1. Medical Device SDLC Workflow +10.1. Medical Device SDLC Workflow In a medical device software development lifecycle (SDLC), AI agents assist across multiple phases from requirements analysis through @@ -1277,19 +1366,6 @@ Internet-Draft WIMSE Execution Context February 2026 Section 11.10(e) and [EU-MDR] require audit trails documenting the complete development process for software used in medical devices. - - - - - - - - -Nennemann Expires 28 August 2026 [Page 23] - -Internet-Draft WIMSE Execution Context February 2026 - - Agent A (Spec Reviewer): tid: task-001 par: [] exec_act: review_requirements_spec @@ -1319,33 +1395,26 @@ Internet-Draft WIMSE Execution Context February 2026 Figure 9: Medical Device SDLC Workflow + + +Nennemann Expires 28 August 2026 [Page 25] + +Internet-Draft WIMSE Execution Context February 2026 + + ECTs record that requirements were reviewed before implementation began, that tests were executed against the implemented code, that the build artifact was validated, and that a human release manager explicitly approved the release. The DAG structure ensures no phase was skipped or reordered. -9.1.1. FDA Audit with DAG Reconstruction +10.1.1. FDA Audit with DAG Reconstruction During a regulatory audit, an FDA reviewer requests evidence of the development process for a specific software release. The auditing authority retrieves all ECTs sharing the same workflow identifier ("wid") from the audit ledger and reconstructs the complete DAG: - - - - - - - - - -Nennemann Expires 28 August 2026 [Page 24] - -Internet-Draft WIMSE Execution Context February 2026 - - task-001 (review_requirements_spec) | v @@ -1380,6 +1449,15 @@ Internet-Draft WIMSE Execution Context February 2026 * [FDA-21CFR11] Section 11.10(e): Computer-generated audit trails that record the date, time, and identity of the operator. + + + + +Nennemann Expires 28 August 2026 [Page 26] + +Internet-Draft WIMSE Execution Context February 2026 + + * [EU-MDR] Annex II: Technical documentation traceability for the software development lifecycle. @@ -1389,19 +1467,12 @@ Internet-Draft WIMSE Execution Context February 2026 * [EU-AI-ACT] Article 14: ECTs can record evidence that human oversight events occurred during the release process. -9.2. Financial Trading Workflow +10.2. Financial Trading Workflow In a financial trading workflow, agents perform risk assessment, compliance verification, and trade execution. The DAG structure records that compliance checks were evaluated before trade execution. - - -Nennemann Expires 28 August 2026 [Page 25] - -Internet-Draft WIMSE Execution Context February 2026 - - Agent A (Risk Assessment): tid: task-001 par: [] exec_act: calculate_risk_exposure @@ -1429,7 +1500,7 @@ Internet-Draft WIMSE Execution Context February 2026 * [EU-AI-ACT] Article 12: Logging of decisions made by AI-driven systems. -9.3. Compensation and Rollback +10.3. Compensation and Rollback When a compliance violation is discovered after execution, ECTs provide a mechanism to record authorized compensation actions with a @@ -1438,22 +1509,7 @@ Internet-Draft WIMSE Execution Context February 2026 - - - - - - - - - - - - - - - -Nennemann Expires 28 August 2026 [Page 26] +Nennemann Expires 28 August 2026 [Page 27] Internet-Draft WIMSE Execution Context February 2026 @@ -1464,6 +1520,7 @@ Internet-Draft WIMSE Execution Context February 2026 "aud": "spiffe://bank.example/system/ledger", "iat": 1772150550, "exp": 1772151150, + "jti": "e4f5a6b7-c8d9-0123-ef01-234567890abc", "wid": "d3e4f5a6-b7c8-9012-def0-123456789012", "tid": "550e8400-e29b-41d4-a716-446655440099", "exec_act": "initiate_trade_rollback", @@ -1481,7 +1538,7 @@ Internet-Draft WIMSE Execution Context February 2026 creating an auditable chain from execution through violation discovery to remediation. -9.4. Autonomous Logistics Coordination +10.4. Autonomous Logistics Coordination In a logistics workflow, multiple compliance checks complete before shipment commitment. The DAG structure records that all required @@ -1508,8 +1565,7 @@ Internet-Draft WIMSE Execution Context February 2026 - -Nennemann Expires 28 August 2026 [Page 27] +Nennemann Expires 28 August 2026 [Page 28] Internet-Draft WIMSE Execution Context February 2026 @@ -1545,12 +1601,12 @@ Internet-Draft WIMSE Execution Context February 2026 execute in parallel. Task 004 depends on both, demonstrating the DAG's ability to represent parallel execution with a join point. -10. Security Considerations +11. Security Considerations This section addresses security considerations following the guidance in [RFC3552]. -10.1. Threat Model +11.1. Threat Model The following threat actors are considered: @@ -1565,7 +1621,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 28] +Nennemann Expires 28 August 2026 [Page 29] Internet-Draft WIMSE Execution Context February 2026 @@ -1573,7 +1629,7 @@ Internet-Draft WIMSE Execution Context February 2026 * Time manipulator: An entity attempting to manipulate timestamps to alter perceived execution ordering. -10.2. Self-Assertion Limitation +11.2. Self-Assertion Limitation ECTs are self-asserted by the executing agent. The agent claims what it did, and this claim is signed with its private key. A compromised @@ -1600,7 +1656,7 @@ Internet-Draft WIMSE Execution Context February 2026 observed the task. An issuing agent could list witnesses that did not participate. -10.2.1. Witness Attestation Model +11.2.1. Witness Attestation Model To address the self-assertion limitation of the "witnessed_by" claim, witnesses SHOULD submit their own independent signed ECTs to the @@ -1621,7 +1677,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 29] +Nennemann Expires 28 August 2026 [Page 30] Internet-Draft WIMSE Execution Context February 2026 @@ -1637,7 +1693,7 @@ Internet-Draft WIMSE Execution Context February 2026 independently signs their own ECT using their own key, and the ledger records both the original task ECT and the witness attestation ECTs. -10.3. Organizational Prerequisites +11.3. Organizational Prerequisites ECTs operate within a broader trust framework. The guarantees provided by ECTs are only meaningful when the following @@ -1655,7 +1711,7 @@ Internet-Draft WIMSE Execution Context February 2026 * Agent deployment governance: Agents are deployed and maintained in a manner that preserves their integrity. -10.4. Signature Verification +11.4. Signature Verification ECTs MUST be signed with the agent's private key using JWS [RFC7515]. The signature algorithm MUST match the algorithm specified in the @@ -1677,12 +1733,12 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 30] +Nennemann Expires 28 August 2026 [Page 31] Internet-Draft WIMSE Execution Context February 2026 -10.5. Replay Attack Prevention +11.5. Replay Attack Prevention ECTs include short expiration times (RECOMMENDED: 5-15 minutes) to limit the window for replay attacks. The "aud" claim restricts @@ -1698,7 +1754,7 @@ 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. -10.6. Man-in-the-Middle Protection +11.6. Man-in-the-Middle Protection ECTs do not replace transport-layer security. ECTs MUST be transmitted over TLS or mTLS connections. When used with the WIMSE @@ -1716,7 +1772,7 @@ Internet-Draft WIMSE Execution Context February 2026 * ECT (execution accountability layer): Records what the agent did and under what policy. -10.7. Key Compromise +11.7. Key Compromise If an agent's private key is compromised, an attacker can forge ECTs that appear to originate from that agent. To mitigate this risk: @@ -1733,7 +1789,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 31] +Nennemann Expires 28 August 2026 [Page 32] Internet-Draft WIMSE Execution Context February 2026 @@ -1746,7 +1802,7 @@ Internet-Draft WIMSE Execution Context February 2026 flagged in the ledger as "signed with subsequently revoked key" for audit purposes. -10.8. Collusion and False Claims +11.8. Collusion and False Claims A single malicious agent cannot forge parent task references because DAG validation requires parent tasks to exist in the ledger. @@ -1767,7 +1823,7 @@ Internet-Draft WIMSE Execution Context February 2026 * Out-of-band audit: External auditors periodically verify ledger contents against expected workflow patterns. -10.9. Denial of Service +11.9. Denial of Service ECT signature verification is computationally inexpensive (approximately 1ms per ECT on modern hardware for ES256). DAG @@ -1789,12 +1845,12 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 32] +Nennemann Expires 28 August 2026 [Page 33] Internet-Draft WIMSE Execution Context February 2026 -10.10. Timestamp Accuracy +11.10. Timestamp Accuracy ECTs rely on timestamps ("iat", "exp") for temporal ordering. Clock skew between agents can lead to incorrect ordering judgments. @@ -1811,7 +1867,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. -10.11. ECT Size Constraints +11.11. ECT Size Constraints ECTs with many parent tasks or large extension objects can increase HTTP header size. Implementations SHOULD limit the "par" array to a @@ -1820,9 +1876,9 @@ Internet-Draft WIMSE Execution Context February 2026 SHOULD NOT exceed 4096 bytes when serialized as JSON and SHOULD NOT exceed a nesting depth of 5 levels (see also Section 4.2.8). -11. Privacy Considerations +12. Privacy Considerations -11.1. Data Exposure in ECTs +12.1. Data Exposure in ECTs ECTs necessarily reveal: @@ -1845,7 +1901,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 33] +Nennemann Expires 28 August 2026 [Page 34] Internet-Draft WIMSE Execution Context February 2026 @@ -1854,7 +1910,7 @@ Internet-Draft WIMSE Execution Context February 2026 * Personally identifiable information (PII) -11.2. Data Minimization +12.2. Data Minimization Implementations SHOULD minimize the information included in ECTs. The "exec_act" claim SHOULD use structured identifiers (e.g., @@ -1871,7 +1927,7 @@ Internet-Draft WIMSE Execution Context February 2026 SHOULD review "compensation_reason" values for potential information leakage before deploying to production. -11.3. Storage and Access Control +12.3. Storage and Access Control ECTs stored in audit ledgers SHOULD be access-controlled so that only authorized auditors and regulators can read them. Implementations @@ -1883,15 +1939,15 @@ Internet-Draft WIMSE Execution Context February 2026 controls, since auditors may need to verify hash correctness but general access to the data values is not needed. -11.4. Regulatory Access +12.4. Regulatory Access ECTs are designed for interpretation by qualified human auditors and regulators. ECTs provide structural records of execution ordering and policy evaluation; they are not intended for public disclosure. -12. IANA Considerations +13. IANA Considerations -12.1. Media Type Registration +13.1. Media Type Registration This document requests registration of the following media type in the "Media Types" registry maintained by IANA: @@ -1901,7 +1957,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 34] +Nennemann Expires 28 August 2026 [Page 35] Internet-Draft WIMSE Execution Context February 2026 @@ -1941,7 +1997,7 @@ Internet-Draft WIMSE Execution Context February 2026 Change controller: IETF -12.2. HTTP Header Field Registration +13.2. HTTP Header Field Registration This document requests registration of the following header field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" @@ -1957,12 +2013,12 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 35] +Nennemann Expires 28 August 2026 [Page 36] Internet-Draft WIMSE Execution Context February 2026 -12.3. JWT Claims Registration +13.3. JWT Claims Registration This document requests registration of the following claims in the "JSON Web Token Claims" registry maintained by IANA: @@ -2013,7 +2069,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 36] +Nennemann Expires 28 August 2026 [Page 37] Internet-Draft WIMSE Execution Context February 2026 @@ -2036,7 +2092,7 @@ Internet-Draft WIMSE Execution Context February 2026 Table 1: JWT Claims Registrations -12.4. ECT Policy Decision Values Registry +13.4. ECT Policy Decision Values Registry This document establishes the "ECT Policy Decision Values" registry under the "JSON Web Token (JWT)" group. Registration policy is @@ -2069,12 +2125,12 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 37] +Nennemann Expires 28 August 2026 [Page 38] Internet-Draft WIMSE Execution Context February 2026 -12.5. ECT Regulated Domain Values Registry +13.5. ECT Regulated Domain Values Registry This document establishes the "ECT Regulated Domain Values" registry under the "JSON Web Token (JWT)" group. Registration policy is @@ -2097,9 +2153,9 @@ Internet-Draft WIMSE Execution Context February 2026 Table 3: ECT Regulated Domain Values -13. References +14. References -13.1. Normative References +14.1. Normative References [I-D.ietf-wimse-arch] Salowey, J. A., Rosomakho, Y., and H. Tschofenig, @@ -2125,7 +2181,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 38] +Nennemann Expires 28 August 2026 [Page 39] Internet-Draft WIMSE Execution Context February 2026 @@ -2164,7 +2220,7 @@ Internet-Draft WIMSE Execution Context February 2026 IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, . -13.2. Informative References +14.2. Informative References [DORA] European Parliament and Council of the European Union, "Regulation (EU) 2022/2554 on digital operational @@ -2181,7 +2237,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 39] +Nennemann Expires 28 August 2026 [Page 40] Internet-Draft WIMSE Execution Context February 2026 @@ -2196,6 +2252,16 @@ Internet-Draft WIMSE Execution Context February 2026 Electronic Signatures", . + [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, + . + + [I-D.ietf-oauth-transaction-tokens-for-agents] + "*** BROKEN REFERENCE ***". + [I-D.ietf-scitt-architecture] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and @@ -2222,6 +2288,16 @@ Internet-Draft WIMSE Execution Context February 2026 Specification", . + + + + + +Nennemann Expires 28 August 2026 [Page 41] + +Internet-Draft WIMSE Execution Context February 2026 + + [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, @@ -2232,16 +2308,6 @@ Internet-Draft WIMSE Execution Context February 2026 DOI 10.17487/RFC8693, January 2020, . - - - - - -Nennemann Expires 28 August 2026 [Page 40] - -Internet-Draft WIMSE Execution Context February 2026 - - [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . @@ -2262,15 +2328,68 @@ WIMSE Workload Identity they form an identity-plus-accountability framework for regulated agentic systems. -OAuth 2.0 Token Exchange +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. ECTs - intentionally use the distinct claim name "exec_act" for the action/ - task type to avoid collision with the "act" claim. Transaction - tokens in OAuth establish API authorization context; ECTs serve the - complementary purpose of recording execution accountability across - multi-step workflows. + the "act" (Actor) claim in the JWT Claims registry. The "act" claim + creates nested JSON objects representing a delegation chain: "who is + acting on behalf of whom." While the nesting superficially resembles + a chain, it is strictly linear (each "act" object contains at most + one nested "act"), represents authorization delegation rather than + task execution, and carries no task identifiers, policy decisions, or + input/output integrity data. The "act" chain cannot represent + branching (fan-out) or convergence (fan-in) and therefore cannot form + a DAG. + + ECTs intentionally use the distinct claim name "exec_act" for the + action/task type to avoid collision with the "act" claim. The two + concepts are orthogonal: "act" records "who authorized whom," ECTs + record "what was done, in what order, with what policy outcomes." + + + + +Nennemann Expires 28 August 2026 [Page 42] + +Internet-Draft WIMSE Execution Context February 2026 + + +Transaction Tokens + + OAuth Transaction Tokens [I-D.ietf-oauth-transaction-tokens] + propagate authorization context across workload call chains. The + Txn-Token "req_wl" claim accumulates a comma-separated list of + workloads that requested replacement tokens, which is the closest + existing mechanism to call-chain recording. + + However, "req_wl" cannot form a DAG because: + + * It is linear: a comma-separated string with no branching or + merging representation. When a workload fans out to multiple + downstream services, each receives the same "req_wl" value and the + branching is invisible. + + * It is incomplete: only workloads that request a replacement token + from the Transaction Token Service appear in "req_wl"; workloads + that forward the token unchanged are not recorded. + + * It carries no task-level granularity, no parent references, no + policy evaluation outcomes, and no execution content. + + Extensions for agentic use cases + ([I-D.ietf-oauth-transaction-tokens-for-agents]) add agent identity + and constraints ("agentic_ctx") but no execution ordering or DAG + structure. + + ECTs and Transaction Tokens are complementary: a Txn-Token propagates + authorization context ("this request is authorized for scope X on + behalf of user Y"), while an ECT records execution accountability + ("task T was performed, depending on tasks P1 and P2, with policy Z + evaluated and approved"). An agent request could carry both a Txn- + Token for authorization and an ECT for execution recording. The WPT + "tth" claim defined in [I-D.ietf-wimse-s2s-protocol] can hash-bind a + WPT to a co-present Txn-Token; a similar binding mechanism for ECTs + is a potential future extension. Distributed Tracing (OpenTelemetry) @@ -2283,21 +2402,17 @@ Distributed Tracing (OpenTelemetry) 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. - - - - - -Nennemann Expires 28 August 2026 [Page 41] +Nennemann Expires 28 August 2026 [Page 43] Internet-Draft WIMSE Execution Context February 2026 + while ECTs provide signed execution records. ECTs may reference + OpenTelemetry trace identifiers in the "ext" claim for correlation. + Blockchain and Distributed Ledgers Both ECTs and blockchain systems provide immutable records. This @@ -2305,7 +2420,7 @@ Blockchain and Distributed Ledgers agnostic to the storage mechanism. ECTs can be stored in append-only logs, databases with cryptographic commitments, blockchain networks, or any storage providing the required properties defined in - Section 8. + Section 9. SCITT (Supply Chain Integrity, Transparency, and Trust) @@ -2344,22 +2459,23 @@ Minimal Implementation 1. Create JWTs with all required claims ("iss", "aud", "iat", "exp", "jti", "tid", "exec_act", "par", "pol", "pol_decision"). - 2. Sign ECTs with the agent's private key using an algorithm - matching the WIT (ES256 recommended). - -Nennemann Expires 28 August 2026 [Page 42] +Nennemann Expires 28 August 2026 [Page 44] Internet-Draft WIMSE Execution Context February 2026 + 2. Sign ECTs with the agent's private key using an algorithm + matching the WIT (ES256 recommended). + 3. Verify ECT signatures against WIT public keys. 4. Perform DAG validation (parent existence, temporal ordering, cycle detection). - 5. Append verified ECTs to an audit ledger. + 5. Store verified ECTs (append to audit ledger in full ledger mode, + or retain locally in point-to-point mode per Section 8). Storage Recommendations @@ -2395,6 +2511,17 @@ Interoperability expected to be tested against multiple JWT libraries to ensure interoperability. + + + + + + +Nennemann Expires 28 August 2026 [Page 45] + +Internet-Draft WIMSE Execution Context February 2026 + + Regulatory Compliance Mapping The following table summarizes how ECTs can contribute to compliance @@ -2402,14 +2529,6 @@ Regulatory Compliance Mapping block; achieving compliance requires additional organizational measures beyond this specification. - - - -Nennemann Expires 28 August 2026 [Page 43] - -Internet-Draft WIMSE Execution Context February 2026 - - +============+========================+==========================+ | Regulation | Requirement | ECT Contribution | +============+========================+==========================+ @@ -2450,6 +2569,15 @@ Example 1: Simple Two-Agent Workflow ECT JOSE Header: + + + + +Nennemann Expires 28 August 2026 [Page 46] + +Internet-Draft WIMSE Execution Context February 2026 + + { "alg": "ES256", "typ": "wimse-exec+jwt", @@ -2458,20 +2586,13 @@ Example 1: Simple Two-Agent Workflow ECT Payload: - - - -Nennemann Expires 28 August 2026 [Page 44] - -Internet-Draft WIMSE Execution Context February 2026 - - { "iss": "spiffe://example.com/agent/data-retrieval", "sub": "spiffe://example.com/agent/data-retrieval", "aud": "spiffe://example.com/agent/validator", "iat": 1772064150, "exp": 1772064750, + "jti": "1a2b3c4d-e5f6-7890-abcd-ef0123456701", "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", "tid": "550e8400-e29b-41d4-a716-446655440001", "exec_act": "fetch_patient_data", @@ -2493,6 +2614,7 @@ Internet-Draft WIMSE Execution Context February 2026 "aud": "spiffe://example.com/system/ledger", "iat": 1772064160, "exp": 1772064760, + "jti": "2b3c4d5e-f6a7-8901-bcde-f01234567802", "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", "tid": "550e8400-e29b-41d4-a716-446655440002", "exec_act": "validate_safety", @@ -2505,6 +2627,13 @@ Internet-Draft WIMSE Execution Context February 2026 The resulting DAG: + + +Nennemann Expires 28 August 2026 [Page 47] + +Internet-Draft WIMSE Execution Context February 2026 + + task-...-0001 (fetch_patient_data) | v @@ -2515,13 +2644,6 @@ Example 2: Medical Device SDLC with Release Approval A multi-step medical device software lifecycle workflow with autonomous agents and human release approval: - - -Nennemann Expires 28 August 2026 [Page 45] - -Internet-Draft WIMSE Execution Context February 2026 - - Task 1 (Spec Review Agent): { @@ -2530,6 +2652,7 @@ Internet-Draft WIMSE Execution Context February 2026 "aud": "spiffe://meddev.example/agent/code-gen", "iat": 1772064150, "exp": 1772064750, + "jti": "3c4d5e6f-a7b8-9012-cdef-012345678903", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "tid": "a1b2c3d4-0001-0000-0000-000000000001", "exec_act": "review_requirements_spec", @@ -2544,12 +2667,36 @@ Internet-Draft WIMSE Execution Context February 2026 Task 2 (Code Generation Agent): + + + + + + + + + + + + + + + + + + +Nennemann Expires 28 August 2026 [Page 48] + +Internet-Draft WIMSE Execution Context February 2026 + + { "iss": "spiffe://meddev.example/agent/code-gen", "sub": "spiffe://meddev.example/agent/code-gen", "aud": "spiffe://meddev.example/agent/test-runner", "iat": 1772064200, "exp": 1772064800, + "jti": "4d5e6f7a-b8c9-0123-def0-123456789004", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "tid": "a1b2c3d4-0001-0000-0000-000000000002", "exec_act": "implement_module", @@ -2562,28 +2709,13 @@ Internet-Draft WIMSE Execution Context February 2026 Task 3 (Autonomous Test Agent): - - - - - - - - - - - -Nennemann Expires 28 August 2026 [Page 46] - -Internet-Draft WIMSE Execution Context February 2026 - - { "iss": "spiffe://meddev.example/agent/test-runner", "sub": "spiffe://meddev.example/agent/test-runner", "aud": "spiffe://meddev.example/agent/build", "iat": 1772064260, "exp": 1772064860, + "jti": "5e6f7a8b-c9d0-1234-ef01-234567890005", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "tid": "a1b2c3d4-0001-0000-0000-000000000003", "exec_act": "execute_test_suite", @@ -2596,12 +2728,31 @@ Internet-Draft WIMSE Execution Context February 2026 Task 4 (Build Agent): + + + + + + + + + + + + + +Nennemann Expires 28 August 2026 [Page 49] + +Internet-Draft WIMSE Execution Context February 2026 + + { "iss": "spiffe://meddev.example/agent/build", "sub": "spiffe://meddev.example/agent/build", "aud": "spiffe://meddev.example/human/release-mgr-42", "iat": 1772064310, "exp": 1772064910, + "jti": "6f7a8b9c-d0e1-2345-f012-345678900006", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "tid": "a1b2c3d4-0001-0000-0000-000000000004", "exec_act": "build_release_artifact", @@ -2614,32 +2765,13 @@ Internet-Draft WIMSE Execution Context February 2026 Task 5 (Human Release Manager Approval): - - - - - - - - - - - - - - - -Nennemann Expires 28 August 2026 [Page 47] - -Internet-Draft WIMSE Execution Context February 2026 - - { "iss": "spiffe://meddev.example/human/release-mgr-42", "sub": "spiffe://meddev.example/human/release-mgr-42", "aud": "spiffe://meddev.example/system/ledger", "iat": 1772064510, "exp": 1772065110, + "jti": "7a8b9c0d-e1f2-3456-0123-456789000007", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "tid": "a1b2c3d4-0001-0000-0000-000000000005", "exec_act": "approve_release", @@ -2658,6 +2790,18 @@ Internet-Draft WIMSE Execution Context February 2026 build, and a human release manager approved the final release with independent witness attestation. + + + + + + + +Nennemann Expires 28 August 2026 [Page 50] + +Internet-Draft WIMSE Execution Context February 2026 + + task-...-0001 (review_requirements_spec) | v @@ -2683,13 +2827,6 @@ Example 3: Parallel Execution with Join A workflow where two tasks execute in parallel and a third task depends on both: - - -Nennemann Expires 28 August 2026 [Page 48] - -Internet-Draft WIMSE Execution Context February 2026 - - task-...-0001 (assess_risk) | \ v v @@ -2702,12 +2839,32 @@ Internet-Draft WIMSE Execution Context February 2026 Task 004 ECT payload: + + + + + + + + + + + + + + +Nennemann Expires 28 August 2026 [Page 51] + +Internet-Draft WIMSE Execution Context February 2026 + + { "iss": "spiffe://bank.example/agent/execution", "sub": "spiffe://bank.example/agent/execution", "aud": "spiffe://bank.example/system/ledger", "iat": 1772064250, "exp": 1772064850, + "jti": "8b9c0d1e-f2a3-4567-1234-567890000008", "wid": "d3e4f5a6-b7c8-9012-def0-123456789012", "tid": "f1e2d3c4-0004-0000-0000-000000000004", "exec_act": "execute_trade", @@ -2741,4 +2898,15 @@ Author's Address -Nennemann Expires 28 August 2026 [Page 49] + + + + + + + + + + + +Nennemann Expires 28 August 2026 [Page 52] diff --git a/draft-nennemann-wimse-execution-context-00.xml b/draft-nennemann-wimse-execution-context-00.xml index 9204ce2..301d638 100644 --- a/draft-nennemann-wimse-execution-context-00.xml +++ b/draft-nennemann-wimse-execution-context-00.xml @@ -32,7 +32,7 @@ - + This document defines Execution Context Tokens (ECTs), an extension to the Workload Identity in Multi System Environments (WIMSE) @@ -64,7 +64,7 @@ regulatory frameworks. - +
    Introduction @@ -149,6 +149,8 @@ regulatory audit scenarios. Integration with the WIMSE identity framework () An HTTP header for ECT transport () + Operational modes including ledger-optional deployment +() Audit ledger interface requirements () @@ -795,6 +797,13 @@ 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 +). 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. +
    Validation Rules @@ -804,12 +813,13 @@ the following DAG validation steps: Task ID Uniqueness: The "tid" claim MUST be unique within the applicable scope (the workflow identified by "wid", or the -entire ledger if "wid" is absent). If a task with the same +entire ECT store if "wid" is absent). If a task with the same "tid" already exists, the ECT MUST be rejected. Parent Existence: Every task identifier listed in the "par" -array MUST correspond to a task that has been previously -recorded in the ledger. If any parent task is not found, the -ECT MUST be rejected. +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. 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). @@ -817,7 +827,7 @@ 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 ledger), not by +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. Acyclicity: Following the chain of parent references MUST NOT @@ -841,14 +851,15 @@ relationship has been established. The following pseudocode describes the DAG validation procedure:
    = ect.iat + clock_skew_tolerance: @@ -856,15 +867,15 @@ function validate_dag(ect, ledger, clock_skew_tolerance): // Step 3: Cycle detection (with traversal limit) visited = set() - result = has_cycle(ect.tid, ect.par, ledger, visited, + result = has_cycle(ect.tid, ect.par, ect_store, visited, max_ancestor_limit) if result is error or result is true: return error("Circular dependency or depth limit exceeded") return success -function has_cycle(target_tid, parent_ids, ledger, visited, - max_depth): +function has_cycle(target_tid, parent_ids, ect_store, + visited, max_depth): if visited.size() >= max_depth: return error("Maximum ancestor traversal limit exceeded") for parent_id in parent_ids: @@ -873,9 +884,9 @@ function has_cycle(target_tid, parent_ids, ledger, visited, if parent_id in visited: continue visited.add(parent_id) - parent = ledger.get(parent_id) + parent = ect_store.get(parent_id) if parent is not null: - result = has_cycle(target_tid, parent.par, ledger, + result = has_cycle(target_tid, parent.par, ect_store, visited, max_depth) if result is error or result is true: return result @@ -938,8 +949,10 @@ verifier's current time, to account for clock skew). Verify "pol_decision" is one of "approved", "rejected", or "pending_human_review". Perform DAG validation per . - If all checks pass, the ECT MUST be appended to the audit -ledger. + If all checks pass and an audit ledger is available, the ECT +SHOULD be appended to the audit ledger. In point-to-point +mode (), the verified ECT is retained +locally by the receiving agent. If any verification step fails, the ECT MUST be rejected and the @@ -1020,24 +1033,101 @@ function verify_ect(ect_jws, verifier_id, ["approved", "rejected", "pending_human_review"]: return reject("Invalid pol_decision value") - // Validate DAG - result = validate_dag(payload, ledger, + // Validate DAG (against ledger or inline parent ECTs) + result = validate_dag(payload, ect_store, clock_skew_tolerance) if result is error: return reject("DAG validation failed") - // All checks passed; append to ledger - ledger.append(payload) + // All checks passed + if ledger is available: + ledger.append(payload) + else: + // Point-to-point mode: retain locally + local_ect_cache.store(payload) return accept ]]>
    +
    + +
    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 + +In point-to-point mode, agents pass parent ECTs directly to +downstream agents via multiple Execution-Context HTTP headers. +No centralized ledger is required. The receiving agent verifies +each parent ECT independently and validates the DAG against the +set of ECTs received in the request. + +This mode is suitable for: + + + Cross-organizational workflows where no shared ledger exists + Lightweight deployments where infrastructure is constrained + Early adoption scenarios before ledger infrastructure is +available + + +Limitations of point-to-point mode: + + + No persistent audit trail unless agents independently retain +ECTs + Global replay detection relies solely on "jti" caches at each +agent; there is no centralized "tid" uniqueness check + The parent ECT chain grows with each hop, increasing HTTP +header size + 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 + +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 + +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
    Overview -ECTs are designed to be recorded in an immutable audit ledger for +Use of an audit ledger is RECOMMENDED for regulated environments +and any deployment requiring persistent, centralized audit trails. +ECTs are designed to be recorded in an immutable audit ledger for compliance verification and post-hoc analysis. This specification defines the logical interface for the ledger but does not mandate a specific storage technology. Implementations MAY use @@ -1249,6 +1339,7 @@ a cryptographic link to the original task: "aud": "spiffe://bank.example/system/ledger", "iat": 1772150550, "exp": 1772151150, + "jti": "e4f5a6b7-c8d9-0123-ef01-234567890abc", "wid": "d3e4f5a6-b7c8-9012-def0-123456789012", "tid": "550e8400-e29b-41d4-a716-446655440099", "exec_act": "initiate_trade_rollback", @@ -2243,6 +2334,36 @@ been incorporated into this document. This document obsoletes RFC + + + Transaction Tokens + + SGNL + + + Practical Identity LLC + + + Defakto Security + + + + Transaction Tokens (Txn-Tokens) are designed to maintain and + propagate user identity and authorization context across workloads + within a trusted domain during the processing of external requests, + such as API calls. They ensure that this context is preserved + throughout the call chain, even when new transactions are initiated + internally, thereby enhancing security and consistency in complex, + multi-service architectures. + + + + + + + + *** BROKEN REFERENCE *** + @@ -2250,7 +2371,7 @@ been incorporated into this document. This document obsoletes RFC - +
    Related Work @@ -2265,15 +2386,64 @@ evaluated?" Together they form an identity-plus-accountability framework for regulated agentic systems.
    -
    OAuth 2.0 Token Exchange +
    OAuth 2.0 Token Exchange and the "act" Claim defines the OAuth 2.0 Token Exchange protocol and registers the "act" (Actor) claim in the JWT Claims registry. -ECTs intentionally use the distinct claim name "exec_act" for the -action/task type to avoid collision with the "act" claim. -Transaction tokens in OAuth establish API authorization context; -ECTs serve the complementary purpose of recording execution -accountability across multi-step workflows. +The "act" claim creates nested JSON objects representing a +delegation chain: "who is acting on behalf of whom." While +the nesting superficially resembles a chain, it is strictly +linear (each "act" object contains at most one nested "act"), +represents authorization delegation rather than task execution, +and carries no task identifiers, policy decisions, or +input/output integrity data. The "act" chain cannot represent +branching (fan-out) or convergence (fan-in) and therefore +cannot form a DAG. + +ECTs intentionally use the distinct claim name "exec_act" for the +action/task type to avoid collision with the "act" claim. The +two concepts are orthogonal: "act" records "who authorized whom," +ECTs record "what was done, in what order, with what policy +outcomes." + +
    +
    Transaction Tokens + +OAuth Transaction Tokens +propagate authorization context across workload call chains. +The Txn-Token "req_wl" claim accumulates a comma-separated list +of workloads that requested replacement tokens, which is the +closest existing mechanism to call-chain recording. + +However, "req_wl" cannot form a DAG because: + + + It is linear: a comma-separated string with no branching or +merging representation. When a workload fans out to multiple +downstream services, each receives the same "req_wl" value and +the branching is invisible. + It is incomplete: only workloads that request a replacement +token from the Transaction Token Service appear in "req_wl"; +workloads that forward the token unchanged are not recorded. + It carries no task-level granularity, no parent references, +no policy evaluation outcomes, and no execution content. + + +Extensions for agentic use cases +() add agent +identity and constraints ("agentic_ctx") but no execution +ordering or DAG structure. + +ECTs and Transaction Tokens are complementary: a Txn-Token +propagates authorization context ("this request is authorized +for scope X on behalf of user Y"), while an ECT records +execution accountability ("task T was performed, depending on +tasks P1 and P2, with policy Z evaluated and approved"). An +agent request could carry both a Txn-Token for authorization +and an ECT for execution recording. The WPT "tth" claim +defined in 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) @@ -2348,7 +2518,9 @@ matching the WIT (ES256 recommended). Verify ECT signatures against WIT public keys. Perform DAG validation (parent existence, temporal ordering, cycle detection). - Append verified ECTs to an audit ledger. + Store verified ECTs (append to audit ledger in full ledger +mode, or retain locally in point-to-point mode per +).
    @@ -2447,6 +2619,7 @@ Agent B: "aud": "spiffe://example.com/agent/validator", "iat": 1772064150, "exp": 1772064750, + "jti": "1a2b3c4d-e5f6-7890-abcd-ef0123456701", "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", "tid": "550e8400-e29b-41d4-a716-446655440001", "exec_act": "fetch_patient_data", @@ -2470,6 +2643,7 @@ task, and creates its own ECT: "aud": "spiffe://example.com/system/ledger", "iat": 1772064160, "exp": 1772064760, + "jti": "2b3c4d5e-f6a7-8901-bcde-f01234567802", "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", "tid": "550e8400-e29b-41d4-a716-446655440002", "exec_act": "validate_safety", @@ -2505,6 +2679,7 @@ autonomous agents and human release approval: "aud": "spiffe://meddev.example/agent/code-gen", "iat": 1772064150, "exp": 1772064750, + "jti": "3c4d5e6f-a7b8-9012-cdef-012345678903", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "tid": "a1b2c3d4-0001-0000-0000-000000000001", "exec_act": "review_requirements_spec", @@ -2527,6 +2702,7 @@ autonomous agents and human release approval: "aud": "spiffe://meddev.example/agent/test-runner", "iat": 1772064200, "exp": 1772064800, + "jti": "4d5e6f7a-b8c9-0123-def0-123456789004", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "tid": "a1b2c3d4-0001-0000-0000-000000000002", "exec_act": "implement_module", @@ -2547,6 +2723,7 @@ autonomous agents and human release approval: "aud": "spiffe://meddev.example/agent/build", "iat": 1772064260, "exp": 1772064860, + "jti": "5e6f7a8b-c9d0-1234-ef01-234567890005", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "tid": "a1b2c3d4-0001-0000-0000-000000000003", "exec_act": "execute_test_suite", @@ -2567,6 +2744,7 @@ autonomous agents and human release approval: "aud": "spiffe://meddev.example/human/release-mgr-42", "iat": 1772064310, "exp": 1772064910, + "jti": "6f7a8b9c-d0e1-2345-f012-345678900006", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "tid": "a1b2c3d4-0001-0000-0000-000000000004", "exec_act": "build_release_artifact", @@ -2587,6 +2765,7 @@ autonomous agents and human release approval: "aud": "spiffe://meddev.example/system/ledger", "iat": 1772064510, "exp": 1772065110, + "jti": "7a8b9c0d-e1f2-3456-0123-456789000007", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "tid": "a1b2c3d4-0001-0000-0000-000000000005", "exec_act": "approve_release", @@ -2655,6 +2834,7 @@ task-...-0004 (execute_trade) "aud": "spiffe://bank.example/system/ledger", "iat": 1772064250, "exp": 1772064850, + "jti": "8b9c0d1e-f2a3-4567-1234-567890000008", "wid": "d3e4f5a6-b7c8-9012-def0-123456789012", "tid": "f1e2d3c4-0004-0000-0000-000000000004", "exec_act": "execute_trade", @@ -2688,529 +2868,579 @@ tracing is built.