ietf-wimse-ect/draft-nennemann-wimse-execution-context-00.md

---
title: "Execution Context Tokens for Distributed Agentic Workflows"
abbrev: "WIMSE Execution Context"
category: std
docname: draft-nennemann-wimse-execution-context-00
submissiontype: IETF
number:
date:
v: 3
area: "Security"
workgroup: "WIMSE"
keyword:
  - execution context
  - workload identity
  - agentic workflows
  - audit trail
  - compliance
  - regulated systems

author:
  -
    fullname: Christian Nennemann
    organization: Independent Researcher
    email: ietf@nennemann.de

normative:
  RFC7515:
  RFC7517:
  RFC7519:
  RFC7518:
  RFC9562:
  RFC9110:
  I-D.ietf-wimse-arch:
  I-D.ietf-wimse-s2s-protocol:

informative:
  RFC3552:
  RFC8693:
  RFC9421:
  I-D.ni-wimse-ai-agent-identity:
  I-D.nennemann-wimse-ect-pol:
    title: "Policy Evaluation and Compensation Extensions for Execution Context Tokens"
    target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect-pol/
    date: false
    author:
      - fullname: Christian Nennemann
  SPIFFE:
    title: "Secure Production Identity Framework for Everyone (SPIFFE)"
    target: https://spiffe.io/docs/latest/spiffe-about/overview/
    date: false
  EU-AI-ACT:
    title: "Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)"
    target: https://eur-lex.europa.eu/eli/reg/2024/1689
    date: 2024-06-13
    author:
      - org: European Parliament and Council of the European Union
  FDA-21CFR11:
    title: "Title 21, Code of Federal Regulations, Part 11: Electronic Records; Electronic Signatures"
    target: https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
    date: false
    author:
      - org: U.S. Food and Drug Administration
  MIFID-II:
    title: "Directive 2014/65/EU of the European Parliament and of the Council on markets in financial instruments (MiFID II)"
    target: https://eur-lex.europa.eu/eli/dir/2014/65
    date: 2014-05-15
    author:
      - org: European Parliament and Council of the European Union
  DORA:
    title: "Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)"
    target: https://eur-lex.europa.eu/eli/reg/2022/2554
    date: 2022-12-14
    author:
      - org: European Parliament and Council of the European Union
  EU-MDR:
    title: "Regulation (EU) 2017/745 on medical devices (MDR)"
    target: https://eur-lex.europa.eu/eli/reg/2017/745
    date: 2017-04-05
    author:
      - org: European Parliament and Council of the European Union
  OPENTELEMETRY:
    title: "OpenTelemetry Specification"
    target: https://opentelemetry.io/docs/specs/otel/
    date: false
    author:
      - org: Cloud Native Computing Foundation
  I-D.ietf-scitt-architecture:
  I-D.ietf-oauth-transaction-tokens:
  I-D.oauth-transaction-tokens-for-agents:

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

--- middle

# Introduction

## 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-regulatory}} 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.

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

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.

## Scope and Applicability

This document defines:

- The Execution Context Token (ECT) format ({{ect-format}})
- DAG structure for task dependency ordering ({{dag-validation}})
- Integration with the WIMSE identity framework
  ({{wimse-integration}})
- An HTTP header for ECT transport ({{http-header}})
- Audit ledger interface requirements ({{ledger-interface}})
- 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

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

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.

# Conventions and Definitions

{::boilerplate bcp14-tagged}

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.

# WIMSE Architecture Integration {#wimse-integration}

## 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

## Extension Model

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

~~~ ascii-art
+--------------------------------------------------+
|  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"     |
+--------------------------------------------------+
~~~
{: #fig-layers title="WIMSE Extension Architecture Layers"}

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.

## Integration Points {#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:

~~~ ascii-art
HTTP Request from Agent A to Agent B:
  Workload-Identity:    <WIT for Agent A>
  Execution-Context:    <ECT recording what A did>
~~~
{: #fig-http-headers title="HTTP Header Stacking"}

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

The receiving agent (Agent B) verifies in order:

1.  WIT (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.

# Execution Context Token Format {#ect-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.

## JOSE Header {#jose-header}

The ECT JOSE header MUST contain the following parameters:

~~~json
{
  "alg": "ES256",
  "typ": "wimse-exec+jwt",
  "kid": "agent-a-key-id-123"
}
~~~
{: #fig-header title="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.

## JWT Claims {#jwt-claims}

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

### 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).

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 "wid" is present, uniqueness is scoped to the
  workflow; when "wid" is absent, uniqueness MUST be enforced
  globally across the ECT store.

### Execution Context {#exec-claims}

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.

### Data Integrity {#data-integrity-claims}

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

### Compensation and Rollback {#compensation-claims}

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.

### Extensions {#extension-claims}

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

## Complete ECT Example

The following is a complete ECT payload example:

~~~json
{
  "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"
  }
}
~~~
{: #fig-full-ect title="Complete ECT Payload Example"}

# HTTP Header Transport {#http-header}

## 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...
~~~
{: #fig-http-example title="HTTP Request with ECT Header"}

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

When a receiver processes multiple Execution-Context headers, it
MUST individually verify each ECT per the procedure in
{{verification}}.  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.

# DAG Validation {#dag-validation}

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

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

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.

## DAG Validation Algorithm

The following pseudocode describes the DAG validation procedure:

~~~ pseudocode
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
~~~
{: #fig-dag-validation title="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 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.

# Signature and Token Verification {#verification}

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

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 {{dag-validation}}.

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.

## Verification Pseudocode

~~~ 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,
                               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
~~~
{: #fig-verification title="ECT Verification Pseudocode"}

# Audit Ledger Interface {#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.

# Security Considerations

This section addresses security considerations following the
guidance in {{RFC3552}}.

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

## Self-Assertion Limitation {#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.

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

## 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
{{verification}}).

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.

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

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

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

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

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

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

## 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 {{extension-claims}}).

# Privacy Considerations

## Data Exposure in ECTs

ECTs necessarily reveal:

- Agent identities ("iss", "aud") for accountability purposes
- Action descriptions ("exec_act") for audit trail completeness
- Timestamps ("iat", "exp") for temporal ordering

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)

## Data Minimization {#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" ({{extension-claims}}) deserve particular
attention: human-readable values risk exposing sensitive operational
details.  See {{extension-claims}} for guidance on using
structured identifiers.

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

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

# IANA Considerations

## Media Type Registration

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

Type name:
: application

Subtype name:
: wimse-exec+jwt

Required parameters:
: none

Optional parameters:
: none

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:
: Christian Nennemann, ietf@nennemann.de

Intended usage:
: COMMON

Restrictions on usage:
: none

Author:
: Christian Nennemann

Change controller:
: IETF

## HTTP Header Field Registration {#header-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, {{http-header}}

## JWT Claims Registration {#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 | {{exec-claims}} |
| exec_act | Action/Task Type | IETF | {{exec-claims}} |
| par | Parent Task Identifiers | IETF | {{exec-claims}} |
| inp_hash | Input Data Hash | IETF | {{data-integrity-claims}} |
| out_hash | Output Data Hash | IETF | {{data-integrity-claims}} |
| ext | Extension Object | IETF | {{extension-claims}} |
{: #table-claims title="JWT Claims Registrations"}

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

--- back

# Use Cases {#use-cases}
{:numbered="false"}

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 {{exec-claims}}.

## Medical Device SDLC Workflow
{:numbered="false"}

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.

~~~
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)
~~~
{: #fig-medtech-sdlc title="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
{:numbered="false"}

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:

~~~
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]
~~~
{: #fig-fda-audit title="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
{:numbered="false"}

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.

~~~
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
~~~
{: #fig-finance title="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
{:numbered="false"}

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
{:numbered="false"}

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

~~~
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
~~~
{: #fig-logistics title="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
{:numbered="false"}

## WIMSE Workload Identity
{:numbered="false"}

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
{: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 or input/output integrity data.  The "act" chain cannot represent
branching (fan-out) or convergence (fan-in) and therefore
cannot form a DAG.

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

## Transaction Tokens
{: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,
  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.

## Distributed Tracing (OpenTelemetry)
{:numbered="false"}

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
{:numbered="false"}

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 {{ledger-interface}}.

## SCITT (Supply Chain Integrity, Transparency, and Trust)
{:numbered="false"}

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 ({{exec-claims}})
can carry SCITT-specific metadata such as Transparency Service
identifiers or Receipt references for tighter integration.

## W3C Verifiable Credentials
{:numbered="false"}

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
{:numbered="false"}

## Minimal Implementation
{:numbered="false"}

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
{:numbered="false"}

- 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
{:numbered="false"}

- 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.
- Total per-request overhead: approximately 5-10ms, acceptable
  for regulated workflows where correctness is prioritized over
  latency.

## Interoperability
{:numbered="false"}

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
{:numbered="false"}

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.

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

# Examples
{:numbered="false"}

## Example 1: Simple Two-Agent Workflow
{:numbered="false"}

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

ECT JOSE Header:

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

ECT Payload:

~~~json
{
  "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:

~~~json
{
  "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
{:numbered="false"}

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

Task 1 (Spec Review Agent):

~~~json
{
  "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):

~~~json
{
  "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):

~~~json
{
  "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):

~~~json
{
  "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):

~~~json
{
  "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.

~~~
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
{:numbered="false"}

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:

~~~json
{
  "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
{:numbered="false"}

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.