Final draft-nennemann-wimse-ect-00 with peer review feedback

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

draft-nennemann-wimse-ect-00.md

@@ -32,10 +32,7 @@ normative:
   I-D.ietf-wimse-s2s-protocol:
 
 informative:
-  RFC3552:
   RFC8693:
-  RFC9421:
-  I-D.ni-wimse-ai-agent-identity:
   SPIFFE:
     title: "Secure Production Identity Framework for Everyone (SPIFFE)"
     target: https://spiffe.io/docs/latest/spiffe-about/overview/
@@ -53,73 +50,26 @@ informative:
 
 --- abstract
 
-This document defines Execution Context Tokens (ECTs), an extension
+This document defines Execution Context Tokens (ECTs), a JWT-based
-to the Workload Identity in Multi System Environments (WIMSE)
+extension to the WIMSE architecture that records task execution
-architecture for distributed agentic workflows.  ECTs provide
+across distributed agentic workflows.  Each ECT is a signed record
-signed, structured records of task execution order across
+of a single task, linked to predecessor tasks through a directed
-agent-to-agent communication.  By extending WIMSE Workload Identity
+acyclic graph (DAG).  ECTs reuse the WIMSE signing model and are
-Tokens with execution context claims in JSON Web Token (JWT)
+transported in a new Execution-Context HTTP header field alongside
-format, this specification enables systems to maintain structured
+existing WIMSE identity headers.
-audit trails of agent execution.  ECTs use a directed acyclic
-graph (DAG) structure to represent task dependencies and integrate
-with WIMSE Workload Identity Tokens (WIT) using the same signing
-model and cryptographic primitives.  A new HTTP header field,
-Execution-Context, is defined for transporting ECTs alongside
-existing WIMSE headers.
 
 --- middle
 
 # Introduction
 
-## Motivation
+The WIMSE framework {{I-D.ietf-wimse-arch}} and its service-to-
-
+service protocol {{I-D.ietf-wimse-s2s-protocol}} authenticate
-The Workload Identity in Multi System Environments (WIMSE)
+workloads across call chains but do not record what those
-framework {{I-D.ietf-wimse-arch}} provides robust workload
+workloads actually did.  This document defines Execution Context
-authentication through Workload Identity Tokens (WIT) and Workload
+Tokens (ECTs), a JWT-based extension that fills the gap between
-Proof Tokens (WPT).  The WIMSE service-to-service protocol
+workload identity and execution accountability.  Each ECT is a
-{{I-D.ietf-wimse-s2s-protocol}} defines how workloads authenticate
+signed record of a single task, linked to predecessor tasks
-each other across call chains using the Workload-Identity and
+through a directed acyclic graph (DAG).
-Workload-Proof-Token HTTP headers.
-
-However, workload identity alone does not address execution
-accountability.  Knowing who performed an action does not record
-what was done or in what order.
-
-Regulated environments increasingly deploy autonomous agents that
-coordinate across organizational boundaries.  Domains such as
-healthcare, finance, and logistics require structured, auditable
-records of automated decision-making and execution.
-
-This document defines an extension to the WIMSE architecture that
-addresses the gap between workload identity and execution
-accountability.  WIMSE authenticates agents; this extension records
-what they did and in what order.
-
-As identified in {{I-D.ni-wimse-ai-agent-identity}}, call context
-in agentic workflows needs to be visible and preserved.  ECTs
-provide a mechanism to address this requirement with cryptographic
-assurances.
-
-## Problem Statement
-
-Three core gaps exist in current approaches to regulated agentic
-systems:
-
-1.  WIMSE authenticates agents but does not record what they
-    actually did.  A WIT proves "Agent A is authorized" but not
-    "Agent A executed Task X, producing Output Z."
-
-2.  No standard mechanism exists to cryptographically order and
-    link task execution across a multi-agent workflow.
-
-3.  No mechanism exists to reconstruct the complete execution
-    history of a distributed workflow for audit purposes.
-
-Existing observability tools such as distributed tracing
-{{OPENTELEMETRY}} provide visibility for debugging and monitoring
-but do not provide cryptographic assurances.  Tracing data is not
-cryptographically signed, not tamper-evident, and not designed for
-regulatory audit scenarios.
 
 ## Scope and Applicability
 
@@ -127,8 +77,6 @@ This document defines:
 
 - The Execution Context Token (ECT) format ({{ect-format}})
 - DAG structure for task dependency ordering ({{dag-validation}})
-- Integration with the WIMSE identity framework
-  ({{wimse-integration}})
 - An HTTP header for ECT transport ({{http-header}})
 - Audit ledger interface requirements ({{ledger-interface}})
 
@@ -178,104 +126,6 @@ Trust Domain:
   shared identity issuer, corresponding to a SPIFFE {{SPIFFE}}
   trust domain.
 
-# WIMSE Architecture Integration {#wimse-integration}
-
-## WIMSE Foundation
-
-The WIMSE architecture {{I-D.ietf-wimse-arch}} defines:
-
-- Workload Identity Tokens (WIT) that prove a workload's identity
-  within a trust domain ("I am Agent X in trust domain Y")
-- Workload Proof Tokens (WPT) that prove possession of the private
-  key associated with a WIT ("I control the key for Agent X")
-- Multi-hop authentication via the service-to-service protocol
-  {{I-D.ietf-wimse-s2s-protocol}}
-
-The following execution accountability needs are complementary to
-the WIMSE scope and are not addressed by workload identity alone:
-
-- Recording what agents actually do with their authenticated
-  identity
-- Maintaining structured execution records
-- Linking actions to their predecessors with cryptographic assurance
-
-## Extension Model
-
-ECTs extend WIMSE by adding an execution accountability layer
-between the identity layer and the application layer:
-
-~~~ ascii-art
-+--------------------------------------------------+
-|  WIMSE Layer (Identity)                          |
-|    WIT: "I am Agent X (spiffe://td/agent/x)"    |
-|    WPT: "I prove I control the key for Agent X"  |
-+--------------------------------------------------+
-                       |
-                       v
-+--------------------------------------------------+
-|  ECT Layer (Execution Accountability) [This Spec]|
-|    ECT: "Task executed, dependencies met,        |
-|          inputs/outputs hashed"                   |
-+--------------------------------------------------+
-                       |
-                       v
-+--------------------------------------------------+
-|  Optional: Audit Ledger (Immutable Record)       |
-|    "ECTs MAY be appended to an audit ledger"     |
-+--------------------------------------------------+
-~~~
-{: #fig-layers title="WIMSE Extension Architecture Layers"}
-
-This extension reuses the WIMSE signing model, extends JWT claims
-using standard JWT extensibility {{RFC7519}}, and maintains WIMSE
-concepts including trust domains and workload identifiers.
-
-## Integration Points {#integration-points}
-
-An ECT integrates with the WIMSE identity framework through the
-following mechanisms:
-
-- The ECT JOSE header "kid" parameter MUST reference the public
-  key identifier from the agent's WIT.
-
-- In WIMSE deployments, the ECT "iss" claim SHOULD use the WIMSE
-  workload identifier format (a SPIFFE ID {{SPIFFE}}).
-
-- The ECT MUST be signed with the same private key associated
-  with the agent's WIT.
-
-- The ECT signing algorithm (JOSE header "alg" parameter) MUST
-  match the algorithm used in the corresponding WIT.
-
-When an agent makes an HTTP request to another agent, the
-Execution-Context header is carried alongside WIMSE identity
-headers:
-
-~~~ ascii-art
-HTTP Request from Agent A to Agent B:
-  Workload-Identity:    <WIT for Agent A>
-  Execution-Context:    <ECT recording what A did>
-~~~
-{: #fig-http-headers title="HTTP Header Stacking"}
-
-When a Workload Proof Token (WPT) is available per
-{{I-D.ietf-wimse-s2s-protocol}}, agents SHOULD include it
-alongside the WIT and ECT.  ECT verification does not depend
-on the presence of a WPT; the ECT is independently verifiable
-via the WIT public key.
-
-The receiving agent (Agent B) verifies in order:
-
-1.  WIT (WIMSE layer): Verifies Agent A's identity within the
-    trust domain.  WPT verification, if present, per
-    {{I-D.ietf-wimse-s2s-protocol}}.
-
-2.  ECT (this extension): Records what Agent A did and what
-    precedent tasks exist.
-
-3.  Ledger (if deployed): Appends the verified ECT to the audit
-    ledger.
-
 # Execution Context Token Format {#ect-format}
 
 An Execution Context Token is a JSON Web Token (JWT) {{RFC7519}}
@@ -284,6 +134,14 @@ JWS Compact Serialization (the base64url-encoded
 `header.payload.signature` format) so that they can be carried in
 a single HTTP header value.
 
+ECTs reuse the WIMSE signing model.  The ECT MUST be signed with
+the same private key associated with the agent's WIT.  The JOSE
+header "kid" parameter MUST reference the public key identifier
+from the agent's WIT, and the "alg" parameter MUST match the
+algorithm used in the corresponding WIT.  In WIMSE deployments,
+the ECT "iss" claim SHOULD use the WIMSE workload identifier
+format (a SPIFFE ID {{SPIFFE}}).
+
 ## JOSE Header {#jose-header}
 
 The ECT JOSE header MUST contain the following parameters:
@@ -317,13 +175,9 @@ kid:
 
 ## JWT Claims {#jwt-claims}
 
-The ECT payload contains both WIMSE-compatible standard JWT claims
-and execution context claims defined by this specification.
-
 ### Standard JWT Claims
 
-The following standard JWT claims {{RFC7519}} MUST be present in
+An ECT MUST contain the following standard JWT claims {{RFC7519}}:
-every ECT:
 
 iss:
 : REQUIRED.  StringOrURI.  A URI identifying the issuer of the
@@ -335,59 +189,29 @@ iss:
 
 aud:
 : REQUIRED.  StringOrURI or array of StringOrURI.  The intended
-  recipient(s) of the ECT.  Because ECTs serve as both inter-agent
+  recipient(s) of the ECT.  The "aud" claim SHOULD contain the
-  messages and audit records, the "aud" claim SHOULD contain the
+  identifiers of all entities that will verify the ECT.  When
-  identifiers of all entities that will verify the ECT.  In
+  an ECT must be verified by both the next agent and the audit
-  practice this means:
+  ledger independently, "aud" MUST be an array containing both
-
+  identifiers.  Each verifier checks that its own identity
-  *  **Point-to-point delivery**: when an ECT is sent from one
+  appears in "aud".
-     agent to a single next agent, "aud" contains that agent's
-     workload identity.  The receiving agent verifies the ECT and
-     forwards it to the ledger on behalf of the issuer.
-
-  *  **Direct-to-ledger submission**: when an ECT is submitted
-     directly to the audit ledger (e.g., after a join or at
-     workflow completion), "aud" contains the ledger's identity.
-
-  *  **Multi-audience**: when an ECT must be verified by both the
-     next agent and the ledger independently, "aud" MUST be an
-     array containing both identifiers (e.g.,
-     \["spiffe://example.com/agent/next",
-     "spiffe://example.com/system/ledger"\]).  Each verifier checks
-     that its own identity appears in the array.
-
-  In multi-parent (join) scenarios where a task depends on ECTs
-  from multiple parent agents, the joining agent creates a new ECT
-  with the parent task IDs in "par".  The "aud" of this new ECT
-  is set according to the rules above based on where the ECT will
-  be delivered — it is independent of the "aud" values in the
-  parent ECTs.
 
 iat:
 : REQUIRED.  NumericDate.  The time at which the ECT was issued.
-  The ECT records a completed action, so the "iat" value reflects
-  when the record was created, not when task execution began.
 
 exp:
 : REQUIRED.  NumericDate.  The expiration time of the ECT.
-  Implementations SHOULD set this to 5 to 15 minutes after "iat"
+  Implementations SHOULD set this to 5 to 15 minutes after "iat".
-  to limit the replay window while allowing for reasonable clock
-  skew and processing time.
-
-The standard JWT "nbf" (Not Before) claim is not used in ECTs
-because ECTs record completed actions and are valid immediately
-upon issuance.
 
 jti:
-: REQUIRED.  String.  A globally unique identifier for both the
+: REQUIRED.  String.  A unique identifier for both the ECT and
-  ECT and the task it records, in UUID format {{RFC9562}}.  Since
+  the task it records, in UUID format {{RFC9562}}.  The "jti"
-  each ECT represents exactly one task, "jti" serves as both the
+  serves as both the token identifier (for replay detection) and
-  token identifier (for replay detection) and the task identifier
+  the task identifier (for DAG parent references in "par").
-  (for DAG parent references in "par").  Receivers MUST reject
+  Receivers MUST reject ECTs whose "jti" has already been seen
-  ECTs whose "jti" has already been seen within the expiration
+  within the expiration window.  When "wid" is present,
-  window.  When "wid" is present, uniqueness is scoped to the
+  uniqueness is scoped to the workflow; when "wid" is absent,
-  workflow; when "wid" is absent, uniqueness MUST be enforced
+  uniqueness MUST be enforced globally across the ECT store.
-  globally across the ECT store.
 
 ### Execution Context {#exec-claims}
 
@@ -401,22 +225,15 @@ wid:
 exec_act:
 : REQUIRED.  String.  The action or task type identifier describing
   what the agent performed (e.g., "process_payment",
-  "validate_safety", "calculate_dosage").  Note: this claim is
+  "validate_safety").  This claim name avoids collision with the
-  intentionally named "exec_act" rather than "act" to avoid
+  "act" (Actor) claim registered by {{RFC8693}}.
-  collision with the "act" (Actor) claim registered by
-  {{RFC8693}}.
 
 par:
 : REQUIRED.  Array of strings.  Parent task identifiers
   representing DAG dependencies.  Each element MUST be the "jti"
   value of a previously verified ECT.  An empty array indicates
   a root task with no dependencies.  A workflow MAY contain
-  multiple root tasks.  Parent ECTs may have passed their own
+  multiple root tasks.
-  "exp" time; ECT expiration applies to the verification window
-  of the ECT itself, not to its validity as a parent reference
-  in the ECT store.  Note: "par" is not a registered JWT claim
-  and does not conflict with OAuth Pushed Authorization Requests
-  (RFC 9126), which defines an endpoint, not a token claim.
 
 ### Data Integrity {#data-integrity-claims}
 
@@ -426,10 +243,9 @@ inputs and outputs without revealing the data itself:
 inp_hash:
 : OPTIONAL.  String.  The base64url encoding (without padding) of
   the SHA-256 hash of the input data, computed over the raw octets
-  of the input.  This follows the same fixed-algorithm pattern
+  of the input.  SHA-256 is the mandatory algorithm with no
-  used by the DPoP "ath" claim {{RFC9449}} and the WIMSE WPT
+  algorithm prefix in the value, consistent with {{RFC9449}} and
-  "tth" claim {{I-D.ietf-wimse-s2s-protocol}}: SHA-256 is the
+  {{I-D.ietf-wimse-s2s-protocol}}.
-  mandatory algorithm with no algorithm prefix in the value.
 
 out_hash:
 : OPTIONAL.  String.  The base64url encoding (without padding) of
@@ -440,24 +256,12 @@ out_hash:
 
 ext:
 : OPTIONAL.  Object.  A general-purpose extension object for
-  domain-specific claims not defined by this specification.  The
+  domain-specific claims not defined by this specification.
-  short name "ext" follows the JWT convention of concise claim
+  Implementations that do not understand extension claims MUST
-  names and is chosen over alternatives like "extensions" for
+  ignore them.  Extension key names SHOULD use reverse domain
-  compactness.  Implementations that do not understand extension
+  notation (e.g., "com.example.custom_field") to avoid
-  claims MUST ignore them.
+  collisions.  The serialized "ext" object SHOULD NOT exceed
-
+  4096 bytes and SHOULD NOT exceed a nesting depth of 5 levels.
-To avoid key collisions between different domains, extension
-key names SHOULD use reverse domain notation (e.g.,
-"com.example.custom_field") to avoid collisions between
-independently developed extensions.  To prevent abuse and
-excessive token size, the serialized JSON representation of
-the "ext" object SHOULD NOT exceed 4096 bytes, and the JSON
-nesting depth within the "ext" object SHOULD NOT exceed 5
-levels.  Implementations SHOULD reject ECTs whose "ext" claim
-exceeds these limits.
-
-Extension keys for domain-specific use cases MAY be defined in
-future documents.
 
 ## Complete ECT Example
 
@@ -498,7 +302,9 @@ parts separated by period (".") characters.
 
 An agent sending a request to another agent includes the
 Execution-Context header alongside the WIMSE Workload-Identity
-header:
+header.  When a Workload Proof Token (WPT) is available per
+{{I-D.ietf-wimse-s2s-protocol}}, agents SHOULD include it
+alongside the WIT and ECT.
 
 ~~~
 GET /api/safety-check HTTP/1.1
@@ -522,19 +328,10 @@ subsequent ECT.
 
 # DAG Validation {#dag-validation}
 
-## Overview
-
 ECTs form a Directed Acyclic Graph (DAG) where each task
-references its parent tasks via the "par" claim.  This structure
+references its parent tasks via the "par" claim.  DAG validation
-provides a cryptographically signed record of execution ordering,
+is performed against the ECT store — either an audit ledger or
-enabling auditors to reconstruct the complete workflow and verify
+the set of parent ECTs received inline.
-that required predecessor tasks were recorded before dependent
-tasks.
-
-DAG validation is performed against the ECT store — either an
-audit ledger or the set of parent ECTs received inline.
-
-## Validation Rules
 
 When receiving and verifying an ECT, implementations MUST perform
 the following DAG validation steps:
@@ -574,28 +371,10 @@ implementations SHOULD enforce a maximum ancestor traversal limit
 (RECOMMENDED: 10000 nodes).  If the limit is reached before cycle
 detection completes, the ECT SHOULD be rejected.
 
-## Handling Unavailable Parent ECTs
+In distributed deployments, a parent ECT may not yet be available
-
+locally due to replication lag.  Implementations MAY defer
-In distributed deployments, a parent ECT referenced in the "par"
+validation to allow parent ECTs to arrive, but MUST NOT treat
-array may not yet be available in the local ECT store at the time
+the ECT as verified until all parent references are resolved.
-of validation — for example, due to replication lag in a
-distributed ledger or out-of-order message delivery.
-
-Implementations MUST distinguish between two cases:
-
-1.  Parent not found and definitively absent: The parent "jti"
-    does not exist in any accessible ECT store.  The ECT MUST be
-    rejected.
-
-2.  Parent not yet available: The parent "jti" is not present
-    locally but may arrive due to known replication delays.
-    Implementations MAY defer validation for a bounded period
-    (RECOMMENDED: no more than 60 seconds).
-
-Deferred ECTs MUST NOT be treated as verified until all parent
-references are resolved.  If any parent reference remains
-unresolved after the deferral period or after the ECT's own "exp"
-time (whichever comes first), the ECT MUST be rejected.
 
 # Signature and Token Verification {#verification}
 
@@ -701,21 +480,13 @@ workflow agents to reduce the risk of collusion.
 
 # Security Considerations
 
-This section addresses security considerations following the
-guidance in {{RFC3552}}.
-
 ## Threat Model
 
-The following threat actors are considered:
+The threat model considers: (1) a malicious agent that creates
-
+false ECT claims, (2) an agent whose private key has been
-- Malicious agent (insider threat): An agent within the trust
+compromised, (3) a ledger tamperer attempting to modify recorded
-  domain that intentionally creates false ECT claims.
+entries, and (4) a time manipulator altering timestamps to affect
-- Compromised agent (external attacker): An agent whose private
+perceived ordering.
-  key has been obtained by an external attacker.
-- Ledger tamperer: An entity attempting to modify or delete ledger
-  entries after they have been recorded.
-- Time manipulator: An entity attempting to manipulate timestamps
-  to alter perceived execution ordering.
 
 ## Self-Assertion Limitation {#self-assertion-limitation}
 
@@ -732,20 +503,9 @@ ECTs do not independently verify that:
 
 The trustworthiness of ECT claims depends on the trustworthiness
 of the signing agent and the integrity of the broader deployment
-environment.
+environment.  ECTs provide a technical mechanism for execution
-
+recording; they do not by themselves satisfy any specific
-## Organizational Prerequisites
+regulatory compliance requirement.
-
-ECTs operate within a broader trust framework.  The guarantees
-provided by ECTs are only meaningful when the following
-organizational controls are in place:
-
-- Key management governance: Controls over who provisions agent
-  keys and how keys are protected.
-- Ledger integrity governance: The ledger is maintained by an
-  entity independent of the workflow agents.
-- Agent deployment governance: Agents are deployed and maintained
-  in a manner that preserves their integrity.
 
 ## Signature Verification
 
@@ -766,109 +526,55 @@ implement custom signature verification.
 
 ## Replay Attack Prevention
 
-ECTs include short expiration times (RECOMMENDED: 5-15 minutes) to
+ECTs include short expiration times (RECOMMENDED: 5-15 minutes)
-limit the window for replay attacks.  The "aud" claim restricts
+and audience restriction via "aud" to limit replay attacks.
-replay to unintended recipients: an ECT intended for Agent B
-will be rejected by Agent C.  The "iat" claim enables receivers to
-reject ECTs that are too old, even if not yet expired.
-
-The DAG structure provides additional replay protection: an ECT
-referencing parent tasks that already have a recorded child task
-with the same action can be flagged as a potential replay.
-
 Implementations MUST maintain a cache of recently-seen "jti"
-values to detect replayed ECTs within the expiration window.
+values and MUST reject ECTs with duplicate "jti" values.  Each
-An ECT with a duplicate "jti" value MUST be rejected.
+ECT is cryptographically bound to the issuing agent via "kid";
-
+verifiers MUST confirm that "kid" resolves to the "iss" agent's
-Additionally, each ECT is cryptographically bound to the issuing
+key (step 8 in {{verification}}).
-agent via the JOSE "kid" parameter, which references the agent's
-WIT public key.  Verifiers MUST confirm that the "kid" resolves
-to the "iss" agent's key (step 8 in {{verification}}), preventing
-one agent from replaying another agent's ECT as its own.
 
 ## Man-in-the-Middle Protection
 
-ECTs do not replace transport-layer security.  ECTs MUST be
+ECTs MUST be transmitted over TLS or mTLS connections.  When used
-transmitted over TLS or mTLS connections.  When used with the WIMSE
+with {{I-D.ietf-wimse-s2s-protocol}}, transport security is
-service-to-service protocol {{I-D.ietf-wimse-s2s-protocol}},
+already established.
-transport security is already established.  HTTP Message Signatures
-{{RFC9421}} provide an alternative channel binding mechanism.
-
-The defense-in-depth model provides:
-
-- TLS/mTLS (transport layer): Prevents network-level tampering.
-- WIT/WPT (WIMSE identity layer): Proves agent identity and
-  request authorization.
-- ECT (execution accountability layer): Records what the agent did.
 
 ## Key Compromise
 
 If an agent's private key is compromised, an attacker can forge
-ECTs that appear to originate from that agent.  To mitigate this
+ECTs that appear to originate from that agent.  Mitigations:
-risk:
 
 - Implementations SHOULD use short-lived keys and rotate them
-  frequently (hours to days, not months).
+  frequently.
-- Private keys SHOULD be stored in Hardware Security Modules (HSMs)
+- Private keys SHOULD be stored in hardware security modules or
-  or equivalent secure key storage.
+  equivalent secure key storage.
 - Trust domains MUST support rapid key revocation.
-- Upon suspected compromise, the trust domain MUST revoke the
-  compromised key and issue a new WIT with a fresh key pair.
 
-ECTs signed with a compromised key that were recorded in the
+ECTs recorded before key revocation remain valid historical
-ledger before revocation remain valid historical records but SHOULD
+records but SHOULD be flagged for audit purposes.  New ECTs
-be flagged in the ledger as "signed with subsequently revoked key"
+MUST NOT reference a parent ECT whose signing key is known to
-for audit purposes.
+be revoked at creation time.
 
-ECT revocation does not propagate through the DAG.  If a parent
+## Collusion and DAG Integrity {#collusion-and-false-claims}
-ECT's signing key is later revoked, child ECTs that were verified
-and recorded before that revocation remain valid — they captured
-a legitimate execution record at the time of issuance.  However,
-auditors reviewing a workflow SHOULD flag any ECT in the DAG
-whose signing key was subsequently revoked, so that the scope of
-a potential compromise can be assessed.  New ECTs MUST NOT be
-created with a "par" reference to an ECT whose signing key is
-known to be revoked at creation time.
-
-## Collusion and False Claims {#collusion-and-false-claims}
 
 A single malicious agent cannot forge parent task references
-because DAG validation requires parent tasks to exist in the
+because DAG validation requires parent tasks to exist in the ECT
-ledger.  However, multiple colluding agents could potentially
+store.  However, multiple colluding agents could create a false
-create a false execution history if they control the ledger.
+execution history.  Additionally, a malicious agent may omit
+actual parent dependencies from "par" to hide influences on its
+output; because ECTs are self-asserted
+({{self-assertion-limitation}}), no mechanism can force complete
+dependency declaration.
 
 Mitigations include:
 
-- Independent ledger maintenance: The ledger SHOULD be maintained
+- The ledger SHOULD be maintained by an entity independent of the
-  by an entity independent of the workflow agents.
+  workflow agents.
-- Cross-verification: Multiple independent ledger replicas can be
+- Multiple independent ledger replicas can be compared for
-  compared for consistency.
+  consistency.
-- Out-of-band audit: External auditors periodically verify ledger
+- External auditors can compare the declared DAG against expected
-  contents against expected workflow patterns.
+  workflow patterns.
-
-## DAG Integrity Attacks
-
-Because the DAG structure is the primary mechanism for establishing
-execution ordering, attackers may attempt to manipulate it:
-
-- False parent references: A malicious agent creates an ECT that
-  references parent tasks from an unrelated workflow, inserting
-  itself into a legitimate execution history.  DAG validation
-  ({{dag-validation}}) mitigates this by requiring parent existence
-  in the ECT store, and the "wid" claim scopes parent references
-  to a single workflow when present.
-- Parent omission (pruning): An agent deliberately omits one or
-  more actual parent dependencies from the "par" array to hide
-  that certain tasks influenced its output.  Because ECTs are
-  self-asserted ({{self-assertion-limitation}}), no mechanism can
-  force an agent to declare all dependencies.  External auditors
-  can detect omission by comparing the declared DAG against
-  expected workflow patterns.
-- Shadow DAGs: Multiple colluding agents fabricate an entire
-  execution history by creating a sequence of ECTs with mutual
-  parent references.  Independent ledger maintenance and
-  cross-verification (see {{collusion-and-false-claims}} above)
-  are the primary mitigations.
 
 Verifiers SHOULD validate that the declared "wid" of parent ECTs
 matches the "wid" of the child ECT, rejecting cross-workflow
@@ -880,54 +586,27 @@ policy.
 ECTs record execution history; they do not convey authorization.
 Verifiers MUST NOT interpret the presence of an ECT, or a
 particular set of parent references in "par", as an authorization
-grant.  The "par" claim demonstrates that predecessor tasks were
+grant.  Authorization decisions MUST remain with the identity and
-recorded, not that the current agent is authorized to act on
+authorization layer (WIT, WPT, and deployment policy).
-their outputs.  Authorization decisions MUST remain with the
-identity and authorization layer (WIT, WPT, and deployment
-policy).  As noted in {{I-D.ni-wimse-ai-agent-identity}},
-AI intermediaries introduce novel escalation vectors; ECTs
-MUST NOT be used to circumvent authorization boundaries.
 
 ## Denial of Service
 
-ECT signature verification is computationally inexpensive
+Implementations SHOULD apply rate limiting to prevent excessive
-(approximately 1ms per ECT on modern hardware for ES256).  DAG
+ECT submissions.  DAG validation SHOULD be performed after
-validation complexity is O(V) where V is the number of ancestor
+signature verification to avoid wasting resources on unsigned
-nodes reachable from the parent references; for typical shallow
+tokens.
-DAGs this is efficient.
-
-Implementations SHOULD apply rate limiting at the API layer to
-prevent excessive ECT submissions.  DAG validation SHOULD be
-performed after signature verification to avoid wasting resources
-on unsigned or incorrectly signed tokens.
 
 ## Timestamp Accuracy
 
-ECTs rely on timestamps ("iat", "exp") for temporal ordering.
+Implementations SHOULD use synchronized time sources (e.g., NTP)
-Clock skew between agents can lead to incorrect ordering
+and SHOULD allow a configurable clock skew tolerance (RECOMMENDED:
-judgments.  Implementations SHOULD use synchronized time sources
+30 seconds).  Cross-organizational deployments MAY require a
-(e.g., NTP) and SHOULD allow a configurable clock skew tolerance
+higher tolerance and SHOULD document the configured value.
-(RECOMMENDED: 30 seconds).
-
-Cross-organizational deployments where agents span multiple trust
-domains with independent time sources MAY require a higher clock
-skew tolerance.  Deployments using trust domain federation SHOULD
-document their configured clock skew tolerance value and SHOULD
-ensure all participating trust domains agree on a common tolerance.
-
-The temporal ordering check in DAG validation incorporates the
-clock skew tolerance to account for minor clock differences
-between agents.
 
 ## ECT Size Constraints
 
-ECTs with many parent tasks or large extension objects can
+Implementations SHOULD limit the "par" array to a maximum of
-increase HTTP header size.  Implementations SHOULD limit the "par"
+256 entries.  See {{extension-claims}} for "ext" size limits.
-array to a maximum of 256 entries.  Workflows requiring more
-parent references SHOULD introduce intermediate aggregation
-tasks.  The "ext" object SHOULD NOT exceed 4096 bytes when
-serialized as JSON and SHOULD NOT exceed a nesting depth of
-5 levels (see also {{extension-claims}}).
 
 # Privacy Considerations