Christian Nennemann
d47f041265
- 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/
164 lines
9.4 KiB
Markdown
164 lines
9.4 KiB
Markdown
# 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)*
|