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/

wimse-intro-email.md

@@ -0,0 +1,51 @@
+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