# 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
(adopted)"] WPT["WPT — Proof-of-Possession
(adopted)"] ECT["ECT — Execution Context
(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).