



Network Working Group                                       C. Nennemann
Internet-Draft                                    Independent Researcher
Intended status: Standards Track                             20 May 2026
Expires: 21 November 2026


                       Agent Context Token (ACT)
                         draft-nennemann-act-01

Abstract

   This document defines the Agent Context Token (ACT), a self-contained
   JWT-based format that captures the full invocation context of an
   autonomous AI agent — its capabilities, constraints, delegation
   provenance, oversight requirements, task metadata, and DAG position —
   and unifies authorization and execution accountability in a single
   token lifecycle.  An ACT begins as a signed authorization mandate and
   transitions into a tamper-evident execution record once the agent
   completes its task, appending cryptographic hashes of inputs and
   outputs and linking to predecessor tasks via a directed acyclic graph
   (DAG).  ACT requires no Authorization Server, no workload identity
   infrastructure, and no transparency service for basic operation.
   Trust is bootstrapped via pre-shared keys and is upgradeable to PKI
   or Decentralized Identifiers (DIDs).  ACT is designed for cross-
   organizational agent federation in regulated and unregulated
   environments alike.  ACT is the general-purpose agent context
   primitive; the WIMSE Execution Context Token (ECT)
   [I-D.nennemann-wimse-ect] is a sibling profile specialized for
   workload-identity-bound execution recording in WIMSE deployments.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 21 November 2026.





Nennemann               Expires 21 November 2026                [Page 1]

Internet-Draft                     ACT                          May 2026


Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   5
     1.2.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   5
     1.3.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   6
     1.4.  Relationship to Related Work  . . . . . . . . . . . . . .   6
       1.4.1.  Concurrent Agent Authorization Proposals  . . . . . .   7
     1.5.  Applicability . . . . . . . . . . . . . . . . . . . . . .   9
       1.5.1.  Model Context Protocol (MCP) Tool-Use Flows . . . . .   9
       1.5.2.  OpenAI Agents SDK and Function Calling  . . . . . . .   9
       1.5.3.  LangGraph and LangChain Agent Graphs  . . . . . . . .  10
       1.5.4.  Google Agent2Agent (A2A) Protocol . . . . . . . . . .  11
       1.5.5.  Enterprise Orchestration Without WIMSE (CrewAI,
               AutoGen)  . . . . . . . . . . . . . . . . . . . . . .  11
       1.5.6.  Relationship to WIMSE ECT . . . . . . . . . . . . . .  12
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .  12
   3.  ACT Lifecycle . . . . . . . . . . . . . . . . . . . . . . . .  13
     3.1.  Phase 1: Authorization Mandate  . . . . . . . . . . . . .  13
     3.2.  Phase 2: Execution Record . . . . . . . . . . . . . . . .  14
     3.3.  Lifecycle State Machine . . . . . . . . . . . . . . . . .  14
   4.  ACT Token Format  . . . . . . . . . . . . . . . . . . . . . .  15
     4.1.  JOSE Header . . . . . . . . . . . . . . . . . . . . . . .  15
     4.2.  JWT Claims: Authorization Phase . . . . . . . . . . . . .  16
       4.2.1.  Standard JWT Claims . . . . . . . . . . . . . . . . .  16
       4.2.2.  ACT Authorization Claims  . . . . . . . . . . . . . .  16
     4.3.  JWT Claims: Execution Phase . . . . . . . . . . . . . . .  19
     4.4.  Complete Examples . . . . . . . . . . . . . . . . . . . .  21
       4.4.1.  Example: Phase 1 — Authorization Mandate  . . . . . .  21
       4.4.2.  Example: Phase 2 — Execution Record (same token,
               re-signed by target agent)  . . . . . . . . . . . . .  22
   5.  Trust Model . . . . . . . . . . . . . . . . . . . . . . . . .  23
     5.1.  Tier 0: Bootstrap (TOFU — Trust On First Use) . . . . . .  23
     5.2.  Tier 1: Pre-Shared Keys (Mandatory-to-Implement)  . . . .  23



Nennemann               Expires 21 November 2026                [Page 2]

Internet-Draft                     ACT                          May 2026


     5.3.  Tier 2: PKI / X.509 . . . . . . . . . . . . . . . . . . .  24
     5.4.  Tier 3: Decentralized Identifiers (DID) . . . . . . . . .  24
     5.5.  Cross-Tier Interoperability . . . . . . . . . . . . . . .  25
   6.  Delegation Chain  . . . . . . . . . . . . . . . . . . . . . .  25
     6.1.  Peer-to-Peer Delegation . . . . . . . . . . . . . . . . .  25
     6.2.  Privilege Reduction Requirements  . . . . . . . . . . . .  25
     6.3.  Delegation Verification . . . . . . . . . . . . . . . . .  26
   7.  DAG Structure and Causal Ordering . . . . . . . . . . . . . .  26
     7.1.  DAG Validation  . . . . . . . . . . . . . . . . . . . . .  27
     7.2.  Root Tasks and Fan-in . . . . . . . . . . . . . . . . . .  27
     7.3.  DAG vs Linear Delegation Chains . . . . . . . . . . . . .  27
       7.3.1.  What Linear Chains Express Well . . . . . . . . . . .  28
       7.3.2.  Limitations of Linear Chains  . . . . . . . . . . . .  28
       7.3.3.  ACT's DAG Approach  . . . . . . . . . . . . . . . . .  29
       7.3.4.  Verifiability Implications  . . . . . . . . . . . . .  29
       7.3.5.  Interoperability with Linear-Chain Designs  . . . . .  30
   8.  Verification Procedure  . . . . . . . . . . . . . . . . . . .  30
     8.1.  Authorization Phase Verification  . . . . . . . . . . . .  30
     8.2.  Execution Phase Verification  . . . . . . . . . . . . . .  31
   9.  Transport . . . . . . . . . . . . . . . . . . . . . . . . . .  31
     9.1.  HTTP Header Transport . . . . . . . . . . . . . . . . . .  31
     9.2.  Non-HTTP Transports . . . . . . . . . . . . . . . . . . .  32
   10. Audit Ledger Interface  . . . . . . . . . . . . . . . . . . .  32
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  32
     11.1.  Threat Model . . . . . . . . . . . . . . . . . . . . . .  32
     11.2.  Self-Assertion Limitation  . . . . . . . . . . . . . . .  33
     11.3.  Key Compromise . . . . . . . . . . . . . . . . . . . . .  33
     11.4.  Replay Attack Prevention . . . . . . . . . . . . . . . .  34
     11.5.  Equivocation . . . . . . . . . . . . . . . . . . . . . .  34
     11.6.  Privilege Escalation . . . . . . . . . . . . . . . . . .  35
     11.7.  Denial of Service  . . . . . . . . . . . . . . . . . . .  35
   12. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  35
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  36
     13.1.  Media Type Registration  . . . . . . . . . . . . . . . .  36
     13.2.  HTTP Header Field Registration . . . . . . . . . . . . .  36
     13.3.  JWT Claims Registration  . . . . . . . . . . . . . . . .  37
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  37
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  37
     14.2.  Informative References . . . . . . . . . . . . . . . . .  38
   Appendix A: Complete JSON Schema  . . . . . . . . . . . . . . . .  41
   Appendix B: Test Vectors  . . . . . . . . . . . . . . . . . . . .  44
     B.0.  Key Material  . . . . . . . . . . . . . . . . . . . . . .  44
     B.1.  Valid Phase 1 ACT: root mandate, Tier 1 (Ed25519), no
            delegation . . . . . . . . . . . . . . . . . . . . . . .  45
     B.2.  Valid Phase 2 ACT: completed execution (transition from
            B.1) . . . . . . . . . . . . . . . . . . . . . . . . . .  47
     B.3.  Valid Phase 2 ACT: fan-in with two predecessor tasks  . .  49
     B.4.  Valid Phase 1 ACT: delegated mandate (depth 1)  . . . . .  51



Nennemann               Expires 21 November 2026                [Page 3]

Internet-Draft                     ACT                          May 2026


     B.5.  Valid Phase 2 ACT: delegated execution record . . . . . .  52
     B.6.  Invalid: delegation depth exceeds maximum . . . . . . . .  54
     B.7.  Invalid: capability escalation in delegated mandate . . .  56
     B.8.  Invalid: exec_act not present in cap  . . . . . . . . . .  56
     B.9.  Invalid: DAG cycle (pred references own jti)  . . . . . .  57
     B.10.  Invalid: missing predecessor task in DAG . . . . . . . .  58
     B.11.  Invalid: tampered payload  . . . . . . . . . . . . . . .  59
     B.12.  Invalid: expired token . . . . . . . . . . . . . . . . .  61
     B.13.  Invalid: audience mismatch . . . . . . . . . . . . . . .  62
     B.14.  Invalid: Phase 2 record signed by wrong key  . . . . . .  63
     B.15.  Invalid: unsigned token (alg "none") . . . . . . . . . .  65
   Appendix C: Deployment Scenarios  . . . . . . . . . . . . . . . .  65
     C.1.  Minimal Deployment (Zero Infrastructure)  . . . . . . . .  65
     C.2.  Regulated Deployment with Hash-Chained Ledger . . . . . .  65
     C.3.  High-Assurance Cross-Organizational Deployment  . . . . .  66
     C.4.  WIMSE Environment Integration . . . . . . . . . . . . . .  66
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  66
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  66

1.  Introduction

   Autonomous AI agents increasingly operate across organizational
   boundaries, executing multi-step workflows where individual tasks are
   delegated from one agent to another.  These workflows create two
   distinct, inseparable compliance requirements:

   1.  *Authorization*: was the agent permitted to perform the action,
       under what constraints, and by whose authority?

   2.  *Accountability*: what did the agent actually do, with what
       inputs, producing what outputs, in what causal relationship to
       prior tasks?

   Existing specifications address these requirements in isolation.  The
   Agent Authorization Profile (AAP) [I-D.aap-oauth-profile] provides
   structured authorization via OAuth 2.0 but requires a central
   Authorization Server.  The WIMSE Execution Context Token
   [I-D.nennemann-wimse-ect] provides execution accountability but
   requires WIMSE workload identity infrastructure (SPIFFE/SPIRE).

   This document defines the Agent Context Token (ACT), which addresses
   both requirements in a single, self-contained token that requires no
   shared infrastructure beyond the ability to verify asymmetric
   signatures.  The word "Context" in the name reflects what the token
   carries: the complete invocation context of an agent — DAG
   references, task metadata, capabilities, delegation chain, and
   oversight claims — bound together in one cryptographically verifiable
   envelope.  ACT is positioned as the general agent context primitive,



Nennemann               Expires 21 November 2026                [Page 4]

Internet-Draft                     ACT                          May 2026


   with the WIMSE Execution Context Token (ECT)
   [I-D.nennemann-wimse-ect] as a sibling profile specialized for
   workload-identity-bound execution contexts in WIMSE deployments.

1.1.  Problem Statement

   Cross-organizational agent federation today faces a bootstrapping
   problem: deploying shared OAuth infrastructure or a common SPIFFE
   trust domain requires organizational agreement before the first
   message is exchanged.  In practice this means either:

   (a) agents operate without cryptographic authorization or audit
   trails, relying on application-layer access control only; or

   (b) organizations adopt one party's identity infrastructure, creating
   a hub-and-spoke dependency that contradicts the decentralized nature
   of agent networks.

   ACT solves this by making pre-shared keys the mandatory-to-implement
   trust baseline — two agents can begin a secure, auditable interaction
   with nothing more than an out-of-band key exchange — while providing
   a clean upgrade path to PKI or DID-based trust without changing the
   token format.

1.2.  Design Goals

   *  *G1 — Zero infrastructure baseline*: ACT MUST be deployable with
      no shared servers, no common identity provider, and no
      transparency service.

   *  *G2 — Single token lifecycle*: Authorization and accountability
      MUST be expressed in the same token format to prevent
      authorization-accountability gaps.

   *  *G3 — Peer-to-peer delegation*: Delegation chains MUST be
      verifiable without contacting an Authorization Server, using
      cryptographic chaining of agent signatures.

   *  *G4 — DAG-native causal ordering*: Workflows with parallel
      branches and fan-in dependencies MUST be expressible natively,
      without flattening to a linear chain.

   *  *G5 — Cross-organizational interoperability*: ACTs issued by
      agents in different trust domains MUST be verifiable by any
      participant holding the issuing agent's public key.






Nennemann               Expires 21 November 2026                [Page 5]

Internet-Draft                     ACT                          May 2026


   *  *G6 — Regulatory applicability*: ACT MUST provide sufficient
      evidence for audit requirements in DORA [DORA], EU AI Act Article
      12 [EUAIA], and IEC 62304 [IEC62304] without requiring additional
      log formats.

   *  *G7 — Upgrade path*: The trust model MUST support migration from
      pre-shared keys to PKI or DID without breaking existing ACT
      chains.

1.3.  Non-Goals

   The following are explicitly out of scope:

   *  Defining internal AI model behavior or decision logic.

   *  Replacing organizational security policies or procedures.

   *  Defining storage formats for audit ledgers.

   *  Specifying token revocation infrastructure (deployments MAY use
      existing mechanisms such as [RFC7009] for this purpose).

   *  Providing non-equivocation guarantees in standalone mode (see
      Section 11.5 for the equivocation discussion and optional
      transparency anchoring).

1.4.  Relationship to Related Work

   *AAP [I-D.aap-oauth-profile]*: ACT addresses the same authorization
   problem as AAP but does not require an Authorization Server.  ACT
   delegation is peer-to-peer via cryptographic signature chaining; AAP
   delegation requires OAuth Token Exchange [RFC8693] against a central
   AS.  ACT is not a profile of AAP; it is an infrastructure-independent
   alternative for the same problem class.

   *WIMSE ECT [I-D.nennemann-wimse-ect]*: ACT addresses the same
   execution accountability problem as the WIMSE Execution Context Token
   but does not require WIMSE workload identity infrastructure.  ACT is
   not a profile of WIMSE; it is deployable in environments without
   SPIFFE/SPIRE.  In environments where WIMSE is deployed, ACT MAY be
   carried alongside WIMSE tokens to augment accountability with
   authorization provenance.









Nennemann               Expires 21 November 2026                [Page 6]

Internet-Draft                     ACT                          May 2026


   *SCITT [I-D.ietf-scitt-architecture]*: For deployments requiring non-
   equivocation guarantees (see Section 11.5), ACT execution records MAY
   be anchored to a SCITT Transparency Service as a Layer 2 mechanism.
   This is OPTIONAL and not required for basic ACT operation.  Note: The
   SCITT architecture draft is currently in AUTH48 (RFC Editor queue) at
   version -22 and is about to become an RFC; readers should use the RFC
   number once assigned.

1.4.1.  Concurrent Agent Authorization Proposals

   Several concurrent proposals in the IETF and academic communities
   address overlapping portions of the agent authorization problem
   space.  This subsection situates ACT relative to those proposals.
   Protocol-layer comparison of linear versus DAG delegation structure
   is deferred to Section 7.3; the summaries below focus on scope and
   deployability.

   *AIP / IBCTs [AIP-IBCT]*: The Agent Interaction Protocol proposes
   Interaction-Bound Capability Tokens in two modes: compact signed JWTs
   for single-hop invocation and Biscuit/Datalog tokens for multi-hop
   delegation, motivated by a survey of approximately 2,000 Model
   Context Protocol servers that found no authorization enforcement.
   ACT addresses the same problem class but relies exclusively on JWT/
   JOSE throughout (no Biscuit or Datalog dependency), defines an
   explicit two-phase lifecycle separating authorization (Mandate) from
   proof-of-execution (Record), and supports DAG delegation structure.
   IBCTs are modeled as append-only chains at the protocol layer; ACT
   operates at the authorization graph layer with revocable lifecycle
   states.

   *SentinelAgent [SentinelAgent]*: SentinelAgent defines a formal
   Delegation Chain Calculus with seven verifiable properties, a TLA+
   mechanization, and reports 100% true-positive and 0% false-positive
   rates against the DelegationBench v4 benchmark.  It addresses the
   same accountability question as ACT — namely, which principal
   authorized a given chain of actions.  The differentiator is
   deployment substrate: SentinelAgent expresses its guarantees in a
   domain-specific formal calculus, whereas ACT encodes the same
   invariants in IETF-standard JWT infrastructure (RFC 7519, RFC 7515,
   RFC 8032) already deployable in existing OAuth- and JOSE-aware
   stacks.










Nennemann               Expires 21 November 2026                [Page 7]

Internet-Draft                     ACT                          May 2026


   *Agentic JWT [AgenticJWT]*: Agentic JWT derives a per-agent identity
   as a one-way hash of the agent's prompt, registered tools, and
   configuration, and chains delegation assertions across invocations.
   It is the closest prior-art JWT-based construction for agentic
   delegation.  ACT differs in that it adds an explicit two-phase
   lifecycle — separating the authorization mandate from the proof-of-
   execution record — and expresses delegation as a DAG via the array-
   valued pred claim rather than a strictly linear chain.

   *OAuth Transaction Tokens for Agents
   [I-D.oauth-transaction-tokens-for-agents]*: This draft extends OAuth
   Transaction Tokens with an actchain claim (an ordered delegation
   array), an agentic_ctx claim conveying intent and constraints, and
   flow-type markers distinguishing interactive from autonomous
   invocations.  It is complementary to ACT at the OAuth layer.  The
   primary differentiators are topology and infrastructure dependency:
   Transaction Tokens for Agents presume an OAuth Authorization Server
   and use a linear actchain, whereas ACT operates peer-to-peer without
   any AS and uses a DAG-valued pred.  A detailed differencing document
   is referenced in Section 11.

   *Helixar Delegation Protocol (HDP)
   [I-D.helixar-hdp-agentic-delegation]*: HDP specifies Ed25519
   signatures over RFC 8785-canonicalized JSON, an append-only linear
   delegation chain with session binding, and offline verification.  ACT
   addresses the same problem but is encoded in JWT/JOSE (aligning with
   the broader IETF token ecosystem) rather than raw canonical JSON, and
   its pred claim admits DAG topologies rather than strictly linear
   chains.

   *SCITT Profile for AI Agent Execution Records
   [I-D.emirdag-scitt-ai-agent-execution]*: This draft defines a SCITT
   profile in which AgentInteractionRecord (AIR) payloads are carried as
   COSE_Sign1 statements anchored to a SCITT Transparency Service.  It
   is highly complementary to ACT: where ACT defines the two-phase
   lifecycle token issued and consumed by agents at runtime, the SCITT
   AI Agent Execution draft defines the payload format suitable for
   long-term anchoring.  Implementations that anchor Phase 2 ACTs to
   SCITT (Section 11) SHOULD consider the AIR payload structure defined
   in that draft as the canonical encoding for anchored records.











Nennemann               Expires 21 November 2026                [Page 8]

Internet-Draft                     ACT                          May 2026


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.




Nennemann               Expires 21 November 2026                [Page 9]

Internet-Draft                     ACT                          May 2026


   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.








Nennemann               Expires 21 November 2026               [Page 10]

Internet-Draft                     ACT                          May 2026


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.





Nennemann               Expires 21 November 2026               [Page 11]

Internet-Draft                     ACT                          May 2026


   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.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   *Agent*: An autonomous software entity that executes tasks, issues
   ACTs as mandates for sub-agents, and produces ACTs as execution
   records of its own actions.

   *Authorization Mandate*: An ACT in Phase 1, encoding what an agent is
   permitted to do, under what constraints, and by whose authority.

   *Execution Record*: An ACT in Phase 2, encoding what an agent
   actually did, including cryptographic hashes of inputs and outputs
   and causal links to predecessor tasks.

   *Directed Acyclic Graph (DAG)*: A graph structure representing task
   dependency ordering where edges are directed and no cycles exist.
   Used by ACT to model causal relationships between tasks in a
   workflow.



Nennemann               Expires 21 November 2026               [Page 12]

Internet-Draft                     ACT                          May 2026


   *Delegation Chain*: A cryptographically verifiable sequence of ACT
   issuances from a root authority through one or more agents, each
   signing a new ACT that reduces privileges relative to the one it
   received.

   *Trust Tier*: A level of key management infrastructure used to
   establish the public key of an ACT issuer.  Tiers range from pre-
   shared keys (Tier 1, mandatory) to PKI (Tier 2) and DIDs (Tier 3).

   *Workflow*: A set of related tasks, identified by a shared wid claim,
   forming a single logical unit of work.

3.  ACT Lifecycle

   An ACT has a two-phase lifecycle.  The same token format is used in
   both phases; the presence or absence of execution claims determines
   which phase a token represents.

   A token is a *Phase 2 Execution Record* if and only if the claim
   exec_act is present.  A token that does not contain exec_act is a
   *Phase 1 Authorization Mandate*. Verifiers MUST determine the phase
   before applying verification rules, and MUST reject a token that is
   presented in the wrong phase for the operation being performed.

3.1.  Phase 1: Authorization Mandate

   In Phase 1, an ACT is created by a delegating agent (or a human
   operator) to authorize a target agent to perform a specific task.
   The token carries:

   *  The identity of the issuing agent and the target agent.

   *  The capabilities granted, with associated constraints.

   *  Human oversight requirements for high-impact actions.

   *  The delegation provenance (who authorized the issuer to delegate).

   *  A task identifier and declared purpose.

   The Phase 1 ACT is signed by the issuing agent using its private key.
   The target agent receives the ACT and uses it as a bearer mandate —
   evidence that it is authorized to proceed.

   Phase 1 ACTs are short-lived.  Implementations SHOULD set expiration
   (exp) to no more than 15 minutes after issuance (iat) for automated
   agent-to-agent workflows.  Longer lifetimes MAY be used for human-
   initiated mandates where the agent may not act immediately.



Nennemann               Expires 21 November 2026               [Page 13]

Internet-Draft                     ACT                          May 2026


3.2.  Phase 2: Execution Record

   Upon completing the authorized task, the executing agent MUST
   transition the ACT to Phase 2 by:

   1.  Adding the exec_act claim describing the action performed.

   2.  Optionally adding inp_hash and/or out_hash SHA-256 hashes of task
       inputs and outputs (RECOMMENDED for regulated environments).

   3.  Adding the pred array referencing predecessor task identifiers
       (DAG dependencies).

   4.  Adding exec_ts and status claims.

   5.  Re-signing the complete token with its own private key.

   The re-signing is critical: it produces a new signature over the
   combined authorization + execution claims, binding the executing
   agent's cryptographic identity to both the mandate it received and
   the execution it performed.  This creates a single, non-repudiable
   record that answers both "was this agent authorized?" and "what did
   it do?"

   Note on issuer signature preservation: re-signing replaces the Phase
   1 signature produced by the issuing agent (iss).  The integrity of
   the original mandate is preserved through the del.chain mechanism:
   the chain entry's sig field is the iss agent's signature over the
   Phase 1 ACT, and this signature remains intact and verifiable in the
   Phase 2 token.  For root mandates where del.chain is empty, the
   issuer's signature is not independently preserved in Phase 2.
   Deployments requiring independent verifiability of the original
   mandate SHOULD retain the Phase 1 ACT separately alongside the Phase
   2 record.

   The resulting Phase 2 ACT SHOULD be submitted to an audit ledger
   (Section 10) and MAY be sent to the next agent in the workflow as
   evidence of completed prerequisites.

3.3.  Lifecycle State Machine











Nennemann               Expires 21 November 2026               [Page 14]

Internet-Draft                     ACT                          May 2026


     [Issuer creates Phase 1 ACT]
              |
              | sign(issuer_key)
              v
       +------------------+
       |  MANDATE         |  Phase 1: Authorization Mandate
       |  (unsigned by    |  Carried as bearer token by target agent
       |   target agent)  |
       +------------------+
              |
              | Target agent executes task
              | adds exec_act, inp_hash, out_hash, pred
              | re-signs with target_agent_key
              v
       +------------------+
       |  RECORD          |  Phase 2: Execution Record
       |  (signed by      |  Submitted to ledger, passed to next agent
       |   target agent)  |
       +------------------+
              |
              | (optional) anchor to SCITT Transparency Service
              v
       +------------------+
       |  ANCHORED        |  Phase 2 + external non-equivocation
       +------------------+

4.  ACT Token Format

   An ACT is a JSON Web Token [RFC7519] signed as a JSON Web Signature
   [RFC7515] using JWS Compact Serialization.  All ACTs MUST use JWS
   Compact Serialization to ensure they can be carried in a single HTTP
   header value.

4.1.  JOSE Header

   The ACT JOSE header MUST contain:

   {
     "alg": "ES256",
     "typ": "act+jwt",
     "kid": "agent-a-key-2026-03"
   }

   *alg* (REQUIRED): The digital signature algorithm.  Implementations
   MUST support ES256 [RFC7518].  EdDSA (Ed25519) [RFC8037] is
   RECOMMENDED for new deployments due to smaller signatures and
   resistance to side-channel attacks.  Symmetric algorithms (HS256,
   HS384, HS512) MUST NOT be used.  The "alg" value MUST NOT be "none".



Nennemann               Expires 21 November 2026               [Page 15]

Internet-Draft                     ACT                          May 2026


   *typ* (REQUIRED): MUST be "act+jwt" to distinguish ACTs from other
   JWT types.

   *kid* (REQUIRED): An identifier for the signing key.  In Tier 1
   deployments (pre-shared keys), this is an opaque string agreed out-
   of-band.  In Tier 2 deployments (PKI), this is the X.509 certificate
   thumbprint.  In Tier 3 deployments (DID), this is the DID key
   fragment (e.g., did:key:z6Mk...#key-1).

   *x5c* (OPTIONAL): In Tier 2 deployments, the X.509 certificate chain
   MAY be included to enable verification without out-of-band key
   distribution.

   *did* (OPTIONAL): In Tier 3 deployments, the full DID of the issuing
   agent MAY be included for resolution.

4.2.  JWT Claims: Authorization Phase

4.2.1.  Standard JWT Claims

   *iss* (REQUIRED): The identifier of the agent issuing the mandate.
   Format depends on trust tier: an opaque string (Tier 1), an X.509
   Subject DN (Tier 2), or a DID (Tier 3).

   *sub* (REQUIRED): The identifier of the agent authorized to act.
   MUST use the same format convention as iss.

   *aud* (REQUIRED): The intended recipient(s).  MUST include the
   identifier of the target agent (sub).  When an audit ledger is
   deployed, MUST also include the ledger's identifier.  When multiple
   recipients are present, MUST be an array.  Verifiers that are audit
   ledgers MUST verify that their own identifier appears in aud.

   *iat* (REQUIRED): Issuance time as a NumericDate [RFC7519].

   *exp* (REQUIRED): Expiration time.  Implementations SHOULD set to no
   more than 15 minutes after iat for automated workflows.

   *jti* (REQUIRED): A UUID [RFC9562] uniquely identifying this ACT and,
   in Phase 2, the task it records.  Used as the task identifier for DAG
   predecessor references in pred.

4.2.2.  ACT Authorization Claims

   *wid* (OPTIONAL): A UUID identifying the workflow to which this task
   belongs.  When present, groups related ACTs and scopes jti uniqueness
   to the workflow.




Nennemann               Expires 21 November 2026               [Page 16]

Internet-Draft                     ACT                          May 2026


   *task* (REQUIRED): An object describing the authorized task:

   {
     "task": {
       "purpose": "validate_patient_dosage",
       "data_sensitivity": "restricted",
       "created_by": "operator:clinical-admin-01",
       "expires_at": 1772064750
     }
   }

   *  purpose (REQUIRED): A string describing the intended task.
      Implementations SHOULD use a controlled vocabulary or reverse-
      domain notation (e.g., "com.example.validate_dosage") to enable
      semantic consistency checking by the receiving agent.

   *  data_sensitivity (OPTIONAL): One of "public", "internal",
      "confidential", "restricted".  Receiving agents MUST NOT perform
      actions that would expose data above this classification.

   *  created_by (OPTIONAL): An identifier for the human or system that
      initiated the workflow.  SHOULD be pseudonymous (see Section 12).

   *  expires_at (OPTIONAL): A NumericDate after which the task mandate
      is no longer valid, independent of exp.

   *cap* (REQUIRED): An array of capability objects, each specifying an
   action the agent is authorized to perform and the constraints under
   which it may do so:

   {
     "cap": [
       {
         "action": "read.patient_record",
         "constraints": {
           "patient_id_scope": "current_task_only",
           "max_records": 1,
           "data_classification_max": "restricted"
         }
       },
       {
         "action": "write.dosage_recommendation",
         "constraints": {
           "status": "draft_only"
         }
       }
     ]
   }



Nennemann               Expires 21 November 2026               [Page 17]

Internet-Draft                     ACT                          May 2026


   Action names MUST conform to the ABNF grammar:

   action-name = component *( "." component )
   component   = ALPHA *( ALPHA / DIGIT / "-" / "_" )

   Receiving agents MUST perform exact string matching on action names.
   Wildcard matching is NOT part of this specification.

   When multiple capabilities match the same action, OR semantics apply:
   if ANY capability grants the action, the request is authorized
   subject to that capability's constraints.  When multiple constraints
   exist within a single capability, AND semantics apply: ALL
   constraints MUST be satisfied.  When the same constraint key appears
   in both a capability-level and a policy-level context, the more
   restrictive value applies: lower numeric limits, narrower allow-lists
   (intersection), broader block-lists (union), and narrower time
   windows.

   *oversight* (OPTIONAL): Human oversight requirements:

   {
     "oversight": {
       "requires_approval_for": ["write.publish", "execute.payment"],
       "approval_ref": "https://approval.example.com/workflow/w-123"
     }
   }

   When requires_approval_for lists an action, the receiving agent MUST
   NOT execute that action autonomously.  The approval mechanism is out
   of scope for this specification.

   *del* (OPTIONAL): Delegation provenance, establishing the chain of
   authority from the root mandate to this ACT.  If del is absent, the
   ACT MUST be treated as a root mandate with depth = 0 and further
   delegation is not permitted (i.e., the receiving agent MUST NOT issue
   sub-mandates based on this ACT).















Nennemann               Expires 21 November 2026               [Page 18]

Internet-Draft                     ACT                          May 2026


   {
     "del": {
       "depth": 1,
       "max_depth": 3,
       "chain": [
         {
           "delegator": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
           "jti": "550e8400-e29b-41d4-a716-446655440000",
           "sig": "base64url-encoded-signature-of-parent-act-hash"
         }
       ]
     }
   }

   *  depth: The current delegation depth. 0 means this is a root
      mandate issued by a human or root authority.

   *  max_depth: The maximum permitted delegation depth.  Receiving
      agents MUST NOT issue sub-mandates that would exceed this depth.

   *  chain: An array of delegation provenance records ordered from root
      to immediate parent (chain[0] is the root authority, chain[depth-
      1] is the direct parent of this ACT).  Each entry contains:

      -  delegator: The identifier of the agent that authorized this
         delegation step (i.e., the iss of the parent ACT at that
         depth).

      -  jti: The jti of the parent ACT that authorized this delegation
         step.

      -  sig: The delegating agent's signature over the SHA-256 hash of
         that parent ACT, providing cryptographic linkage without
         requiring the full parent ACT to be transmitted.

   The sig field in each chain entry is the critical departure from
   AAP's delegation model: rather than requiring a central AS to
   validate the chain, any verifier holding the delegating agent's
   public key can independently verify each step by recomputing the hash
   and checking the signature.

4.3.  JWT Claims: Execution Phase

   The following claims are added by the executing agent when
   transitioning to Phase 2.  Their presence distinguishes an Execution
   Record from an Authorization Mandate.





Nennemann               Expires 21 November 2026               [Page 19]

Internet-Draft                     ACT                          May 2026


   *exec_act* (REQUIRED in Phase 2): A string identifying the action
   actually performed.  MUST conform to the same ABNF grammar as
   capability action names.  MUST match one of the action values in the
   cap array of the Phase 1 claims.

   *pred* (REQUIRED in Phase 2): An array of jti values of predecessor
   tasks in the DAG.  An empty array indicates a root task.  Each value
   MUST be the jti of a previously verified ACT (Phase 2) within the
   same workflow (same wid) or the global ACT store if wid is absent.

   *inp_hash* (OPTIONAL): The base64url encoding (without padding) of
   the SHA-256 hash of the task's input data, computed over the raw
   octets of the serialized input.  Provides cryptographic evidence of
   what data the agent processed.

   *out_hash* (OPTIONAL): The base64url encoding (without padding) of
   the SHA-256 hash of the task's output data, using the same format as
   inp_hash.  Provides cryptographic evidence of what data the agent
   produced.

   *exec_ts* (REQUIRED in Phase 2): A NumericDate recording the actual
   time of task execution.  MAY differ from iat when the agent queued
   the mandate before execution.  MUST be greater than or equal to iat.
   SHOULD be less than or equal to exp; execution after mandate expiry
   is possible when tasks are long-running and MUST NOT cause automatic
   rejection, but implementors SHOULD log a warning.

   *status* (REQUIRED in Phase 2): One of "completed", "failed",
   "partial".  Allows audit systems to distinguish successful execution
   from partial or failed attempts, which is essential for regulated
   environments where failed attempts must be recorded.

   *err* (OPTIONAL, present when status is "failed" or "partial"): An
   object providing error context:

   {
     "err": {
       "code": "constraint_violation",
       "detail": "data_classification_max exceeded"
     }
   }

   Error detail SHOULD NOT reveal internal system state beyond what is
   necessary for audit purposes.







Nennemann               Expires 21 November 2026               [Page 20]

Internet-Draft                     ACT                          May 2026


4.4.  Complete Examples

4.4.1.  Example: Phase 1 — Authorization Mandate

   {
     "alg": "ES256",
     "typ": "act+jwt",
     "kid": "agent-clinical-key-2026-03"
   }
   .
   {
     "iss": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
     "sub": "did:key:z6MknGc3omCyas4b1GmEn4xySHgLuSHxrKrUBnrhJekxZHFz",
     "aud": [
       "did:key:z6MknGc3omCyas4b1GmEn4xySHgLuSHxrKrUBnrhJekxZHFz",
       "https://ledger.hospital.example.com"
     ],
     "iat": 1772064000,
     "exp": 1772064900,
     "jti": "550e8400-e29b-41d4-a716-446655440001",

     "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",

     "task": {
       "purpose": "validate_treatment_recommendation",
       "data_sensitivity": "restricted",
       "created_by": "operator:clinical-admin-01"
     },

     "cap": [
       {
         "action": "read.patient_record",
         "constraints": {
           "patient_id_scope": "current_task_only",
           "max_records": 1
         }
       },
       {
         "action": "write.safety_assessment",
         "constraints": {
           "status": "draft_only"
         }
       }
     ],

     "oversight": {
       "requires_approval_for": ["write.publish_assessment"]
     },



Nennemann               Expires 21 November 2026               [Page 21]

Internet-Draft                     ACT                          May 2026


     "del": {
       "depth": 0,
       "max_depth": 2,
       "chain": []
     }
   }

4.4.2.  Example: Phase 2 — Execution Record (same token, re-signed by
        target agent)

   {
     "alg": "EdDSA",
     "typ": "act+jwt",
     "kid": "agent-safety-key-2026-03"
   }
   .
   {
     "iss": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
     "sub": "did:key:z6MknGc3omCyas4b1GmEn4xySHgLuSHxrKrUBnrhJekxZHFz",
     "aud": [
       "did:key:z6MknGc3omCyas4b1GmEn4xySHgLuSHxrKrUBnrhJekxZHFz",
       "https://ledger.hospital.example.com"
     ],
     "iat": 1772064000,
     "exp": 1772064900,
     "jti": "550e8400-e29b-41d4-a716-446655440001",

     "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",

     "task": {
       "purpose": "validate_treatment_recommendation",
       "data_sensitivity": "restricted",
       "created_by": "operator:clinical-admin-01"
     },

     "cap": [
       {
         "action": "read.patient_record",
         "constraints": {
           "patient_id_scope": "current_task_only",
           "max_records": 1
         }
       },
       {
         "action": "write.safety_assessment",
         "constraints": {
           "status": "draft_only"
         }



Nennemann               Expires 21 November 2026               [Page 22]

Internet-Draft                     ACT                          May 2026


       }
     ],

     "oversight": {
       "requires_approval_for": ["write.publish_assessment"]
     },

     "del": {
       "depth": 0,
       "max_depth": 2,
       "chain": []
     },

     "exec_act": "write.safety_assessment",
     "pred": ["550e8400-e29b-41d4-a716-446655440000"],
     "inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
     "out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
     "exec_ts": 1772064300,
     "status": "completed"
   }

5.  Trust Model

   ACT defines four trust tiers.  Tier 1 is mandatory-to-implement; all
   others are optional upgrades.  An ACT verifier MUST be able to
   process ACTs from any tier it has configured.  The trust tier in use
   is determined by the kid format and the presence of x5c or did header
   parameters.

5.1.  Tier 0: Bootstrap (TOFU — Trust On First Use)

   Tier 0 is NOT part of the normative trust model and MUST NOT be used
   in regulated environments.  It is defined here for documentation
   purposes only, to describe the common bootstrapping scenario.

   In Tier 0, the first ACT received from an agent establishes its
   public key.  This is equivalent to SSH TOFU behavior: an attacker who
   intercepts the first message can substitute their own key.  Tier 0
   deployments MUST transition to Tier 1 or higher before exchanging
   ACTs that carry sensitive capabilities.

5.2.  Tier 1: Pre-Shared Keys (Mandatory-to-Implement)

   In Tier 1, both parties exchange public keys out-of-band prior to the
   first ACT exchange.  The kid is an opaque string agreed during the
   key exchange.  Implementations MUST support Tier 1.





Nennemann               Expires 21 November 2026               [Page 23]

Internet-Draft                     ACT                          May 2026


   Key exchange MAY occur via any out-of-band mechanism: manual
   configuration, a configuration management system, or a prior
   authenticated channel.  This specification does not mandate a
   specific key exchange protocol.

   Tier 1 public keys MUST be Ed25519 [RFC8037] or P-256 (ES256)
   [RFC7518] keys.  RSA keys SHOULD NOT be used in Tier 1 deployments
   due to key size.  Key rotation MUST be performed out-of-band using
   the same mechanism as the initial exchange.

5.3.  Tier 2: PKI / X.509

   In Tier 2, agent identity is bound to an X.509 certificate issued by
   a mutually trusted Certificate Authority (CA).  The kid is the
   certificate thumbprint (SHA-256 of the DER-encoded certificate).

   Cross-organizational ACT exchange in Tier 2 requires either:

   (a) a mutually trusted root CA, or (b) cross-certification between
   the organizations' CAs, or (c) explicit trust anchoring (one
   organization's CA is added to the other's trust store).

   The x5c JOSE header parameter [RFC7515] MAY carry the full
   certificate chain to enable verification without out-of-band trust
   store configuration.

5.4.  Tier 3: Decentralized Identifiers (DID)

   In Tier 3, agent identity is expressed as a DID [W3C-DID].  The kid
   is a DID key fragment.  The did JOSE header parameter carries the
   full DID for resolution.

   Implementations SHOULD support at minimum did:key [DID-KEY] for self-
   contained key distribution without external resolution, and did:web
   [DID-WEB] for organizations that prefer DNS-anchored identity.

   DID resolution latency introduces a dependency on external
   infrastructure.  To preserve the zero-infrastructure baseline,
   implementations using Tier 3 MAY cache DID Documents and MUST specify
   a maximum cache TTL in their configuration.











Nennemann               Expires 21 November 2026               [Page 24]

Internet-Draft                     ACT                          May 2026


5.5.  Cross-Tier Interoperability

   A delegation chain MAY include agents operating at different trust
   tiers.  Each step in the chain is verified using the trust tier of
   the signing agent at that step.  Verifiers MUST NOT reject a chain
   solely because it mixes trust tiers, but MAY apply stricter policy
   for chains that include Tier 0 or Tier 1 steps when exchanging
   sensitive capabilities.

6.  Delegation Chain

   ACT delegation is peer-to-peer: no Authorization Server is involved.
   Delegation is expressed as a cryptographically verifiable chain of
   ACT issuances, where each step reduces privileges relative to the
   previous step.

6.1.  Peer-to-Peer Delegation

   When Agent A authorizes Agent B to perform a sub-task, Agent A:

   1.  Creates a new ACT with sub set to Agent B's identifier.

   2.  Sets cap to a subset of A's own authorized capabilities, with
       constraints at least as restrictive as those in A's mandate.

   3.  Sets del.depth to A's own del.depth + 1.

   4.  Sets del.max_depth to no more than the del.max_depth value in A's
       own mandate.

   5.  Adds a chain entry containing A's identifier as delegator, the
       jti of A's own mandate, and a sig value computed as:

      sig = Sign(A.private_key, SHA-256(canonical_ACT_phase1_bytes))

       where canonical_ACT_phase1_bytes is the UTF-8 encoded bytes of
       the JWS Compact Serialization of A's Phase 1 ACT.

   6.  Signs the new ACT with A's private key.

6.2.  Privilege Reduction Requirements

   When issuing a delegated ACT, the issuing agent MUST reduce
   privileges by one or more of:

   *  Removing capabilities (sub-set of parent capabilities only).





Nennemann               Expires 21 November 2026               [Page 25]

Internet-Draft                     ACT                          May 2026


   *  Adding stricter constraints (lower rate limits, narrower domains,
      shorter time windows, lower data classification ceiling).

   *  Reducing token lifetime (exp closer to iat).

   *  Reducing del.max_depth.

   The issuing agent MUST NOT grant capabilities not present in its own
   mandate.  Capability escalation via delegation is prohibited and MUST
   be detected and rejected by verifiers.

   For well-known numeric constraints (e.g., max_records,
   max_requests_per_hour), "more restrictive" means a numerically lower
   or equal value.  For well-known enumerated constraints (e.g.,
   data_sensitivity), "more restrictive" means a value that is equal or
   higher in the defined ordering ("public" < "internal" <
   "confidential" < "restricted").  For unknown or domain-specific
   constraint keys, verifiers MUST treat the constraint as non-
   comparable and MUST reject the delegation unless the delegated
   constraint value is byte-for-byte identical to the parent constraint
   value.

6.3.  Delegation Verification

   A verifier receiving a delegated ACT MUST:

   1.  Verify the ACT's own signature (Section 8.1).

   2.  For each entry in del.chain, in order from index 0 to del.depth -
       1: a.  Retrieve the public key for entry.delegator. b.  Verify
       that entry.sig is a valid signature over the SHA-256 hash of the
       referenced parent ACT (identified by entry.jti). c.  Verify that
       the capabilities in the current ACT are a subset of the
       capabilities in the parent ACT, per the constraint comparison
       rules in Section 6.2.

   3.  Verify that del.depth does not exceed del.max_depth.

   4.  Verify that del.chain length equals del.depth.

   If any step fails, the ACT MUST be rejected.

7.  DAG Structure and Causal Ordering

   ACTs in Phase 2 form a DAG over the pred (predecessor) claim.  The
   DAG encodes causal dependencies: a task MAY NOT begin before all its
   parent tasks are completed.




Nennemann               Expires 21 November 2026               [Page 26]

Internet-Draft                     ACT                          May 2026


7.1.  DAG Validation

   When processing a Phase 2 ACT, implementations MUST:

   1.  *Uniqueness*: Verify the jti is unique within the workflow (wid)
       or globally if wid is absent.

   2.  *Predecessor Existence*: Verify every jti in pred corresponds to
       a Phase 2 ACT available in the ACT store or audit ledger.

   3.  *Temporal Ordering*: Verify that for each parent: parent.exec_ts
       < child.exec_ts + clock_skew_tolerance (RECOMMENDED tolerance: 30
       seconds).  Causal ordering is primarily enforced by DAG
       structure, not timestamps.

   4.  *Acyclicity*: Following parent references MUST NOT lead back to
       the current ACT's jti.  Implementations MUST enforce a maximum
       ancestor traversal limit (RECOMMENDED: 10,000 nodes).

   5.  *Capability Consistency*: Verify that exec_act matches one of the
       action values in the cap array from Phase 1.

7.2.  Root Tasks and Fan-in

   A root task has pred = [].  A workflow MAY have multiple root tasks
   representing parallel branches with no shared predecessor.

   Fan-in — a task with multiple parents — is expressed naturally:

   {
     "pred": [
       "550e8400-e29b-41d4-a716-446655440001",
       "550e8400-e29b-41d4-a716-446655440002"
     ]
   }

   This indicates the current task depends on the completion of both
   referenced parent tasks, which MAY have been executed in parallel by
   different agents.

7.3.  DAG vs Linear Delegation Chains

   Several concurrent proposals for agent authorization model delegation
   as an ordered, linear chain of tokens or principals.  Examples
   include the actchain claim of
   [I-D.oauth-transaction-tokens-for-agents], the Agentic JWT
   construction of [AgenticJWT], the AIP / Interaction-Bound Context
   Token (IBCT) model of [AIP-IBCT], and the delegation record defined



Nennemann               Expires 21 November 2026               [Page 27]

Internet-Draft                     ACT                          May 2026


   in [I-D.helixar-hdp-agentic-delegation].  In each of these designs,
   the trail from the originator to the final executor is represented as
   an ordered array recording one predecessor per hop.

7.3.1.  What Linear Chains Express Well

   Linear chains are a natural fit for simple sequential delegation:
   agent A delegates to agent B, which delegates to agent C.  The chain
   records the history of that single hand-off in order, and verifiers
   can walk from the current holder back to the originator without
   branching.  For interactive user-to-agent-to-service flows, where
   each step has exactly one predecessor, a linear chain is both
   sufficient and compact.

7.3.2.  Limitations of Linear Chains

   Agentic workflows in practice are rarely purely linear.  Planner
   agents dispatch parallel sub-tasks; synthesizer agents consume
   results from multiple independent branches; tool calls execute
   concurrently and their outputs are merged.  A linear chain cannot
   faithfully represent the following common topologies:

   *  *Fork*: A single task spawns multiple independent sub-tasks.  A
      linear chain cannot express that two concurrent sub-executions
      share a common parent authorization but are otherwise independent;
      each sub-task would either omit its siblings or fabricate a false
      ordering between them.

   *  *Join (fan-in)*: A task whose output depends on results from
      several predecessors has no single prior hop.  Linear chains
      cannot express multiple-parent relationships without either
      collapsing parallel branches into an arbitrary order or
      duplicating records.

   *  *Diamond dependencies*: A planner dispatches parallel work and
      later synthesizes the results.  The synthesis step depends on
      every branch, and all branches depend on the same planner.  This
      diamond shape requires a DAG; a linear chain forces the verifier
      to pick one branch and discard the others.

   *  *Cross-chain references*: When two independently authorized chains
      produce outputs that are later combined (e.g., a shared cache
      lookup and a fresh retrieval), linear chains force a single
      history and cannot record that the combined result has two
      distinct provenances.






Nennemann               Expires 21 November 2026               [Page 28]

Internet-Draft                     ACT                          May 2026


7.3.3.  ACT's DAG Approach

   As specified in Section 4.3, the pred claim is an array of parent jti
   values rather than a single scalar.  This allows an ACT to record:

   *  Zero parents (a root task, pred = []);

   *  Exactly one parent (a linear chain, equivalent to the single-
      predecessor designs referenced above);

   *  Multiple parents (fan-in from parallel branches); and

   *  Any acyclic shape that matches the actual execution structure.

   The following example illustrates a diamond workflow.  A research
   agent (A) dispatches a web-search agent (B) and a code-analysis agent
   (C) in parallel; both complete, and their outputs are combined by a
   writer agent (D):

           +-----+
           |  A  |   pred = []
           +-----+
            /   \
           v     v
        +---+   +---+
        | B |   | C |   pred = [A.jti]
        +---+   +---+
           \   /
            v v
           +-----+
           |  D  |   pred = [B.jti, C.jti]
           +-----+

   A linear actchain representation cannot express that D depends on
   both B and C.  At best, it can record one of the two parents and lose
   the other, or serialize B and C into a false sequential order.

7.3.4.  Verifiability Implications

   With a DAG representation, an auditor holding the set of Phase 2 ACTs
   for a workflow can reconstruct the full execution graph, not just one
   chain per final record.  This matters for:

   *  *Debugging*: identifying which branch contributed an erroneous
      input to a downstream synthesis.

   *  *Compliance*: demonstrating that every input to a regulated
      decision was itself authorized, not only the most recent hop.



Nennemann               Expires 21 November 2026               [Page 29]

Internet-Draft                     ACT                          May 2026


   *  *Tamper-evidence*: detecting that a branch has been omitted, since
      the surviving siblings' pred arrays name the missing predecessor
      by jti.

7.3.5.  Interoperability with Linear-Chain Designs

   ACT's DAG reduces to a linear chain in the degenerate case where
   every pred array has length zero or one.  An implementation that
   requires linear-chain semantics MAY treat such ACTs as equivalent to
   actchain-style records and ignore the fork/join capability.  The
   reverse reduction is not available: a linear-chain-only design cannot
   represent ACT DAG topologies without loss of information.

   ACT therefore takes the linear chain as a strict subset of its model
   rather than as a competing approach.  The DAG generalization is
   deliberate and is motivated by the concurrent, branching nature of
   real agentic executions rather than by any deficiency in the linear-
   chain designs for the sequential cases they target.

8.  Verification Procedure

8.1.  Authorization Phase Verification

   A receiving agent MUST verify a Phase 1 ACT as follows:

   1.   Parse JWS Compact Serialization per [RFC7515].

   2.   Verify typ is "act+jwt".

   3.   Verify alg is in the verifier's algorithm allowlist.  The
        allowlist MUST NOT include "none" or any symmetric algorithm.

   4.   Retrieve the public key for kid per the applicable trust tier
        (Section 5).

   5.   Verify the JWS signature.

   6.   Verify exp has not passed (with clock skew tolerance:
        RECOMMENDED maximum 5 minutes).

   7.   Verify iat is not unreasonably in the future (RECOMMENDED: no
        more than 30 seconds ahead).

   8.   Verify aud contains the verifier's own identifier.

   9.   Verify iss is a trusted agent identity per local policy.





Nennemann               Expires 21 November 2026               [Page 30]

Internet-Draft                     ACT                          May 2026


   10.  Verify sub matches the verifier's own identifier (the agent is
        the intended recipient of this mandate).

   11.  Verify all required claims are present and well-formed.

   12.  Verify delegation chain (Section 6.3) if del.chain is non-empty.

   13.  Verify capabilities are within policy limits.

8.2.  Execution Phase Verification

   In addition to all Phase 1 verification steps, a verifier processing
   a Phase 2 ACT MUST:

   1.  Verify exec_act is present and matches an action in cap.

   2.  Verify pred is present and perform DAG validation (Section 7.1).

   3.  Verify exec_ts is present and is greater than or equal to iat.
       If exec_ts is after exp, implementations SHOULD log a warning but
       MUST NOT reject the record solely on this basis.

   4.  Verify status is present and has a valid value.

   5.  Verify the re-signature was produced by the sub agent (the
       executing agent), not the iss agent (the mandating agent).  This
       is verified by checking that the kid in the Phase 2 JOSE header
       corresponds to the sub agent's public key.

   6.  If inp_hash or out_hash are present, verify them against locally
       available input/output data when possible.

9.  Transport

9.1.  HTTP Header Transport

   This specification defines two HTTP [RFC9110] header fields for ACT
   transport:

   *ACT-Mandate*: Carries a Phase 1 ACT issued by an upstream agent or
   operator.  Value is the JWS Compact Serialization of the ACT.

   GET /api/safety-check HTTP/1.1
   Host: safety-agent.example.com
   ACT-Mandate: eyJhbGci...Phase1ACT...

   *ACT-Record*: Carries a Phase 2 ACT from a predecessor agent, serving
   as evidence of completed prerequisites.



Nennemann               Expires 21 November 2026               [Page 31]

Internet-Draft                     ACT                          May 2026


   POST /api/downstream HTTP/1.1
   Host: downstream-agent.example.com
   ACT-Mandate: eyJhbGci...Phase1ACT...
   ACT-Record: eyJhbGci...Phase2ACT...

   Multiple ACT-Record header lines MAY be included when a task has
   multiple completed predecessors (DAG fan-in).  If any single ACT-
   Record fails verification, the receiver MUST reject the entire
   request.

9.2.  Non-HTTP Transports

   For non-HTTP transports (MCP stdio, A2A message queues, AMQP, etc.),
   ACTs SHOULD be carried as a dedicated field in the transport's
   metadata envelope.  The field name SHOULD be act_mandate for Phase 1
   ACTs and act_record for Phase 2 ACTs.  Implementations MUST use the
   JWS Compact Serialization form in all transports.

10.  Audit Ledger Interface

   Phase 2 ACTs SHOULD be submitted to an immutable audit ledger.  A
   ledger is RECOMMENDED for regulated environments but is not required
   for basic ACT operation.  This specification does not mandate a
   specific storage technology.

   When an audit ledger is deployed, the implementation MUST provide:

   1.  *Append-only semantics*: Once an ACT is recorded, it MUST NOT be
       modified or deleted.

   2.  *Ordering*: A monotonically increasing sequence number per
       recorded ACT.

   3.  *Lookup*: Efficient retrieval by jti value.

   4.  *Integrity*: A cryptographic commitment scheme over recorded ACTs
       (e.g., hash-chaining, Merkle tree anchoring, or SCITT
       registration per [I-D.ietf-scitt-architecture]).

11.  Security Considerations

11.1.  Threat Model

   ACT assumes an adversarial environment where:

   *  Individual agents may be compromised.





Nennemann               Expires 21 November 2026               [Page 32]

Internet-Draft                     ACT                          May 2026


   *  Network paths may be intercepted (mitigated by transport
      security).

   *  Attackers may attempt to replay valid ACTs from prior
      interactions.

   *  Colluding agents may attempt to fabricate execution records.

   *  Agents may attempt privilege escalation via manipulated delegation
      chains.

   ACT does NOT assume:

   *  A trusted central authority (by design).

   *  Synchronized clocks beyond the stated skew tolerance.

   *  Availability of external network services during verification.

11.2.  Self-Assertion Limitation

   Phase 2 ACTs are self-asserted: an executing agent signs its own
   execution record.  A compromised agent with an intact private key can
   produce Phase 2 ACTs claiming arbitrary inputs, outputs, and action
   types, as long as the claimed exec_act matches an authorized
   capability.

   This is a fundamental limitation of self-sovereign attestation.  It
   is the same limitation affecting WIMSE ECT [I-D.nennemann-wimse-ect].

   Mitigations:

   *  *Cross-agent corroboration*: A receiving agent that processes an
      ACT-Record as a prerequisite independently verifies that the
      claimed out_hash matches the data it actually received.

   *  *Ledger sequencing*: An append-only ledger with monotonic sequence
      numbers prevents retroactive insertion of fabricated records.

   *  *SCITT anchoring*: For high-assurance deployments, Phase 2 ACTs
      SHOULD be anchored to a SCITT Transparency Service, providing
      external witness that the record was submitted at a claimed time.

11.3.  Key Compromise

   If an agent's private key is compromised, an attacker can issue
   arbitrary Phase 1 mandates (impersonating the agent as an issuer) and
   fabricate Phase 2 records (impersonating the agent as an executor).



Nennemann               Expires 21 November 2026               [Page 33]

Internet-Draft                     ACT                          May 2026


   Key compromise response:

   1.  The compromised agent's identifier MUST be added to all
       verifiers' deny lists.

   2.  In Tier 2 (PKI) deployments, the certificate MUST be revoked via
       CRL or OCSP.

   3.  In Tier 3 (DID) deployments, the DID Document MUST be updated to
       revoke the compromised key.

   4.  In Tier 1 (pre-shared key) deployments, both parties MUST perform
       an out-of-band key rotation.

   ACT chains that include records signed by a compromised key MUST be
   treated as potentially tainted from the point of compromise.  Audit
   systems MUST flag all ACTs signed after the estimated compromise
   time.

11.4.  Replay Attack Prevention

   jti uniqueness within the applicable scope (workflow or global)
   provides replay detection.  Verifiers MUST reject ACTs whose jti has
   already been seen and processed.

   exp provides a time-bounded replay window.  Verifiers MUST reject
   expired ACTs.  The combination of jti and exp means that replay
   detection state only needs to be maintained for the duration of token
   lifetimes.

11.5.  Equivocation

   In standalone deployment (no audit ledger, no SCITT anchoring), ACT
   does NOT provide non-equivocation guarantees.  A compromised agent
   can maintain two valid ACT chains — presenting Phase 2 records with
   different out_hash values to different verifiers — and both will pass
   independent verification.

   *Deployments claiming DORA [DORA] Article 10/11 compliance or EU AI
   Act [EUAIA] Article 12 compliance MUST use one of:*

   (a) A shared append-only audit ledger visible to all relevant
   parties, with cryptographic integrity (hash chaining or Merkle
   trees).

   (b) SCITT anchoring [I-D.ietf-scitt-architecture] providing external
   Transparency Service receipts.




Nennemann               Expires 21 November 2026               [Page 34]

Internet-Draft                     ACT                          May 2026


   Standalone ACT provides tamper detection (a verifier can detect
   modification of a record it has seen) but not split-view prevention
   (a verifier cannot detect a different record shown to another
   verifier).

11.6.  Privilege Escalation

   Verifiers MUST check that each step in del.chain reduces or maintains
   (never increases) the capabilities relative to the preceding step.
   Implementations MUST reject ACTs where:

   *  del.depth exceeds del.max_depth.

   *  cap contains actions not present in any referenced parent ACT.

   *  Constraints in cap are less restrictive than those in the parent.

11.7.  Denial of Service

   ACT verification is more computationally expensive than standard JWT
   validation due to delegation chain verification and DAG traversal.

   Mitigations:

   *  Reject ACTs larger than 64KB before parsing.

   *  Enforce maximum del.chain length (RECOMMENDED: 10 entries).

   *  Enforce maximum DAG ancestor traversal depth (RECOMMENDED: 10,000
      nodes, Section 7.1).

   *  Cache verification results for recently seen jti values within the
      token lifetime window.

12.  Privacy Considerations

   ACT tokens and audit ledger records may contain information that
   identifies agents, organizations, or individuals.  Implementations
   SHOULD apply data minimization principles:

   *  task.created_by SHOULD use a pseudonymous identifier rather than a
      personal email address or real name.

   *  task.purpose SHOULD use a controlled vocabulary code rather than
      free-text descriptions that may contain personal data.






Nennemann               Expires 21 November 2026               [Page 35]

Internet-Draft                     ACT                          May 2026


   *  del.chain entries reveal organizational structure.  Cross-
      organizational delegation chains SHOULD use Tier 3 (DID)
      identifiers that do not reveal organizational affiliation.

   *  inp_hash and out_hash are hashes of data, not the data itself, and
      do not constitute personal data under GDPR Article 4(1) provided
      the underlying data is not trivially reversible (e.g., hashes of
      very short strings).

   For GDPR Article 17 (right to erasure) compliance, audit ledgers
   SHOULD store only ACT tokens (which contain hashes, not raw data) and
   SHOULD implement crypto-shredding for any associated encrypted
   payloads.

13.  IANA Considerations

13.1.  Media Type Registration

   This document requests registration of the following media type:

   *  Type name: application

   *  Subtype name: act+jwt

   *  Required parameters: none

   *  Encoding considerations: binary (base64url-encoded JWT)

   *  Security considerations: See Section 11.

   *  Interoperability considerations: See Section 8.1.

   *  Specification: This document.

13.2.  HTTP Header Field Registration

   This document requests registration of the following HTTP header
   fields in the "Hypertext Transfer Protocol (HTTP) Field Name
   Registry":

   *  Header field name: ACT-Mandate

   *  Applicable protocol: HTTP

   *  Status: permanent

   *  Specification: This document, Section 9.1.




Nennemann               Expires 21 November 2026               [Page 36]

Internet-Draft                     ACT                          May 2026


   *  Header field name: ACT-Record

   *  Applicable protocol: HTTP

   *  Status: permanent

   *  Specification: This document, Section 9.1.

13.3.  JWT Claims Registration

   This document requests registration of the following claims in the
   IANA "JSON Web Token Claims" registry:

    +============+====================================+===============+
    | Claim Name | Description                        | Reference     |
    +============+====================================+===============+
    | wid        | Workflow identifier                | This document |
    +------------+------------------------------------+---------------+
    | task       | Task authorization context         | This document |
    +------------+------------------------------------+---------------+
    | cap        | Capabilities with constraints      | This document |
    +------------+------------------------------------+---------------+
    | oversight  | Human oversight requirements       | This document |
    +------------+------------------------------------+---------------+
    | del        | Delegation provenance chain        | This document |
    +------------+------------------------------------+---------------+
    | exec_act   | Executed action identifier         | This document |
    +------------+------------------------------------+---------------+
    | pred       | Predecessor task identifiers (DAG) | This document |
    +------------+------------------------------------+---------------+
    | inp_hash   | SHA-256 hash of task input         | This document |
    +------------+------------------------------------+---------------+
    | out_hash   | SHA-256 hash of task output        | This document |
    +------------+------------------------------------+---------------+
    | exec_ts    | Actual execution timestamp         | This document |
    +------------+------------------------------------+---------------+
    | status     | Execution status                   | This document |
    +------------+------------------------------------+---------------+
    | err        | Execution error context            | This document |
    +------------+------------------------------------+---------------+

                                  Table 1

14.  References

14.1.  Normative References





Nennemann               Expires 21 November 2026               [Page 37]

Internet-Draft                     ACT                          May 2026


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/rfc/rfc7515>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7517>.

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7518>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7519>.

   [RFC8037]  Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
              and Signatures in JSON Object Signing and Encryption
              (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
              <https://www.rfc-editor.org/rfc/rfc8037>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [RFC9562]  Davis, K., Peabody, B., and P. Leach, "Universally Unique
              IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
              2024, <https://www.rfc-editor.org/rfc/rfc9562>.

14.2.  Informative References

   [A2A-SPEC] Google, "Agent2Agent (A2A) Protocol",
              <https://github.com/a2aproject/A2A>.

   [AgenticJWT]
              "Agentic JWT: A JSON Web Token Profile for Delegated Agent
              Authorization", 2025, <https://arxiv.org/abs/2509.13597>.




Nennemann               Expires 21 November 2026               [Page 38]

Internet-Draft                     ACT                          May 2026


   [AIP-IBCT] S., P., "AIP: Agent Interaction Protocol with Interaction-
              Bound Context Tokens", March 2026,
              <https://arxiv.org/abs/2603.24775>.

   [AUTOGEN]  Microsoft, "AutoGen Documentation",
              <https://microsoft.github.io/autogen/>.

   [CREWAI]   CrewAI, "CrewAI Documentation",
              <https://docs.crewai.com/>.

   [DID-KEY]  D., L., "The did:key Method v0.7", 2021,
              <https://w3c-ccg.github.io/did-method-key/>.

   [DID-WEB]  O., S., "did:web Method Specification", 2022,
              <https://w3c-ccg.github.io/did-method-web/>.

   [DORA]     European Parliament, "Digital Operational Resilience Act
              (DORA), Regulation (EU) 2022/2554", 2022,
              <https://eur-lex.europa.eu/eli/reg/2022/2554/oj>.

   [EUAIA]    European Parliament, "EU Artificial Intelligence Act,
              Regulation (EU) 2024/1689", 2024,
              <https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.

   [I-D.aap-oauth-profile]
              A., C., "Agent Authorization Profile (AAP) for OAuth 2.0",
              Work in Progress, Internet-Draft, draft-aap-oauth-profile-
              01, February 2026, <https://datatracker.ietf.org/doc/
              draft-aap-oauth-profile/>.

   [I-D.emirdag-scitt-ai-agent-execution]
              Emirdag, "A SCITT Profile for AI Agent Execution Records",
              Work in Progress, Internet-Draft, draft-emirdag-scitt-ai-
              agent-execution-00, April 2026,
              <https://datatracker.ietf.org/doc/draft-emirdag-scitt-ai-
              agent-execution/>.

   [I-D.helixar-hdp-agentic-delegation]
              Helixar, "Helixar Delegation Protocol (HDP) for Agentic
              Delegation", Work in Progress, Internet-Draft, draft-
              helixar-hdp-agentic-delegation-00, 2026,
              <https://datatracker.ietf.org/doc/draft-helixar-hdp-
              agentic-delegation/>.

   [I-D.ietf-scitt-architecture]
              Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
              Y., and S. Lasker, "An Architecture for Trustworthy and
              Transparent Digital Supply Chains", Work in Progress,



Nennemann               Expires 21 November 2026               [Page 39]

Internet-Draft                     ACT                          May 2026


              Internet-Draft, draft-ietf-scitt-architecture-22, 10
              October 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-scitt-architecture-22>.

   [I-D.nennemann-wimse-ect]
              Nennemann, C., "Execution Context Tokens for Distributed
              Agentic Workflows", Work in Progress, Internet-Draft,
              draft-nennemann-wimse-ect-02, 2026,
              <https://datatracker.ietf.org/doc/draft-nennemann-wimse-
              ect/>.

   [I-D.oauth-transaction-tokens-for-agents]
              G., F., "Transaction Tokens for Agentic AI Systems", Work
              in Progress, Internet-Draft, draft-oauth-transaction-
              tokens-for-agents-06, 2026,
              <https://datatracker.ietf.org/doc/draft-oauth-transaction-
              tokens-for-agents/>.

   [IEC62304] IEC, "Medical device software — Software life cycle
              processes, IEC 62304:2006+AMD1:2015", 2015,
              <https://www.iec.ch/>.

   [LANGGRAPH]
              LangChain, "LangGraph Documentation",
              <https://langchain-ai.github.io/langgraph/>.

   [MCP-SPEC] "Model Context Protocol Specification", 25 November 2025,
              <https://modelcontextprotocol.io/
              specification/2025-11-25>.

   [OPENAI-AGENTS-SDK]
              OpenAI, "OpenAI Agents SDK",
              <https://openai.github.io/openai-agents-python/>.

   [RFC7009]  Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
              2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
              August 2013, <https://www.rfc-editor.org/rfc/rfc7009>.

   [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
              and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
              DOI 10.17487/RFC8693, January 2020,
              <https://www.rfc-editor.org/rfc/rfc8693>.

   [SentinelAgent]
              Patil, "SentinelAgent: A Formal Delegation Chain Calculus
              for Verifiable Agent Authorization", April 2026,
              <https://arxiv.org/abs/2604.02767>.




Nennemann               Expires 21 November 2026               [Page 40]

Internet-Draft                     ACT                          May 2026


   [W3C-DID]  M., S., "Decentralized Identifiers (DIDs) v1.0", July
              2022, <https://www.w3.org/TR/did-core/>.

Appendix A: Complete JSON Schema

   The following JSON Schema (2020-12) describes the claim set of ACT
   Phase 1 (Authorization Mandate) and Phase 2 (Execution Record)
   tokens.  A token is a Phase 2 record if and only if it contains the
   exec_act, exec_ts, pred, and status claims; otherwise it is a Phase 1
   mandate.  The schema validates structure only; semantic rules
   (capability subset on delegation, exec_act membership in cap, DAG
   acyclicity, depth bounds) are specified normatively in the body of
   this document and cannot be expressed in JSON Schema.

   {
     "$schema": "https://json-schema.org/draft/2020-12/schema",
     "$id": "urn:ietf:params:act:schema:token",
     "title": "Agent Context Token (ACT)",
     "type": "object",
     "oneOf": [
       { "$ref": "#/$defs/phase1" },
       { "$ref": "#/$defs/phase2" }
     ],
     "$defs": {
       "actionName": {
         "type": "string",
         "pattern": "^[A-Za-z][A-Za-z0-9_-]*(\\.[A-Za-z][A-Za-z0-9_-]*)*$"
       },
       "numericDate": { "type": "integer", "minimum": 0 },
       "uuid": {
         "type": "string",
         "format": "uuid"
       },
       "audience": {
         "oneOf": [
           { "type": "string" },
           {
             "type": "array",
             "items": { "type": "string" },
             "minItems": 1
           }
         ]
       },
       "task": {
         "type": "object",
         "required": ["purpose"],
         "properties": {
           "purpose": { "type": "string", "minLength": 1 },



Nennemann               Expires 21 November 2026               [Page 41]

Internet-Draft                     ACT                          May 2026


           "data_sensitivity": {
             "type": "string",
             "enum": [
               "public", "internal", "confidential", "restricted"
             ]
           },
           "created_by": { "type": "string" },
           "expires_at": { "$ref": "#/$defs/numericDate" }
         },
         "additionalProperties": true
       },
       "capability": {
         "type": "object",
         "required": ["action"],
         "properties": {
           "action": { "$ref": "#/$defs/actionName" },
           "constraints": { "type": "object" }
         },
         "additionalProperties": false
       },
       "oversight": {
         "type": "object",
         "properties": {
           "requires_approval_for": {
             "type": "array",
             "items": { "$ref": "#/$defs/actionName" }
           },
           "approval_ref": { "type": "string" }
         },
         "additionalProperties": false
       },
       "delegationEntry": {
         "type": "object",
         "required": ["delegator", "jti", "sig"],
         "properties": {
           "delegator": { "type": "string" },
           "jti": { "$ref": "#/$defs/uuid" },
           "sig": { "type": "string" }
         },
         "additionalProperties": false
       },
       "delegation": {
         "type": "object",
         "required": ["depth", "max_depth", "chain"],
         "properties": {
           "depth": { "type": "integer", "minimum": 0 },
           "max_depth": { "type": "integer", "minimum": 0 },
           "chain": {



Nennemann               Expires 21 November 2026               [Page 42]

Internet-Draft                     ACT                          May 2026


             "type": "array",
             "items": { "$ref": "#/$defs/delegationEntry" }
           }
         },
         "additionalProperties": false
       },
       "error": {
         "type": "object",
         "required": ["code"],
         "properties": {
           "code": { "type": "string" },
           "detail": { "type": "string" }
         },
         "additionalProperties": false
       },
       "commonClaims": {
         "type": "object",
         "required": [
           "iss", "sub", "aud", "iat", "exp", "jti", "task", "cap"
         ],
         "properties": {
           "iss": { "type": "string" },
           "sub": { "type": "string" },
           "aud": { "$ref": "#/$defs/audience" },
           "iat": { "$ref": "#/$defs/numericDate" },
           "exp": { "$ref": "#/$defs/numericDate" },
           "jti": { "$ref": "#/$defs/uuid" },
           "wid": { "$ref": "#/$defs/uuid" },
           "task": { "$ref": "#/$defs/task" },
           "cap": {
             "type": "array",
             "minItems": 1,
             "items": { "$ref": "#/$defs/capability" }
           },
           "oversight": { "$ref": "#/$defs/oversight" },
           "del": { "$ref": "#/$defs/delegation" }
         }
       },
       "phase1": {
         "allOf": [{ "$ref": "#/$defs/commonClaims" }],
         "not": {
           "anyOf": [
             { "required": ["exec_act"] },
             { "required": ["exec_ts"] },
             { "required": ["status"] }
           ]
         }
       },



Nennemann               Expires 21 November 2026               [Page 43]

Internet-Draft                     ACT                          May 2026


       "phase2": {
         "allOf": [{ "$ref": "#/$defs/commonClaims" }],
         "required": ["exec_act", "pred", "exec_ts", "status"],
         "properties": {
           "exec_act": { "$ref": "#/$defs/actionName" },
           "pred": {
             "type": "array",
             "items": { "$ref": "#/$defs/uuid" }
           },
           "inp_hash": { "type": "string" },
           "out_hash": { "type": "string" },
           "exec_ts": { "$ref": "#/$defs/numericDate" },
           "status": {
             "type": "string",
             "enum": ["completed", "failed", "partial"]
           },
           "err": { "$ref": "#/$defs/error" }
         }
       }
     }
   }

Appendix B: Test Vectors

   All vectors in this appendix are produced by the reference
   implementation using fixed Ed25519 seeds and fixed identifiers, and
   are therefore reproducible.  The base timestamp (iat) is 1772064000
   (2026-02-26T00:00:00Z).  Long Base64url values are wrapped for
   display only; line breaks are not part of the value.

B.0.  Key Material

   Three Ed25519 key pairs are used, identified by kid.  Keys are given
   in JWK [RFC7517] form using the Ed25519 OKP encoding [RFC8037]; "d"
   is the private seed and "x" is the public key, both Base64url-
   encoded.  These seeds are recognizable test patterns and MUST NOT be
   used in production.

   {
     "kty": "OKP",
     "crv": "Ed25519",
     "kid": "iss-key",
     "d": "AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8",
     "x": "A6EHv_POEL4dcN0Y50vAmWfk1jCbpQ1fHdyGZBJVMbg"
   }






Nennemann               Expires 21 November 2026               [Page 44]

Internet-Draft                     ACT                          May 2026


   {
     "kty": "OKP",
     "crv": "Ed25519",
     "kid": "sub-key",
     "d": "ICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj8",
     "x": "Kay64UG8yvCyLhqU000LxzYeUm0L_hLIl5S8kyKWbdc"
   }

   {
     "kty": "OKP",
     "crv": "Ed25519",
     "kid": "agent-c-key",
     "d": "QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl8",
     "x": "JUO5L_EJVRFHatyDadtt3JM2ZaEZeN2hQE7hBmypVZ0"
   }

B.1.  Valid Phase 1 ACT: root mandate, Tier 1 (Ed25519), no delegation

   JOSE Header:

   {
     "alg": "EdDSA",
     "typ": "act+jwt",
     "kid": "iss-key"
   }

   JWT Claims:
























Nennemann               Expires 21 November 2026               [Page 45]

Internet-Draft                     ACT                          May 2026


   {
     "iss": "agent-issuer",
     "sub": "agent-subject",
     "aud": [
       "agent-subject",
       "https://ledger.example.com"
     ],
     "iat": 1772064000,
     "exp": 1772064900,
     "jti": "550e8400-e29b-41d4-a716-446655440001",
     "task": {
       "purpose": "validate_data",
       "data_sensitivity": "restricted"
     },
     "cap": [
       {
         "action": "read.data",
         "constraints": {
           "max_records": 10
         }
       },
       {
         "action": "write.result"
       }
     ],
     "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
     "del": {
       "depth": 0,
       "max_depth": 2,
       "chain": []
     }
   }

   JWS Compact Serialization:

   eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJpc3Mta2V5In0.
   eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
   IjpbImFnZW50LXN1YmplY3QiLCJodHRwczovL2xlZGdlci5leGFtcGxlLmNvbSJd
   LCJpYXQiOjE3NzIwNjQwMDAsImV4cCI6MTc3MjA2NDkwMCwianRpIjoiNTUwZTg0
   MDAtZTI5Yi00MWQ0LWE3MTYtNDQ2NjU1NDQwMDAxIiwidGFzayI6eyJwdXJwb3Nl
   IjoidmFsaWRhdGVfZGF0YSIsImRhdGFfc2Vuc2l0aXZpdHkiOiJyZXN0cmljdGVk
   In0sImNhcCI6W3siYWN0aW9uIjoicmVhZC5kYXRhIiwiY29uc3RyYWludHMiOnsi
   bWF4X3JlY29yZHMiOjEwfX0seyJhY3Rpb24iOiJ3cml0ZS5yZXN1bHQifV0sIndp
   ZCI6ImEwYjFjMmQzLWU0ZjUtNjc4OS1hYmNkLWVmMDEyMzQ1Njc4OSIsImRlbCI6
   eyJkZXB0aCI6MCwibWF4X2RlcHRoIjoyLCJjaGFpbiI6W119fQ._nVgyp4X0zYvy
   ylbyBgE_CWKAVdEMFgHjHIUkhxEsr83PQw_rzxNryDd179_KdkCo_kxWDbfmEQV-
   JA1-pknBA




Nennemann               Expires 21 November 2026               [Page 46]

Internet-Draft                     ACT                          May 2026


   Expected result: Accept.  The signature verifies under kid "iss-key"
   and all required Phase 1 claims are present.

B.2.  Valid Phase 2 ACT: completed execution (transition from B.1)

   JOSE Header:

   {
     "alg": "EdDSA",
     "typ": "act+jwt",
     "kid": "sub-key"
   }

   JWT Claims:





































Nennemann               Expires 21 November 2026               [Page 47]

Internet-Draft                     ACT                          May 2026


   {
     "iss": "agent-issuer",
     "sub": "agent-subject",
     "aud": [
       "agent-subject",
       "https://ledger.example.com"
     ],
     "iat": 1772064000,
     "exp": 1772064900,
     "jti": "550e8400-e29b-41d4-a716-446655440001",
     "task": {
       "purpose": "validate_data",
       "data_sensitivity": "restricted"
     },
     "cap": [
       {
         "action": "read.data",
         "constraints": {
           "max_records": 10
         }
       },
       {
         "action": "write.result"
       }
     ],
     "exec_act": "read.data",
     "pred": [],
     "exec_ts": 1772064300,
     "status": "completed",
     "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
     "del": {
       "depth": 0,
       "max_depth": 2,
       "chain": []
     },
     "inp_hash": "DHooOQxm8XoCuW4a2BOMC2ZP8VyzFYj1gRvKzRdfX_g",
     "out_hash": "n24FIk7teYuF6yXfVBqJ9THKIWuU9C0M5qlGlhLtx2U"
   }

   JWS Compact Serialization:











Nennemann               Expires 21 November 2026               [Page 48]

Internet-Draft                     ACT                          May 2026


   eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJzdWIta2V5In0.
   eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
   IjpbImFnZW50LXN1YmplY3QiLCJodHRwczovL2xlZGdlci5leGFtcGxlLmNvbSJd
   LCJpYXQiOjE3NzIwNjQwMDAsImV4cCI6MTc3MjA2NDkwMCwianRpIjoiNTUwZTg0
   MDAtZTI5Yi00MWQ0LWE3MTYtNDQ2NjU1NDQwMDAxIiwidGFzayI6eyJwdXJwb3Nl
   IjoidmFsaWRhdGVfZGF0YSIsImRhdGFfc2Vuc2l0aXZpdHkiOiJyZXN0cmljdGVk
   In0sImNhcCI6W3siYWN0aW9uIjoicmVhZC5kYXRhIiwiY29uc3RyYWludHMiOnsi
   bWF4X3JlY29yZHMiOjEwfX0seyJhY3Rpb24iOiJ3cml0ZS5yZXN1bHQifV0sImV4
   ZWNfYWN0IjoicmVhZC5kYXRhIiwicHJlZCI6W10sImV4ZWNfdHMiOjE3NzIwNjQz
   MDAsInN0YXR1cyI6ImNvbXBsZXRlZCIsIndpZCI6ImEwYjFjMmQzLWU0ZjUtNjc4
   OS1hYmNkLWVmMDEyMzQ1Njc4OSIsImRlbCI6eyJkZXB0aCI6MCwibWF4X2RlcHRo
   IjoyLCJjaGFpbiI6W119LCJpbnBfaGFzaCI6IkRIb29PUXhtOFhvQ3VXNGEyQk9N
   QzJaUDhWeXpGWWoxZ1J2S3pSZGZYX2ciLCJvdXRfaGFzaCI6Im4yNEZJazd0ZVl1
   RjZ5WGZWQnFKOVRIS0lXdVU5QzBNNXFsR2xoTHR4MlUifQ.ByEeEiMp2MwLHEeiF
   iaV-fRjJw37VdIWahoaGdtR3EnlRMxI01jN9-TuPnUSDqIAf8yfzbri3FTjb02zX
   h0LBA

   Expected result: Accept.  Phase 2 record; the signature verifies
   under kid "sub-key" and exec_act "read.data" is present in cap.

B.3.  Valid Phase 2 ACT: fan-in with two predecessor tasks

   JOSE Header:

   {
     "alg": "EdDSA",
     "typ": "act+jwt",
     "kid": "sub-key"
   }

   JWT Claims:




















Nennemann               Expires 21 November 2026               [Page 49]

Internet-Draft                     ACT                          May 2026


   {
     "iss": "agent-issuer",
     "sub": "agent-subject",
     "aud": "agent-subject",
     "iat": 1772064000,
     "exp": 1772064900,
     "jti": "550e8400-e29b-41d4-a716-446655440005",
     "task": {
       "purpose": "merge_results"
     },
     "cap": [
       {
         "action": "compute.result"
       }
     ],
     "exec_act": "compute.result",
     "pred": [
       "550e8400-e29b-41d4-a716-446655440003",
       "550e8400-e29b-41d4-a716-446655440004"
     ],
     "exec_ts": 1772064200,
     "status": "completed",
     "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
     "del": {
       "depth": 0,
       "max_depth": 1,
       "chain": []
     }
   }

   JWS Compact Serialization:

   eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJzdWIta2V5In0.
   eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
   IjoiYWdlbnQtc3ViamVjdCIsImlhdCI6MTc3MjA2NDAwMCwiZXhwIjoxNzcyMDY0
   OTAwLCJqdGkiOiI1NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMDUi
   LCJ0YXNrIjp7InB1cnBvc2UiOiJtZXJnZV9yZXN1bHRzIn0sImNhcCI6W3siYWN0
   aW9uIjoiY29tcHV0ZS5yZXN1bHQifV0sImV4ZWNfYWN0IjoiY29tcHV0ZS5yZXN1
   bHQiLCJwcmVkIjpbIjU1MGU4NDAwLWUyOWItNDFkNC1hNzE2LTQ0NjY1NTQ0MDAw
   MyIsIjU1MGU4NDAwLWUyOWItNDFkNC1hNzE2LTQ0NjY1NTQ0MDAwNCJdLCJleGVj
   X3RzIjoxNzcyMDY0MjAwLCJzdGF0dXMiOiJjb21wbGV0ZWQiLCJ3aWQiOiJhMGIx
   YzJkMy1lNGY1LTY3ODktYWJjZC1lZjAxMjM0NTY3ODkiLCJkZWwiOnsiZGVwdGgi
   OjAsIm1heF9kZXB0aCI6MSwiY2hhaW4iOltdfX0.Koikd5apdJ1LLfdl0n0-arQ4
   nDWbrygFImdE8QMKtWFwE35bIjIlr8ILXcr-0jDOBt0IJa8b_0yZROkUPlEgCA

   Expected result: Accept.  Phase 2 fan-in; pred lists the two
   predecessor jti values from the parallel branches.




Nennemann               Expires 21 November 2026               [Page 50]

Internet-Draft                     ACT                          May 2026


B.4.  Valid Phase 1 ACT: delegated mandate (depth 1)

   JOSE Header:

   {
     "alg": "EdDSA",
     "typ": "act+jwt",
     "kid": "iss-key"
   }

   JWT Claims:

   {
     "iss": "agent-issuer",
     "sub": "agent-c",
     "aud": "agent-c",
     "iat": 1772064010,
     "exp": 1772064600,
     "jti": "550e8400-e29b-41d4-a716-446655440006",
     "task": {
       "purpose": "delegated_read"
     },
     "cap": [
       {
         "action": "read.data",
         "constraints": {
           "max_records": 5
         }
       }
     ],
     "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
     "del": {
       "depth": 1,
       "max_depth": 2,
       "chain": [
         {
           "delegator": "agent-issuer",
           "jti": "550e8400-e29b-41d4-a716-446655440001",
           "sig": "cYYbPuSiYxFV1D45qBKkzUo2GZMjkVkN4IEnJt4433CN8MJ6sAEVy4Huqr4ebuF7fCKpvGijOidrOkfY-BJFCQ"
         }
       ]
     }
   }

   JWS Compact Serialization:






Nennemann               Expires 21 November 2026               [Page 51]

Internet-Draft                     ACT                          May 2026


   eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJpc3Mta2V5In0.
   eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1jIiwiYXVkIjoiYWdl
   bnQtYyIsImlhdCI6MTc3MjA2NDAxMCwiZXhwIjoxNzcyMDY0NjAwLCJqdGkiOiI1
   NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMDYiLCJ0YXNrIjp7InB1
   cnBvc2UiOiJkZWxlZ2F0ZWRfcmVhZCJ9LCJjYXAiOlt7ImFjdGlvbiI6InJlYWQu
   ZGF0YSIsImNvbnN0cmFpbnRzIjp7Im1heF9yZWNvcmRzIjo1fX1dLCJ3aWQiOiJh
   MGIxYzJkMy1lNGY1LTY3ODktYWJjZC1lZjAxMjM0NTY3ODkiLCJkZWwiOnsiZGVw
   dGgiOjEsIm1heF9kZXB0aCI6MiwiY2hhaW4iOlt7ImRlbGVnYXRvciI6ImFnZW50
   LWlzc3VlciIsImp0aSI6IjU1MGU4NDAwLWUyOWItNDFkNC1hNzE2LTQ0NjY1NTQ0
   MDAwMSIsInNpZyI6ImNZWWJQdVNpWXhGVjFENDVxQktrelVvMkdaTWprVmtONElF
   bkp0NDQzM0NOOE1KNnNBRVZ5NEh1cXI0ZWJ1RjdmQ0twdkdpak9pZHJPa2ZZLUJK
   RkNRIn1dfX0.k4SGmgQrAdUN_f-LsJVAL5A3Q-2NHllGaSx1WOmdbcRzvW2uOfct
   1K0e_zxnd_7UHvLClTE01kKiQ3zU1imtCQ

   Expected result: Accept.  Delegated mandate at depth 1; the delegated
   cap (max_records=5) is a subset of the parent cap (max_records=10).

B.5.  Valid Phase 2 ACT: delegated execution record

   JOSE Header:

   {
     "alg": "EdDSA",
     "typ": "act+jwt",
     "kid": "agent-c-key"
   }

   JWT Claims:























Nennemann               Expires 21 November 2026               [Page 52]

Internet-Draft                     ACT                          May 2026


   {
     "iss": "agent-issuer",
     "sub": "agent-c",
     "aud": "agent-c",
     "iat": 1772064010,
     "exp": 1772064600,
     "jti": "550e8400-e29b-41d4-a716-446655440006",
     "task": {
       "purpose": "delegated_read"
     },
     "cap": [
       {
         "action": "read.data",
         "constraints": {
           "max_records": 5
         }
       }
     ],
     "exec_act": "read.data",
     "pred": [],
     "exec_ts": 1772064350,
     "status": "completed",
     "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
     "del": {
       "depth": 1,
       "max_depth": 2,
       "chain": [
         {
           "delegator": "agent-issuer",
           "jti": "550e8400-e29b-41d4-a716-446655440001",
           "sig": "cYYbPuSiYxFV1D45qBKkzUo2GZMjkVkN4IEnJt4433CN8MJ6sAEVy4Huqr4ebuF7fCKpvGijOidrOkfY-BJFCQ"
         }
       ]
     }
   }

   JWS Compact Serialization:














Nennemann               Expires 21 November 2026               [Page 53]

Internet-Draft                     ACT                          May 2026


   eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJhZ2VudC1jLWtl
   eSJ9.eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1jIiwiYXVkIjo
   iYWdlbnQtYyIsImlhdCI6MTc3MjA2NDAxMCwiZXhwIjoxNzcyMDY0NjAwLCJqdGk
   iOiI1NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMDYiLCJ0YXNrIjp
   7InB1cnBvc2UiOiJkZWxlZ2F0ZWRfcmVhZCJ9LCJjYXAiOlt7ImFjdGlvbiI6InJ
   lYWQuZGF0YSIsImNvbnN0cmFpbnRzIjp7Im1heF9yZWNvcmRzIjo1fX1dLCJleGV
   jX2FjdCI6InJlYWQuZGF0YSIsInByZWQiOltdLCJleGVjX3RzIjoxNzcyMDY0MzU
   wLCJzdGF0dXMiOiJjb21wbGV0ZWQiLCJ3aWQiOiJhMGIxYzJkMy1lNGY1LTY3ODk
   tYWJjZC1lZjAxMjM0NTY3ODkiLCJkZWwiOnsiZGVwdGgiOjEsIm1heF9kZXB0aCI
   6MiwiY2hhaW4iOlt7ImRlbGVnYXRvciI6ImFnZW50LWlzc3VlciIsImp0aSI6IjU
   1MGU4NDAwLWUyOWItNDFkNC1hNzE2LTQ0NjY1NTQ0MDAwMSIsInNpZyI6ImNZWWJ
   QdVNpWXhGVjFENDVxQktrelVvMkdaTWprVmtONElFbkp0NDQzM0NOOE1KNnNBRVZ
   5NEh1cXI0ZWJ1RjdmQ0twdkdpak9pZHJPa2ZZLUJKRkNRIn1dfX0.dCUyOsyvrRA
   vM7m0WO6LBnIhijckknlbX3kVGxmkKlzekQmKTAJQbM5H2WbACOh3LpB9LW3hgCE
   luEjhd4laAw

   Expected result: Accept.  Phase 2 record for the delegated mandate;
   the signature verifies under kid "agent-c-key".

B.6.  Invalid: delegation depth exceeds maximum

   JOSE Header:

   {
     "alg": "EdDSA",
     "typ": "act+jwt",
     "kid": "iss-key"
   }

   JWT Claims:





















Nennemann               Expires 21 November 2026               [Page 54]

Internet-Draft                     ACT                          May 2026


   {
     "iss": "agent-issuer",
     "sub": "agent-subject",
     "aud": "agent-subject",
     "iat": 1772064000,
     "exp": 1772064900,
     "jti": "550e8400-e29b-41d4-a716-446655440008",
     "task": {
       "purpose": "bad_depth"
     },
     "cap": [
       {
         "action": "read.data"
       }
     ],
     "del": {
       "depth": 3,
       "max_depth": 2,
       "chain": [
         {
           "delegator": "a",
           "jti": "j1",
           "sig": "sig1"
         },
         {
           "delegator": "b",
           "jti": "j2",
           "sig": "sig2"
         },
         {
           "delegator": "c",
           "jti": "j3",
           "sig": "sig3"
         }
       ]
     }
   }

   JWS Compact Serialization:












Nennemann               Expires 21 November 2026               [Page 55]

Internet-Draft                     ACT                          May 2026


   eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJpc3Mta2V5In0.
   eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
   IjoiYWdlbnQtc3ViamVjdCIsImlhdCI6MTc3MjA2NDAwMCwiZXhwIjoxNzcyMDY0
   OTAwLCJqdGkiOiI1NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMDgi
   LCJ0YXNrIjp7InB1cnBvc2UiOiJiYWRfZGVwdGgifSwiY2FwIjpbeyJhY3Rpb24i
   OiJyZWFkLmRhdGEifV0sImRlbCI6eyJkZXB0aCI6MywibWF4X2RlcHRoIjoyLCJj
   aGFpbiI6W3siZGVsZWdhdG9yIjoiYSIsImp0aSI6ImoxIiwic2lnIjoic2lnMSJ9
   LHsiZGVsZWdhdG9yIjoiYiIsImp0aSI6ImoyIiwic2lnIjoic2lnMiJ9LHsiZGVs
   ZWdhdG9yIjoiYyIsImp0aSI6ImozIiwic2lnIjoic2lnMyJ9XX19.bhZ7ZaXG6GN
   q4vqquQPcxImFlu50rV8Ae16D06N_X9bRCu9pCiMcY2LTK9XRYWcKlRjUyBRVNJX
   02bFXJ5wGAA

   Expected result: Reject. del.depth (3) exceeds del.max_depth (2).

B.7.  Invalid: capability escalation in delegated mandate

   Expected result: Reject.  The delegated cap (max_records=100) is not
   a subset of the parent cap (max_records=10); privilege reduction is
   violated.  This vector is a delegation-creation check; no token is
   issued.

B.8.  Invalid: exec_act not present in cap

   JOSE Header:

   {
     "alg": "EdDSA",
     "typ": "act+jwt",
     "kid": "sub-key"
   }

   JWT Claims:



















Nennemann               Expires 21 November 2026               [Page 56]

Internet-Draft                     ACT                          May 2026


   {
     "iss": "agent-issuer",
     "sub": "agent-subject",
     "aud": "agent-subject",
     "iat": 1772064000,
     "exp": 1772064900,
     "jti": "550e8400-e29b-41d4-a716-446655440009",
     "task": {
       "purpose": "bad_exec"
     },
     "cap": [
       {
         "action": "read.data"
       }
     ],
     "exec_act": "delete.everything",
     "pred": [],
     "exec_ts": 1772064100,
     "status": "completed"
   }

   JWS Compact Serialization:

   eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJzdWIta2V5In0.
   eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
   IjoiYWdlbnQtc3ViamVjdCIsImlhdCI6MTc3MjA2NDAwMCwiZXhwIjoxNzcyMDY0
   OTAwLCJqdGkiOiI1NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMDki
   LCJ0YXNrIjp7InB1cnBvc2UiOiJiYWRfZXhlYyJ9LCJjYXAiOlt7ImFjdGlvbiI6
   InJlYWQuZGF0YSJ9XSwiZXhlY19hY3QiOiJkZWxldGUuZXZlcnl0aGluZyIsInBy
   ZWQiOltdLCJleGVjX3RzIjoxNzcyMDY0MTAwLCJzdGF0dXMiOiJjb21wbGV0ZWQi
   fQ.AI-K0abyWHyAUTxIUS22kqhmSdgfOVyLMHaOm6vauEd3YpoRQ8vdzJ2Oblk07
   qyXwR5pAlDewYOwCJTSmIK0Cg

   Expected result: Reject. exec_act "delete.everything" does not match
   any cap.action.

B.9.  Invalid: DAG cycle (pred references own jti)

   JOSE Header:

   {
     "alg": "EdDSA",
     "typ": "act+jwt",
     "kid": "sub-key"
   }

   JWT Claims:




Nennemann               Expires 21 November 2026               [Page 57]

Internet-Draft                     ACT                          May 2026


   {
     "iss": "agent-issuer",
     "sub": "agent-subject",
     "aud": "agent-subject",
     "iat": 1772064000,
     "exp": 1772064900,
     "jti": "550e8400-e29b-41d4-a716-44665544000a",
     "task": {
       "purpose": "cycle_test"
     },
     "cap": [
       {
         "action": "read.data"
       }
     ],
     "exec_act": "read.data",
     "pred": [
       "550e8400-e29b-41d4-a716-44665544000a"
     ],
     "exec_ts": 1772064100,
     "status": "completed"
   }

   JWS Compact Serialization:

   eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJzdWIta2V5In0.
   eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
   IjoiYWdlbnQtc3ViamVjdCIsImlhdCI6MTc3MjA2NDAwMCwiZXhwIjoxNzcyMDY0
   OTAwLCJqdGkiOiI1NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMGEi
   LCJ0YXNrIjp7InB1cnBvc2UiOiJjeWNsZV90ZXN0In0sImNhcCI6W3siYWN0aW9u
   IjoicmVhZC5kYXRhIn1dLCJleGVjX2FjdCI6InJlYWQuZGF0YSIsInByZWQiOlsi
   NTUwZTg0MDAtZTI5Yi00MWQ0LWE3MTYtNDQ2NjU1NDQwMDBhIl0sImV4ZWNfdHMi
   OjE3NzIwNjQxMDAsInN0YXR1cyI6ImNvbXBsZXRlZCJ9.9V4Pd5QoKBXLnBCAJne
   PR_QArbIdLAEYFkM0az0ATr_A8BqjQdCQm-zDxExszLBnSdVclHo1Ns25FSpzrDj
   VDg

   Expected result: Reject. pred references the record's own jti,
   forming a cycle.

B.10.  Invalid: missing predecessor task in DAG

   JOSE Header:

   {
     "alg": "EdDSA",
     "typ": "act+jwt",
     "kid": "sub-key"
   }



Nennemann               Expires 21 November 2026               [Page 58]

Internet-Draft                     ACT                          May 2026


   JWT Claims:

   {
     "iss": "agent-issuer",
     "sub": "agent-subject",
     "aud": "agent-subject",
     "iat": 1772064000,
     "exp": 1772064900,
     "jti": "550e8400-e29b-41d4-a716-44665544000b",
     "task": {
       "purpose": "missing_parent"
     },
     "cap": [
       {
         "action": "read.data"
       }
     ],
     "exec_act": "read.data",
     "pred": [
       "nonexistent-parent-jti"
     ],
     "exec_ts": 1772064100,
     "status": "completed"
   }

   JWS Compact Serialization:

   eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJzdWIta2V5In0.
   eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
   IjoiYWdlbnQtc3ViamVjdCIsImlhdCI6MTc3MjA2NDAwMCwiZXhwIjoxNzcyMDY0
   OTAwLCJqdGkiOiI1NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMGIi
   LCJ0YXNrIjp7InB1cnBvc2UiOiJtaXNzaW5nX3BhcmVudCJ9LCJjYXAiOlt7ImFj
   dGlvbiI6InJlYWQuZGF0YSJ9XSwiZXhlY19hY3QiOiJyZWFkLmRhdGEiLCJwcmVk
   IjpbIm5vbmV4aXN0ZW50LXBhcmVudC1qdGkiXSwiZXhlY190cyI6MTc3MjA2NDEw
   MCwic3RhdHVzIjoiY29tcGxldGVkIn0.PSxajLuiL_b2cAZT2Eab5UR-nZDMs2BE
   jEkhzeId8vQzYkldQb9h5xrvvRD9lsjglzda4wscpU-IoW4m8Kw4Cw

   Expected result: Reject. pred references a jti that is not a
   previously verified task.

B.11.  Invalid: tampered payload

   JOSE Header:








Nennemann               Expires 21 November 2026               [Page 59]

Internet-Draft                     ACT                          May 2026


   {
     "alg": "EdDSA",
     "typ": "act+jwt",
     "kid": "iss-key"
   }

   JWT Claims:

   {
     "iss": "agent-issuer",
     "sub": "agent-subject",
     "aud": [
       "agent-subject",
       "https://ledger.example.com"
     ],
     "iat": 1772064000,
     "exp": 1772064900,
     "jti": "550e8400-e29b-41d4-a716-446655440001",
     "task": {
       "purpose": "validate_data",
       "tata_sensitivity": "restricted"
     },
     "cap": [
       {
         "action": "read.data",
         "constraints": {
           "max_records": 10
         }
       },
       {
         "action": "write.result"
       }
     ],
     "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
     "del": {
       "depth": 0,
       "max_depth": 2,
       "chain": []
     }
   }

   JWS Compact Serialization:









Nennemann               Expires 21 November 2026               [Page 60]

Internet-Draft                     ACT                          May 2026


   eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJpc3Mta2V5In0.
   eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
   IjpbImFnZW50LXN1YmplY3QiLCJodHRwczovL2xlZGdlci5leGFtcGxlLmNvbSJd
   LCJpYXQiOjE3NzIwNjQwMDAsImV4cCI6MTc3MjA2NDkwMCwianRpIjoiNTUwZTg0
   MDAtZTI5Yi00MWQ0LWE3MTYtNDQ2NjU1NDQwMDAxIiwidGFzayI6eyJwdXJwb3Nl
   IjoidmFsaWRhdGVfZGF0YSIsInRhdGFfc2Vuc2l0aXZpdHkiOiJyZXN0cmljdGVk
   In0sImNhcCI6W3siYWN0aW9uIjoicmVhZC5kYXRhIiwiY29uc3RyYWludHMiOnsi
   bWF4X3JlY29yZHMiOjEwfX0seyJhY3Rpb24iOiJ3cml0ZS5yZXN1bHQifV0sIndp
   ZCI6ImEwYjFjMmQzLWU0ZjUtNjc4OS1hYmNkLWVmMDEyMzQ1Njc4OSIsImRlbCI6
   eyJkZXB0aCI6MCwibWF4X2RlcHRoIjoyLCJjaGFpbiI6W119fQ._nVgyp4X0zYvy
   ylbyBgE_CWKAVdEMFgHjHIUkhxEsr83PQw_rzxNryDd179_KdkCo_kxWDbfmEQV-
   JA1-pknBA

   Expected result: Reject.  The signature does not verify; one byte of
   the claims segment was altered after signing.

B.12.  Invalid: expired token

   JOSE Header:

   {
     "alg": "EdDSA",
     "typ": "act+jwt",
     "kid": "iss-key"
   }

   JWT Claims:

   {
     "iss": "agent-issuer",
     "sub": "agent-subject",
     "aud": "agent-subject",
     "iat": 1772060400,
     "exp": 1772061300,
     "jti": "550e8400-e29b-41d4-a716-44665544000c",
     "task": {
       "purpose": "expired_test"
     },
     "cap": [
       {
         "action": "read.data"
       }
     ]
   }

   JWS Compact Serialization:





Nennemann               Expires 21 November 2026               [Page 61]

Internet-Draft                     ACT                          May 2026


   eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJpc3Mta2V5In0.
   eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
   IjoiYWdlbnQtc3ViamVjdCIsImlhdCI6MTc3MjA2MDQwMCwiZXhwIjoxNzcyMDYx
   MzAwLCJqdGkiOiI1NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMGMi
   LCJ0YXNrIjp7InB1cnBvc2UiOiJleHBpcmVkX3Rlc3QifSwiY2FwIjpbeyJhY3Rp
   b24iOiJyZWFkLmRhdGEifV19.mK6-ML3hkOlAVvHeG5PPnvr3do9KT-1g4OISjlB
   WrcHac-JPWnzOSZmMiESIKA6mXNSYVxnTDLZyFbAPglrCAQ

   Expected result: Reject. exp is in the past (expired 45 minutes
   before the verification time).

B.13.  Invalid: audience mismatch

   JOSE Header:

   {
     "alg": "EdDSA",
     "typ": "act+jwt",
     "kid": "iss-key"
   }

   JWT Claims:

   {
     "iss": "agent-issuer",
     "sub": "wrong-agent",
     "aud": "wrong-agent",
     "iat": 1772064000,
     "exp": 1772064900,
     "jti": "550e8400-e29b-41d4-a716-44665544000d",
     "task": {
       "purpose": "wrong_aud_test"
     },
     "cap": [
       {
         "action": "read.data"
       }
     ]
   }

   JWS Compact Serialization:










Nennemann               Expires 21 November 2026               [Page 62]

Internet-Draft                     ACT                          May 2026


   eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJpc3Mta2V5In0.
   eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJ3cm9uZy1hZ2VudCIsImF1ZCI6
   Indyb25nLWFnZW50IiwiaWF0IjoxNzcyMDY0MDAwLCJleHAiOjE3NzIwNjQ5MDAs
   Imp0aSI6IjU1MGU4NDAwLWUyOWItNDFkNC1hNzE2LTQ0NjY1NTQ0MDAwZCIsInRh
   c2siOnsicHVycG9zZSI6Indyb25nX2F1ZF90ZXN0In0sImNhcCI6W3siYWN0aW9u
   IjoicmVhZC5kYXRhIn1dfQ.8vP0564UjixScto2vo0MX5wt5TX_dP9ilDB8aPEpl
   WnOovQgQUHywL0_BqSaqgM7NrtjGnITmVoJ6RtUrjV8CA

   Expected result: Reject. aud does not include the verifier identity.

B.14.  Invalid: Phase 2 record signed by wrong key

   JOSE Header:

   {
     "alg": "EdDSA",
     "typ": "act+jwt",
     "kid": "sub-key"
   }

   JWT Claims:






























Nennemann               Expires 21 November 2026               [Page 63]

Internet-Draft                     ACT                          May 2026


   {
     "iss": "agent-issuer",
     "sub": "agent-subject",
     "aud": [
       "agent-subject",
       "https://ledger.example.com"
     ],
     "iat": 1772064000,
     "exp": 1772064900,
     "jti": "550e8400-e29b-41d4-a716-446655440001",
     "task": {
       "purpose": "validate_data",
       "data_sensitivity": "restricted"
     },
     "cap": [
       {
         "action": "read.data",
         "constraints": {
           "max_records": 10
         }
       },
       {
         "action": "write.result"
       }
     ],
     "exec_act": "read.data",
     "pred": [],
     "exec_ts": 1772064300,
     "status": "completed",
     "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
     "del": {
       "depth": 0,
       "max_depth": 2,
       "chain": []
     }
   }

   JWS Compact Serialization:













Nennemann               Expires 21 November 2026               [Page 64]

Internet-Draft                     ACT                          May 2026


   eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJzdWIta2V5In0.
   eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
   IjpbImFnZW50LXN1YmplY3QiLCJodHRwczovL2xlZGdlci5leGFtcGxlLmNvbSJd
   LCJpYXQiOjE3NzIwNjQwMDAsImV4cCI6MTc3MjA2NDkwMCwianRpIjoiNTUwZTg0
   MDAtZTI5Yi00MWQ0LWE3MTYtNDQ2NjU1NDQwMDAxIiwidGFzayI6eyJwdXJwb3Nl
   IjoidmFsaWRhdGVfZGF0YSIsImRhdGFfc2Vuc2l0aXZpdHkiOiJyZXN0cmljdGVk
   In0sImNhcCI6W3siYWN0aW9uIjoicmVhZC5kYXRhIiwiY29uc3RyYWludHMiOnsi
   bWF4X3JlY29yZHMiOjEwfX0seyJhY3Rpb24iOiJ3cml0ZS5yZXN1bHQifV0sImV4
   ZWNfYWN0IjoicmVhZC5kYXRhIiwicHJlZCI6W10sImV4ZWNfdHMiOjE3NzIwNjQz
   MDAsInN0YXR1cyI6ImNvbXBsZXRlZCIsIndpZCI6ImEwYjFjMmQzLWU0ZjUtNjc4
   OS1hYmNkLWVmMDEyMzQ1Njc4OSIsImRlbCI6eyJkZXB0aCI6MCwibWF4X2RlcHRo
   IjoyLCJjaGFpbiI6W119fQ.rTp6oHlLzG32Ex6P08rAafhmjzRdwQTjwgU1Cod1a
   kFy3x5KpaX5fkfeCiK5i0D6HAtwUYR61_HlBWCcJj5_BA

   Expected result: Reject.  The Phase 2 record claims kid "sub-key" but
   was signed with the issuer's private key; the signature does not
   verify.

B.15.  Invalid: unsigned token (alg "none")

   JWS Compact Serialization:

   eyJhbGciOiJub25lIiwidHlwIjoiYWN0K2p3dCIsImtpZCI6ImsifQ.eyJpc3MiO
   iJhIiwic3ViIjoiYiJ9.

   Expected result: Reject.  The JOSE header alg is "none"; unsigned
   tokens MUST NOT be accepted.

Appendix C: Deployment Scenarios

C.1.  Minimal Deployment (Zero Infrastructure)

   Two organizations exchange pre-shared public keys via secure email.
   Each agent signs Phase 1 mandates and Phase 2 records with its
   Ed25519 key.  No ledger, no external services.  Suitable for
   development and low-risk workflows.

   Limitation: No non-equivocation (Section 11.5).

C.2.  Regulated Deployment with Hash-Chained Ledger

   Phase 2 ACTs are submitted to a shared append-only ledger with hash-
   chaining.  Each recorded ACT extends a cryptographic chain, providing
   tamper evidence for each ACT and the chain as a whole.  The ledger is
   shared between all regulated parties participating in the workflow.
   Suitable for DORA compliance.





Nennemann               Expires 21 November 2026               [Page 65]

Internet-Draft                     ACT                          May 2026


C.3.  High-Assurance Cross-Organizational Deployment

   Phase 2 ACTs are anchored to a SCITT Transparency Service.  SCITT
   receipts are attached to the audit record as non-equivocation proofs.
   DID-based agent identities (Tier 3) enable self-sovereign key
   management without shared CA infrastructure.

C.4.  WIMSE Environment Integration

   In environments where WIMSE is already deployed, ACT-Mandate and ACT-
   Record headers are carried alongside the WIMSE Workload-Identity
   header.  The ECT and ACT serve different purposes: the ECT records
   workload-level execution in WIMSE terms; the ACT records the
   authorization provenance and capability constraints that governed the
   action.

Acknowledgments

   The author thanks the IETF WIMSE, OAuth, and SCITT working groups for
   foundational work on workload identity, delegated authorization, and
   transparent supply chain records that informs this specification.

Author's Address

   Christian Nennemann
   Independent Researcher
   Email: ietf@nennemann.de
























Nennemann               Expires 21 November 2026               [Page 66]
