c/ietf-draft-analyzer
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
Christian Nennemann
2026-04-12 07:33:08 +02:00
parent b38747ad92
commit 3a139dfc7e
53 changed files with 8718 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

194
workspace/packages/act/docs/section-1.5-applicability.md Normal file
View File

@@ -0,0 +1,194 @@
# Section 1.5: Applicability (for draft-nennemann-act-01)
Insert after Section 1.4 (Relationship to Related Work).
---
### 1.5. Applicability
ACT is designed as a general-purpose primitive for AI agent
authorization and execution accountability. While a sibling
specification [I-D.nennemann-wimse-ect] profiles execution context
tokens specifically for the WIMSE working group's workload identity
infrastructure, ACT operates without any shared identity plane. This
section identifies deployment contexts where ACT applies independently
of WIMSE, and clarifies how ACT complements — rather than competes
with — ecosystem-specific agent protocols.
#### 1.5.1. Model Context Protocol (MCP) Tool-Use Flows
The Model Context Protocol [MCP-SPEC] defines a client-server
interface by which LLM hosts invoke external tools via structured
JSON-RPC calls. MCP 2025-11-25 mandates OAuth 2.1 for transport-layer
authentication, but provides no mechanism for carrying per-invocation
authorization constraints or for producing a tamper-evident record
of what arguments were passed and what result was returned.
ACT addresses this gap as follows: when an MCP host is about to
dispatch a tool call on behalf of an agent, it SHOULD issue a Phase 1
ACT Mandate encoding the permitted tool name (e.g., as a capability
constraint), the declaring scope, and any parameter-level constraints
applicable to that invocation. The MCP server, upon receiving the
request, MAY validate the ACT Mandate and, upon completing the tool
execution, SHOULD transition the token to Phase 2 by appending
SHA-256 hashes of the serialized input arguments and the JSON
response, then re-sign. The resulting Phase 2 ACT constitutes an
unforgeable record that a specific tool was called with specific
arguments and returned a specific result, independently of MCP's
OAuth layer.
This integration requires no modification to MCP transport; the ACT
SHOULD be carried in the `ACT-Mandate` and `ACT-Record` HTTP headers
defined in Section 9.1 of this document.
#### 1.5.2. OpenAI Agents SDK and Function Calling
The OpenAI Agents SDK [OPENAI-AGENTS-SDK] enables composition of
agents via handoffs — structured transfers of control from one agent
to another, each potentially invoking registered function tools. The
SDK provides no built-in mechanism for a receiving agent to verify
that the handoff was authorized by a named principal, nor for the
invoking agent to produce a verifiable record of what functions it
called.
ACT is applicable at the handoff boundary: the orchestrating agent
SHOULD issue a Phase 1 ACT Mandate to the receiving agent at the
moment of handoff, encoding the permitted function set as
capability constraints and the maximum privilege the receiving agent
MAY exercise. The receiving agent SHOULD attach its Phase 2 ACT
Record to any callback or downstream response, providing the
orchestrator with cryptographic evidence of the actions taken. In
multi-turn chains involving multiple handoffs, the DAG linkage
(Section 7) allows each handoff to be expressed as a parent-child
edge, preserving the full causal ordering of the agent invocation
sequence.
Implementations that use the OpenAI function calling API directly,
without the Agents SDK, MAY apply ACT at the application layer: the
calling process issues a Phase 1 ACT before the function call
parameter block is finalized, and the receiving function handler
returns a Phase 2 ACT alongside its JSON result.
#### 1.5.3. LangGraph and LangChain Agent Graphs
LangGraph [LANGGRAPH] models agent workflows as typed StateGraphs in
which nodes represent agent invocations or tool calls and edges
represent conditional transitions. The DAG structure of ACT (Section
7) is a natural fit for this model: each LangGraph node that performs
an observable action corresponds to exactly one ACT task identifier
(`tid`), and directed edges in the LangGraph correspond to `pred`
(predecessor) references in successor ACTs.
ACT is applicable at the node boundary: when a LangGraph node
dispatches a sub-agent or invokes a tool with side effects, it SHOULD
issue a Phase 1 ACT Mandate encoding the node's permitted actions
before any external call is made. Upon transition out of the node,
a Phase 2 ACT Record SHOULD be produced and attached to the
LangGraph state object alongside the node's output. Downstream nodes
that fan-in from multiple predecessors MAY retrieve the set of parent
ACT identifiers from the shared state to populate their `pred` array,
thereby expressing LangGraph's fan-in semantics within the ACT DAG
without any additional infrastructure.
In contrast to LangGraph's built-in state audit trail, which is
mutable in-process memory, Phase 2 ACTs are cryptographically signed
and portable: they can be exported from a LangGraph run and
submitted to an external audit ledger, satisfying compliance
requirements that cannot be met by in-process logging alone.
#### 1.5.4. Google Agent2Agent (A2A) Protocol
The Agent2Agent protocol [A2A-SPEC] defines a task-oriented JSON-RPC
interface for inter-agent communication, with authentication
delegated to OAuth 2.0 or API key schemes declared in each agent's
Agent Card. A2A provides no mechanism for a receiving agent to
verify the authorization provenance of a task request beyond the
transport-layer credential, and produces no token that represents
the execution of the task in a verifiable, portable form.
ACT is applicable as a session-layer accountability complement to
A2A: a client agent SHOULD include a Phase 1 ACT Mandate in the
`metadata` field of the A2A Task object, encoding the task type as
a capability constraint and the delegating agent's identity as the
ACT issuer. The receiving agent SHOULD validate the Mandate before
beginning task execution and SHOULD return a Phase 2 ACT Record
as an artifact in the A2A TaskResult, enabling the client agent to
retain cryptographic proof of what was executed on its behalf.
This integration does not require modification to A2A's transport or
authentication scheme; ACT and A2A's OAuth credentials operate at
independent layers and are not redundant. A2A's credential answers
"is this client permitted to contact this server?"; the ACT Mandate
answers "is this agent permitted to request this specific task
under these constraints?".
#### 1.5.5. Enterprise Orchestration Without WIMSE (CrewAI, AutoGen)
Enterprise orchestration frameworks such as CrewAI [CREWAI] and
AutoGen [AUTOGEN] deploy multi-agent systems within a single
organizational boundary, typically without SPIFFE/SPIRE workload
identity infrastructure. In these environments, OAuth Authorization
Servers are often unavailable or impractical to deploy for intra-
process agent communication.
ACT is applicable in this context via its Tier 1 (pre-shared key)
trust model (Section 5.2): each agent role in a CrewAI Crew or
AutoGen ConversableAgent graph is assigned an Ed25519 keypair at
instantiation time. The orchestrating agent issues Phase 1 Mandates
to worker agents before delegating tasks, constraining each worker
to only the tools and actions relevant to its role. Worker agents
produce Phase 2 Records on task completion. The resulting ACT chain
is exportable as a structured audit trail that satisfies the
per-action logging requirements of DORA [DORA] and EU AI Act
Article 12 [EUAIA] without requiring shared infrastructure beyond
the ability to exchange public keys at deployment time.
Implementations SHOULD NOT use ACT's self-assertion mode (where an
agent issues and records its own mandate without external sign-off)
in regulated workflows; at minimum, the orchestrating agent MUST
sign the initial Mandate so that accountability is anchored to a
principal outside the executing agent.
#### 1.5.6. Relationship to WIMSE ECT
Where WIMSE infrastructure is deployed, ACT and the WIMSE Execution
Context Token [I-D.nennemann-wimse-ect] serve complementary and
non-overlapping functions. The ECT records workload-level execution
in WIMSE terms — which SPIFFE workload executed, in which trust
domain, against which service. ACT records the authorization
provenance — which agent was permitted to request which action,
under what capability constraints, by whose authority — and
transitions that authorization record into an execution record upon
task completion.
In mixed environments, both tokens SHOULD be carried simultaneously:
the `Workload-Identity` header carries the WIMSE ECT; the
`ACT-Record` header carries the ACT. Verifiers MAY correlate the
two by matching the ACT `tid` claim against application-layer
identifiers present in the ECT's task context. Neither token is a
profile or extension of the other; they operate at different
abstraction layers and their co-presence is additive.
---
## Informative References to Add
```
[MCP-SPEC] Model Context Protocol Specification, 2025-11-25,
<https://modelcontextprotocol.io/specification/2025-11-25>
[OPENAI-AGENTS-SDK] OpenAI, "Agents SDK",
<https://openai.github.io/openai-agents-python/>
[LANGGRAPH] LangChain, "LangGraph Documentation",
<https://langchain-ai.github.io/langgraph/>
[A2A-SPEC] Google, "Agent2Agent (A2A) Protocol",
<https://github.com/a2aproject/A2A>
[CREWAI] CrewAI, "CrewAI Documentation",
<https://docs.crewai.com/>
[AUTOGEN] Microsoft, "AutoGen Documentation",
<https://microsoft.github.io/autogen/>
```