feat: draft -02 with ACT liaison, related work, IETF 123 prep
- 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/
This commit is contained in:
251
ietf123-slides-outline.md
Normal file
251
ietf123-slides-outline.md
Normal file
@@ -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).
|
||||
Reference in New Issue
Block a user