feat: ACT/ECT strategy, package restructure, draft -01/-02 prep

Strategic work for IETF submission of draft-nennemann-act-01 and
draft-nennemann-wimse-ect-02:

Package restructure:
- move ACT and ECT refimpls to workspace/packages/{act,ect}/
- ietf-act and ietf-ect distribution names (sibling packages)
- cross-spec interop test plan (INTEROP-TEST-PLAN.md)

ACT draft -01 revisions:
- rename 'par' claim to 'pred' (align with ECT)
- rename 'Agent Compact Token' to 'Agent Context Token' (semantic
  alignment with ECT family)
- add Applicability section (MCP, OpenAI, LangGraph, A2A, CrewAI)
- add DAG vs Linear Delegation Chains section (differentiator vs
  txn-tokens-for-agents actchain, Agentic JWT, AIP/IBCTs)
- add Related Work: AIP, SentinelAgent, Agentic JWT, txn-tokens-for-agents,
  HDP, SCITT-AI-agent-execution
- pin SCITT arch to -22, note AUTH48 status

Outreach drafts:
- Emirdag liaison email (SCITT-AI coordination)
- OAuth ML response on txn-tokens-for-agents-06

Strategy document:
- STRATEGY.md with phased action plan, risk register, timeline

Submodule:
- update workspace/drafts/ietf-wimse-ect pointer to -02 commit

workspace/drafts/outreach/emirdag-liaison-email.md

@@ -0,0 +1,30 @@
+Dear Dr. Emirdag,
+
+Congratulations on the publication of draft-emirdag-scitt-ai-agent-execution-00 earlier today. I came across it while tracking SCITT-adjacent work on AI agent accountability, and I wanted to reach out because the positioning looks genuinely complementary to a pair of drafts I have been developing.
+
+Brief introduction: I am Christian Nennemann, an independent researcher working on execution-context and lifecycle tokens for agentic systems. My current IETF work consists of:
+
+- draft-nennemann-act-01 (Agent Context Token): a JWT-based two-phase lifecycle — a pre-execution Mandate token carrying authorization, scope, and input commitments, followed by a post-execution Record token committing to outputs and linking back via `pred`. Multiple Records form a DAG, signed with Ed25519 or ES256.
+- draft-nennemann-wimse-ect-02 (Execution Context Token): a WIMSE profile with three assurance levels and identity binding for the workload that produced a given execution.
+
+Reading your AIR specification, the layering seems fairly clean: ACT defines *what* is being anchored — the lifecycle token with its authorization proof, input/output commitments, and causal predecessor links — while AIR defines *how* it is anchored on a SCITT transparency service as a COSE_Sign1 payload with its hash-chain, four-step verification, and EU AI Act / NIST AI RMF mappings. There is real conceptual overlap on input/output hashing, reasoning capture, identity, timing, and causality, which suggests that coordinating now would save both of us retrofitting later.
+
+A few concrete options, in rough order of effort:
+
+(a) Cross-citations in both drafts, establishing the "ACT record → AIR payload → SCITT receipt" flow as the intended pipeline.
+(b) A short shared section on "Anchoring ACT Records in SCITT" — either folded into ACT-02 or as a small companion draft if you prefer neutral ground.
+(c) Aligning claim semantics where they overlap — in particular input/output hash representation (I currently use `inp_hash` / `out_hash`, JWT-side) so that translation to AIR is lossless.
+(d) If we both attend IETF 123, a joint slot in SCITT or a side meeting could make the layering concrete for the WG.
+
+I would be happy to send you the current ACT and ECT drafts and to review yours in detail before either of us adds formal cross-references. Low-pressure — mainly wanted to flag the alignment while the drafts are still malleable.
+
+Looking forward to your thoughts.
+
+Best regards,
+Christian Nennemann
+Independent Researcher
+[contact details]
+
+---
+
+**Suggested subject line:** Liaison proposal: ACT/ECT lifecycle tokens and SCITT-AI AIR — complementary layering

workspace/drafts/outreach/oauth-ml-response.md

@@ -0,0 +1,71 @@
+**To:** oauth@ietf.org
+**From:** Christian Nennemann <ietf@nennemann.de>
+**Subject:** draft-oauth-transaction-tokens-for-agents-06: complementary work on DAG-based delegation (draft-nennemann-act)
+
+Hi all,
+
+I noticed the publication of draft-oauth-transaction-tokens-for-agents-06
+(Raut et al., 2026-04-11) and wanted to share some complementary work that
+addresses an adjacent slice of the agent-delegation problem space. The
+Amazon draft fills a real gap at the OAuth authorization-server layer, and
+I think there is useful coordination potential rather than overlap.
+
+# Technical difference in one paragraph
+
+draft-oauth-transaction-tokens-for-agents introduces `actchain` as an
+ordered array documenting delegation history, plus `agentic_ctx` carrying
+type/version/intent/operational constraints, with a split between
+principal-initiated and autonomous flow types. Our work
+(draft-nennemann-act-01) models delegation history as a DAG through a
+`pred` (predecessor) claim that is itself an array of parent token
+references. A linear `actchain` is a special case of the DAG form where
+every node has exactly one predecessor.
+
+# Why a DAG, concretely
+
+Consider an agent that fans out to N parallel sub-agents (e.g. one per
+data source) and then synthesizes a single response from their results.
+The synthesis step has N predecessors, not one. A linear `actchain`
+cannot express this fan-in; you would have to either linearize artificially
+(losing causality) or emit N parallel chains (losing the join). With a
+DAG-valued `pred`, the synthesis token references all N predecessor tokens
+directly, and a verifier can walk the graph to check that each parallel
+branch was authorized and unexpired. Fork, join, and diamond topologies
+fall out of the same structure.
+
+# Layering, not competition
+
+These two drafts sit at different layers:
+
+- Txn-Tokens-for-Agents is anchored at an OAuth authorization server:
+  the AS mints and validates tokens, and `actchain` is read in the
+  context of an AS-issued transaction token.
+- ACT is designed for peer-to-peer agent orchestration without
+  requiring an AS in the hot path — useful for multi-vendor agent
+  meshes where no single AS is authoritative. It is transport-agnostic
+  and leans on JWS for provenance.
+
+An AS-issued txn-token could carry an ACT-shaped `pred` graph
+internally, or an ACT chain could terminate at an AS that upgrades it
+into a txn-token for a specific resource. The two seem stackable.
+
+# Offer
+
+Happy to compare test vectors, especially around:
+
+- claim naming: `agentic_ctx` (Raut) vs ACT's `task` claim — is there
+  an opportunity to align on a shared intent/constraint shape so
+  downstream verifiers don't have to parse both?
+- linear-subset interop: confirming that a degenerate DAG (each node
+  one parent) round-trips cleanly to/from `actchain`.
+- autonomous-flow semantics: how ACT's unattended-delegation marker
+  maps onto Raut's autonomous flow type.
+
+ACT draft: https://datatracker.ietf.org/doc/draft-nennemann-act/
+
+Feedback welcome, on- or off-list.
+
+Best,
+Christian Nennemann
+Independent Researcher
+ietf@nennemann.de