ietf-wimse-ect/ietf123-slides-outline.md

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:

  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.

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