diff --git a/DIFF-vs-txn-tokens-for-agents.md b/DIFF-vs-txn-tokens-for-agents.md new file mode 100644 index 0000000..2bf5d77 --- /dev/null +++ b/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)* diff --git a/draft-nennemann-wimse-ect.md b/draft-nennemann-wimse-ect.md index d7fe1f9..f68ee32 100644 --- a/draft-nennemann-wimse-ect.md +++ b/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: @@ -1692,6 +1783,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 +1909,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 +1979,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 diff --git a/ietf123-slides-outline.md b/ietf123-slides-outline.md new file mode 100644 index 0000000..1d36d2b --- /dev/null +++ b/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
(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). diff --git a/refimpl/python/MOVED.md b/refimpl/python/MOVED.md new file mode 100644 index 0000000..25554d2 --- /dev/null +++ b/refimpl/python/MOVED.md @@ -0,0 +1 @@ +Canonical location moved to workspace/packages/ect/ diff --git a/wimse-intro-email.md b/wimse-intro-email.md new file mode 100644 index 0000000..3f115fb --- /dev/null +++ b/wimse-intro-email.md @@ -0,0 +1,51 @@ +From: Christian Nennemann +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