# 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)*