docs: update WIMSE ECT draft; add -02 PDF; gitignore python artifacts

- bump docname to draft-nennemann-wimse-ect-02
- add Relationship to ACT subsection (normative ACT reference)
- add Related Work: WIMSE arch §3.3.9, Composition Safety (AgentRFC),
  MIGT taxonomy, NIST/NCCoE, SCITT-AI-agent-execution, DAWN
- acknowledge wimse-http-signature -03 breaking change (wimse-aud param)
- pin SCITT arch to -22 (AUTH48), txn-tokens to -08 (WG Last Call)
- add DIFF vs txn-tokens-for-agents-06 for WIMSE list intro
- add IETF 123 slide outline (10-min WIMSE slot)
- add wimse-intro-email draft for mailing list post
- mark refimpl as moved to workspace/packages/ect/

.gitignore

@@ -3,3 +3,8 @@
 draft-nennemann-wimse-ect-*.xml
 draft-nennemann-wimse-ect-*.txt
 draft-nennemann-wimse-ect-*.html
+
+# Python build/test artifacts
+__pycache__/
+*.egg-info/
+.coverage

DIFF-vs-txn-tokens-for-agents.md

@@ -0,0 +1,163 @@
+# ACT + ECT vs. draft-oauth-transaction-tokens-for-agents: Differentiation
+
+**Purpose**: Pre-emptive overlap analysis for the WIMSE mailing list introduction.
+This document is factual and non-adversarial. Raut et al.'s work is relevant
+and well-motivated; the goal is to clarify where these specifications are
+complementary and where they address genuinely different problems.
+
+---
+
+## What Each Specification Does
+
+- **draft-nennemann-act (ACT)**: Defines a two-phase JWT lifecycle that first
+  authorizes an agent via a signed capability mandate and then seals that
+  authorization into a tamper-evident execution record, requiring no shared
+  Authorization Server or identity infrastructure.
+
+- **draft-nennemann-wimse-ect (ECT)**: Defines a single-phase, WIMSE-profile
+  JWT for recording task execution with explicit assurance levels (L1–L3) and
+  workload-identity binding; a sibling profile of ACT for deployments that
+  already run SPIFFE/SPIRE or equivalent.
+
+- **draft-oauth-transaction-tokens-for-agents-06 (Txn-Agents)**: Extends the
+  OAuth Transaction Tokens (draft-ietf-oauth-transaction-tokens) issuance model
+  by adding agent identity context (`act`, `agentic_ctx`, `actchain`) to tokens
+  issued by a central Transaction Token Service (TTS), covering both
+  principal-initiated and autonomous agent flows.
+
+---
+
+## Claim-Level Comparison
+
+| Claim / Concept       | ACT (Phase 1)      | ACT (Phase 2)      | ECT                | Txn-Agents         |
+|-----------------------|--------------------|--------------------|--------------------|--------------------|
+| `iss`                 | Required           | Required           | Required (L2/L3)   | TTS URI            |
+| `sub`                 | Target agent id    | Target agent id    | —                  | Principal identity |
+| `aud`                 | Required           | Required           | Required (L2/L3)   | Resource server    |
+| `iat` / `exp`         | Required           | Required           | Required           | Required           |
+| `jti`                 | Task UUID          | Task UUID          | Task + token UUID  | —                  |
+| `act`                 | —                  | —                  | —                  | Acting agent id    |
+| `actchain`            | `del.chain` (ACT)  | `del.chain` (ACT)  | —                  | Delegation array   |
+| `txn`                 | —                  | —                  | —                  | Txn correlation id |
+| `purp` / `task`       | `task.purpose`     | `task.purpose`     | `exec_act`         | `purp`             |
+| `cap` (capabilities)  | Required array     | Preserved          | —                  | `scope` (OAuth)    |
+| `oversight`           | Optional HITL ref  | Preserved          | —                  | —                  |
+| `inp_hash`            | —                  | Recommended        | Optional           | —                  |
+| `out_hash`            | —                  | Recommended        | Optional           | —                  |
+| `pred` (DAG parents)  | —                  | Required array     | Required array     | —                  |
+| `wid` (workflow id)   | Optional           | Optional           | Optional           | —                  |
+| `agentic_ctx`         | —                  | —                  | —                  | Optional object    |
+| `req_wl`              | —                  | —                  | —                  | Requesting wl id   |
+| `exec_ts` / `status`  | —                  | Required           | —                  | —                  |
+| Assurance levels      | Trust tiers (0–3)  | Trust tiers (0–3)  | L1 / L2 / L3       | Single model       |
+| Identity binding      | Pre-shared/PKI/DID | Pre-shared/PKI/DID | WIMSE WIT / X.509  | OAuth access token |
+
+**Shared semantics** (identical or directly comparable): `jti`, `wid`,
+`inp_hash`, `out_hash`, `pred`. ECT's `exec_act` and ACT's `task.purpose`
+overlap in intent (action type identifier) but differ in schema. ACT's
+`del.chain` and Txn-Agents' `actchain` both track delegation lineage but
+through different issuance models (peer-signed vs. TTS-issued).
+
+---
+
+## Lifecycle Model
+
+**Txn-Agents** is a single-phase extension. A Transaction Token Service (TTS)
+issues one token per request, populated from the agent's OAuth access token.
+Token replacement re-issues a new token with updated `act`/`actchain` but the
+same `txn`. There is no concept of a pre-execution authorization phase separate
+from the token itself; the token *is* the authorization assertion at the moment
+of issuance.
+
+**ACT** is two-phase by design. Phase 1 (Mandate): a delegating agent signs an
+authorization token encoding capabilities, constraints, and oversight
+requirements *before* execution begins. Phase 2 (Record): the executing agent
+appends `exec_act`, `inp_hash`, `out_hash`, `pred`, and `exec_ts` and
+re-signs the entire token with its own key. This re-signature binds the
+agent's cryptographic identity to both the mandate it received and the
+execution it performed in a single non-repudiable envelope.
+
+**ECT** is single-phase and records execution only. It does not carry
+authorization intent. It is designed for deployments where authorization is
+handled by the existing identity plane (WIMSE WIT/WPT, OAuth, X.509) and only
+execution recording is needed.
+
+---
+
+## Accountability Story
+
+**ACT's unique property** is the commitment transition. A Phase 2 ACT is
+cryptographic evidence of two facts simultaneously: (a) the agent *was
+authorized* under specific capability constraints at a specific time, and (b)
+the agent *did act*, processing specific inputs and producing specific outputs
+as hashed. No other specification in this space fuses pre-execution
+authorization and post-execution recording in a single token whose signature
+chain preserves both. Txn-Agents can assert who acted and in what context; it
+cannot assert what was permitted before the fact.
+
+**ECT's unique property** is graduated assurance and WIMSE integration.
+L1/L2/L3 let deployments select the appropriate compliance posture. L3
+requires every ECT to be committed to an audit ledger with hash-chain or
+Merkle-tree commitment — satisfying DORA, EU AI Act Article 12, and IEC 62304
+requirements without a separate log format. ECT's `iss` is anchored to the
+SPIFFE workload identity, providing stronger workload binding than a client
+credential alone.
+
+**Txn-Agents' accountability model** relies on the TTS to produce honest
+tokens from verified access tokens. The audit trail consists of logged `act`
+and `sub` claims per the spec's SHOULD recommendation. This is operationally
+simpler and sufficient for many enterprise deployments, but it does not
+constitute a tamper-evident record of what the agent actually processed.
+
+---
+
+## Where These Could Be Used Together
+
+ACT and Txn-Agents are complementary in OAuth-enabled deployments. A Txn-Agent
+token can serve as the bearer credential for the initial service call; an ACT
+Mandate, carried in a separate `ACT-Mandate` header, adds fine-grained
+capability constraints on top of the OAuth scope. The Txn-Agents token handles
+the transaction correlation and TTS-based trust; the ACT Mandate and subsequent
+ACT Record handle per-invocation authorization evidence and tamper-evident
+execution recording.
+
+ECT and Txn-Agents are similarly composable: Txn-Agents handles principal and
+agent identity within an OAuth trust domain; ECT handles workload-level
+execution recording within the WIMSE trust domain. They operate at different
+layers and their co-presence is additive.
+
+---
+
+## When to Use Which
+
+| Situation                                                        | Recommendation                          |
+|------------------------------------------------------------------|-----------------------------------------|
+| You have OAuth infrastructure and a TTS                          | Txn-Agents as authorization layer        |
+| You need tamper-evident pre/post execution binding               | ACT (two-phase lifecycle)               |
+| You have WIMSE/SPIFFE deployed and need execution recording      | ECT                                     |
+| Cross-org federation with no shared AS or identity provider      | ACT (Tier 1 pre-shared key bootstrap)   |
+| Regulated environment requiring ledger-committed audit trail     | ECT L3 (or ACT + SCITT anchor)          |
+| You need delegation lineage across multiple agent hops           | Txn-Agents `actchain` or ACT `del.chain`|
+| You need capability-level constraints beyond OAuth scope strings | ACT `cap` array                         |
+| HITL approval gating before execution                            | ACT `oversight` claim                   |
+
+---
+
+## Honest Overlap
+
+The real overlap zone is multi-agent delegation tracking. Both Txn-Agents'
+`actchain` and ACT's `del.chain` record which agents delegated to which.
+Implementers who already run a TTS and OAuth infrastructure have less reason to
+adopt ACT's peer-to-peer delegation model. For those deployments,
+Txn-Agents covers the identity and delegation layer adequately, and only the
+execution recording gap (handled by ECT or ACT Phase 2) would remain unaddressed.
+
+ACT does not require a TTS, an Authorization Server, or a SPIFFE trust domain.
+This is its primary differentiator for cross-organizational or
+infrastructure-light deployments — not a claim of superiority over
+OAuth-native approaches in environments where that infrastructure exists.
+
+---
+
+*draft-nennemann-act-01 / draft-nennemann-wimse-ect-02 vs.
+draft-oauth-transaction-tokens-for-agents-06 (Raut, Amazon, April 2026)*

build.sh

@@ -43,8 +43,27 @@ echo "Generating text output..."
 echo "Generating HTML output..."
 "$XML2RFC" "$DIR/$DRAFT.xml" --html --quiet 2>/dev/null
 
+# Step 4: XML -> PDF (requires weasyprint + pangocffi + pycairo injected into xml2rfc venv
+# and pydyf<0.10 pinned; see /home/c/projects/research.ietf/workspace/drafts/README-pdf.md)
+echo "Generating PDF output..."
+if "$XML2RFC" "$DIR/$DRAFT.xml" --pdf --quiet 2>/dev/null; then
+  PDF_OK=1
+else
+  echo "  xml2rfc --pdf failed; falling back to weasyprint on HTML"
+  if command -v weasyprint >/dev/null 2>&1; then
+    weasyprint "$DIR/$DRAFT.html" "$DIR/$DRAFT.pdf" >/dev/null 2>&1 && PDF_OK=1 || PDF_OK=0
+  else
+    PDF_OK=0
+  fi
+fi
+
 echo ""
 echo "Build complete:"
 echo "  $DRAFT.xml   (submit this to datatracker)"
 echo "  $DRAFT.txt"
 echo "  $DRAFT.html"
+if [ "${PDF_OK:-0}" = "1" ]; then
+  echo "  $DRAFT.pdf"
+else
+  echo "  (PDF generation skipped — missing deps)"
+fi

draft-nennemann-wimse-ect.md

@@ -2,7 +2,7 @@
 title: "Execution Context Tokens for Distributed Agentic Workflows"
 abbrev: "WIMSE Execution Context"
 category: std
-docname: draft-nennemann-wimse-ect-01
+docname: draft-nennemann-wimse-ect-02
 submissiontype: IETF
 number:
 date:
@@ -30,6 +30,14 @@ normative:
   RFC9449:
   RFC9562:
   RFC9110:
+  I-D.nennemann-act:
+    title: "Agent Context Token (ACT)"
+    target: https://datatracker.ietf.org/doc/draft-nennemann-act/
+    seriesinfo:
+      Internet-Draft: draft-nennemann-act-01
+    date: 2026
+    author:
+      - fullname: Christian Nennemann
 
 informative:
   RFC6838:
@@ -37,6 +45,13 @@ informative:
   RFC8725:
   I-D.ietf-wimse-arch:
   I-D.ietf-wimse-s2s-protocol:
+  I-D.ietf-wimse-http-signature:
+    title: "HTTP Message Signatures for Workloads"
+    target: https://datatracker.ietf.org/doc/draft-ietf-wimse-http-signature-03/
+    seriesinfo:
+      Internet-Draft: draft-ietf-wimse-http-signature-03
+    date: 2026-04-07
+  RFC9421:
   SPIFFE:
     title: "SPIFFE ID"
     target: https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/
@@ -47,7 +62,13 @@ informative:
     date: false
     author:
       - org: Cloud Native Computing Foundation
+  # draft-ietf-scitt-architecture is currently in AUTH48 (RFC Editor
+  # queue) at version -22. To become RFC upon publication. Readers
+  # should use the RFC number once assigned. Refcache pins -22.
   I-D.ietf-scitt-architecture:
+  # draft-ietf-oauth-transaction-tokens is in IETF WG Last Call at
+  # version -08. Normative reference will be updated to the published
+  # RFC. Refcache pins -08.
   I-D.ietf-oauth-transaction-tokens:
   I-D.oauth-transaction-tokens-for-agents:
     title: "Transaction Tokens for Agentic AI Systems"
@@ -57,6 +78,39 @@ informative:
     date: 2025
     author:
       - fullname: Vittorio Bertocci
+  I-D.draft-emirdag-scitt-ai-agent-execution:
+    title: "SCITT Profile for AI Agent Execution"
+    target: https://datatracker.ietf.org/doc/draft-emirdag-scitt-ai-agent-execution/
+    date: 2026
+    author:
+      - fullname: Emirdag
+  I-D.draft-king-dawn-requirements:
+    title: "Requirements for Discovery of AI Agents and Workloads Across Network Boundaries"
+    target: https://datatracker.ietf.org/doc/draft-king-dawn-requirements/
+    date: 2026
+    author:
+      - fullname: King
+      - fullname: Farrel
+  AgentRFC:
+    title: "AgentRFC: Security Design Principles and Conformance Testing for Agent Protocols"
+    target: https://arxiv.org/abs/2603.23801
+    date: 2026
+    author:
+      - fullname: Zheng, Shenghan
+      - fullname: Zhang, Qifan
+  MIGT:
+    title: "Who Governs the Machine? A Machine Identity Governance Taxonomy"
+    target: https://arxiv.org/abs/2604.06148
+    date: 2026
+    author:
+      - fullname: Kurtz, Andrew
+      - fullname: Krawiecka, Klaudia
+  NIST-NCCoE-AI-Agents:
+    title: "Accelerating the Adoption of Software and AI Agent Identity and Authorization"
+    target: https://www.nccoe.nist.gov/projects/ai-agent-identity-authorization
+    date: 2026
+    author:
+      - org: NIST
   RFC9334:
 
 --- abstract
@@ -141,6 +195,31 @@ Assurance level selection is orthogonal to human-in-the-loop
 (HITL) policy: any level may be combined with HITL requirements.
 Level selection guidance is provided in {{level-selection}}.
 
+## Relationship to Agent Context Tokens (ACT)
+
+The Agent Context Token (ACT) {{I-D.nennemann-act}} defines a
+two-phase authorization and accountability mechanism for agentic
+workflows.  In the first phase an ACT Mandate authorizes an agent
+to perform a bounded set of actions with explicit capability
+constraints and delegation chains.  In the second phase an ACT
+Record captures what the agent actually did, enabling post-hoc
+comparison between authorized and observed behavior.
+
+ECTs and ACTs are complementary.  ACTs answer "was this agent
+authorized to act, and what did it do relative to that
+authorization?"  ECTs answer "which workload executed this task,
+in which trust domain, and at what assurance level?"  The two
+tokens serve different accountability layers and a deployment MAY
+carry both simultaneously: an ACT for capability-scoped
+authorization and audit, and an ECT for workload-identity-bound
+execution recording with DAG ordering and assurance levels.
+
+The following claims have identical semantics in both
+specifications: "exec_act", "jti", "wid", "inp_hash", "out_hash",
+and "pred".  Implementations that produce both token types MUST
+use consistent values for these claims when they refer to the same
+task.
+
 # Conventions and Definitions
 
 {::boilerplate bcp14-tagged}
@@ -778,6 +857,18 @@ When the deployment uses the WIMSE framework
 - ECTs are transported alongside the WIT and WPT
   ({{I-D.ietf-wimse-s2s-protocol}}) in HTTP requests.
 
+ECT defines its own `Execution-Context` HTTP header field
+({{http-header}}) and does not rely on WIMSE HTTP message
+signature machinery.  Deployments that additionally apply WIMSE
+HTTP message signatures {{I-D.ietf-wimse-http-signature}} to
+protect requests should note that as of
+draft-ietf-wimse-http-signature-03 the audience value is conveyed
+via the `wimse-aud` signature metadata parameter (per the HTTP
+Message Signatures framework {{RFC9421}}) rather than a dedicated
+HTTP header.  This change does not affect the ECT payload's own
+`aud` claim or the `Execution-Context` header defined in this
+document.
+
 ### X.509 Binding {#x509-binding}
 
 When the deployment uses X.509 certificates:
@@ -1677,6 +1768,129 @@ Trust Domain: internal.example
 ~~~
 {: #fig-internal title="Internal Microservice Workflow (L1)"}
 
+## Dev-SDLC (mixed L1-L3)
+{:numbered="false"}
+
+A software development lifecycle provides a canonical example of
+mixed assurance levels within a single continuous-delivery
+workflow.  A commit event triggers an internal build agent (L1),
+which produces a versioned artifact.  Three parallel agents then
+process the artifact: an LLM-powered code-review agent operated
+by an external vendor (L2, non-repudiation required), an SBOM
+and vulnerability scanner operated by a separate external scan
+vendor (L2), and an internal test runner (L1).  Their ECTs fan
+in to a staging deployment agent (L2) that operates across the
+organizational boundary of the artifact registry.  Once staging
+tests pass, a human approver issues an Authorization Context
+Token (ACT) via a Verifiable Credential, and the production
+deployment agent (L3) executes the promotion to the regulated
+production environment, recording its ECT on an audit ledger.
+A rollback agent (L3) uses the same ledger entry as its pred
+reference, ensuring the rollback is chained to the promotion it
+reverses.
+
+This workflow uses three assurance levels simultaneously because
+each phase carries different accountability requirements.
+Internal build and test steps (L1) do not cross trust boundaries
+and require no signing overhead.  Steps touching external
+vendors or the artifact registry boundary (L2) require signed
+ECTs so each party can prove its contribution non-repudiably.
+The production promotion and any rollback (L3) require tamper-
+evident audit-ledger entries to satisfy change-management and
+regulatory obligations (e.g., SOC 2, ISO 27001 change records).
+
+~~~
+Trust Domain: internal.example
+  Agent D1 (Build):
+    jti: task-301    pred:[]
+    iss: spiffe://internal.example/agent/build
+    exec_act: build_artifact
+
+  Agent D5 (Test Runner):
+    jti: task-303    pred:[task-301]
+    iss: spiffe://internal.example/agent/test
+    exec_act: run_tests
+
+Trust Domain: llm-vendor.example (external)
+  Agent D2 (LLM Code Review):
+    jti: task-302    pred:[task-301]
+    iss: spiffe://llm-vendor.example/agent/review
+    exec_act: llm_code_review
+
+Trust Domain: scan-vendor.example (external)
+  Agent D3 (SBOM/Vuln Scanner):
+    jti: task-304    pred:[task-301]
+    iss: spiffe://scan-vendor.example/agent/scanner
+    exec_act: scan_sbom_vulnerabilities
+
+Trust Domain: internal.example
+  Agent D4 (Staging Deploy):
+    jti: task-305    pred:[task-302, task-303, task-304]
+    iss: spiffe://internal.example/agent/staging
+    exec_act: deploy_staging
+
+  Agent D6 (Human Approver — ACT):
+    jti: task-306    pred:[task-305]
+    iss: spiffe://internal.example/identity/approver
+    exec_act: authorize_production_promotion
+
+  Agent D7 (Production Deploy):
+    jti: task-307    pred:[task-305]
+    iss: spiffe://internal.example/agent/prod-deploy
+    exec_act: promote_to_production
+
+  Agent D8 (Rollback):
+    jti: task-308    pred:[task-307]
+    iss: spiffe://internal.example/agent/rollback
+    exec_act: rollback_production
+~~~
+{: #fig-devsdlc title="Dev-SDLC Workflow (mixed L1-L3)"}
+
+The resulting DAG:
+
+~~~
+task-301 (build_artifact)  [internal.example, L1]
+   |            |                  |
+   v            v                  v
+task-302      task-303           task-304
+(llm_code_    (run_tests)        (scan_sbom_
+ review)       [internal,L1]      vulnerabilities)
+[llm-vendor,                     [scan-vendor,L2]
+ L2]                  \
+        \               \          /
+         \               v        /
+          +-----> task-305 (deploy_staging)
+                   [internal.example, L2]
+                          |
+                          v
+                   task-306 (authorize_production_promotion)
+                   [internal.example — human ACT]
+                          |
+                          v
+                   task-307 (promote_to_production)
+                   [internal.example, L3 — audit ledger]
+                          |
+                          v
+                   task-308 (rollback_production)
+                   [internal.example, L3 — audit ledger]
+~~~
+{: #fig-devsdlc-dag title="Dev-SDLC DAG"}
+
+Three properties distinguish this use case.  First, AI-
+intermediary ECTs from external vendors (task-302 from llm-
+vendor.example, task-304 from scan-vendor.example) are consumed
+as pred references by the internal staging deploy agent
+(task-305), demonstrating cross-domain fan-in where the
+internal orchestrator must verify externally-signed ECTs before
+proceeding.  Second, the human approver's ACT (task-306) is
+explicitly chained as a pred of the production deploy ECT
+(task-307), creating a verifiable record that promotion was
+authorized before execution — addressing the "what did the AI
+agent do to our production code?" audit requirement.  Third,
+the rollback ECT (task-308) chains to the promotion ECT
+(task-307), ensuring the audit ledger captures the full
+promote-then-rollback lifecycle as a single traceable unit.
+
 # Related Work
 {:numbered="false"}
 
@@ -1692,6 +1906,108 @@ identity-plus-accountability framework for regulated agentic
 systems.  ECTs define an explicit WIMSE identity binding (see
 {{wimse-binding}}) but are not limited to WIMSE deployments.
 
+Section 3.3.9 of the WIMSE architecture
+{{I-D.ietf-wimse-arch}} explicitly names "AI and ML-Based
+Intermediaries as autonomous agents propagating security context
+downstream" as an in-scope architectural case but does not itself
+specify a format for that propagated execution context.  ECTs
+provide the standardized execution-context format that this
+architectural section requires: a JWT-based per-task record that
+an AI/ML intermediary can produce, sign, and propagate downstream
+to preserve accountability across the agent chain.  In this
+sense, ECTs directly realize a requirement surfaced by the WIMSE
+charter itself, and the Execution-Context HTTP header defined in
+{{http-header}} is the concrete on-the-wire encoding for the
+§3.3.9 propagation model.
+
+ECTs are also designed to compose with the HTTP message signing
+profile defined in {{I-D.ietf-wimse-http-signature}}: an
+Execution-Context header carrying an L2 or L3 ECT can be covered
+by a WIMSE HTTP message signature over the same request, so that
+integrity protection of the ECT and of its transport binding are
+aligned under a single signing model.
+
+## Composition Safety for Agent Protocols
+{:numbered="false"}
+
+Recent analysis of agent protocol security
+({{AgentRFC}}) establishes that security properties which hold
+for individual agent protocols can break when those protocols
+are composed through shared infrastructure, because assumptions
+made by one protocol are not necessarily preserved by adjacent
+hops.  This provides theoretical motivation for tracking
+execution context at each hop in an agent chain rather than
+relying solely on end-to-end authorization tokens, since the
+boundary where composition fails is generally not observable
+from any single endpoint.  ECTs record execution context
+per-task with a cryptographic binding to the issuing agent, so
+that composition-induced failures become detectable during
+post-hoc audit even when they were not prevented in-band.
+
+## Machine Identity Governance (MIGT)
+{:numbered="false"}
+
+The Machine Identity Governance Taxonomy {{MIGT}} catalogues
+risk categories for enterprise machine identities and documents
+that AI agents and automated workflows now outnumber human
+identities in enterprise environments by ratios exceeding 80 to
+1.  The taxonomy identifies record-keeping, traceability, and
+non-repudiation of automated actions as primary risk categories
+under regulatory regimes such as EU AI Act Article 12 on
+record-keeping, which ECT execution records are specifically
+designed to address.  ECTs provide the per-task signed artifact
+that such governance frameworks require as evidence that a given
+automated action was performed by a specific agent identity at a
+specific time.
+
+## NIST/NCCoE AI Agent Identity
+{:numbered="false"}
+
+The NIST/NCCoE concept paper on AI agent identity and
+authorization {{NIST-NCCoE-AI-Agents}} is the first US
+government standards-body document to treat AI agent identity as
+an enterprise identity management concern, explicitly building on
+OAuth, OIDC, and SCIM rather than proposing a parallel stack.
+This validates ECT's standards-first approach of layering
+accountability on existing IETF credentials and JOSE signing
+primitives, and ECTs are positioned to serve as a referenced
+execution-record format for the NCCoE demonstration project
+alongside the identity and authorization primitives it
+enumerates.
+
+## SCITT AI Agent Execution Profile
+{:numbered="false"}
+
+The SCITT profile for AI agent execution
+{{I-D.draft-emirdag-scitt-ai-agent-execution}} defines an
+AgentInteractionRecord (AIR) with COSE_Sign1 payloads intended
+for anchoring into SCITT Transparency Services.  ECTs and AIR
+are complementary along the in-transit vs. at-rest dimension:
+ECTs carry execution context in transit, embedded in a JWT and
+propagated through the Execution-Context HTTP header defined in
+{{http-header}}, while AIR anchors records into a SCITT
+transparency service for long-term tamper-evident storage.
+Higher-assurance ECT deployments operating at Level 3
+({{level-3}}) MAY use AIR as the SCITT payload format when the
+configured audit ledger is a SCITT Transparency Service, with
+the ECT's signed payload converted into the COSE_Sign1 envelope
+expected by AIR.
+
+## DAWN: Discovery of Agents and Workloads
+{:numbered="false"}
+
+The proposed DAWN working group and its requirements draft
+{{I-D.draft-king-dawn-requirements}} define requirements for
+discovering AI agents, workloads, and named entities across
+organizational boundaries.  ECTs are identity-framework agnostic
+by design ({{identity-binding}}) and therefore compose cleanly
+with any discovery mechanism DAWN may produce, regardless of the
+underlying credential type (WIMSE WIT/WPT, X.509, OAuth, or JWK
+sets).  If DAWN charters, the workload and agent bindings
+recorded in an ECT are directly usable as discoverable
+execution-context metadata for agents located through DAWN
+discovery, without requiring changes to the ECT format itself.
+
 ## OAuth 2.0 Token Exchange and the "act" Claim
 {:numbered="false"}
 
@@ -1716,6 +2032,8 @@ ECTs record "what was done, in what order."
 {:numbered="false"}
 
 OAuth Transaction Tokens {{I-D.ietf-oauth-transaction-tokens}}
+(currently at version -08 and in IETF Last Call; the normative
+reference will be updated to the published RFC)
 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
@@ -1784,7 +2102,9 @@ 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
+The SCITT architecture {{I-D.ietf-scitt-architecture}} (version -22,
+currently in AUTH48 / RFC Editor queue and about to become an RFC;
+readers should use the RFC number once assigned) 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

ietf123-slides-outline.md

@@ -0,0 +1,251 @@
+# IETF 123 — WIMSE Agenda Slot Outline
+
+**Draft**: draft-nennemann-wimse-ect-02
+**Related**: draft-nennemann-act-01 (independent submission)
+**Slot**: 10 minutes (approx. 8–10 content slides + title + thanks)
+**Presenter**: Christian Nennemann, Independent
+**Venue**: IETF 123, WIMSE WG, July 2026
+
+---
+
+## Pacing plan
+
+| Slide | Topic                          | Target time |
+|-------|--------------------------------|-------------|
+| 1     | Title                          | 15s         |
+| 2     | The gap                        | 45s         |
+| 3     | What ECT is                    | 75s         |
+| 4     | Why three assurance levels     | 60s         |
+| 5     | How it fits WIMSE (diagram)    | 75s         |
+| 6     | ACT — the primitive            | 60s         |
+| 7     | DAG vs linear chain (diagram)  | 75s         |
+| 8     | Landscape                      | 60s         |
+| 9     | What I'm asking for            | 30s         |
+| 10    | Thanks / Q&A                   | remainder   |
+
+Total talk: ~8 min; 2 min cushion for Q&A or overrun.
+
+---
+
+## Slide 1 — Title
+
+**On slide**:
+
+- ECT — Execution Context Tokens for Distributed Agentic Workflows
+- draft-nennemann-wimse-ect-02
+- Christian Nennemann, Independent Researcher
+- IETF 123 — WIMSE — July 2026
+
+**Speaker notes**:
+State name, affiliation, draft version in one breath. Skip any pleasantries — the slot is 10 minutes. Move to slide 2 immediately.
+
+---
+
+## Slide 2 — The gap
+
+**On slide**:
+
+- WIMSE adopted drafts establish **who** a workload is:
+  - `draft-ietf-wimse-arch-07` — architecture
+  - `draft-ietf-wimse-s2s-protocol` — service-to-service
+  - `draft-ietf-wimse-workload-identifier` — identifier
+  - `draft-ietf-wimse-token-translation` / WPT — proof-of-possession
+- `arch-07 §3.3.9` explicitly names AI/ML intermediaries as workloads that propagate security context.
+- **Missing**: a standardized format for recording **what** they executed and **in what order**.
+
+**Speaker notes**:
+The WG has solved identity and proof-of-possession. It has not yet standardized how an agent workflow records its own execution. Arch §3.3.9 flags AI intermediaries as in-scope but leaves the execution-recording format open. That's the gap ECT fills. Do not editorialize about AI hype — just cite the section and move on.
+
+---
+
+## Slide 3 — What ECT is
+
+**On slide**:
+
+- **JWT** (RFC 7519) payload; one token = one task.
+- **Three assurance levels**:
+  - L1: unsigned JSON (TLS-only, internal)
+  - L2: JOSE-signed JWS (baseline, cross-org)
+  - L3: JOSE-signed + audit ledger (regulated)
+- **DAG via `pred` claim** — each ECT lists predecessor task IDs.
+- **Transport**: new `Execution-Context` HTTP header.
+- **Identity-framework agnostic**: WIMSE WIT/WPT, X.509, OAuth, or bare JWK sets.
+
+**Speaker notes**:
+Hit the five bullets fast. The identity-agnostic bit is important for the WG: ECT does not require WIMSE, but it composes cleanly with it. The `pred` claim is the DAG primitive — come back to this on slide 7. Skip claim-by-claim detail; the draft has the table.
+
+---
+
+## Slide 4 — Why three assurance levels
+
+**On slide**:
+
+- Same payload structure at all three levels — only the envelope and verification rules differ.
+- L1 → L2 → L3 is a deployment choice, not a spec fork.
+- Lets a dev mesh (L1) and a regulated cross-org workflow (L3) share tooling and semantics.
+- Higher-level ECT **MAY** reference lower-level parents in `pred`; assurance of the chain = lowest link.
+
+**Speaker notes**:
+This is where feedback at IETF 122 landed: one spec, three tiers, explicit downgrade semantics. The design goal is to avoid a situation where the regulated world and the dev world run incompatible specs. If running short, cut the last bullet.
+
+---
+
+## Slide 5 — How ECT fits WIMSE
+
+**On slide** (diagram):
+
+```
+         WIMSE layering — identity, proof, execution
+
+   +----------------------------+
+   |  WIT — Workload Identity   |   who is this workload?
+   |  (adopted)                 |   (arch, identifier)
+   +-------------+--------------+
+                 |
+                 v
+   +----------------------------+
+   |  WPT — Proof-of-Possession |   is this workload speaking
+   |  (adopted)                 |   on this call, right now?
+   +-------------+--------------+
+                 |
+                 v
+   +----------------------------+
+   |  ECT — Execution Context   |   what did it execute,
+   |  (this draft)              |   and after what?
+   +----------------------------+
+
+   arch-07 §3.3.9: AI/ML intermediaries propagate security context.
+   ECT is the record layer that propagation leaves behind.
+```
+
+**Speaker notes**:
+This is the key diagram. WIT answers "who", WPT answers "is it them, now", ECT answers "what happened". The three layers are independent tokens with independent lifetimes. Explicitly name-check arch-07 §3.3.9 — it's the hook for adoption. If the audience takes away one slide, this is it.
+
+---
+
+## Slide 6 — ACT: the primitive ECT builds on
+
+**On slide**:
+
+- **ACT** (`draft-nennemann-act-01`, independent submission) — general two-phase lifecycle token.
+  - Phase 1: **Mandate** — what the agent is *authorized* to do (capabilities, delegation chain).
+  - Phase 2: **Record** — what the agent *actually did*.
+- **ECT** is the WIMSE-targeted single-phase execution profile — the Record phase, bound to workload identity.
+- Shared claim semantics: `jti`, `wid`, `exec_act`, `inp_hash`, `out_hash`, `pred`.
+- A deployment **MAY** carry both: ACT for capability-scoped authorization, ECT for workload-identity-bound execution recording.
+
+**Speaker notes**:
+Introduce ACT briefly so the WG knows where ECT sits in the family. ACT is intentionally identity-agnostic and lives outside WIMSE; ECT is the WIMSE-profiled execution side. The two drafts share six claims with identical semantics so implementers do not double-encode. Do not pitch ACT for WIMSE adoption here — that is not the ask.
+
+---
+
+## Slide 7 — DAG vs linear chain
+
+**On slide** (diagram):
+
+```
+   Linear chain (actchain, Agentic-JWT):
+
+        T1 ──> T2 ──> T3 ──> T4
+
+   DAG (ECT — pred: [parent-jtis]):
+
+              ┌──> T2 ──┐
+              │         │
+        T1 ───┤         ├──> T4
+              │         │
+              └──> T3 ──┘
+
+   Real agent workflows: fork (planner dispatches), join (aggregator
+   merges), diamond (tool + memory paths converge). Linear chains
+   cannot represent this without flattening and losing ordering.
+```
+
+- Unique to ECT in the WIMSE/OAuth space: a diamond is a first-class topology, not an edge case.
+- Compare:
+  - `draft-oauth-transaction-tokens-for-agents-00` — linear chain.
+  - *Agentic JWT* (arXiv 2509.13597) — linear chain.
+
+**Speaker notes**:
+Fork/join/diamond topologies are how planner-worker-aggregator agents actually run. A linear chain forces the implementer to serialize, which loses causal ordering and breaks audit reconstruction. The `pred` claim is an array — multi-parent by construction. If short on time, drop the arXiv bullet; the txn-tokens-for-agents comparison is the one WIMSE attendees will know.
+
+---
+
+## Slide 8 — Landscape
+
+**On slide**:
+
+- ~14 individual drafts now touch agent execution / accountability.
+- ECT's position in that space:
+  - (a) **WIMSE-aligned** — composes with WIT/WPT, arch §3.3.9 hook.
+  - (b) **Assurance levels** — L1/L2/L3 in one spec.
+  - (c) **DAG** — not a linear chain.
+  - (d) **Reference implementation** — Python, 56 tests, 90%+ coverage, public.
+- Adjacent: SCITT-AI-agent-execution (Emirdag) for ledger anchoring; txn-tokens-for-agents (Bertocci) for authorization transactions.
+
+**Speaker notes**:
+The WG has seen a lot of agent drafts. Differentiate ECT on four axes in one slide: WIMSE alignment, assurance tiers, DAG, running code. Name Emirdag and Bertocci by draft so the WG sees ECT is positioning cooperatively, not competitively.
+
+---
+
+## Slide 9 — What I'm asking for
+
+**On slide**:
+
+- **Feedback** on `-02` — claims, header, L1/L2/L3 boundaries, identity binding.
+- **Coordination** with `SCITT-AI-agent-execution` (Emirdag) on L3 ledger anchoring.
+- **Consideration** for WG adoption after one or two revisions — fits the chartered scope (arch §3.3.9) and composes with adopted work.
+
+**Speaker notes**:
+State the three asks flat. No begging, no apologies. Adoption is the long-term goal; feedback and coordination are the near-term asks. If a chair wants to push back on scope, that is the conversation this slide invites.
+
+---
+
+## Slide 10 — Thanks + Q&A
+
+**On slide**:
+
+- Thanks.
+- `draft-nennemann-wimse-ect-02`
+- `draft-nennemann-act-01`
+- refimpl: (link)
+- Contact: `ietf@nennemann.de`
+- Questions?
+
+**Speaker notes**:
+Stop talking. Let the mic open.
+
+---
+
+## Diagram rendering notes
+
+- **Slide 5** layering diagram: render as a clean vertical stack with arrows. Mermaid equivalent:
+
+  ```mermaid
+  flowchart TD
+    WIT["WIT — Workload Identity<br/>(adopted)"]
+    WPT["WPT — Proof-of-Possession<br/>(adopted)"]
+    ECT["ECT — Execution Context<br/>(this draft)"]
+    WIT --> WPT --> ECT
+  ```
+
+- **Slide 7** DAG diagram: render the diamond explicitly with T1 as root, T2 and T3 as parallel children, T4 as join.
+
+  ```mermaid
+  flowchart LR
+    T1 --> T2
+    T1 --> T3
+    T2 --> T4
+    T3 --> T4
+  ```
+
+Both should be exported as PNG/SVG for the PDF deck; ASCII fallbacks above are for the outline and for text-only channels.
+
+---
+
+## Timing discipline
+
+- If running long at slide 4: cut the last bullet on slide 4 and the last bullet on slide 7.
+- If running long at slide 6: compress ACT to "two-phase primitive; ECT is the Record phase" and drop the shared-claims bullet.
+- If running long at slide 8: drop the landscape count and lead with the four-axis differentiator.
+- Never cut slide 5 (the layering diagram) or slide 9 (the ask).

refimpl/python/MOVED.md

@@ -0,0 +1 @@
+Canonical location moved to workspace/packages/ect/

wimse-intro-email.md

@@ -0,0 +1,51 @@
+From: Christian Nennemann <ietf@nennemann.de>
+To: wimse@ietf.org
+Subject: Individual Draft: Execution Context Token for Agentic Workflows (draft-nennemann-wimse-ect-02)
+
+Hello WIMSE,
+
+I have submitted an individual draft, "Execution Context Tokens for
+Distributed Agentic Workflows" (draft-nennemann-wimse-ect-02), for the
+working group's consideration. The draft is available on datatracker at:
+https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
+
+The problem I am trying to address is execution context propagation
+across workloads in distributed agentic workflows. The re-chartered
+WIMSE scope explicitly calls out "execution context propagation for
+agentic workflows", and while the adopted drafts (arch, s2s-protocol,
+identifier, wpt) establish workload identity and call context, none of
+them currently carry a verifiable record of what a workload actually
+executed on behalf of an upstream caller. The arch document frames
+execution context as in-scope for WIMSE; ECT is one proposed mechanism
+to fill that gap at the workload layer.
+
+ECT is a JWT that records a single task execution. Tasks are linked
+into a DAG via a "pred" claim listing parent task identifiers, which
+allows a verifier to reconstruct the causal history across workload
+boundaries. The draft defines three assurance levels (self-attested,
+runtime-attested, hardware-attested), an "Execution-Context" HTTP
+header for propagation, and binding to WIMSE workload identities so
+that each task record is anchored to the workload that produced it.
+ECT normatively references a sibling individual submission,
+draft-nennemann-act-01 (Agent Context Token), which carries the
+upstream agent/user call context that ECT executions are attributed to.
+
+I am aware of draft-oauth-transaction-tokens-for-agents and have
+attached a diff document describing how ECT differs and where the two
+are complementary. In short, Txn-Tokens-for-Agents operates at the
+OAuth authorization layer (short-lived tokens for cross-service
+transactions), whereas ECT operates at the WIMSE workload layer
+(verifiable execution records linked by DAG). I would appreciate WG
+feedback on whether that framing is accurate and whether the layering
+is useful.
+
+I would welcome review and comments on the list, and I would like to
+request a 10-minute slot at the WIMSE session at IETF 123 (July 2026)
+to present the draft and gather feedback. I am happy to iterate on the
+document based on list input before then.
+
+Thank you,
+
+Christian Nennemann
+Independent Researcher
+ietf@nennemann.de