ietf-wimse-ect/DIFF-vs-txn-tokens-for-agents.md

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)