Christian Nennemann
d47f041265
- 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/
52 lines
2.5 KiB
Markdown
52 lines
2.5 KiB
Markdown
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
|