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

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

Browse Source 
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Christian Nennemann
2026-02-25 23:26:25 +01:00
parent bbf557e54b
commit 6e5eba641a
4 changed files with 1492 additions and 3175 deletions
Download Patch File Download Diff File Expand all files Collapse all files

545
draft-nennemann-wimse-ect-00.md
View File

@@ -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
to the Workload Identity in Multi System Environments (WIMSE)
architecture for distributed agentic workflows. ECTs provide
signed, structured records of task execution order across
agent-to-agent communication. By extending WIMSE Workload Identity
Tokens with execution context claims in JSON Web Token (JWT)
format, this specification enables systems to maintain structured
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.
This document defines Execution Context Tokens (ECTs), a JWT-based
extension to the WIMSE architecture that records task execution
across distributed agentic workflows. Each ECT is a signed record
of a single task, linked to predecessor tasks through a directed
acyclic graph (DAG). ECTs reuse the WIMSE signing model and are
transported in a new Execution-Context HTTP header field alongside
existing WIMSE identity headers.
--- middle
# Introduction
## Motivation
The Workload Identity in Multi System Environments (WIMSE)
framework {{I-D.ietf-wimse-arch}} provides robust workload
authentication through Workload Identity Tokens (WIT) and Workload
Proof Tokens (WPT). The WIMSE service-to-service protocol
{{I-D.ietf-wimse-s2s-protocol}} defines how workloads authenticate
each other across call chains using the Workload-Identity and
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.
The WIMSE framework {{I-D.ietf-wimse-arch}} and its service-to-
service protocol {{I-D.ietf-wimse-s2s-protocol}} authenticate
workloads across call chains but do not record what those
workloads actually did. This document defines Execution Context
Tokens (ECTs), a JWT-based extension that fills the gap between
workload identity and execution accountability. Each ECT is a
signed record of a single task, linked to predecessor tasks
through a directed acyclic graph (DAG).
## 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
every ECT:
An ECT MUST contain the following standard JWT claims {{RFC7519}}:
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
messages and audit records, the "aud" claim SHOULD contain the
identifiers of all entities that will verify the ECT. In
practice this means:
* **Point-to-point delivery**: when an ECT is sent from one
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.
recipient(s) of the ECT. The "aud" claim SHOULD contain the
identifiers of all entities that will verify the ECT. When
an ECT must be verified by both the next agent and the audit
ledger independently, "aud" MUST be an array containing both
identifiers. Each verifier checks that its own identity
appears in "aud".
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"
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.
Implementations SHOULD set this to 5 to 15 minutes after "iat".
jti:
: REQUIRED. String. A globally unique identifier for both the
ECT and the task it records, in UUID format {{RFC9562}}. Since
each ECT represents exactly one task, "jti" serves as both the
token identifier (for replay detection) and the task identifier
(for DAG parent references in "par"). Receivers MUST reject
ECTs whose "jti" has already been seen within the expiration
window. When "wid" is present, uniqueness is scoped to the
workflow; when "wid" is absent, uniqueness MUST be enforced
globally across the ECT store.
: REQUIRED. String. A unique identifier for both the ECT and
the task it records, in UUID format {{RFC9562}}. The "jti"
serves as both the token identifier (for replay detection) and
the task identifier (for DAG parent references in "par").
Receivers MUST reject ECTs whose "jti" has already been seen
within the expiration window. When "wid" is present,
uniqueness is scoped to the workflow; when "wid" is absent,
uniqueness MUST be enforced 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
intentionally named "exec_act" rather than "act" to avoid
collision with the "act" (Actor) claim registered by
{{RFC8693}}.
"validate_safety"). This claim name avoids 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
"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.
multiple root tasks.
### 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
used by the DPoP "ath" claim {{RFC9449}} and the WIMSE WPT
"tth" claim {{I-D.ietf-wimse-s2s-protocol}}: SHA-256 is the
mandatory algorithm with no algorithm prefix in the value.
of the input. SHA-256 is the mandatory algorithm with no
algorithm prefix in the value, consistent with {{RFC9449}} and
{{I-D.ietf-wimse-s2s-protocol}}.
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
short name "ext" follows the JWT convention of concise claim
names and is chosen over alternatives like "extensions" for
compactness. Implementations that do not understand extension
claims MUST ignore them.
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.
domain-specific claims not defined by this specification.
Implementations that do not understand extension claims MUST
ignore them. Extension key names SHOULD use reverse domain
notation (e.g., "com.example.custom_field") to avoid
collisions. The serialized "ext" object SHOULD NOT exceed
4096 bytes and SHOULD NOT exceed a nesting depth of 5 levels.
## 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
provides a cryptographically signed record of execution ordering,
enabling auditors to reconstruct the complete workflow and verify
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
references its parent tasks via the "par" claim. DAG validation
is performed against the ECT store — either an audit ledger or
the set of parent ECTs received inline.
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 referenced in the "par"
array may not yet be available in the local ECT store at the time
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.
In distributed deployments, a parent ECT may not yet be available
locally due to replication lag. Implementations MAY defer
validation to allow parent ECTs to arrive, but MUST NOT treat
the ECT as verified until all parent references are resolved.
# 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:
- Malicious agent (insider threat): An agent within the trust
domain that intentionally creates false ECT claims.
- Compromised agent (external attacker): An agent whose private
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.
The threat model considers: (1) a malicious agent that creates
false ECT claims, (2) an agent whose private key has been
compromised, (3) a ledger tamperer attempting to modify recorded
entries, and (4) a time manipulator altering timestamps to affect
perceived 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.
## Organizational Prerequisites
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.
environment. ECTs provide a technical mechanism for execution
recording; they do not by themselves satisfy any specific
regulatory compliance requirement.
## Signature Verification
@@ -766,109 +526,55 @@ implement custom signature verification.
## Replay Attack Prevention
ECTs include short expiration times (RECOMMENDED: 5-15 minutes) to
limit the window for replay attacks. The "aud" claim restricts
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.
ECTs include short expiration times (RECOMMENDED: 5-15 minutes)
and audience restriction via "aud" to limit replay attacks.
Implementations MUST maintain a cache of recently-seen "jti"
values to detect replayed ECTs within the expiration window.
An ECT with a duplicate "jti" value MUST be rejected.
Additionally, each ECT is cryptographically bound to the issuing
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.
values and MUST reject ECTs with duplicate "jti" values. Each
ECT is cryptographically bound to the issuing agent via "kid";
verifiers MUST confirm that "kid" resolves to the "iss" agent's
key (step 8 in {{verification}}).
## Man-in-the-Middle Protection
ECTs do not replace transport-layer security. ECTs MUST be
transmitted over TLS or mTLS connections. When used with the WIMSE
service-to-service protocol {{I-D.ietf-wimse-s2s-protocol}},
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.
ECTs MUST be transmitted over TLS or mTLS connections. When used
with {{I-D.ietf-wimse-s2s-protocol}}, transport security is
already established.
## 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
risk:
ECTs that appear to originate from that agent. Mitigations:
- Implementations SHOULD use short-lived keys and rotate them
frequently (hours to days, not months).
- Private keys SHOULD be stored in Hardware Security Modules (HSMs)
or equivalent secure key storage.
frequently.
- Private keys SHOULD be stored in hardware security modules or
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
ledger before revocation remain valid historical records but SHOULD
be flagged in the ledger as "signed with subsequently revoked key"
for audit purposes.
ECTs recorded before key revocation remain valid historical
records but SHOULD be flagged for audit purposes. New ECTs
MUST NOT reference a parent ECT whose signing key is known to
be revoked at creation time.
ECT revocation does not propagate through the DAG. If a parent
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}
## Collusion and DAG Integrity {#collusion-and-false-claims}
A single malicious agent cannot forge parent task references
because DAG validation requires parent tasks to exist in the
ledger. However, multiple colluding agents could potentially
create a false execution history if they control the ledger.
because DAG validation requires parent tasks to exist in the ECT
store. However, multiple colluding agents could create a false
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
by an entity independent of the workflow agents.
- Cross-verification: Multiple independent ledger replicas can be
compared for consistency.
- Out-of-band audit: External auditors periodically verify ledger
contents against expected 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.
- The ledger SHOULD be maintained by an entity independent of the
workflow agents.
- Multiple independent ledger replicas can be compared for
consistency.
- External auditors can compare the declared DAG against expected
workflow patterns.
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
recorded, not that the current agent is authorized to act on
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.
grant. Authorization decisions MUST remain with the identity and
authorization layer (WIT, WPT, and deployment policy).
## Denial of Service
ECT signature verification is computationally inexpensive
(approximately 1ms per ECT on modern hardware for ES256). DAG
validation complexity is O(V) where V is the number of ancestor
nodes reachable from the parent references; for typical shallow
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.
Implementations SHOULD apply rate limiting to prevent excessive
ECT submissions. DAG validation SHOULD be performed after
signature verification to avoid wasting resources on unsigned
tokens.
## Timestamp Accuracy
ECTs rely on timestamps ("iat", "exp") for temporal ordering.
Clock skew between agents can lead to incorrect ordering
judgments. Implementations SHOULD use synchronized time sources
(e.g., NTP) and SHOULD allow a configurable clock skew tolerance
(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.
Implementations SHOULD use synchronized time sources (e.g., NTP)
and SHOULD allow a configurable clock skew tolerance (RECOMMENDED:
30 seconds). Cross-organizational deployments MAY require a
higher tolerance and SHOULD document the configured value.
## ECT Size Constraints
ECTs with many parent tasks or large extension objects can
increase HTTP header size. Implementations SHOULD limit the "par"
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}}).
Implementations SHOULD limit the "par" array to a maximum of
256 entries. See {{extension-claims}} for "ext" size limits.
# Privacy Considerations