



WIMSE                                                       C. Nennemann
Internet-Draft                                    Independent Researcher
Intended status: Standards Track                        25 February 2026
Expires: 29 August 2026


       Execution Context Tokens for Distributed Agentic Workflows
               draft-nennemann-wimse-execution-context-00

Abstract

   This document defines Execution Context Tokens (ECTs), an extension
   to the Workload Identity in Multi System Environments (WIMSE)
   architecture for distributed agentic workflows in regulated
   environments.  ECTs provide signed, structured records of task
   execution order and compliance state across agent-to-agent
   communication.  By extending WIMSE Workload Identity Tokens with
   execution context claims in JSON Web Token (JWT) format, this
   specification enables regulated systems to maintain structured audit
   trails that support compliance verification.  ECTs use a directed
   acyclic graph (DAG) structure to represent task dependencies and
   integrate with WIMSE Workload Identity Tokens (WIT) using the same
   signing model and cryptographic primitives.  Policy evaluation and
   compensation extensions are defined in [I-D.nennemann-wimse-ect-pol].
   A new HTTP header field, Execution-Context, is defined for
   transporting ECTs alongside existing WIMSE headers.  ECTs are a
   technical building block that supports, but does not by itself
   constitute, compliance with regulatory frameworks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 29 August 2026.






Nennemann                Expires 29 August 2026                 [Page 1]

Internet-Draft           WIMSE Execution Context           February 2026


Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Problem Statement . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Scope and Applicability . . . . . . . . . . . . . . . . .   5
     1.4.  Relationship to Regulatory Compliance . . . . . . . . . .   5
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   6
   3.  WIMSE Architecture Integration  . . . . . . . . . . . . . . .   6
     3.1.  WIMSE Foundation  . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Extension Model . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  Integration Points  . . . . . . . . . . . . . . . . . . .   8
   4.  Execution Context Token Format  . . . . . . . . . . . . . . .   9
     4.1.  JOSE Header . . . . . . . . . . . . . . . . . . . . . . .   9
     4.2.  JWT Claims  . . . . . . . . . . . . . . . . . . . . . . .   9
       4.2.1.  Standard JWT Claims . . . . . . . . . . . . . . . . .   9
       4.2.2.  Execution Context . . . . . . . . . . . . . . . . . .  11
       4.2.3.  Data Integrity  . . . . . . . . . . . . . . . . . . .  11
       4.2.4.  Compensation and Rollback . . . . . . . . . . . . . .  12
       4.2.5.  Extensions  . . . . . . . . . . . . . . . . . . . . .  12
     4.3.  Complete ECT Example  . . . . . . . . . . . . . . . . . .  13
   5.  HTTP Header Transport . . . . . . . . . . . . . . . . . . . .  13
     5.1.  Execution-Context Header Field  . . . . . . . . . . . . .  13
   6.  DAG Validation  . . . . . . . . . . . . . . . . . . . . . . .  14
     6.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  14
     6.2.  Validation Rules  . . . . . . . . . . . . . . . . . . . .  14
     6.3.  DAG Validation Algorithm  . . . . . . . . . . . . . . . .  15
   7.  Signature and Token Verification  . . . . . . . . . . . . . .  17
     7.1.  Verification Procedure  . . . . . . . . . . . . . . . . .  17
     7.2.  Verification Pseudocode . . . . . . . . . . . . . . . . .  18
   8.  Audit Ledger Interface  . . . . . . . . . . . . . . . . . . .  20
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
     9.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  20
     9.2.  Self-Assertion Limitation . . . . . . . . . . . . . . . .  21



Nennemann                Expires 29 August 2026                 [Page 2]

Internet-Draft           WIMSE Execution Context           February 2026


     9.3.  Organizational Prerequisites  . . . . . . . . . . . . . .  21
     9.4.  Signature Verification  . . . . . . . . . . . . . . . . .  22
     9.5.  Replay Attack Prevention  . . . . . . . . . . . . . . . .  22
     9.6.  Man-in-the-Middle Protection  . . . . . . . . . . . . . .  22
     9.7.  Key Compromise  . . . . . . . . . . . . . . . . . . . . .  23
     9.8.  Collusion and False Claims  . . . . . . . . . . . . . . .  23
     9.9.  Denial of Service . . . . . . . . . . . . . . . . . . . .  24
     9.10. Timestamp Accuracy  . . . . . . . . . . . . . . . . . . .  24
     9.11. ECT Size Constraints  . . . . . . . . . . . . . . . . . .  24
   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  24
     10.1.  Data Exposure in ECTs  . . . . . . . . . . . . . . . . .  24
     10.2.  Data Minimization  . . . . . . . . . . . . . . . . . . .  25
     10.3.  Storage and Access Control . . . . . . . . . . . . . . .  25
     10.4.  Regulatory Access  . . . . . . . . . . . . . . . . . . .  25
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
     11.1.  Media Type Registration  . . . . . . . . . . . . . . . .  25
     11.2.  HTTP Header Field Registration . . . . . . . . . . . . .  26
     11.3.  JWT Claims Registration  . . . . . . . . . . . . . . . .  27
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  27
     12.2.  Informative References . . . . . . . . . . . . . . . . .  28
   Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . .  30
     Medical Device SDLC Workflow  . . . . . . . . . . . . . . . . .  30
       FDA Audit with DAG Reconstruction . . . . . . . . . . . . . .  31
     Financial Trading Workflow  . . . . . . . . . . . . . . . . . .  32
     Compensation and Rollback . . . . . . . . . . . . . . . . . . .  33
     Autonomous Logistics Coordination . . . . . . . . . . . . . . .  33
   Related Work  . . . . . . . . . . . . . . . . . . . . . . . . . .  34
     WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . .  34
     OAuth 2.0 Token Exchange and the "act" Claim  . . . . . . . . .  34
     Transaction Tokens  . . . . . . . . . . . . . . . . . . . . . .  35
     Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . .  36
     Blockchain and Distributed Ledgers  . . . . . . . . . . . . . .  36
     SCITT (Supply Chain Integrity, Transparency, and Trust) . . . .  36
     W3C Verifiable Credentials  . . . . . . . . . . . . . . . . . .  37
   Implementation Guidance . . . . . . . . . . . . . . . . . . . . .  37
     Minimal Implementation  . . . . . . . . . . . . . . . . . . . .  37
     Storage Recommendations . . . . . . . . . . . . . . . . . . . .  37
     Performance Considerations  . . . . . . . . . . . . . . . . . .  37
     Interoperability  . . . . . . . . . . . . . . . . . . . . . . .  38
   Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . .  38
   Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  39
     Example 1: Simple Two-Agent Workflow  . . . . . . . . . . . . .  39
     Example 2: Medical Device SDLC with Release Approval  . . . . .  40
     Example 3: Parallel Execution with Join . . . . . . . . . . . .  43
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  44
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  44




Nennemann                Expires 29 August 2026                 [Page 3]

Internet-Draft           WIMSE Execution Context           February 2026


1.  Introduction

1.1.  Motivation

   The Workload Identity in Multi System Environments (WIMSE) framework
   [I-D.ietf-wimse-arch] provides robust workload authentication through
   Workload Identity Tokens (WIT) and Workload Proof Tokens (WPT).  The
   WIMSE service-to-service protocol [I-D.ietf-wimse-s2s-protocol]
   defines how workloads authenticate each other across call chains
   using the Workload-Identity and Workload-Proof-Token HTTP headers.

   However, workload identity alone does not address execution
   accountability.  Knowing who performed an action does not record what
   was done or in what order.

   Regulated environments increasingly deploy autonomous agents that
   coordinate across organizational boundaries.  Domains such as
   healthcare, finance, and logistics require structured, auditable
   records of automated decision-making and execution.  Table 2 in the
   appendix illustrates how ECTs relate to specific regulatory
   frameworks.

   This document defines an extension to the WIMSE architecture that
   addresses the gap between workload identity and execution
   accountability.  WIMSE authenticates agents; this extension records
   what they did and in what order.

   As identified in [I-D.ni-wimse-ai-agent-identity], call context in
   agentic workflows needs to be visible and preserved.  ECTs provide a
   mechanism to address this requirement with cryptographic assurances.

1.2.  Problem Statement

   Three core gaps exist in current approaches to regulated agentic
   systems:

   1.  WIMSE authenticates agents but does not record what they actually
       did.  A WIT proves "Agent A is authorized" but not "Agent A
       executed Task X, producing Output Z."

   2.  No standard mechanism exists to cryptographically order and link
       task execution across a multi-agent workflow.

   3.  No mechanism exists to reconstruct the complete execution history
       of a distributed workflow for audit purposes.






Nennemann                Expires 29 August 2026                 [Page 4]

Internet-Draft           WIMSE Execution Context           February 2026


   Existing observability tools such as distributed tracing
   [OPENTELEMETRY] provide visibility for debugging and monitoring but
   do not provide cryptographic assurances.  Tracing data is not
   cryptographically signed, not tamper-evident, and not designed for
   regulatory audit scenarios.

1.3.  Scope and Applicability

   This document defines:

   *  The Execution Context Token (ECT) format (Section 4)

   *  DAG structure for task dependency ordering (Section 6)

   *  Integration with the WIMSE identity framework (Section 3)

   *  An HTTP header for ECT transport (Section 5)

   *  Audit ledger interface requirements (Section 8)

   *  Policy evaluation and compensation extensions are defined
      separately in [I-D.nennemann-wimse-ect-pol]

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

   *  Workload authentication and identity provisioning

   *  Key distribution and management

   *  Trust domain establishment and management

   *  Credential lifecycle management

1.4.  Relationship to Regulatory Compliance

   ECTs are a technical mechanism that can support compliance programs
   by providing structured, cryptographically signed execution records.
   ECTs do not by themselves constitute compliance with any regulatory
   framework referenced in this document.

   Compliance with each referenced regulation requires organizational
   controls, policies, procedures, validation, and governance measures
   beyond the scope of this specification.  The regulatory references in
   this document are intended to motivate the design requirements, not
   to claim that implementing ECTs satisfies these regulations.






Nennemann                Expires 29 August 2026                 [Page 5]

Internet-Draft           WIMSE Execution Context           February 2026


   ECTs provide evidence of claimed execution ordering.  They do not
   independently verify that the claimed execution actually occurred as
   described or that the agent faithfully performed the stated action.
   The trustworthiness of ECT claims depends on the trustworthiness of
   the signing agent and the integrity of the broader deployment
   environment.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The following terms are used in this document:

   Agent:  An autonomous workload, as defined by WIMSE
      [I-D.ietf-wimse-arch], that executes tasks within a workflow.

   Task:  A discrete unit of agent work that consumes inputs and
      produces outputs.

   Directed Acyclic Graph (DAG):  A graph structure representing task
      dependency ordering where edges are directed and no cycles exist.

   Execution Context Token (ECT):  A JSON Web Token [RFC7519] defined by
      this specification that records task execution details.

   Audit Ledger:  An append-only, immutable log of all ECTs within a
      workflow or set of workflows, used for regulatory audit and
      compliance verification.

   Workload Identity Token (WIT):  A WIMSE credential proving a
      workload's identity within a trust domain.

   Workload Proof Token (WPT):  A WIMSE proof-of-possession token used
      for request-level authentication.

   Trust Domain:  A WIMSE concept representing an organizational
      boundary with a shared identity issuer, corresponding to a SPIFFE
      [SPIFFE] trust domain.

   Witness:  A third-party entity that observes and attests to the
      execution of a task, providing additional accountability.

3.  WIMSE Architecture Integration




Nennemann                Expires 29 August 2026                 [Page 6]

Internet-Draft           WIMSE Execution Context           February 2026


3.1.  WIMSE Foundation

   The WIMSE architecture [I-D.ietf-wimse-arch] defines:

   *  Workload Identity Tokens (WIT) that prove a workload's identity
      within a trust domain ("I am Agent X in trust domain Y")

   *  Workload Proof Tokens (WPT) that prove possession of the private
      key associated with a WIT ("I control the key for Agent X")

   *  Multi-hop authentication via the service-to-service protocol
      [I-D.ietf-wimse-s2s-protocol]

   The following execution accountability needs are complementary to the
   WIMSE scope and are not addressed by workload identity alone:

   *  Recording what agents actually do with their authenticated
      identity

   *  Maintaining structured execution records

   *  Linking actions to their predecessors with cryptographic assurance

3.2.  Extension Model

   ECTs extend WIMSE by adding an execution accountability layer between
   the identity layer and the application layer:

   +--------------------------------------------------+
   |  WIMSE Layer (Identity)                          |
   |    WIT: "I am Agent X (spiffe://td/agent/x)"    |
   |    WPT: "I prove I control the key for Agent X"  |
   +--------------------------------------------------+
                          |
                          v
   +--------------------------------------------------+
   |  ECT Layer (Execution Accountability) [This Spec]|
   |    ECT: "Task executed, dependencies met,        |
   |          inputs/outputs hashed"                   |
   +--------------------------------------------------+
                          |
                          v
   +--------------------------------------------------+
   |  Optional: Audit Ledger (Immutable Record)       |
   |    "ECTs MAY be appended to an audit ledger"     |
   +--------------------------------------------------+

               Figure 1: WIMSE Extension Architecture Layers



Nennemann                Expires 29 August 2026                 [Page 7]

Internet-Draft           WIMSE Execution Context           February 2026


   This extension reuses the WIMSE signing model, extends JWT claims
   using standard JWT extensibility [RFC7519], and maintains WIMSE
   concepts including trust domains and workload identifiers.

3.3.  Integration Points

   An ECT integrates with the WIMSE identity framework through the
   following mechanisms:

   *  The ECT JOSE header "kid" parameter MUST reference the public key
      identifier from the agent's WIT.

   *  In WIMSE deployments, the ECT "iss" claim SHOULD use the WIMSE
      workload identifier format (a SPIFFE ID [SPIFFE]).

   *  The ECT MUST be signed with the same private key associated with
      the agent's WIT.

   *  The ECT signing algorithm (JOSE header "alg" parameter) MUST match
      the algorithm used in the corresponding WIT.

   When an agent makes an HTTP request to another agent, the Execution-
   Context header is carried alongside WIMSE identity headers:

   HTTP Request from Agent A to Agent B:
     Workload-Identity:    <WIT for Agent A>
     Execution-Context:    <ECT recording what A did>

                       Figure 2: HTTP Header Stacking

   When a Workload Proof Token (WPT) is available per
   [I-D.ietf-wimse-s2s-protocol], agents SHOULD include it alongside the
   WIT and ECT.  ECT verification does not depend on the presence of a
   WPT; the ECT is independently verifiable via the WIT public key.

   The receiving agent (Agent B) verifies in order:

   1.  WIT (WIMSE layer): Verifies Agent A's identity within the trust
       domain.  WPT verification, if present, per
       [I-D.ietf-wimse-s2s-protocol].

   2.  ECT (this extension): Records what Agent A did and what precedent
       tasks exist.

   3.  Ledger (if deployed): Appends the verified ECT to the audit
       ledger.





Nennemann                Expires 29 August 2026                 [Page 8]

Internet-Draft           WIMSE Execution Context           February 2026


4.  Execution Context Token Format

   An Execution Context Token is a JSON Web Token (JWT) [RFC7519] signed
   as a JSON Web Signature (JWS) [RFC7515] using the Compact
   Serialization.  JWS JSON Serialization MUST NOT be used for ECTs.

4.1.  JOSE Header

   The ECT JOSE header MUST contain the following parameters:

   {
     "alg": "ES256",
     "typ": "wimse-exec+jwt",
     "kid": "agent-a-key-id-123"
   }

                     Figure 3: ECT JOSE Header Example

   alg:  REQUIRED.  The digital signature algorithm used to sign the
      ECT.  MUST match the algorithm in the corresponding WIT.
      Implementations MUST support ES256 [RFC7518].  The "alg" value
      MUST NOT be "none".  Symmetric algorithms (e.g., HS256, HS384,
      HS512) MUST NOT be used, as ECTs require asymmetric signatures for
      non-repudiation.

   typ:  REQUIRED.  MUST be set to "wimse-exec+jwt" to distinguish ECTs
      from other JWT types, consistent with the WIMSE convention for
      type parameter values.

   kid:  REQUIRED.  The key identifier referencing the public key from
      the agent's WIT [RFC7517].  Used by verifiers to look up the
      correct public key for signature verification.

4.2.  JWT Claims

   The ECT payload contains both WIMSE-compatible standard JWT claims
   and execution context claims defined by this specification.

4.2.1.  Standard JWT Claims

   The following standard JWT claims [RFC7519] MUST be present in every
   ECT:

   iss:  REQUIRED.  StringOrURI.  A URI identifying the issuer of the
      ECT.  In WIMSE deployments, this SHOULD be the workload's SPIFFE
      ID in the format spiffe://<trust-domain>/<path>, matching the
      "sub" claim of the agent's WIT.  Non-WIMSE deployments MAY use
      other URI schemes (e.g., HTTPS URLs or URN:UUID identifiers).



Nennemann                Expires 29 August 2026                 [Page 9]

Internet-Draft           WIMSE Execution Context           February 2026


   aud:  REQUIRED.  StringOrURI or array of StringOrURI.  The intended
      recipient(s) of the ECT.  Because ECTs serve as both inter-agent
      messages and audit records, the "aud" claim SHOULD contain the
      identifiers of all entities that will verify the ECT.  In practice
      this means:

      *  *Point-to-point delivery*: when an ECT is sent from one agent
         to a single next agent, "aud" contains that agent's workload
         identity.  The receiving agent verifies the ECT and forwards it
         to the ledger on behalf of the issuer.

      *  *Direct-to-ledger submission*: when an ECT is submitted
         directly to the audit ledger (e.g., after a join or at workflow
         completion), "aud" contains the ledger's identity.

      *  *Multi-audience*: when an ECT must be verified by both the next
         agent and the ledger independently, "aud" MUST be an array
         containing both identifiers (e.g.,
         ["spiffe://example.com/agent/next",
         "spiffe://example.com/system/ledger"]).  Each verifier checks
         that its own identity appears in the array.

      In multi-parent (join) scenarios where a task depends on ECTs from
      multiple parent agents, the joining agent creates a new ECT with
      the parent task IDs in "par".  The "aud" of this new ECT is set
      according to the rules above based on where the ECT will be
      delivered — it is independent of the "aud" values in the parent
      ECTs.

   iat:  REQUIRED.  NumericDate.  The time at which the ECT was issued.
      The ECT records a completed action, so the "iat" value reflects
      when the record was created, not when task execution began.

   exp:  REQUIRED.  NumericDate.  The expiration time of the ECT.
      Implementations SHOULD set this to 5 to 15 minutes after "iat" to
      limit the replay window while allowing for reasonable clock skew
      and processing time.

   The standard JWT "nbf" (Not Before) claim is not used in ECTs because
   ECTs record completed actions and are valid immediately upon
   issuance.

   jti:  REQUIRED.  String.  A globally unique identifier for both the
      ECT and the task it records, in UUID format [RFC9562].  Since each
      ECT represents exactly one task, "jti" serves as both the token
      identifier (for replay detection) and the task identifier (for DAG
      parent references in "par").  Receivers MUST reject ECTs whose
      "jti" has already been seen within the expiration window.  When



Nennemann                Expires 29 August 2026                [Page 10]

Internet-Draft           WIMSE Execution Context           February 2026


      "wid" is present, uniqueness is scoped to the workflow; when "wid"
      is absent, uniqueness MUST be enforced globally across the ECT
      store.

4.2.2.  Execution Context

   The following claims are defined by this specification:

   wid:  OPTIONAL.  String.  A workflow identifier that groups related
      ECTs into a single workflow.  When present, MUST be a UUID
      [RFC9562].

   exec_act:  REQUIRED.  String.  The action or task type identifier
      describing what the agent performed (e.g., "process_payment",
      "validate_safety", "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 the "jti"
      value of a previously verified ECT.  An empty array indicates a
      root task with no dependencies.  A workflow MAY contain multiple
      root tasks.

4.2.3.  Data Integrity

   The following claims provide integrity verification for task inputs
   and outputs without revealing the data itself:

   inp_hash:  OPTIONAL.  String.  A cryptographic hash of the input
      data, formatted as "hash-algorithm:base64url-encoded-hash" (e.g.,
      "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg").  The hash
      algorithm identifier MUST be a lowercase value from the IANA Named
      Information Hash Algorithm Registry (e.g., "sha-256", "sha-384",
      "sha-512").  Implementations MUST support "sha-256" and SHOULD use
      "sha-256" unless a stronger algorithm is required.
      Implementations MUST NOT accept hash algorithms weaker than
      SHA-256 (e.g., MD5, SHA-1).  The hash MUST be computed over the
      raw octets of the input data.

   out_hash:  OPTIONAL.  String.  A cryptographic hash of the output
      data, using the same format and algorithm requirements as
      "inp_hash".








Nennemann                Expires 29 August 2026                [Page 11]

Internet-Draft           WIMSE Execution Context           February 2026


4.2.4.  Compensation and Rollback

   Compensation and rollback extensions are defined in
   [I-D.nennemann-wimse-ect-pol].  The referenced parent ECTs may have
   passed their own "exp" time; ECT expiration applies to the
   verification window of the ECT itself, not to its validity as a
   parent reference in the ECT store.

4.2.5.  Extensions

   ext:  OPTIONAL.  Object.  An extension object for domain-specific
      claims not defined by this specification.  Implementations that do
      not understand extension claims MUST ignore them.

   To avoid key collisions between different domains, extension key
   names SHOULD use reverse domain notation (e.g.,
   "com.example.custom_field") to avoid collisions between independently
   developed extensions.  To prevent abuse and excessive token size, the
   serialized JSON representation of the "ext" object SHOULD NOT exceed
   4096 bytes, and the JSON nesting depth within the "ext" object SHOULD
   NOT exceed 5 levels.  Implementations SHOULD reject ECTs whose "ext"
   claim exceeds these limits.

   The following extension keys are defined by this specification for
   common use cases.  Because these keys are documented here, they use
   short names without reverse domain prefixes:

   *  "exec_time_ms": Integer.  Execution duration in milliseconds.

   *  "regulated_domain": String.  Regulatory domain (e.g., "medtech",
      "finance", "military").

   *  "model_version": String.  AI/ML model version.

   *  "witnessed_by": Array of StringOrURI.  Identifiers of third-party
      entities that the issuer claims observed the task.  Note: this is
      self-asserted; for verifiable witness attestation, witnesses
      should submit independent signed ECTs.

   *  "inp_classification": String.  Data sensitivity classification
      (e.g., "public", "confidential", "restricted").

   Additional extension keys for policy evaluation and compensation are
   defined in [I-D.nennemann-wimse-ect-pol].







Nennemann                Expires 29 August 2026                [Page 12]

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",
     "aud": "spiffe://example.com/agent/safety",
     "iat": 1772064150,
     "exp": 1772064750,
     "jti": "550e8400-e29b-41d4-a716-446655440001",

     "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
     "exec_act": "recommend_treatment",
     "par": [],

     "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
     "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",

     "ext": {
       "exec_time_ms": 245,
       "regulated_domain": "medtech",
       "model_version": "clinical-reasoning-v4.2"
     }
   }

                   Figure 4: Complete ECT Payload Example

5.  HTTP Header Transport

5.1.  Execution-Context Header Field

   This specification defines the Execution-Context HTTP header field
   [RFC9110] for transporting ECTs between agents.

   The header field value is the ECT in JWS Compact Serialization format
   [RFC7515].  The value consists of three Base64url-encoded parts
   separated by period (".") characters.

   An agent sending a request to another agent includes the Execution-
   Context header alongside the WIMSE Workload-Identity header:

   GET /api/safety-check HTTP/1.1
   Host: safety-agent.example.com
   Workload-Identity: eyJhbGci...WIT...
   Execution-Context: eyJhbGci...ECT...

                   Figure 5: HTTP Request with ECT Header




Nennemann                Expires 29 August 2026                [Page 13]

Internet-Draft           WIMSE Execution Context           February 2026


   When multiple parent tasks contribute context to a single request,
   multiple Execution-Context header field lines MAY be included, each
   carrying a separate ECT in JWS Compact Serialization format.

   When a receiver processes multiple Execution-Context headers, it MUST
   individually verify each ECT per the procedure in Section 7.  If any
   single ECT fails verification, the receiver MUST reject the entire
   request.  The set of verified parent task IDs across all received
   ECTs represents the complete set of parent dependencies available for
   the receiving agent's subsequent ECT.

6.  DAG Validation

6.1.  Overview

   ECTs form a Directed Acyclic Graph (DAG) where each task references
   its parent tasks via the "par" claim.  This structure provides a
   cryptographically signed record of execution ordering, enabling
   auditors to reconstruct the complete workflow and verify that
   required predecessor tasks were recorded before dependent tasks.

   DAG validation is performed against the ECT store — either an audit
   ledger or the set of parent ECTs received inline.

6.2.  Validation Rules

   When receiving and verifying an ECT, implementations MUST perform the
   following DAG validation steps:

   1.  Task ID Uniqueness: The "jti" claim MUST be unique within the
       applicable scope (the workflow identified by "wid", or the entire
       ECT store if "wid" is absent).  If an ECT with the same "jti"
       already exists, the ECT MUST be rejected.

   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.












Nennemann                Expires 29 August 2026                [Page 14]

Internet-Draft           WIMSE Execution Context           February 2026


   3.  Temporal Ordering: The "iat" value of every parent task MUST NOT
       be greater than the "iat" value of the current task plus a
       configurable clock skew tolerance (RECOMMENDED: 30 seconds).
       That is, for each parent: parent.iat < child.iat +
       clock_skew_tolerance.  The tolerance accounts for clock skew
       between agents; it does not guarantee strict causal ordering from
       timestamps alone.  Causal ordering is primarily enforced by the
       DAG structure (parent existence in the ECT store), not by
       timestamps.  If any parent task violates this constraint, the ECT
       MUST be rejected.

   4.  Acyclicity: Following the chain of parent references MUST NOT
       lead back to the current ECT's "jti".  If a cycle is detected,
       the ECT MUST be rejected.

   5.  Trust Domain Consistency: Parent tasks SHOULD belong to the same
       trust domain or to a trust domain with which a federation
       relationship has been established.

6.3.  DAG Validation Algorithm

   The following pseudocode describes the DAG validation procedure:





























Nennemann                Expires 29 August 2026                [Page 15]

Internet-Draft           WIMSE Execution Context           February 2026


   function validate_dag(ect, ect_store, clock_skew_tolerance):
     // Step 1: Uniqueness check
     if ect_store.contains(ect.jti, ect.wid):
       return error("ECT ID already exists")

     // Step 2: Parent existence and temporal ordering
     for parent_id in ect.par:
       parent = ect_store.get(parent_id)
       if parent is null:
         return error("Parent task not found: " + parent_id)
       if parent.iat >= ect.iat + clock_skew_tolerance:
         return error("Parent task not earlier than current")

     // Step 3: Cycle detection (with traversal limit)
     visited = set()
     result = has_cycle(ect.jti, 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_jti, parent_ids, ect_store,
                      visited, max_depth):
     if visited.size() >= max_depth:
       return error("Maximum ancestor traversal limit exceeded")
     for parent_id in parent_ids:
       if parent_id == target_jti:
         return true
       if parent_id in visited:
         continue
       visited.add(parent_id)
       parent = ect_store.get(parent_id)
       if parent is not null:
         result = has_cycle(target_jti, parent.par, ect_store,
                             visited, max_depth)
         if result is error or result is true:
           return result
     return false

                    Figure 6: DAG Validation Pseudocode

   The cycle detection traverses the ancestor graph rooted at the
   current task's parents.  The complexity is O(V) where V is the number
   of ancestor nodes reachable from the current task's parent
   references.  For typical workflows with shallow DAGs, this is
   efficient.  To prevent denial-of-service via extremely deep or wide
   DAGs, implementations SHOULD enforce a maximum ancestor traversal



Nennemann                Expires 29 August 2026                [Page 16]

Internet-Draft           WIMSE Execution Context           February 2026


   limit (RECOMMENDED: 10000 nodes).  If the limit is reached before
   cycle detection completes, the ECT SHOULD be rejected.
   Implementations SHOULD cache cycle detection results for previously
   verified tasks to avoid redundant traversals.

7.  Signature and Token Verification

7.1.  Verification Procedure

   When an agent receives an ECT, it MUST perform the following
   verification steps in order:

   1.   Parse the JWS Compact Serialization to extract the JOSE header,
        payload, and signature components per [RFC7515].

   2.   Verify that the "typ" header parameter is "wimse-exec+jwt".

   3.   Verify that the "alg" header parameter is not "none" and is not
        a symmetric algorithm.

   4.   Verify the "kid" header parameter references a known, valid
        public key from a WIT within the trust domain.

   5.   Retrieve the public key identified by "kid" and verify the JWS
        signature per [RFC7515] Section 5.2.

   6.   Verify that the signing key identified by "kid" has not been
        revoked within the trust domain.  Implementations MUST check the
        key's revocation status using the trust domain's key lifecycle
        mechanism (e.g., certificate revocation list, OCSP, or SPIFFE
        trust bundle updates).

   7.   Verify the "alg" header parameter matches the algorithm in the
        corresponding WIT.

   8.   Verify the "iss" claim matches the "sub" claim of the WIT
        associated with the "kid" public key.

   9.   Verify the "aud" claim contains the verifier's own workload
        identity.  When "aud" is an array, it is sufficient that the
        verifier's identity appears as one element; the presence of
        other audience values does not cause verification failure.  When
        the verifier is the audit ledger, the ledger's own identity MUST
        appear in "aud".

   10.  Verify the "exp" claim indicates the ECT has not expired.





Nennemann                Expires 29 August 2026                [Page 17]

Internet-Draft           WIMSE Execution Context           February 2026


   11.  Verify the "iat" claim is not unreasonably far in the past
        (implementation-specific threshold, RECOMMENDED maximum of 15
        minutes) and is not unreasonably far in the future (RECOMMENDED:
        no more than 30 seconds ahead of the verifier's current time, to
        account for clock skew).

   12.  Verify all required claims ("jti", "exec_act", "par") are
        present and well-formed.

   13.  Perform DAG validation per Section 6.

   14.  If all checks pass and an audit ledger is deployed, the ECT
        SHOULD be appended to the ledger.

   If any verification step fails, the ECT MUST be rejected and the
   failure MUST be logged for audit purposes.  Error messages SHOULD NOT
   reveal whether specific parent task IDs exist in the ECT store, to
   prevent information disclosure.

   When ECT verification fails during HTTP request processing, the
   receiving agent SHOULD respond with HTTP 403 (Forbidden) if the WIT
   is valid but the ECT is invalid, and HTTP 401 (Unauthorized) if the
   ECT signature verification fails.  The response body SHOULD include a
   generic error indicator without revealing which specific verification
   step failed.  The receiving agent MUST NOT process the requested
   action when ECT verification fails.

7.2.  Verification Pseudocode

   function verify_ect(ect_jws, verifier_id,
                        trust_domain_keys, ect_store):
     // Parse JWS
     (header, payload, signature) = parse_jws(ect_jws)

     // Verify header
     if header.typ != "wimse-exec+jwt":
       return reject("Invalid typ parameter")

     if header.alg == "none" or is_symmetric(header.alg):
       return reject("Prohibited algorithm")

     // Look up public key
     public_key = trust_domain_keys.get(header.kid)
     if public_key is null:
       return reject("Unknown key identifier")

     // Verify signature
     if not verify_jws_signature(header, payload,



Nennemann                Expires 29 August 2026                [Page 18]

Internet-Draft           WIMSE Execution Context           February 2026


                                  signature, public_key):
       return reject("Invalid signature")

     // Verify key not revoked
     if is_key_revoked(header.kid, trust_domain_keys):
       return reject("Signing key has been revoked")

     // Verify algorithm alignment
     wit = get_wit_for_key(header.kid)
     if header.alg != wit.alg:
       return reject("Algorithm mismatch with WIT")

     // Verify issuer matches WIT subject
     if payload.iss != wit.sub:
       return reject("Issuer does not match WIT subject")

     // Verify audience
     if verifier_id not in payload.aud:
       return reject("ECT not intended for this recipient")

     // Verify not expired
     if payload.exp < current_time():
       return reject("ECT has expired")

     // Verify iat freshness (not too old, not in the future)
     if payload.iat < current_time() - max_age_threshold:
       return reject("ECT issued too long ago")
     if payload.iat > current_time() + clock_skew_tolerance:
       return reject("ECT issued in the future")

     // Verify required claims
     for claim in ["jti", "exec_act", "par"]:
       if claim not in payload:
         return reject("Missing required claim: " + claim)

     // Validate DAG (against ECT store 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; record if store is available
     if ect_store is not null:
       ect_store.append(payload)
     return accept

                   Figure 7: ECT Verification Pseudocode




Nennemann                Expires 29 August 2026                [Page 19]

Internet-Draft           WIMSE Execution Context           February 2026


8.  Audit Ledger Interface

   ECTs MAY be recorded in an immutable audit ledger for compliance
   verification and post-hoc analysis.  A ledger is RECOMMENDED for
   regulated environments but is not required for point-to-point
   operation.  This specification does not mandate a specific storage
   technology.  Implementations MAY use append-only logs, databases with
   cryptographic commitment schemes, distributed ledgers, or any storage
   mechanism that provides the required properties.

   When an audit ledger is deployed, the implementation MUST provide:

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

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

   3.  Lookup by ECT ID: The ledger MUST support efficient retrieval of
       ECT entries by "jti" value.

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

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

9.  Security Considerations

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

9.1.  Threat Model

   The following threat actors are considered:

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

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

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

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



Nennemann                Expires 29 August 2026                [Page 20]

Internet-Draft           WIMSE Execution Context           February 2026


9.2.  Self-Assertion Limitation

   ECTs are self-asserted by the executing agent.  The agent claims what
   it did, and this claim is signed with its private key.  A compromised
   or malicious agent could create ECTs with false claims (e.g.,
   claiming an action was performed when it was not).

   ECTs do not independently verify that:

   *  The claimed execution actually occurred as described

   *  The input/output hashes correspond to the actual data processed

   *  The agent faithfully performed the stated action

   The trustworthiness of ECT claims depends on the trustworthiness of
   the signing agent.  To mitigate single-agent false claims, regulated
   environments SHOULD use the "witnessed_by" extension key (carried in
   "ext") to include independent third-party observers at critical
   decision points.  However, this value is self-asserted by the ECT
   issuer: the listed witnesses do not co-sign the ECT and there is no
   cryptographic evidence within a single ECT that the witnesses
   actually observed the task.  An issuing agent could list witnesses
   that did not participate.

   To strengthen witness attestation beyond self-assertion, witnesses
   SHOULD submit their own independent signed ECTs referencing the
   observed task's "jti" in the "par" array.  Auditors can then cross-
   check the "witnessed_by" extension against independent witness ECTs
   in the ECT store.

9.3.  Organizational Prerequisites

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

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

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

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






Nennemann                Expires 29 August 2026                [Page 21]

Internet-Draft           WIMSE Execution Context           February 2026


9.4.  Signature Verification

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

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

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

9.5.  Replay Attack Prevention

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

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

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

9.6.  Man-in-the-Middle Protection

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

   The defense-in-depth model provides:

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

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

   *  ECT (execution accountability layer): Records what the agent did.



Nennemann                Expires 29 August 2026                [Page 22]

Internet-Draft           WIMSE Execution Context           February 2026


9.7.  Key Compromise

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

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

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

   *  Trust domains MUST support rapid key revocation.

   *  Upon suspected compromise, the trust domain MUST revoke the
      compromised key and issue a new WIT with a fresh key pair.

   ECTs signed with a compromised key that were recorded in the ledger
   before revocation remain valid historical records but SHOULD be
   flagged in the ledger as "signed with subsequently revoked key" for
   audit purposes.

9.8.  Collusion and False Claims

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

   Mitigations include:

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

   *  Witness attestation: Using the "witnessed_by" extension key in
      "ext" to include independent third-party observers.

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

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










Nennemann                Expires 29 August 2026                [Page 23]

Internet-Draft           WIMSE Execution Context           February 2026


9.9.  Denial of Service

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

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

9.10.  Timestamp Accuracy

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

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

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

9.11.  ECT Size Constraints

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

10.  Privacy Considerations

10.1.  Data Exposure in ECTs

   ECTs necessarily reveal:

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

   *  Action descriptions ("exec_act") for audit trail completeness



Nennemann                Expires 29 August 2026                [Page 24]

Internet-Draft           WIMSE Execution Context           February 2026


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

   ECTs are designed to NOT reveal:

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

   *  Internal computation details or intermediate steps

   *  Proprietary algorithms or intellectual property

   *  Personally identifiable information (PII)

10.2.  Data Minimization

   Implementations SHOULD minimize the information included in ECTs.
   The "exec_act" claim SHOULD use structured identifiers (e.g.,
   "process_payment") rather than natural language descriptions.
   Extension keys in "ext" (Section 4.2.5) deserve particular attention:
   human-readable values risk exposing sensitive operational details.
   See Section 4.2.5 for guidance on using structured identifiers.

10.3.  Storage and Access Control

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

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

10.4.  Regulatory Access

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

11.  IANA Considerations

11.1.  Media Type Registration

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

   Type name:  application



Nennemann                Expires 29 August 2026                [Page 25]

Internet-Draft           WIMSE Execution Context           February 2026


   Subtype name:  wimse-exec+jwt

   Required parameters:  none

   Optional parameters:  none

   Encoding considerations:  8bit; an ECT is a JWT that is a JWS using
      the Compact Serialization, which is a sequence of Base64url-
      encoded values separated by period characters.

   Security considerations:  See the Security Considerations section of
      this document.

   Interoperability considerations:  none

   Published specification:  This document

   Applications that use this media type:  Applications that implement
      regulated agentic workflows requiring execution context tracing
      and audit trails.

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

   Person and email address to contact for further information:  Christi
      an Nennemann, ietf@nennemann.de

   Intended usage:  COMMON

   Restrictions on usage:  none

   Author:  Christian Nennemann

   Change controller:  IETF

11.2.  HTTP Header Field Registration

   This document requests registration of the following header field in
   the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
   maintained by IANA:

   Field name:  Execution-Context

   Status:  permanent

   Specification document:  This document, Section 5





Nennemann                Expires 29 August 2026                [Page 26]

Internet-Draft           WIMSE Execution Context           February 2026


11.3.  JWT Claims Registration

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

   +============+=====================+===================+===========+
   | Claim Name | Claim Description   | Change Controller | Reference |
   +============+=====================+===================+===========+
   |    wid     | Workflow Identifier |        IETF       |  Section  |
   |            |                     |                   |   4.2.2   |
   +------------+---------------------+-------------------+-----------+
   |  exec_act  | Action/Task Type    |        IETF       |  Section  |
   |            |                     |                   |   4.2.2   |
   +------------+---------------------+-------------------+-----------+
   |    par     | Parent Task         |        IETF       |  Section  |
   |            | Identifiers         |                   |   4.2.2   |
   +------------+---------------------+-------------------+-----------+
   |  inp_hash  | Input Data Hash     |        IETF       |  Section  |
   |            |                     |                   |   4.2.3   |
   +------------+---------------------+-------------------+-----------+
   |  out_hash  | Output Data Hash    |        IETF       |  Section  |
   |            |                     |                   |   4.2.3   |
   +------------+---------------------+-------------------+-----------+
   |    ext     | Extension Object    |        IETF       |  Section  |
   |            |                     |                   |   4.2.5   |
   +------------+---------------------+-------------------+-----------+

                    Table 1: JWT Claims Registrations

   Policy evaluation claims and the ECT Policy Decision Values registry
   are defined in [I-D.nennemann-wimse-ect-pol].

12.  References

12.1.  Normative References

   [I-D.ietf-wimse-arch]
              Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
              "Workload Identity in a Multi System Environment (WIMSE)
              Architecture", Work in Progress, Internet-Draft, draft-
              ietf-wimse-arch-06, 30 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
              arch-06>.

   [I-D.ietf-wimse-s2s-protocol]
              Campbell, B., Salowey, J. A., Schwenkschuster, A., and Y.
              Sheffer, "WIMSE Workload-to-Workload Authentication", Work
              in Progress, Internet-Draft, draft-ietf-wimse-s2s-



Nennemann                Expires 29 August 2026                [Page 27]

Internet-Draft           WIMSE Execution Context           February 2026


              protocol-07, 16 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
              s2s-protocol-07>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/rfc/rfc7515>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7517>.

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7518>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7519>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [RFC9562]  Davis, K., Peabody, B., and P. Leach, "Universally Unique
              IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
              2024, <https://www.rfc-editor.org/rfc/rfc9562>.

12.2.  Informative References

   [DORA]     European Parliament and Council of the European Union,
              "Regulation (EU) 2022/2554 on digital operational
              resilience for the financial sector (DORA)", 14 December
              2022, <https://eur-lex.europa.eu/eli/reg/2022/2554>.

   [EU-AI-ACT]
              European Parliament and Council of the European Union,
              "Regulation (EU) 2024/1689 of the European Parliament and



Nennemann                Expires 29 August 2026                [Page 28]

Internet-Draft           WIMSE Execution Context           February 2026


              of the Council laying down harmonised rules on artificial
              intelligence (Artificial Intelligence Act)", 13 June 2024,
              <https://eur-lex.europa.eu/eli/reg/2024/1689>.

   [EU-MDR]   European Parliament and Council of the European Union,
              "Regulation (EU) 2017/745 on medical devices (MDR)", 5
              April 2017, <https://eur-lex.europa.eu/eli/reg/2017/745>.

   [FDA-21CFR11]
              U.S. Food and Drug Administration, "Title 21, Code of
              Federal Regulations, Part 11: Electronic Records;
              Electronic Signatures", <https://www.ecfr.gov/current/
              title-21/chapter-I/subchapter-A/part-11>.

   [I-D.ietf-oauth-transaction-tokens]
              Tulshibagwale, A., Fletcher, G., and P. Kasselman,
              "Transaction Tokens", Work in Progress, Internet-Draft,
              draft-ietf-oauth-transaction-tokens-07, 24 January 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              transaction-tokens-07>.

   [I-D.ietf-scitt-architecture]
              Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
              Y., and S. Lasker, "An Architecture for Trustworthy and
              Transparent Digital Supply Chains", Work in Progress,
              Internet-Draft, draft-ietf-scitt-architecture-22, 10
              October 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-scitt-architecture-22>.

   [I-D.nennemann-wimse-ect-pol]
              Nennemann, C., "Policy Evaluation and Compensation
              Extensions for Execution Context Tokens",
              <https://datatracker.ietf.org/doc/draft-nennemann-wimse-
              ect-pol/>.

   [I-D.ni-wimse-ai-agent-identity]
              Yuan, N. and P. C. Liu, "WIMSE Applicability for AI
              Agents", Work in Progress, Internet-Draft, draft-ni-wimse-
              ai-agent-identity-01, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ni-wimse-ai-
              agent-identity-01>.

   [I-D.oauth-transaction-tokens-for-agents]
              Raut, A., "Transaction Tokens For Agents", Work in
              Progress, Internet-Draft, draft-oauth-transaction-tokens-
              for-agents-04, 10 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-oauth-
              transaction-tokens-for-agents-04>.



Nennemann                Expires 29 August 2026                [Page 29]

Internet-Draft           WIMSE Execution Context           February 2026


   [MIFID-II] European Parliament and Council of the European Union,
              "Directive 2014/65/EU of the European Parliament and of
              the Council on markets in financial instruments (MiFID
              II)", 15 May 2014,
              <https://eur-lex.europa.eu/eli/dir/2014/65>.

   [OPENTELEMETRY]
              Cloud Native Computing Foundation, "OpenTelemetry
              Specification",
              <https://opentelemetry.io/docs/specs/otel/>.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/rfc/rfc3552>.

   [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
              and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
              DOI 10.17487/RFC8693, January 2020,
              <https://www.rfc-editor.org/rfc/rfc8693>.

   [RFC9421]  Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
              Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
              February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

   [SPIFFE]   "Secure Production Identity Framework for Everyone
              (SPIFFE)",
              <https://spiffe.io/docs/latest/spiffe-about/overview/>.

Use Cases

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

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

Medical Device SDLC Workflow

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



Nennemann                Expires 29 August 2026                [Page 30]

Internet-Draft           WIMSE Execution Context           February 2026


   Agent A (Spec Reviewer):
     jti: task-001    par: []
     exec_act: review_requirements_spec

   Agent B (Code Generator):
     jti: task-002    par: [task-001]
     exec_act: implement_module

   Agent C (Test Agent):
     jti: task-003    par: [task-002]
     exec_act: execute_test_suite

   Agent D (Build Agent):
     jti: task-004    par: [task-003]
     exec_act: build_release_artifact

   Human Release Manager:
     jti: task-005    par: [task-004]
     exec_act: approve_release
     ext: {witnessed_by: [...]}  (extension metadata)

                   Figure 8: Medical Device SDLC Workflow

   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.

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 29 August 2026                [Page 31]

Internet-Draft           WIMSE Execution Context           February 2026


   task-001 (review_requirements_spec)
     |
     v
   task-002 (implement_module)
     |
     v
   task-003 (execute_test_suite)
     |
     v
   task-004 (build_release_artifact)
     |
     v
   task-005 (approve_release) [human, witnessed]

                 Figure 9: Reconstructed DAG for FDA Audit

   The reconstructed DAG provides cryptographic evidence that:

   *  Each phase was executed by an identified and authenticated agent.

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

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

   *  Timestamps and execution durations are recorded for each step.

   This can contribute to compliance with:

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

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

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

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

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 29 August 2026                [Page 32]

Internet-Draft           WIMSE Execution Context           February 2026


   Agent A (Risk Assessment):
     jti: task-001    par: []
     exec_act: calculate_risk_exposure

   Agent B (Compliance):
     jti: task-002    par: [task-001]
     exec_act: verify_compliance

   Agent C (Execution):
     jti: task-003    par: [task-002]
     exec_act: execute_trade

                   Figure 10: Financial Trading Workflow

   This can contribute to compliance with:

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

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

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

Compensation and Rollback

   Compensation and rollback use cases are described in
   [I-D.nennemann-wimse-ect-pol].  The core ECT mechanism supports
   compensation through the "par" claim, which links a remediation ECT
   to the original task.

Autonomous Logistics Coordination

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















Nennemann                Expires 29 August 2026                [Page 33]

Internet-Draft           WIMSE Execution Context           February 2026


   Agent A (Route Planning):
     jti: task-001    par: []
     exec_act: plan_route

   Agent B (Customs):
     jti: task-002    par: [task-001]
     exec_act: validate_customs

   Agent C (Safety):
     jti: task-003    par: [task-001]
     exec_act: verify_cargo_safety

   Agent D (Payment):
     jti: task-004    par: [task-002, task-003]
     exec_act: authorize_payment

   System (Commitment):
     jti: task-005    par: [task-004]
     exec_act: commit_shipment

             Figure 11: Logistics Workflow with Parallel Tasks

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

Related Work

WIMSE Workload Identity

   The WIMSE architecture [I-D.ietf-wimse-arch] and service-to- service
   protocol [I-D.ietf-wimse-s2s-protocol] provide the identity
   foundation upon which ECTs are built.  WIT/WPT answer "who is this
   agent?" and "does it control the claimed key?" while ECTs record
   "what did this agent do?"  Together they form an identity-plus-
   accountability framework for regulated agentic systems.

OAuth 2.0 Token Exchange and the "act" Claim

   [RFC8693] defines the OAuth 2.0 Token Exchange protocol and registers
   the "act" (Actor) claim in the JWT Claims registry.  The "act" claim
   creates nested JSON objects representing a delegation chain: "who is
   acting on behalf of whom."  While the nesting superficially resembles
   a chain, it is strictly linear (each "act" object contains at most
   one nested "act"), represents authorization delegation rather than
   task execution, and carries no task identifiers or input/output
   integrity data.  The "act" chain cannot represent branching (fan-out)
   or convergence (fan-in) and therefore cannot form a DAG.



Nennemann                Expires 29 August 2026                [Page 34]

Internet-Draft           WIMSE Execution Context           February 2026


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

Transaction Tokens

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

   However, "req_wl" cannot form a DAG because:

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

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

   *  It carries no task-level granularity, no parent references, and no
      execution content.

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

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










Nennemann                Expires 29 August 2026                [Page 35]

Internet-Draft           WIMSE Execution Context           February 2026


Distributed Tracing (OpenTelemetry)

   OpenTelemetry [OPENTELEMETRY] and similar distributed tracing systems
   provide observability for debugging and monitoring.  ECTs differ in
   several important ways: ECTs are cryptographically signed per-task
   with the agent's private key; ECTs are tamper-evident through JWS
   signatures; ECTs enforce DAG validation rules; and ECTs are designed
   for regulatory audit rather than operational monitoring.
   OpenTelemetry data is typically controlled by the platform operator
   and can be modified or deleted without detection.  ECTs and
   distributed traces are complementary: traces provide observability
   while ECTs provide signed execution records.  ECTs may reference
   OpenTelemetry trace identifiers in the "ext" claim for correlation.

Blockchain and Distributed Ledgers

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

SCITT (Supply Chain Integrity, Transparency, and Trust)

   The SCITT architecture [I-D.ietf-scitt-architecture] defines a
   framework for creating transparent and auditable supply chain records
   through Transparency Services, Signed Statements, and Receipts.  ECTs
   and SCITT are naturally complementary: the ECT "wid" (Workflow
   Identifier) claim can serve as a correlation identifier referenced in
   SCITT Signed Statements, linking a complete ECT audit trail to a
   supply chain transparency record.  For example, in a regulated
   manufacturing workflow, each agent step produces an ECT (recording
   what was done, by whom, under under what constraints), while the
   overall workflow identified by "wid" is registered as a SCITT Signed
   Statement on a Transparency Service.  This enables auditors to verify
   both the individual execution steps (via ECT DAG validation) and the
   end-to-end supply chain integrity (via SCITT Receipts) using the
   "wid" as the shared correlation point.  The "ext" claim in ECTs
   (Section 4.2.2) can carry SCITT-specific metadata such as
   Transparency Service identifiers or Receipt references for tighter
   integration.









Nennemann                Expires 29 August 2026                [Page 36]

Internet-Draft           WIMSE Execution Context           February 2026


W3C Verifiable Credentials

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

Implementation Guidance

Minimal Implementation

   A minimal conforming implementation needs to:

   1.  Create JWTs with all required claims ("iss", "aud", "iat", "exp",
       "jti", "exec_act", "par").

   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.  If an audit ledger is deployed, append verified ECTs to it.

Storage Recommendations

   *  Append-only log: Simplest approach; immutability by design.

   *  Database with hash chains: Periodic cryptographic commitments over
      batches of entries.

   *  Distributed ledger: Maximum immutability guarantees for cross-
      organizational audit.

   *  Hybrid: Hot storage in a database, cold archive in immutable
      storage.

Performance Considerations

   *  ES256 signature verification: approximately 1ms per ECT on modern
      hardware.

   *  DAG validation: O(V) where V is the number of reachable ancestor
      nodes (typically small for shallow workflows).

   *  JSON serialization: sub-millisecond per ECT.



Nennemann                Expires 29 August 2026                [Page 37]

Internet-Draft           WIMSE Execution Context           February 2026


   *  Total per-request overhead: approximately 5-10ms, acceptable for
      regulated workflows where correctness is prioritized over latency.

Interoperability

   Implementations are expected to use established JWT/JWS libraries
   (JOSE) for token creation and verification.  Custom cryptographic
   implementations are strongly discouraged.  Implementations are
   expected to be tested against multiple JWT libraries to ensure
   interoperability.

Regulatory Compliance Mapping

   The following table summarizes how ECTs can contribute to compliance
   with various regulatory frameworks.  ECTs are a technical building
   block; achieving compliance requires additional organizational
   measures beyond this specification.


































Nennemann                Expires 29 August 2026                [Page 38]

Internet-Draft           WIMSE Execution Context           February 2026


    +============+========================+==========================+
    | Regulation | Requirement            | ECT Contribution         |
    +============+========================+==========================+
    | FDA 21 CFR | Audit trails recording | Cryptographic signatures |
    | Part 11    | date, time, operator,  | and append-only ledger   |
    |            | actions (11.10(e))     | contribute to audit      |
    |            |                        | trail requirements       |
    +------------+------------------------+--------------------------+
    | EU MDR     | Technical              | ECTs provide signed      |
    |            | documentation          | records of AI-assisted   |
    |            | traceability (Annex    | decision sequences       |
    |            | II)                    |                          |
    +------------+------------------------+--------------------------+
    | EU AI Act  | Automatic logging      | ECTs contribute          |
    | Art. 12    | capabilities for high- | cryptographic activity   |
    |            | risk AI                | logging                  |
    +------------+------------------------+--------------------------+
    | EU AI Act  | Human oversight        | ECTs can record evidence |
    | Art. 14    | capability             | that human oversight     |
    |            |                        | events occurred          |
    +------------+------------------------+--------------------------+
    | MiFID II   | Transaction records    | ECTs provide             |
    |            | for supervisory        | cryptographic execution  |
    |            | authorities            | sequence records         |
    +------------+------------------------+--------------------------+
    | DORA Art.  | ICT activity logging   | ECT ledger contributes   |
    | 12         | policies               | to ICT activity audit    |
    |            |                        | trail                    |
    +------------+------------------------+--------------------------+

                  Table 2: Regulatory Compliance Mapping

Examples

Example 1: Simple Two-Agent Workflow

   Agent A executes a data retrieval task and sends the ECT to Agent B:

   ECT JOSE Header:

   {
     "alg": "ES256",
     "typ": "wimse-exec+jwt",
     "kid": "agent-a-key-2026-02"
   }

   ECT Payload:




Nennemann                Expires 29 August 2026                [Page 39]

Internet-Draft           WIMSE Execution Context           February 2026


   {
     "iss": "spiffe://example.com/agent/data-retrieval",
     "aud": "spiffe://example.com/agent/validator",
     "iat": 1772064150,
     "exp": 1772064750,
     "jti": "550e8400-e29b-41d4-a716-446655440001",
     "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
     "exec_act": "fetch_patient_data",
     "par": [],
     "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
     "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
   }

   Agent B receives the ECT, verifies it, executes a validation task,
   and creates its own ECT:

   {
     "iss": "spiffe://example.com/agent/validator",
     "aud": "spiffe://example.com/system/ledger",
     "iat": 1772064160,
     "exp": 1772064760,
     "jti": "550e8400-e29b-41d4-a716-446655440002",
     "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
     "exec_act": "validate_safety",
     "par": ["550e8400-e29b-41d4-a716-446655440001"]
   }

   The resulting DAG:

   task-...-0001 (fetch_patient_data)
     |
     v
   task-...-0002 (validate_safety)

Example 2: Medical Device SDLC with Release Approval

   A multi-step medical device software lifecycle workflow with
   autonomous agents and human release approval:

   Task 1 (Spec Review Agent):











Nennemann                Expires 29 August 2026                [Page 40]

Internet-Draft           WIMSE Execution Context           February 2026


   {
     "iss": "spiffe://meddev.example/agent/spec-reviewer",
     "aud": "spiffe://meddev.example/agent/code-gen",
     "iat": 1772064150,
     "exp": 1772064750,
     "jti": "a1b2c3d4-0001-0000-0000-000000000001",
     "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
     "exec_act": "review_requirements_spec",
     "par": [],
     "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
     "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
   }

   Task 2 (Code Generation Agent):

   {
     "iss": "spiffe://meddev.example/agent/code-gen",
     "aud": "spiffe://meddev.example/agent/test-runner",
     "iat": 1772064200,
     "exp": 1772064800,
     "jti": "a1b2c3d4-0001-0000-0000-000000000002",
     "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
     "exec_act": "implement_module",
     "par": ["a1b2c3d4-0001-0000-0000-000000000001"]
   }

   Task 3 (Autonomous Test Agent):

   {
     "iss": "spiffe://meddev.example/agent/test-runner",
     "aud": "spiffe://meddev.example/agent/build",
     "iat": 1772064260,
     "exp": 1772064860,
     "jti": "a1b2c3d4-0001-0000-0000-000000000003",
     "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
     "exec_act": "execute_test_suite",
     "par": ["a1b2c3d4-0001-0000-0000-000000000002"]
   }

   Task 4 (Build Agent):











Nennemann                Expires 29 August 2026                [Page 41]

Internet-Draft           WIMSE Execution Context           February 2026


   {
     "iss": "spiffe://meddev.example/agent/build",
     "aud": "spiffe://meddev.example/human/release-mgr-42",
     "iat": 1772064310,
     "exp": 1772064910,
     "jti": "a1b2c3d4-0001-0000-0000-000000000004",
     "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
     "exec_act": "build_release_artifact",
     "par": ["a1b2c3d4-0001-0000-0000-000000000003"],
     "out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc"
   }

   Task 5 (Human Release Manager Approval):

   {
     "iss": "spiffe://meddev.example/human/release-mgr-42",
     "aud": "spiffe://meddev.example/system/ledger",
     "iat": 1772064510,
     "exp": 1772065110,
     "jti": "a1b2c3d4-0001-0000-0000-000000000005",
     "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
     "exec_act": "approve_release",
     "par": ["a1b2c3d4-0001-0000-0000-000000000004"],
     "ext": {
       "witnessed_by": [
         "spiffe://meddev.example/audit/qa-observer-1"
       ]
     }
   }

   The resulting DAG records the complete SDLC: spec review preceded
   implementation, implementation preceded testing, testing preceded
   build, and a human release manager approved the final release.  The
   "ext" object in task 5 carries witness metadata via the
   "witnessed_by" extension key.
















Nennemann                Expires 29 August 2026                [Page 42]

Internet-Draft           WIMSE Execution Context           February 2026


   task-...-0001 (review_requirements_spec)
     |
     v
   task-...-0002 (implement_module)
     |
     v
   task-...-0003 (execute_test_suite)
     |
     v
   task-...-0004 (build_release_artifact)
     |
     v
   task-...-0005 (approve_release) [human]

   An FDA auditor reconstructs this DAG by querying the audit ledger for
   all ECTs with wid "c2d3e4f5-a6b7-8901-cdef-012345678901" and
   verifying each signature.  The DAG provides cryptographic evidence
   that the SDLC followed the prescribed process with human oversight at
   the release gate.

Example 3: Parallel Execution with Join

   A workflow where two tasks execute in parallel and a third task
   depends on both:

   task-...-0001 (assess_risk)
     |            \
     v             v
   task-...-0002  task-...-0003
   (check         (verify
   compliance)    liquidity)
     |            /
     v           v
   task-...-0004 (execute_trade)

   Task 004 ECT payload:















Nennemann                Expires 29 August 2026                [Page 43]

Internet-Draft           WIMSE Execution Context           February 2026


   {
     "iss": "spiffe://bank.example/agent/execution",
     "aud": "spiffe://bank.example/system/ledger",
     "iat": 1772064250,
     "exp": 1772064850,
     "jti": "f1e2d3c4-0004-0000-0000-000000000004",
     "wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
     "exec_act": "execute_trade",
     "par": [
       "f1e2d3c4-0002-0000-0000-000000000002",
       "f1e2d3c4-0003-0000-0000-000000000003"
     ]
   }

   The "par" array with two entries records that both compliance
   checking and liquidity verification were completed before trade
   execution.

Acknowledgments

   The author thanks the WIMSE working group for their foundational work
   on workload identity in multi-system environments.  The concepts of
   Workload Identity Tokens and Workload Proof Tokens provide the
   identity foundation upon which execution context tracing is built.

Author's Address

   Christian Nennemann
   Independent Researcher
   Email: ietf@nennemann.de





















Nennemann                Expires 29 August 2026                [Page 44]
