Merge branch 'main' of git.xorwell.de:c/ietf-wimse-ect

Draft improvements:
- Rename ext -> ect_ext, clarify iss/aud requirements per level
- Add algorithm agility guidance and RFC 8725 reference
- Add HTTP header size constraints and body transport fallback
- Add cross-level parent reference semantics
- Add emerging agent protocols (A2A, MCP) to Related Work
- Fix HTTP error handling (403 not 401), IANA +jwt suffix note
- Add workflow consistency check to DAG validation
- Add defense-in-depth note for acyclicity check

Supporting files:
- Fix blog post outdated claim names (par -> pred, ext -> ect_ext)
- Update refimpl README with -00 vs -01 migration mapping
- Add refimpl IMPROVEMENTS.md section 6 with -01 migration tasks

.gitea/workflows/claude.yml

@@ -0,0 +1,134 @@
+name: Claude Code Assistant
+
+on:
+  issues:
+    types: [opened, labeled]
+  issue_comment:
+    types: [created]
+
+concurrency:
+  group: claude-${{ github.event.issue.number }}
+  cancel-in-progress: true
+
+jobs:
+  claude-code:
+    if: >-
+      (github.event_name == 'issues' &&
+       contains(toJSON(github.event.issue.labels), 'claude')) ||
+      (github.event_name == 'issue_comment' &&
+       contains(github.event.comment.body, '@claude') &&
+       github.event.comment.user.login != 'admin')
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Run Claude on Issue
+        env:
+          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
+          GIT_TOKEN: ${{ secrets.GIT_TOKEN }}
+        run: |
+          set +e
+
+          # Configure git
+          git config user.name "Claude Bot"
+          git config user.email "claude@localhost"
+          git remote set-url origin "http://admin:${GIT_TOKEN}@localhost:3000/${{ github.repository }}.git"
+
+          ISSUE_NUMBER="${{ github.event.issue.number }}"
+          ISSUE_TITLE="${{ github.event.issue.title }}"
+          REPO="${{ github.repository }}"
+          LABELS_JSON='${{ toJSON(github.event.issue.labels) }}'
+
+          # Determine model + cost limits from issue labels
+          # Default: haiku (cheap). Add claude:sonnet or claude:opus for harder tasks.
+          CLAUDE_MODEL="haiku"
+          MAX_TURNS=15
+          MAX_BUDGET="0.50"
+          EFFORT="low"
+          if echo "$LABELS_JSON" | grep -q '"claude:opus"'; then
+            CLAUDE_MODEL="claude-opus-4-6"
+            MAX_TURNS=40
+            MAX_BUDGET="5.00"
+            EFFORT="high"
+          elif echo "$LABELS_JSON" | grep -q '"claude:sonnet"'; then
+            CLAUDE_MODEL="claude-sonnet-4-6"
+            MAX_TURNS=25
+            MAX_BUDGET="2.00"
+            EFFORT="medium"
+          fi
+
+          ISSUE_BODY=$(curl -s "http://localhost:3000/api/v1/repos/${REPO}/issues/${ISSUE_NUMBER}" \
+            -H "Authorization: token ${GIT_TOKEN}" | python3 -c "import sys,json; print(json.load(sys.stdin).get('body',''))")
+
+          COMMENT_BODY=""
+          if [ "${{ github.event_name }}" = "issue_comment" ]; then
+            COMMENT_ID="${{ github.event.comment.id }}"
+            COMMENT_BODY=$(curl -s "http://localhost:3000/api/v1/repos/${REPO}/issues/comments/${COMMENT_ID}" \
+              -H "Authorization: token ${GIT_TOKEN}" | python3 -c "import sys,json; print(json.load(sys.stdin).get('body',''))")
+          fi
+
+          BRANCH="claude/issue-${ISSUE_NUMBER}"
+          git checkout -b "${BRANCH}"
+
+          # Run Claude Code with cost controls
+          claude -p "You are working on the repository ${REPO} (Gitea instance at http://localhost:3000).
+          A Gitea issue needs your attention:
+
+          Issue #${ISSUE_NUMBER}: ${ISSUE_TITLE}
+          Description: ${ISSUE_BODY}
+          Additional context: ${COMMENT_BODY}
+
+          IMPORTANT RULES:
+          - Do NOT retry failed commands more than once. If something fails twice, stop and report the error.
+          - Do NOT loop on failing tests. Fix the obvious issue or report it. Never run the same failing command 3+ times.
+          - If you cannot complete the task, push what you have, create the PR as draft, and explain what is blocked.
+          - Be efficient: read only files you need, make targeted edits, avoid unnecessary exploration.
+
+          Steps:
+          1. Read and understand the relevant parts of the codebase
+          2. Implement the requested changes
+          3. Commit your changes with a descriptive message
+          4. Push branch ${BRANCH} to origin
+          5. Create a pull request targeting main that references issue #${ISSUE_NUMBER}
+          6. Post a comment on issue #${ISSUE_NUMBER} summarizing what you did
+
+          Git is configured. You are on branch ${BRANCH}. Work in the current directory.
+          Use git commands to push, and curl to the Gitea API for PR creation and comments.
+          Gitea API token is available as env var GIT_TOKEN." \
+            --allowedTools "Bash,Read,Edit,Write,Glob,Grep" \
+            --model "${CLAUDE_MODEL}" \
+            --max-turns "${MAX_TURNS}" \
+            --max-budget-usd "${MAX_BUDGET}" \
+            --effort "${EFFORT}" \
+            --permission-mode bypassPermissions \
+            --output-format json 2>&1 > /tmp/claude-result.json
+
+          CLAUDE_EXIT=$?
+
+          # Extract cost from JSON output
+          COST=$(python3 -c "
+          import json
+          with open('/tmp/claude-result.json') as f:
+              data = json.load(f)
+          cost = data.get('total_cost_usd', 0)
+          print(f'\${cost:.4f}')
+          " 2>/dev/null || echo "unknown")
+
+          # Amend the last commit to include cost and model
+          if git log --oneline main..HEAD 2>/dev/null | head -1 | grep -q .; then
+            LAST_MSG=$(git log -1 --format=%B)
+            git commit --amend -m "${LAST_MSG}
+
+          Claude model: ${CLAUDE_MODEL} | API cost: ${COST}" --no-verify
+            git push origin "${BRANCH}" --force
+          fi
+
+          # Post cost as comment
+          curl -s -X POST "http://localhost:3000/api/v1/repos/${REPO}/issues/${ISSUE_NUMBER}/comments" \
+            -H "Authorization: token ${GIT_TOKEN}" \
+            -H "Content-Type: application/json" \
+            -d "{\"body\": \"Done (model: **${CLAUDE_MODEL}**, effort: ${EFFORT}, budget cap: \$${MAX_BUDGET}). API cost: **${COST}**\"}" > /dev/null
+
+          exit ${CLAUDE_EXIT}

.gitignore

@@ -1 +1,5 @@
 .refcache/
+# Generated build outputs (XML, TXT, HTML)
+draft-nennemann-wimse-ect-*.xml
+draft-nennemann-wimse-ect-*.txt
+draft-nennemann-wimse-ect-*.html

blog-ect-assurance-levels.md

@@ -0,0 +1,163 @@
+# The False Choice: Why Agentic Audit Trails Need Assurance Levels
+
+*How draft-nennemann-wimse-ect-01 introduces L1/L2/L3 to bridge the gap between "no overhead" and "full regulatory compliance."*
+
+---
+
+When you're building a system where AI agents act on behalf of users — approving transactions, recommending treatments, executing trades — you face a question that doesn't have a clean answer: how much proof do you need that each step actually happened?
+
+The first version of the Execution Context Token specification (draft-nennemann-wimse-ect-00) answered this with "all of it." Every ECT required a full JWS asymmetric signature, tightly coupled to WIMSE Workload Identity Tokens. That's the right answer for cross-organizational deployments where two companies need cryptographic non-repudiation. But it's wildly excessive for a team running an internal AI pipeline behind a service mesh. And it's not enough for a healthcare system that needs to prove, years later, that every step in a clinical decision was tamper-evidently recorded.
+
+The -01 revision introduces three assurance levels: L1, L2, and L3. Same payload. Same DAG structure. Same claims. Different envelopes, different verification, different guarantees. Choose the one that fits your threat model.
+
+## What Are ECTs?
+
+Before diving into assurance levels, a quick recap. Execution Context Tokens are JWT-based records of what an agent actually did in a distributed workflow. Each ECT captures a single task — "recommend_treatment", "verify_compliance", "execute_trade" — and links it to its predecessor tasks through a directed acyclic graph (DAG).
+
+ECTs originated as an extension to the IETF WIMSE (Workload Identity in Multi-System Environments) framework, but the -01 revision makes them identity-framework agnostic. Your identity layer handles "who is this agent?" ECTs handle "what did this agent do, and in what order?"
+
+The key properties:
+
+- **Per-task granularity.** One ECT per task, not one per session or per request chain.
+- **DAG ordering.** Parent references (`pred` claim) create a verifiable execution graph. Fan-out, fan-in, parallel branches — all representable.
+- **Data integrity without data exposure.** Input and output hashes (`inp_hash`, `out_hash`) prove what was processed without revealing the data itself.
+- **Identity-framework agnostic.** ECTs work with WIMSE WIT/WPT, X.509 certificates, OAuth credentials, or plain JWK sets. The spec defines abstract identity binding requirements and concrete profiles for each framework.
+
+## The Problem with draft-00
+
+The -00 draft defined one mode of operation: JWS Compact Serialization with asymmetric signing. Every ECT, always. This created two problems:
+
+**Too heavy for internal deployments.** If all your agents run in the same Kubernetes cluster behind Istio with mTLS, requiring every agent to sign every ECT with ES256 is pure overhead. You already trust the transport. You already trust the agents (you operate them). The signature gives you non-repudiation, but you don't need non-repudiation — you need structured execution records for debugging and observability.
+
+**Not heavy enough for regulated deployments.** A JWS signature proves who created the ECT and that it wasn't tampered with. But it doesn't prove the ECT was *recorded*. A malicious or buggy agent could create a valid signed ECT and then quietly drop it. For environments subject to FDA 21 CFR Part 11, MiFID II, or the EU AI Act, you need more: a tamper-evident ledger with cryptographic commitment, hash chains, and verifiable receipts proving that every ECT was committed to permanent storage at a specific time.
+
+One size doesn't fit all. The -01 revision acknowledges this by introducing three assurance levels.
+
+## Three Assurance Levels
+
+### Level 1: Unsigned JSON
+
+At L1, an ECT is a plain JSON object. No signature. No JWS envelope. Integrity comes from TLS.
+
+**What you get:**
+- Structured execution records with the full ECT payload (all the same claims)
+- DAG validation (parent references, acyclicity, temporal ordering)
+- Transport integrity via TLS/mTLS
+
+**What you don't get:**
+- Non-repudiation (no signature binds the ECT to the issuer)
+- Tamper detection after delivery (a compromised intermediary could modify the ECT)
+- Issuer authentication at the ECT layer
+
+**Where it fits:** Internal microservice meshes, development environments, AI platforms where all agents are operated by the same team. Think of it as "structured tracing" — you get the DAG and the claims without the PKI overhead.
+
+**Hard rule:** L1 MUST NOT cross trust domain boundaries. If agents from different organizations interact, L1 is not appropriate.
+
+### Level 2: JOSE Asymmetric Signing
+
+L2 is the -00 behavior, generalized. Each ECT is a signed JWT in JWS Compact Serialization format. The agent signs with a private key bound to its identity credential — whether that's a WIMSE WIT, an X.509 certificate, or a key from a JWK set. The verifier resolves the `kid` through the deployment's identity framework.
+
+**What you get (beyond L1):**
+- Non-repudiation (the cryptographic signature proves the issuer)
+- Tamper detection (any modification invalidates the signature)
+- Issuer authentication (the `kid` links to the agent's identity credential)
+- Audience restriction (`aud` limits who can verify)
+
+**Where it fits:** Cross-organization deployments, peer-to-peer agent communication, any environment requiring cryptographic proof of origin. L2 is the recommended default for production.
+
+**Backward compatibility:** Implementations of draft-nennemann-wimse-ect-00 are L2-compatible. No changes needed.
+
+### Level 3: JOSE Signing with Audit Ledger
+
+L3 is L2 plus a mandatory audit ledger with cryptographic commitment. The JWS signing is identical to L2. The difference is what happens after signing: the ECT must be recorded in a ledger that provides hash chains, Merkle proofs (or equivalent), and verifiable receipts.
+
+**What you get (beyond L2):**
+- Tamper-evident history (hash chains detect modification, insertion, or deletion of ledger entries)
+- Cryptographic commitment (Merkle proofs allow independent verification of inclusion)
+- Non-repudiation of recording (the receipt proves the ECT was committed at a specific time and position)
+
+**The ledger requirements:**
+- Each entry includes a cryptographic hash of the previous entry (hash chain)
+- The ledger provides verifiable commitment proofs
+- Upon append, the ledger returns a receipt with the sequence number, entry hash, and commitment proof
+- The ledger should be operated independently of the workflow agents
+
+**Recording modes:** L3 supports both synchronous recording (wait for receipt before sending the ECT downstream) and asynchronous recording (send first, verify receipt later). Synchronous is stronger; asynchronous is faster. Deployments choose based on latency requirements.
+
+**Where it fits:** Regulated environments — healthcare (FDA audit trails), financial services (MiFID II transaction reporting), any system subject to the EU AI Act's requirements for activity logs in high-risk AI systems.
+
+## Decision Framework
+
+Choosing the right level is straightforward. Ask three questions:
+
+**1. Do agents cross trust domain boundaries?**
+If yes, you need at least L2. Non-repudiation is essential when different organizations operate different agents. If no, L1 is an option.
+
+**2. Do you need cryptographic non-repudiation?**
+If you need to prove, after the fact, that a specific agent produced a specific ECT, you need L2 or L3. If TLS-level trust is sufficient, L1 works.
+
+**3. Do you operate under regulatory requirements for tamper-evident audit trails?**
+If yes, you need L3. The hash-chained ledger with cryptographic commitment provides the tamper evidence that regulators require. If no, L2 is sufficient for production deployments with non-repudiation.
+
+The decision tree in practice:
+
+```
+Internal only, no non-repudiation needed?      → L1
+Cross-org or non-repudiation needed?            → L2
+Regulatory tamper-evident audit trail required?  → L3
+```
+
+A single deployment can use different levels for different workflows. Your internal data preprocessing pipeline might be L1, your cross-org partner integrations L2, and your regulated clinical decision workflows L3.
+
+## Real-World Applications
+
+**Healthcare — Clinical Decision Support (L3).** A clinical AI system recommends treatments, checks drug interactions, and routes cases for specialist review. Every step is an ECT. The DAG proves that the safety check happened before the treatment recommendation reached the physician. The L3 ledger provides the tamper-evident audit trail that FDA 21 CFR Part 11 requires for electronic records.
+
+**Financial Services — Algorithmic Trading (L3).** An investment bank's agents coordinate with an external credit rating agency. Portfolio risk analysis, credit assessment, compliance verification, and trade execution form a cross-organizational DAG. L3 ensures every step is signed and committed to a tamper-evident ledger for MiFID II compliance.
+
+**Internal AI Platform — Model Serving (L1).** A company's internal AI platform chains preprocessors, model inference, and postprocessors. All services run in the same Kubernetes cluster with mTLS. L1 ECTs provide structured execution tracing for debugging without PKI overhead.
+
+**Multi-Organization API Gateway (L2).** A SaaS platform's agents interact with customer-operated agents. Both sides need to prove what happened, but there's no regulatory requirement for a tamper-evident ledger. L2 gives both organizations signed, verifiable execution records.
+
+## The Upgrade Path
+
+This is arguably the most important design property of the assurance levels: **the payload is the same at every level.** The same `jti`, `iss`, `aud`, `iat`, `exp`, `exec_act`, `pred`, `inp_hash`, `out_hash`, and `ect_ext` claims appear in every ECT, whether it's unsigned JSON or a ledger-committed JWS token.
+
+What changes is the envelope and the verification procedure. This means upgrading from L1 to L2 means adding a JWS wrapper around the same payload. Upgrading from L2 to L3 means deploying an audit ledger and adding the ledger recording step after JWS verification.
+
+Your DAG structure doesn't change. Your claim semantics don't change. Your workflow logic doesn't change. The agents still produce the same payload — they just wrap it differently and verify it more thoroughly.
+
+This is intentional. A startup might begin with L1 during development, move to L2 when they start working with external partners, and add L3 when they enter regulated markets. At each step, the payload format is familiar, the DAG is the same, and only the security envelope changes.
+
+## What Changed from -00 to -01
+
+A summary of the structural changes:
+
+**New Section 1.2: Assurance Levels and Applicability.** Defines L1, L2, L3 with applicability guidance.
+
+**Restructured Section 3: ECT Format.** The payload structure is now level-independent (Section 3.1), with separate subsections for L1 (3.3), L2 (3.4), and L3 (3.5). Each level has its own transport, verification, and security properties subsections.
+
+**iss/aud requirement relaxation.** The `iss` and `aud` claims move from REQUIRED to RECOMMENDED at the payload level. They remain REQUIRED for L2 and L3 (the verification procedure mandates them), but L1 deployments can omit them when identity is handled entirely at the transport layer.
+
+**Updated verification.** Section 6 adds level detection as the first step. L1 gets a simplified procedure (no signature steps). L2 retains the -00 procedure. L3 adds ledger recording and receipt verification.
+
+**Expanded audit ledger.** Section 7 distinguishes baseline ledger requirements (all levels) from L3-specific requirements (hash chains, commitment proofs, receipts). New subsections cover ledger independence and L3 verification procedures.
+
+**Level-specific security analysis.** Section 8 adds a new subsection analyzing each level's security properties, including L1 limitations and L3 ledger properties.
+
+**Identity-framework agnostic design.** The -00 draft hardcoded WIMSE WIT/WPT as the identity layer. The -01 draft introduces an abstract "Identity Binding" section defining what any identity framework must provide (key association, issuer correspondence, algorithm consistency, revocation checking) and then defines concrete profiles for WIMSE, X.509, and JWK sets. The `typ` header moves from `wimse-exec+jwt` to `exec+jwt` (with backward compatibility for the old value). This means you can use ECTs without deploying WIMSE — bring your own identity framework.
+
+## What's Next
+
+The -01 draft is open for working group feedback. Key questions for the community:
+
+- Is the three-level structure the right granularity, or should there be intermediate levels?
+- Should L3 ledger requirements reference SCITT (Supply Chain Integrity, Transparency, and Trust) more directly?
+- Are the L1 restrictions (MUST NOT cross trust domain boundaries) sufficient, or should L1 be further constrained?
+- Are the identity binding profiles (WIMSE, X.509, JWK set) sufficient, or should additional profiles be defined (e.g., OAuth client credentials, DID-based)?
+
+The reference implementations (Go and Python) will be updated to support all three levels and the pluggable identity binding model. Community contributions and feedback are welcome — the specification is developed in the open, and the goal is a standard that works for real deployments, from internal microservices to regulated clinical AI systems.
+
+---
+
+*Christian Nennemann is an independent researcher focused on workload identity and execution accountability in agentic AI systems. The ECT specification originated within the IETF WIMSE working group and is designed for use with any identity framework.*

build.sh

@@ -1,22 +1,39 @@
 #!/bin/bash
 set -e
 
-DRAFT="draft-nennemann-wimse-ect-00"
 DIR="$(cd "$(dirname "$0")" && pwd)"
+SRC="$DIR/draft-nennemann-wimse-ect.md"
+
+# Extract docname from YAML front matter
+DRAFT=$(grep '^docname:' "$SRC" | head -1 | awk '{print $2}')
+if [ -z "$DRAFT" ]; then
+  echo "Error: could not extract docname from $SRC"
+  exit 1
+fi
 
 # Tool paths
-KRAMDOWN="/usr/local/lib/ruby/gems/3.4.0/bin/kramdown-rfc2629"
-XML2RFC="/Users/christian/Library/Python/3.9/bin/xml2rfc"
+KRAMDOWN="$(which kramdown-rfc2629 2>/dev/null)"
+XML2RFC="$(which xml2rfc 2>/dev/null)"
+
+if [ -z "$KRAMDOWN" ]; then
+  echo "Error: kramdown-rfc2629 not found. Install with: gem install kramdown-rfc2629"
+  exit 1
+fi
+if [ -z "$XML2RFC" ]; then
+  echo "Error: xml2rfc not found. Install with: pip install xml2rfc"
+  exit 1
+fi
 
 export PYTHONWARNINGS="ignore::UserWarning"
 
+echo "Building: $DRAFT"
 echo "Using kramdown-rfc2629: $KRAMDOWN"
 echo "Using xml2rfc:          $XML2RFC"
 echo ""
 
 # Step 1: Markdown -> XML
 echo "Converting markdown to XML..."
-"$KRAMDOWN" "$DIR/$DRAFT.md" > "$DIR/$DRAFT.xml"
+"$KRAMDOWN" "$SRC" > "$DIR/$DRAFT.xml"
 
 # Step 2: XML -> TXT
 echo "Generating text output..."

draft-nennemann-wimse-ect-00.md

@@ -1,926 +0,0 @@
----
-title: "Execution Context Tokens for Distributed Agentic Workflows"
-abbrev: "WIMSE Execution Context"
-category: std
-docname: draft-nennemann-wimse-ect-00
-submissiontype: IETF
-number:
-date:
-v: 3
-area: "ART"
-workgroup: "WIMSE"
-keyword:
-  - execution context
-  - workload identity
-  - agentic workflows
-  - audit trail
-
-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:
-  RFC8693:
-  SPIFFE:
-    title: "Secure Production Identity Framework for Everyone (SPIFFE)"
-    target: https://spiffe.io/docs/latest/spiffe-about/overview/
-    date: false
-  OPENTELEMETRY:
-    title: "OpenTelemetry Specification"
-    target: https://opentelemetry.io/docs/specs/otel/
-    date: false
-    author:
-      - org: Cloud Native Computing Foundation
-  I-D.ietf-scitt-architecture:
-  RFC9449:
-  I-D.ietf-oauth-transaction-tokens:
-  I-D.oauth-transaction-tokens-for-agents:
-
---- abstract
-
-This document defines Execution Context Tokens (ECTs), a JWT-based
-extension to the WIMSE architecture that records task execution
-across distributed agentic workflows.  Each ECT is a signed record
-of a single task, linked to predecessor tasks through a directed
-acyclic graph (DAG).  ECTs reuse the WIMSE signing model and are
-transported in a new Execution-Context HTTP header field alongside
-existing WIMSE identity headers.
-
---- middle
-
-# Introduction
-
-The WIMSE framework {{I-D.ietf-wimse-arch}} and its service-to-
-service protocol {{I-D.ietf-wimse-s2s-protocol}} authenticate
-workloads across call chains but do not record what those
-workloads actually did.  This document defines Execution Context
-Tokens (ECTs), a JWT-based extension that fills the gap between
-workload identity and execution accountability.  Each ECT is a
-signed record of a single task, linked to predecessor tasks
-through a directed acyclic graph (DAG).
-
-## Scope and Applicability
-
-This document defines:
-
-- The Execution Context Token (ECT) format ({{ect-format}})
-- DAG structure for task dependency ordering ({{dag-validation}})
-- An HTTP header for ECT transport ({{http-header}})
-- Audit ledger interface requirements ({{ledger-interface}})
-
-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
-
-# 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 audit and 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.
-
-# 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}}.  ECTs MUST use
-JWS Compact Serialization (the base64url-encoded
-`header.payload.signature` format) so that they can be carried in
-a single HTTP header value.
-
-ECTs reuse the WIMSE signing model.  The ECT MUST be signed with
-the same private key associated with the agent's WIT.  The JOSE
-header "kid" parameter MUST reference the public key identifier
-from the agent's WIT, and the "alg" parameter MUST match the
-algorithm used in the corresponding WIT.  In WIMSE deployments,
-the ECT "iss" claim SHOULD use the WIMSE workload identifier
-format (a SPIFFE ID {{SPIFFE}}).
-
-## 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}
-
-### Standard JWT Claims
-
-An ECT MUST contain the following standard JWT claims {{RFC7519}}:
-
-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.  The "aud" claim SHOULD contain the
-  identifiers of all entities that will verify the ECT.  When
-  an ECT must be verified by both the next agent and the audit
-  ledger independently, "aud" MUST be an array containing both
-  identifiers.  Each verifier checks that its own identity
-  appears in "aud".
-
-iat:
-: REQUIRED.  NumericDate.  The time at which the ECT was issued.
-
-exp:
-: REQUIRED.  NumericDate.  The expiration time of the ECT.
-  Implementations SHOULD set this to 5 to 15 minutes after "iat".
-
-jti:
-: REQUIRED.  String.  A unique identifier for both the ECT and
-  the task it records, in UUID format {{RFC9562}}.  The "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").  This claim name avoids 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.  The base64url encoding (without padding) of
-  the SHA-256 hash of the input data, computed over the raw octets
-  of the input.  SHA-256 is the mandatory algorithm with no
-  algorithm prefix in the value, consistent with {{RFC9449}} and
-  {{I-D.ietf-wimse-s2s-protocol}}.
-
-out_hash:
-: OPTIONAL.  String.  The base64url encoding (without padding) of
-  the SHA-256 hash of the output data, using the same format as
-  "inp_hash".
-
-### Extensions {#extension-claims}
-
-ext:
-: OPTIONAL.  Object.  A general-purpose extension object for
-  domain-specific claims not defined by this specification.
-  Implementations that do not understand extension claims MUST
-  ignore them.  Extension key names SHOULD use reverse domain
-  notation (e.g., "com.example.custom_field") to avoid
-  collisions.  The serialized "ext" object SHOULD NOT exceed
-  4096 bytes and SHOULD NOT exceed a nesting depth of 5 levels.
-
-## 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": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-  "out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
-
-  "ext": {
-    "com.example.trace_id": "abc123"
-  }
-}
-~~~
-{: #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.  When a Workload Proof Token (WPT) is available per
-{{I-D.ietf-wimse-s2s-protocol}}, agents SHOULD include it
-alongside the WIT and ECT.
-
-~~~
-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}
-
-ECTs form a Directed Acyclic Graph (DAG) where each task
-references its parent tasks via the "par" claim.  DAG validation
-is performed against the ECT store — either an audit ledger or
-the set of parent ECTs received inline.
-
-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.
-
-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.
-
-In distributed deployments, a parent ECT may not yet be available
-locally due to replication lag.  Implementations MAY defer
-validation to allow parent ECTs to arrive, but MUST NOT treat
-the ECT as verified until all parent references are resolved.
-
-# 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 appears in the
-    verifier's configured allowlist of accepted signing algorithms.
-    The allowlist MUST NOT include "none" or any symmetric
-    algorithm (e.g., HS256, HS384, HS512).  Implementations MUST
-    include ES256 in the allowlist; additional asymmetric algorithms
-    MAY be included per deployment policy.
-
-4.  Verify the "kid" header parameter references a known, valid
-    public key from a WIT within the trust domain.
-
-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.
-
-# 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
-
-## Threat Model
-
-The threat model considers: (1) a malicious agent that creates
-false ECT claims, (2) an agent whose private key has been
-compromised, (3) a ledger tamperer attempting to modify recorded
-entries, and (4) a time manipulator altering timestamps to affect
-perceived 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 and the integrity of the broader deployment
-environment.  ECTs provide a technical mechanism for execution
-recording; they do not by themselves satisfy any specific
-regulatory compliance requirement.
-
-## 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)
-and audience restriction via "aud" to limit replay attacks.
-Implementations MUST maintain a cache of recently-seen "jti"
-values and MUST reject ECTs with duplicate "jti" values.  Each
-ECT is cryptographically bound to the issuing agent via "kid";
-verifiers MUST confirm that "kid" resolves to the "iss" agent's
-key (step 8 in {{verification}}).
-
-## Man-in-the-Middle Protection
-
-ECTs MUST be transmitted over TLS or mTLS connections.  When used
-with {{I-D.ietf-wimse-s2s-protocol}}, transport security is
-already established.
-
-## Key Compromise
-
-If an agent's private key is compromised, an attacker can forge
-ECTs that appear to originate from that agent.  Mitigations:
-
-- Implementations SHOULD use short-lived keys and rotate them
-  frequently.
-- Private keys SHOULD be stored in hardware security modules or
-  equivalent secure key storage.
-- Trust domains MUST support rapid key revocation.
-
-ECTs recorded before key revocation remain valid historical
-records but SHOULD be flagged for audit purposes.  New ECTs
-MUST NOT reference a parent ECT whose signing key is known to
-be revoked at creation time.
-
-## Collusion and DAG Integrity {#collusion-and-false-claims}
-
-A single malicious agent cannot forge parent task references
-because DAG validation requires parent tasks to exist in the ECT
-store.  However, multiple colluding agents could create a false
-execution history.  Additionally, a malicious agent may omit
-actual parent dependencies from "par" to hide influences on its
-output; because ECTs are self-asserted
-({{self-assertion-limitation}}), no mechanism can force complete
-dependency declaration.
-
-Mitigations include:
-
-- The ledger SHOULD be maintained by an entity independent of the
-  workflow agents.
-- Multiple independent ledger replicas can be compared for
-  consistency.
-- External auditors can compare the declared DAG against expected
-  workflow patterns.
-
-Verifiers SHOULD validate that the declared "wid" of parent ECTs
-matches the "wid" of the child ECT, rejecting cross-workflow
-parent references unless explicitly permitted by deployment
-policy.
-
-## Privilege Escalation via ECTs
-
-ECTs record execution history; they do not convey authorization.
-Verifiers MUST NOT interpret the presence of an ECT, or a
-particular set of parent references in "par", as an authorization
-grant.  Authorization decisions MUST remain with the identity and
-authorization layer (WIT, WPT, and deployment policy).
-
-## Denial of Service
-
-Implementations SHOULD apply rate limiting to prevent excessive
-ECT submissions.  DAG validation SHOULD be performed after
-signature verification to avoid wasting resources on unsigned
-tokens.
-
-## Timestamp Accuracy
-
-Implementations SHOULD use synchronized time sources (e.g., NTP)
-and SHOULD allow a configurable clock skew tolerance (RECOMMENDED:
-30 seconds).  Cross-organizational deployments MAY require a
-higher tolerance and SHOULD document the configured value.
-
-## ECT Size Constraints
-
-Implementations SHOULD limit the "par" array to a maximum of
-256 entries.  See {{extension-claims}} for "ext" size limits.
-
-# 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 can read them.  Implementations SHOULD
-consider encryption at rest for ledger storage.  ECTs provide
-structural records of execution ordering; they are not intended
-for public disclosure.
-
-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.
-
-# 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 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"}
-
---- back
-
-# Use Cases {#use-cases}
-{:numbered="false"}
-
-This section describes a representative use case demonstrating how
-ECTs provide structured execution records.
-
-Note: task identifiers in this section are abbreviated for
-readability.  In production, all "jti" values are required to be
-UUIDs per {{exec-claims}}.
-
-## Cross-Organization Financial Trading
-{:numbered="false"}
-
-In a cross-organization trading workflow, an investment bank's
-agents coordinate with an external credit rating agency.  The
-agents operate in separate trust domains with a federation
-relationship.  The DAG records that independent assessments from
-both organizations were completed before trade execution.
-
-~~~
-Trust Domain: bank.example
-  Agent A1 (Portfolio Risk):
-    jti: task-001    par: []
-    iss: spiffe://bank.example/agent/risk
-    exec_act: analyze_portfolio_risk
-
-Trust Domain: ratings.example (external)
-  Agent B1 (Credit Rating):
-    jti: task-002    par: []
-    iss: spiffe://ratings.example/agent/credit
-    exec_act: assess_credit_rating
-
-Trust Domain: bank.example
-  Agent A2 (Compliance):
-    jti: task-003    par: [task-001, task-002]
-    iss: spiffe://bank.example/agent/compliance
-    exec_act: verify_trade_compliance
-
-  Agent A3 (Execution):
-    jti: task-004    par: [task-003]
-    iss: spiffe://bank.example/agent/execution
-    exec_act: execute_trade
-~~~
-{: #fig-finance title="Cross-Organization Trading Workflow"}
-
-The resulting DAG:
-
-~~~
-task-001 (analyze_portfolio_risk)   task-002 (assess_credit_rating)
-  [bank.example]                      [ratings.example]
-          \                              /
-           v                            v
-         task-003 (verify_trade_compliance)
-           [bank.example]
-                    |
-                    v
-         task-004 (execute_trade)
-           [bank.example]
-~~~
-{: #fig-finance-dag title="Cross-Organization DAG"}
-
-Task 003 has two parents from different trust domains,
-demonstrating cross-organizational fan-in.  The compliance agent
-verifies both parent ECTs — one signed by a local key and one by
-a federated key from the rating agency's trust domain.
-
-# 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.
-- It cannot represent convergence (fan-in): when two independent
-  paths must both complete before a dependent task proceeds, a
-  linear "req_wl" string cannot express that relationship.
-
-Extensions for agentic use cases
-({{I-D.oauth-transaction-tokens-for-agents}}) add agent
-identity and constraints ("agentic_ctx") but no execution
-ordering or DAG 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.
-
-## W3C Provenance Data Model (PROV)
-{:numbered="false"}
-
-The W3C PROV Data Model defines an Entity-Activity-Agent ontology
-for representing provenance information.  PROV's concepts map
-closely to ECT structures: PROV Activities correspond to ECT
-tasks, PROV Agents correspond to WIMSE workloads, and PROV's
-"wasInformedBy" relation corresponds to ECT "par" references.
-However, PROV uses RDF/OWL ontologies designed for post-hoc
-documentation, while ECTs are runtime-embeddable JWT tokens with
-cryptographic signatures.  ECT audit data could be exported to
-PROV format for interoperability with provenance-aware systems.
-
-## SCITT (Supply Chain Integrity, Transparency, and Trust)
-{:numbered="false"}
-
-The SCITT architecture {{I-D.ietf-scitt-architecture}} defines a
-framework for transparent and auditable supply chain records.
-ECTs and SCITT are complementary: the ECT "wid" claim can serve
-as a correlation identifier in SCITT Signed Statements, linking
-an ECT audit trail to a supply chain transparency record.
-
-# 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.

refimpl/IMPROVEMENTS.md

@@ -7,7 +7,7 @@ Suggestions that could make the implementations more robust, spec-strict, or pro
 ## 1. **Spec alignment** ✅
 
 - **ext size/depth (Section 4.2.7)**  
-  **Done.** Both refimpls reject when serialized `ext` exceeds 4096 bytes or JSON depth exceeds 5 (`ValidateExt` / `validate_ext`). Used in create and verify.
+  **Done.** Both refimpls reject when serialized `ect_ext` exceeds 4096 bytes or JSON depth exceeds 5 (`ValidateExt` / `validate_ext`). Used in create and verify.
 
 - **jti / wid format**  
   **Done.** Optional UUID (RFC 9562) validation: `CreateOptions.ValidateUUIDs` / `VerifyOptions.ValidateUUIDs` (Go), `validate_uuids` (Python). Helpers: `ValidUUID` / `valid_uuid`.
@@ -58,3 +58,18 @@ Suggestions that could make the implementations more robust, spec-strict, or pro
 ---
 
 **Summary:** All listed improvements are implemented. For production, also consider: key rotation, WIT integration, and metrics around verify/create latency and error kinds.
+
+---
+
+## 6. **draft-01 migration** (NOT YET IMPLEMENTED)
+
+The refimpl was built against draft-nennemann-wimse-ect-00. The -01 draft introduced breaking changes that need to be reflected:
+
+- **Rename `par` to `pred`**: The predecessor claim was renamed. Update struct fields, JSON tags, serialization/deserialization, tests, and testdata.
+- **Remove `pol` and `pol_decision`**: Policy claims were removed from the core spec. Deployments should use `ect_ext` for domain-specific claims like policy decisions.
+- **Remove `sub`**: The `sub` claim is not part of the ECT specification. Remove from types and examples.
+- **Update `typ` default**: Prefer `exec+jwt` over `wimse-exec+jwt`. Both must be accepted for backward compatibility.
+- **Add L1 support**: The -01 draft introduces unsigned JSON ECTs (Level 1). The refimpl currently only supports L2 (signed JWS).
+- **Add L3 support**: The -01 draft introduces audit ledger requirements for Level 3. The existing in-memory ledger needs hash chain and receipt support.
+- **Update `MaxParLength` naming**: Rename to `MaxPredLength` to match the new claim name.
+- **Update hash format**: The -01 draft specifies SHA-256 base64url without algorithm prefix (no `sha-256:` prefix), consistent with RFC 9449.

refimpl/README.md

@@ -1,6 +1,18 @@
 # WIMSE Execution Context Tokens — Reference Implementations
 
-This directory contains **reference implementations** of [Execution Context Tokens (ECTs)](../draft-nennemann-wimse-execution-context-00.txt) for the WIMSE (Workload Identity in Multi System Environments) draft. Each refimpl provides ECT creation, verification, DAG validation, and an in-memory audit ledger.
+> **Note**: These reference implementations were built against **draft-nennemann-wimse-ect-00**.
+> The current draft (**-01**) introduced several claim name changes and structural updates:
+>
+> | -00 (refimpl) | -01 (current draft) | Notes |
+> |---------------|---------------------|-------|
+> | `par`         | `pred`              | Predecessor task IDs |
+> | `pol`, `pol_decision` | removed (use `ect_ext`) | Policy claims moved to extension object |
+> | `sub`         | not defined         | Standard JWT claim, not part of ECT spec |
+> | `typ: wimse-exec+jwt` | `typ: exec+jwt` (preferred) | Both accepted for backward compat |
+>
+> The refimpl update to -01 is tracked in IMPROVEMENTS.md.
+
+This directory contains **reference implementations** of Execution Context Tokens (ECTs) for the WIMSE (Workload Identity in Multi System Environments) draft. Each refimpl provides ECT creation, verification, DAG validation, and an in-memory audit ledger.
 
 ## Implementations
 
@@ -11,11 +23,11 @@ This directory contains **reference implementations** of [Execution Context Toke
 
 ## Scope (all refimpls)
 
-- **ECT format**: JWT (JWS Compact Serialization) with required/optional claims per the spec (Section 4).
-- **Creation**: Build and sign ECTs with ES256; `kid` and `typ: wimse-exec+jwt` in the JOSE header.
-- **Verification**: Full Section 7 procedure (parse, typ/alg, key resolution, signature, claims, optional DAG).
-- **DAG validation**: Section 6 (uniqueness, parent existence, temporal ordering, acyclicity, parent policy).
-- **Ledger**: Interface plus in-memory append-only store (Section 9).
+- **ECT format**: JWT (JWS Compact Serialization) with required/optional claims per the spec.
+- **Creation**: Build and sign ECTs with ES256; `kid` and `typ` in the JOSE header.
+- **Verification**: Full verification procedure (parse, typ/alg, key resolution, signature, claims, optional DAG).
+- **DAG validation**: Uniqueness, parent existence, temporal ordering, acyclicity, parent policy.
+- **Ledger**: Interface plus in-memory append-only store.
 
 No WIT/WPT issuance or full WIMSE stack; refimpls use key resolution only. Suitable for conformance testing and as a template for production integrations.
 
@@ -41,8 +53,8 @@ python3 -m pytest tests/ -v
 
 ## Specification
 
-- **Draft**: `draft-nennemann-wimse-execution-context-00`
-- **Sections**: 4 (format), 5 (HTTP header), 6 (DAG), 7 (verification), 9 (ledger interface).
+- **Current draft**: `draft-nennemann-wimse-ect-01`
+- **Refimpl implements**: `-00` claim names (see migration note above)
 
 ## License