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
3.0 KiB
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
actchainis 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'staskclaim — 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