The following are out of scope and are handled by WIMSE:¶
@@ -2236,7 +2257,7 @@ evaluated for this task (e.g.,
REQUIRED. String. The result of the policy evaluation. MUST
be one of the values registered in the ECT Policy Decision
-Values registry (Section 12.4). Initial values
+Values registry (Section 13.4). Initial values
are:¶
@@ -2341,7 +2362,7 @@ milliseconds. MUST be a non-negative integer.
@@ -2368,10 +2389,10 @@ use SPIFFE ID format. Note that this claim is self-asserted by
the ECT issuer; witnesses listed here do not co-sign this ECT.
For stronger assurance, witnesses SHOULD submit independent
signed ECTs to the ledger attesting to their observation (see
-Section 10.2.1). In regulated environments,
+Section 11.2.1). In regulated environments,
implementations SHOULD use witness attestation for critical
decision points to mitigate the risk of single-agent false
-claims. See also Section 10.2 for the security
+claims. See also Section 11.2 for the security
implications of self-asserted witness claims.¶
@@ -2397,7 +2418,7 @@ action. MUST be present if "compensation_required" i
Values SHOULD use structured identifiers (e.g.,
"policy_violation_in_parent_trade") rather than free-form text
to minimize the risk of embedding sensitive information. See
-Section 11.2 for privacy guidance.
+Section 12.2 for privacy guidance.
If "compensation_reason" is present, "compensation_required"
MUST be true.¶
@@ -2549,6 +2570,12 @@ 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 can be performed against an audit ledger (when
+available) or against parent ECTs received inline via
+Execution-Context headers (in point-to-point mode per
+Section 8). The validation rules below use the term
+"ECT store" to refer to either the ledger or the set of inline
+parent ECTs available to the verifier.¶
@@ -2562,14 +2589,15 @@ the following DAG validation steps:¶
Parent Existence: Every task identifier listed in the "par"
-array MUST correspond to a task that has been previously
-recorded in the ledger. If any parent task is not found, the
-ECT MUST be rejected.¶
+array MUST correspond to a task that is available in the ECT
+store (either previously recorded in the ledger or received
+inline as a verified parent ECT). If any parent task is not
+found, the ECT MUST be rejected.¶
Temporal Ordering: The "iat" value of every parent task MUST NOT be greater than the "iat" value of the current task plus a
@@ -2578,7 +2606,7 @@ That is, for each parent: parent.iat < child.iat +
clock_skew_tolerance. The tolerance accounts for clock skew
between agents; it does not guarantee strict causal ordering
from timestamps alone. Causal ordering is primarily enforced
-by the DAG structure (parent existence in the ledger), not by
+by the DAG structure (parent existence in the ECT store), not by
timestamps. If any parent task violates this constraint, the
ECT MUST be rejected.¶
@@ -2614,14 +2642,15 @@ relationship has been established.
If all checks pass, the ECT MUST be appended to the audit
-ledger.¶
+
If all checks pass and an audit ledger is available, the ECT
+SHOULD be appended to the audit ledger. In point-to-point
+mode (Section 8), the verified ECT is retained
+locally by the receiving agent.¶
If any verification step fails, the ECT MUST be rejected and the
@@ -2837,14 +2868,18 @@ function verify_ect(ect_jws, verifier_id,
["approved", "rejected", "pending_human_review"]:
return reject("Invalid pol_decision value")
- // Validate DAG
- result = validate_dag(payload, ledger,
+ // Validate DAG (against ledger or inline parent ECTs)
+ result = validate_dag(payload, ect_store,
clock_skew_tolerance)
if result is error:
return reject("DAG validation failed")
- // All checks passed; append to ledger
- ledger.append(payload)
+ // All checks passed
+ if ledger is available:
+ ledger.append(payload)
+ else:
+ // Point-to-point mode: retain locally
+ local_ect_cache.store(payload)
return accept
@@ -2856,63 +2891,155 @@ function verify_ect(ect_jws, verifier_id,
ECTs can be deployed in three operational modes depending on the
+availability and requirements of the deployment environment. All
+modes use the same ECT format and verification procedure; they
+differ in how parent ECTs are resolved during DAG validation and
+where verified ECTs are stored.¶
In point-to-point mode, agents pass parent ECTs directly to
+downstream agents via multiple Execution-Context HTTP headers.
+No centralized ledger is required. The receiving agent verifies
+each parent ECT independently and validates the DAG against the
+set of ECTs received in the request.¶
No persistent audit trail unless agents independently retain
+ECTs¶
+
+
+
Global replay detection relies solely on "jti" caches at each
+agent; there is no centralized "tid" uniqueness check¶
+
+
+
The parent ECT chain grows with each hop, increasing HTTP
+header size¶
+
+
+
Post-hoc audit reconstruction requires collecting ECTs from
+multiple agents¶
+
+
+
Agents operating in point-to-point mode MUST retain verified
+parent ECTs for at least the duration of the workflow to support
+DAG validation of downstream requests. Agents SHOULD persist
+ECTs locally for audit purposes even when no centralized ledger
+is available.¶
In deferred ledger mode, agents create and verify ECTs in-flight
+using point-to-point delivery, and submit collected ECTs to an
+audit ledger after the workflow completes or at periodic intervals.¶
+
This mode decouples real-time workflow execution from ledger
+availability. DAG validation during execution uses inline parent
+ECTs; full DAG validation against the complete workflow is
+performed at ledger submission time.¶
+
Agents MUST include all collected ECTs when submitting to the
+ledger. The ledger MUST re-validate the complete DAG upon
+submission.¶
In full ledger mode, every verified ECT is immediately appended
+to an audit ledger. DAG validation is performed against the
+ledger, which serves as the authoritative ECT store. This is
+the RECOMMENDED mode for regulated environments where persistent,
+centralized audit trails are required.¶
ECTs are designed to be recorded in an immutable audit ledger for
+
Use of an audit ledger is RECOMMENDED for regulated environments
+and any deployment requiring persistent, centralized audit trails.
+ECTs are designed to be recorded in an immutable audit ledger for
compliance verification and post-hoc analysis. This specification
defines the logical interface for the ledger but does not mandate
a specific storage technology. Implementations MAY use
append-only logs, databases with cryptographic commitment schemes,
distributed ledgers, or any storage mechanism that provides the
-required properties.¶
Each ledger entry is a logical record containing:¶
+
Each ledger entry is a logical record containing:¶
-
+
{
"ledger_sequence": 42,
@@ -2931,45 +3058,45 @@ workflow agents to reduce the risk of collusion.Ledger Entry Example
-
The "ect_jws" field contains the full JWS Compact Serialization
+
The "ect_jws" field contains the full JWS Compact Serialization
and is the authoritative record. The other fields ("agent_id",
"action", "parents") are convenience indexes derived from the
ECT payload; if they disagree with the JWS payload, the JWS
payload takes precedence. Implementations SHOULD validate that
convenience index fields match the corresponding values in the
JWS payload at write time to prevent desynchronization between
-the authoritative JWS and the indexed fields.¶
This section describes representative use cases demonstrating how
+
This section describes representative use cases demonstrating how
ECTs provide execution records in regulated environments. These
examples demonstrate ECT mechanics; production deployments would
include additional domain-specific requirements beyond the scope
-of this specification.¶
-
Note: task identifiers in this section are abbreviated for
+of this specification.¶
+
Note: task identifiers in this section are abbreviated for
readability. In production, all "tid" values are required to be
-UUIDs per Section 4.2.2.¶
In a medical device software development lifecycle (SDLC),
+
In a medical device software development lifecycle (SDLC),
AI agents assist across multiple phases from requirements
analysis through release approval. Regulatory frameworks
including [FDA-21CFR11] Section 11.10(e) and [EU-MDR] require
audit trails documenting the complete development process for
-software used in medical devices.¶
Agent A (Spec Reviewer):
tid: task-001 par: []
@@ -3003,24 +3130,24 @@ Human Release Manager:
Medical Device SDLC Workflow
-
ECTs record that requirements were reviewed before implementation
+
ECTs record that requirements were reviewed before implementation
began, that tests were executed against the implemented code, that
the build artifact was validated, and that a human release manager
explicitly approved the release. The DAG structure ensures no
-phase was skipped or reordered.¶
During a regulatory audit, an FDA reviewer requests evidence of
+
During a regulatory audit, an FDA reviewer requests evidence of
the development process for a specific software release. The
auditing authority retrieves all ECTs sharing the same workflow
identifier ("wid") from the audit ledger and reconstructs the
-complete DAG:¶
In a financial trading workflow, agents perform risk assessment,
+
In a financial trading workflow, agents perform risk assessment,
compliance verification, and trade execution. The DAG structure
records that compliance checks were evaluated before trade
-execution.¶
When a compliance violation is discovered after execution, ECTs
+
When a compliance violation is discovered after execution, ECTs
provide a mechanism to record authorized compensation actions with
-a cryptographic link to the original task:¶
{
"iss": "spiffe://bank.example/agent/operations",
@@ -3150,6 +3277,7 @@ a cryptographic link to the original task:Compensation ECT Example
-
The "par" claim links the compensation action to the original
+
The "par" claim links the compensation action to the original
trade, creating an auditable chain from execution through
-violation discovery to remediation.¶
In a logistics workflow, multiple compliance checks complete
+
In a logistics workflow, multiple compliance checks complete
before shipment commitment. The DAG structure records that all
-required checks were completed:¶
Note that tasks 002 and 003 both depend only on task-001 and can
+
Note that tasks 002 and 003 both depend only on task-001 and can
execute in parallel. Task 004 depends on both, demonstrating the
-DAG's ability to represent parallel execution with a join point.¶
+DAG's ability to represent parallel execution with a join point.¶
ECTs are self-asserted by the executing agent. The agent claims
+
ECTs are self-asserted by the executing agent. The agent claims
what it did, and this claim is signed with its private key. A
compromised or malicious agent could create ECTs with false claims
(e.g., setting "pol_decision" to "approved" without actually
-evaluating the policy).¶
The trustworthiness of ECT claims depends on the trustworthiness
+
The trustworthiness of ECT claims depends on the trustworthiness
of the signing agent. To mitigate single-agent false claims,
regulated environments SHOULD use the "witnessed_by" mechanism
to include independent third-party observers at critical decision
@@ -3286,306 +3414,306 @@ points. However, the "witnessed_by" claim is self-asserted by
the ECT issuer: the listed witnesses do not co-sign the ECT and
there is no cryptographic proof within a single ECT that the
witnesses actually observed the task. An issuing agent could
-list witnesses that did not participate.¶
To address the self-assertion limitation of the "witnessed_by"
+
To address the self-assertion limitation of the "witnessed_by"
claim, witnesses SHOULD submit their own independent signed ECTs
to the audit ledger attesting to the observed task. A witness
-attestation ECT:¶
MUST set "iss" to the witness's own workload identity.¶
+
+
MUST set "iss" to the witness's own workload identity.¶
-
-
MUST set "exec_act" to "witness_attestation" (or a domain-
-specific equivalent).¶
+
+
MUST set "exec_act" to "witness_attestation" (or a domain-
+specific equivalent).¶
-
-
MUST include the observed task's "tid" in the "par" array,
-linking the attestation to the original task.¶
+
+
MUST include the observed task's "tid" in the "par" array,
+linking the attestation to the original task.¶
-
-
MUST set "pol_decision" to "approved" to indicate the witness
-confirms the observation.¶
+
+
MUST set "pol_decision" to "approved" to indicate the witness
+confirms the observation.¶
-
When a task's "witnessed_by" claim lists one or more witnesses,
+
When a task's "witnessed_by" claim lists one or more witnesses,
auditors SHOULD verify that corresponding witness attestation
ECTs exist in the ledger for each listed witness. A mismatch
between the "witnessed_by" list and the set of independent witness
-ECTs in the ledger SHOULD be flagged during audit review.¶
-
This model converts witness attestation from a self-asserted claim
+ECTs in the ledger SHOULD be flagged during audit review.¶
+
This model converts witness attestation from a self-asserted claim
to a cryptographically verifiable property of the ledger: the
witness independently signs their own ECT using their own key,
and the ledger records both the original task ECT and the witness
-attestation ECTs.¶
ECTs operate within a broader trust framework. The guarantees
+
ECTs operate within a broader trust framework. The guarantees
provided by ECTs are only meaningful when the following
-organizational controls are in place:¶
ECTs MUST be signed with the agent's private key using JWS
+
ECTs MUST be signed with the agent's private key using JWS
[RFC7515]. The signature algorithm MUST match the algorithm
specified in the agent's WIT. Receivers MUST verify the ECT
signature against the WIT public key before processing any
claims. Receivers MUST verify that the signing key has not been
revoked within the trust domain (see step 6 in
-Section 7).¶
-
If signature verification fails or if the signing key has been
+Section 7).¶
+
If signature verification fails or if the signing key has been
revoked, the ECT MUST be rejected entirely and the failure MUST
-be logged.¶
-
Implementations MUST use established JWS libraries and MUST NOT
-implement custom signature verification.¶
ECTs include short expiration times (RECOMMENDED: 5-15 minutes) to
+
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
+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"
+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.
-An ECT with a duplicate "jti" value MUST be rejected.¶
+An ECT with a duplicate "jti" value MUST be rejected.¶
ECTs do not replace transport-layer security. ECTs MUST be
+
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.¶
Upon suspected compromise, the trust domain MUST revoke the
-compromised key and issue a new WIT with a fresh key pair.¶
+
+
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 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.¶
A single malicious agent cannot forge parent task references
+
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.¶
ECT signature verification is computationally inexpensive
+
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
+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.¶
ECTs rely on timestamps ("iat", "exp") for temporal ordering.
+
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
+(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
+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.¶
ECTs with many parent tasks or large extension objects can
+
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 Section 4.2.8).¶
Implementations SHOULD minimize the information included in ECTs.
+
Implementations SHOULD minimize the information included in ECTs.
The "exec_act" claim SHOULD use structured identifiers (e.g.,
"process_payment") rather than natural language descriptions.
The "pol" claim SHOULD reference policy identifiers rather than
-embedding policy content.¶
-
The "compensation_reason" claim (Section 4.2.7)
+embedding policy content.¶
+
The "compensation_reason" claim (Section 4.2.7)
deserves particular attention: because it is human-readable and
may describe the circumstances of a failure or policy violation,
it risks exposing sensitive operational details. Implementations
@@ -3593,167 +3721,167 @@ it risks exposing sensitive operational details. Implementations
"policy_violation_in_parent_trade") rather than free-form
natural language explanations. Implementers SHOULD review
"compensation_reason" values for potential information leakage
-before deploying to production.¶
ECTs stored in audit ledgers SHOULD be access-controlled so that
+
ECTs stored in audit ledgers SHOULD be access-controlled so that
only authorized auditors and regulators can read them.
Implementations SHOULD consider encryption at rest for ledger
-storage containing sensitive regulatory data.¶
-
Full input and output data (corresponding to the hashes in ECTs)
+storage containing sensitive regulatory data.¶
+
Full input and output data (corresponding to the hashes in ECTs)
SHOULD be stored separately from the ledger with additional access
controls, since auditors may need to verify hash correctness but
-general access to the data values is not needed.¶
+general access to the data values is not needed.¶
ECTs are designed for interpretation by qualified human auditors
+
ECTs are designed for interpretation by qualified human auditors
and regulators. ECTs provide structural records of execution
ordering and policy evaluation; they are not intended for public
-disclosure.¶
This document requests registration of the following header field
+
This document requests registration of the following header field
in the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
-maintained by IANA:¶
This document establishes the "ECT Policy Decision Values"
+
This document establishes the "ECT Policy Decision Values"
registry under the "JSON Web Token (JWT)" group. Registration
-policy is Specification Required per [RFC8126].¶
This document establishes the "ECT Regulated Domain Values"
+
This document establishes the "ECT Regulated Domain Values"
registry under the "JSON Web Token (JWT)" group. Registration
-policy is Specification Required per [RFC8126].¶
Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture-22, , <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-22>.
@@ -4162,26 +4298,79 @@ evaluated?" Together they form an identity-plus-accountability
framework for regulated agentic systems.¶
[RFC8693] defines the OAuth 2.0 Token Exchange protocol and
registers the "act" (Actor) claim in the JWT Claims registry.
-ECTs intentionally use the distinct claim name "exec_act" for the
-action/task type to avoid collision with the "act" claim.
-Transaction tokens in OAuth establish API authorization context;
-ECTs serve the complementary purpose of recording execution
-accountability across multi-step workflows.¶
+The "act" claim creates nested JSON objects representing a
+delegation chain: "who is acting on behalf of whom." While
+the nesting superficially resembles a chain, it is strictly
+linear (each "act" object contains at most one nested "act"),
+represents authorization delegation rather than task execution,
+and carries no task identifiers, policy decisions, or
+input/output integrity data. The "act" chain cannot represent
+branching (fan-out) or convergence (fan-in) and therefore
+cannot form a DAG.¶
+
ECTs intentionally use the distinct claim name "exec_act" for the
+action/task type to avoid collision with the "act" claim. The
+two concepts are orthogonal: "act" records "who authorized whom,"
+ECTs record "what was done, in what order, with what policy
+outcomes."¶
OAuth Transaction Tokens [I-D.ietf-oauth-transaction-tokens]
+propagate authorization context across workload call chains.
+The Txn-Token "req_wl" claim accumulates a comma-separated list
+of workloads that requested replacement tokens, which is the
+closest existing mechanism to call-chain recording.¶
It is linear: a comma-separated string with no branching or
+merging representation. When a workload fans out to multiple
+downstream services, each receives the same "req_wl" value and
+the branching is invisible.¶
+
+
+
It is incomplete: only workloads that request a replacement
+token from the Transaction Token Service appear in "req_wl";
+workloads that forward the token unchanged are not recorded.¶
+
+
+
It carries no task-level granularity, no parent references,
+no policy evaluation outcomes, and no execution content.¶
+
+
+
Extensions for agentic use cases
+([I-D.ietf-oauth-transaction-tokens-for-agents]) add agent
+identity and constraints ("agentic_ctx") but no execution
+ordering or DAG structure.¶
+
ECTs and Transaction Tokens are complementary: a Txn-Token
+propagates authorization context ("this request is authorized
+for scope X on behalf of user Y"), while an ECT records
+execution accountability ("task T was performed, depending on
+tasks P1 and P2, with policy Z evaluated and approved"). An
+agent request could carry both a Txn-Token for authorization
+and an ECT for execution recording. The WPT "tth" claim
+defined in [I-D.ietf-wimse-s2s-protocol] can hash-bind a
+WPT to a co-present Txn-Token; a similar binding mechanism
+for ECTs is a potential future extension.¶
OpenTelemetry [OPENTELEMETRY] and similar distributed tracing
+
OpenTelemetry [OPENTELEMETRY] and similar distributed tracing
systems provide observability for debugging and monitoring. ECTs
differ in several important ways: ECTs are cryptographically
signed per-task with the agent's private key; ECTs are
@@ -4192,28 +4381,28 @@ by the platform operator and can be modified or deleted without
detection. ECTs and distributed traces are complementary: traces
provide observability while ECTs provide signed execution records.
ECTs may reference OpenTelemetry trace identifiers in the "ext"
-claim for correlation.¶
Both ECTs and blockchain systems provide immutable records. This
+
Both ECTs and blockchain systems provide immutable records. This
specification intentionally defines only the ECT token format and
is agnostic to the storage mechanism. ECTs can be stored in
append-only logs, databases with cryptographic commitments,
blockchain networks, or any storage providing the required
-properties defined in Section 8.¶
The SCITT architecture [I-D.ietf-scitt-architecture] defines a
framework for creating transparent and auditable supply chain
records through Transparency Services, Signed Statements, and
Receipts. ECTs and SCITT are naturally complementary: the ECT
@@ -4229,19 +4418,19 @@ steps (via ECT DAG validation) and the end-to-end supply chain
integrity (via SCITT Receipts) using the "wid" as the shared
correlation point. The "ext" claim in ECTs (Section 4.2.2)
can carry SCITT-specific metadata such as Transparency Service
-identifiers or Receipt references for tighter integration.¶
+identifiers or Receipt references for tighter integration.¶
W3C Verifiable Credentials represent claims about subjects (e.g.,
+
W3C Verifiable Credentials represent claims about subjects (e.g.,
identity, qualifications). ECTs represent execution records of
actions (what happened, in what order, under what policy). While
both use JWT/JWS as a serialization format, their semantics and
-use cases are distinct.¶
Store verified ECTs (append to audit ledger in full ledger
+mode, or retain locally in point-to-point mode per
+Section 8).¶
@@ -4432,6 +4623,7 @@ Agent B:¶
"aud": "spiffe://example.com/agent/validator",
"iat": 1772064150,
"exp": 1772064750,
+ "jti": "1a2b3c4d-e5f6-7890-abcd-ef0123456701",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"tid": "550e8400-e29b-41d4-a716-446655440001",
"exec_act": "fetch_patient_data",
@@ -4455,6 +4647,7 @@ task, and creates its own ECT:¶= ect.iat + clock_skew_tolerance:
@@ -791,15 +804,15 @@ function validate_dag(ect, ledger, clock_skew_tolerance):
// Step 3: Cycle detection (with traversal limit)
visited = set()
- result = has_cycle(ect.tid, ect.par, ledger, visited,
+ result = has_cycle(ect.tid, ect.par, ect_store, visited,
max_ancestor_limit)
if result is error or result is true:
return error("Circular dependency or depth limit exceeded")
return success
-function has_cycle(target_tid, parent_ids, ledger, visited,
- max_depth):
+function has_cycle(target_tid, parent_ids, ect_store,
+ visited, max_depth):
if visited.size() >= max_depth:
return error("Maximum ancestor traversal limit exceeded")
for parent_id in parent_ids:
@@ -808,9 +821,9 @@ function has_cycle(target_tid, parent_ids, ledger, visited,
if parent_id in visited:
continue
visited.add(parent_id)
- parent = ledger.get(parent_id)
+ parent = ect_store.get(parent_id)
if parent is not null:
- result = has_cycle(target_tid, parent.par, ledger,
+ result = has_cycle(target_tid, parent.par, ect_store,
visited, max_depth)
if result is error or result is true:
return result
@@ -885,8 +898,10 @@ verification steps in order:
14. Perform DAG validation per {{dag-validation}}.
-15. If all checks pass, the ECT MUST be appended to the audit
- ledger.
+15. If all checks pass and an audit ledger is available, the ECT
+ SHOULD be appended to the audit ledger. In point-to-point
+ mode ({{operational-modes}}), the verified ECT is retained
+ locally by the receiving agent.
If any verification step fails, the ECT MUST be rejected and the
failure MUST be logged for audit purposes. Error messages
@@ -965,22 +980,91 @@ function verify_ect(ect_jws, verifier_id,
["approved", "rejected", "pending_human_review"]:
return reject("Invalid pol_decision value")
- // Validate DAG
- result = validate_dag(payload, ledger,
+ // Validate DAG (against ledger or inline parent ECTs)
+ result = validate_dag(payload, ect_store,
clock_skew_tolerance)
if result is error:
return reject("DAG validation failed")
- // All checks passed; append to ledger
- ledger.append(payload)
+ // All checks passed
+ if ledger is available:
+ ledger.append(payload)
+ else:
+ // Point-to-point mode: retain locally
+ local_ect_cache.store(payload)
return accept
~~~
{: #fig-verification title="ECT Verification Pseudocode"}
+# Operational Modes {#operational-modes}
+
+ECTs can be deployed in three operational modes depending on the
+availability and requirements of the deployment environment. All
+modes use the same ECT format and verification procedure; they
+differ in how parent ECTs are resolved during DAG validation and
+where verified ECTs are stored.
+
+## Point-to-Point Mode {#point-to-point-mode}
+
+In point-to-point mode, agents pass parent ECTs directly to
+downstream agents via multiple Execution-Context HTTP headers.
+No centralized ledger is required. The receiving agent verifies
+each parent ECT independently and validates the DAG against the
+set of ECTs received in the request.
+
+This mode is suitable for:
+
+- Cross-organizational workflows where no shared ledger exists
+- Lightweight deployments where infrastructure is constrained
+- Early adoption scenarios before ledger infrastructure is
+ available
+
+Limitations of point-to-point mode:
+
+- No persistent audit trail unless agents independently retain
+ ECTs
+- Global replay detection relies solely on "jti" caches at each
+ agent; there is no centralized "tid" uniqueness check
+- The parent ECT chain grows with each hop, increasing HTTP
+ header size
+- Post-hoc audit reconstruction requires collecting ECTs from
+ multiple agents
+
+Agents operating in point-to-point mode MUST retain verified
+parent ECTs for at least the duration of the workflow to support
+DAG validation of downstream requests. Agents SHOULD persist
+ECTs locally for audit purposes even when no centralized ledger
+is available.
+
+## Deferred Ledger Mode {#deferred-ledger-mode}
+
+In deferred ledger mode, agents create and verify ECTs in-flight
+using point-to-point delivery, and submit collected ECTs to an
+audit ledger after the workflow completes or at periodic intervals.
+
+This mode decouples real-time workflow execution from ledger
+availability. DAG validation during execution uses inline parent
+ECTs; full DAG validation against the complete workflow is
+performed at ledger submission time.
+
+Agents MUST include all collected ECTs when submitting to the
+ledger. The ledger MUST re-validate the complete DAG upon
+submission.
+
+## Full Ledger Mode {#full-ledger-mode}
+
+In full ledger mode, every verified ECT is immediately appended
+to an audit ledger. DAG validation is performed against the
+ledger, which serves as the authoritative ECT store. This is
+the RECOMMENDED mode for regulated environments where persistent,
+centralized audit trails are required.
+
# Audit Ledger Interface {#ledger-interface}
## Overview
+Use of an audit ledger is RECOMMENDED for regulated environments
+and any deployment requiring persistent, centralized audit trails.
ECTs are designed to be recorded in an immutable audit ledger for
compliance verification and post-hoc analysis. This specification
defines the logical interface for the ledger but does not mandate
@@ -1185,6 +1269,7 @@ a cryptographic link to the original task:
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772150550,
"exp": 1772151150,
+ "jti": "e4f5a6b7-c8d9-0123-ef01-234567890abc",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"tid": "550e8400-e29b-41d4-a716-446655440099",
"exec_act": "initiate_trade_rollback",
@@ -1654,16 +1739,63 @@ ECTs record "what did this agent do?" and "what policy was
evaluated?" Together they form an identity-plus-accountability
framework for regulated agentic systems.
-## OAuth 2.0 Token Exchange
+## OAuth 2.0 Token Exchange and the "act" Claim
{:numbered="false"}
{{RFC8693}} defines the OAuth 2.0 Token Exchange protocol and
registers the "act" (Actor) claim in the JWT Claims registry.
+The "act" claim creates nested JSON objects representing a
+delegation chain: "who is acting on behalf of whom." While
+the nesting superficially resembles a chain, it is strictly
+linear (each "act" object contains at most one nested "act"),
+represents authorization delegation rather than task execution,
+and carries no task identifiers, policy decisions, or
+input/output integrity data. The "act" chain cannot represent
+branching (fan-out) or convergence (fan-in) and therefore
+cannot form a DAG.
+
ECTs intentionally use the distinct claim name "exec_act" for the
-action/task type to avoid collision with the "act" claim.
-Transaction tokens in OAuth establish API authorization context;
-ECTs serve the complementary purpose of recording execution
-accountability across multi-step workflows.
+action/task type to avoid collision with the "act" claim. The
+two concepts are orthogonal: "act" records "who authorized whom,"
+ECTs record "what was done, in what order, with what policy
+outcomes."
+
+## Transaction Tokens
+{:numbered="false"}
+
+OAuth Transaction Tokens {{I-D.ietf-oauth-transaction-tokens}}
+propagate authorization context across workload call chains.
+The Txn-Token "req_wl" claim accumulates a comma-separated list
+of workloads that requested replacement tokens, which is the
+closest existing mechanism to call-chain recording.
+
+However, "req_wl" cannot form a DAG because:
+
+- It is linear: a comma-separated string with no branching or
+ merging representation. When a workload fans out to multiple
+ downstream services, each receives the same "req_wl" value and
+ the branching is invisible.
+- It is incomplete: only workloads that request a replacement
+ token from the Transaction Token Service appear in "req_wl";
+ workloads that forward the token unchanged are not recorded.
+- It carries no task-level granularity, no parent references,
+ no policy evaluation outcomes, and no execution content.
+
+Extensions for agentic use cases
+({{I-D.ietf-oauth-transaction-tokens-for-agents}}) add agent
+identity and constraints ("agentic_ctx") but no execution
+ordering or DAG structure.
+
+ECTs and Transaction Tokens are complementary: a Txn-Token
+propagates authorization context ("this request is authorized
+for scope X on behalf of user Y"), while an ECT records
+execution accountability ("task T was performed, depending on
+tasks P1 and P2, with policy Z evaluated and approved"). An
+agent request could carry both a Txn-Token for authorization
+and an ECT for execution recording. The WPT "tth" claim
+defined in {{I-D.ietf-wimse-s2s-protocol}} can hash-bind a
+WPT to a co-present Txn-Token; a similar binding mechanism
+for ECTs is a potential future extension.
## Distributed Tracing (OpenTelemetry)
{:numbered="false"}
@@ -1737,7 +1869,9 @@ A minimal conforming implementation needs to:
3. Verify ECT signatures against WIT public keys.
4. Perform DAG validation (parent existence, temporal ordering,
cycle detection).
-5. Append verified ECTs to an audit ledger.
+5. Store verified ECTs (append to audit ledger in full ledger
+ mode, or retain locally in point-to-point mode per
+ {{operational-modes}}).
## Storage Recommendations
{:numbered="false"}
@@ -1817,6 +1951,7 @@ ECT Payload:
"aud": "spiffe://example.com/agent/validator",
"iat": 1772064150,
"exp": 1772064750,
+ "jti": "1a2b3c4d-e5f6-7890-abcd-ef0123456701",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"tid": "550e8400-e29b-41d4-a716-446655440001",
"exec_act": "fetch_patient_data",
@@ -1840,6 +1975,7 @@ task, and creates its own ECT:
"aud": "spiffe://example.com/system/ledger",
"iat": 1772064160,
"exp": 1772064760,
+ "jti": "2b3c4d5e-f6a7-8901-bcde-f01234567802",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"tid": "550e8400-e29b-41d4-a716-446655440002",
"exec_act": "validate_safety",
@@ -1875,6 +2011,7 @@ Task 1 (Spec Review Agent):
"aud": "spiffe://meddev.example/agent/code-gen",
"iat": 1772064150,
"exp": 1772064750,
+ "jti": "3c4d5e6f-a7b8-9012-cdef-012345678903",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000001",
"exec_act": "review_requirements_spec",
@@ -1897,6 +2034,7 @@ Task 2 (Code Generation Agent):
"aud": "spiffe://meddev.example/agent/test-runner",
"iat": 1772064200,
"exp": 1772064800,
+ "jti": "4d5e6f7a-b8c9-0123-def0-123456789004",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000002",
"exec_act": "implement_module",
@@ -1917,6 +2055,7 @@ Task 3 (Autonomous Test Agent):
"aud": "spiffe://meddev.example/agent/build",
"iat": 1772064260,
"exp": 1772064860,
+ "jti": "5e6f7a8b-c9d0-1234-ef01-234567890005",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000003",
"exec_act": "execute_test_suite",
@@ -1937,6 +2076,7 @@ Task 4 (Build Agent):
"aud": "spiffe://meddev.example/human/release-mgr-42",
"iat": 1772064310,
"exp": 1772064910,
+ "jti": "6f7a8b9c-d0e1-2345-f012-345678900006",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000004",
"exec_act": "build_release_artifact",
@@ -1957,6 +2097,7 @@ Task 5 (Human Release Manager Approval):
"aud": "spiffe://meddev.example/system/ledger",
"iat": 1772064510,
"exp": 1772065110,
+ "jti": "7a8b9c0d-e1f2-3456-0123-456789000007",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000005",
"exec_act": "approve_release",
@@ -2025,6 +2166,7 @@ Task 004 ECT payload:
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772064250,
"exp": 1772064850,
+ "jti": "8b9c0d1e-f2a3-4567-1234-567890000008",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"tid": "f1e2d3c4-0004-0000-0000-000000000004",
"exec_act": "execute_trade",
diff --git a/draft-nennemann-wimse-execution-context-00.txt b/draft-nennemann-wimse-execution-context-00.txt
index 199e333..d19f891 100644
--- a/draft-nennemann-wimse-execution-context-00.txt
+++ b/draft-nennemann-wimse-execution-context-00.txt
@@ -92,10 +92,10 @@ Table of Contents
4.2.3. Policy Claims . . . . . . . . . . . . . . . . . . . . 12
4.2.4. Data Integrity Claims . . . . . . . . . . . . . . . . 13
4.2.5. Operational Claims . . . . . . . . . . . . . . . . . 13
- 4.2.6. Witness Claims . . . . . . . . . . . . . . . . . . . 13
+ 4.2.6. Witness Claims . . . . . . . . . . . . . . . . . . . 14
4.2.7. Compensation Claims . . . . . . . . . . . . . . . . . 14
4.2.8. Extension Claims . . . . . . . . . . . . . . . . . . 14
- 4.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 14
+ 4.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 15
5. HTTP Header Transport . . . . . . . . . . . . . . . . . . . . 15
5.1. Execution-Context Header Field . . . . . . . . . . . . . 15
6. DAG Validation . . . . . . . . . . . . . . . . . . . . . . . 16
@@ -105,7 +105,7 @@ Table of Contents
7. Signature and Token Verification . . . . . . . . . . . . . . 19
7.1. Verification Procedure . . . . . . . . . . . . . . . . . 19
7.2. Verification Pseudocode . . . . . . . . . . . . . . . . . 20
- 8. Audit Ledger Interface . . . . . . . . . . . . . . . . . . . 22
+ 8. Operational Modes . . . . . . . . . . . . . . . . . . . . . . 22
@@ -114,54 +114,54 @@ Nennemann Expires 28 August 2026 [Page 2]
Internet-Draft WIMSE Execution Context February 2026
- 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 22
- 8.2. Required Properties . . . . . . . . . . . . . . . . . . . 22
- 8.3. Ledger Entry Structure . . . . . . . . . . . . . . . . . 22
- 9. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 23
- 9.1. Medical Device SDLC Workflow . . . . . . . . . . . . . . 23
- 9.1.1. FDA Audit with DAG Reconstruction . . . . . . . . . . 24
- 9.2. Financial Trading Workflow . . . . . . . . . . . . . . . 25
- 9.3. Compensation and Rollback . . . . . . . . . . . . . . . . 26
- 9.4. Autonomous Logistics Coordination . . . . . . . . . . . . 27
- 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
- 10.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 28
- 10.2. Self-Assertion Limitation . . . . . . . . . . . . . . . 29
- 10.2.1. Witness Attestation Model . . . . . . . . . . . . . 29
- 10.3. Organizational Prerequisites . . . . . . . . . . . . . . 30
- 10.4. Signature Verification . . . . . . . . . . . . . . . . . 30
- 10.5. Replay Attack Prevention . . . . . . . . . . . . . . . . 31
- 10.6. Man-in-the-Middle Protection . . . . . . . . . . . . . . 31
- 10.7. Key Compromise . . . . . . . . . . . . . . . . . . . . . 31
- 10.8. Collusion and False Claims . . . . . . . . . . . . . . . 32
- 10.9. Denial of Service . . . . . . . . . . . . . . . . . . . 32
- 10.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 33
- 10.11. ECT Size Constraints . . . . . . . . . . . . . . . . . . 33
- 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33
- 11.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . 33
- 11.2. Data Minimization . . . . . . . . . . . . . . . . . . . 34
- 11.3. Storage and Access Control . . . . . . . . . . . . . . . 34
- 11.4. Regulatory Access . . . . . . . . . . . . . . . . . . . 34
- 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
- 12.1. Media Type Registration . . . . . . . . . . . . . . . . 34
- 12.2. HTTP Header Field Registration . . . . . . . . . . . . . 35
- 12.3. JWT Claims Registration . . . . . . . . . . . . . . . . 36
- 12.4. ECT Policy Decision Values Registry . . . . . . . . . . 37
- 12.5. ECT Regulated Domain Values Registry . . . . . . . . . . 38
- 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
- 13.1. Normative References . . . . . . . . . . . . . . . . . . 38
- 13.2. Informative References . . . . . . . . . . . . . . . . . 39
- Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 41
- WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 41
- OAuth 2.0 Token Exchange . . . . . . . . . . . . . . . . . . . 41
- Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 41
- Blockchain and Distributed Ledgers . . . . . . . . . . . . . . 42
- SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 42
- W3C Verifiable Credentials . . . . . . . . . . . . . . . . . . 42
- Implementation Guidance . . . . . . . . . . . . . . . . . . . . . 42
- Minimal Implementation . . . . . . . . . . . . . . . . . . . . 42
- Storage Recommendations . . . . . . . . . . . . . . . . . . . . 43
- Performance Considerations . . . . . . . . . . . . . . . . . . 43
- Interoperability . . . . . . . . . . . . . . . . . . . . . . . 43
+ 8.1. Point-to-Point Mode . . . . . . . . . . . . . . . . . . . 22
+ 8.2. Deferred Ledger Mode . . . . . . . . . . . . . . . . . . 23
+ 8.3. Full Ledger Mode . . . . . . . . . . . . . . . . . . . . 23
+ 9. Audit Ledger Interface . . . . . . . . . . . . . . . . . . . 23
+ 9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 9.2. Required Properties . . . . . . . . . . . . . . . . . . . 24
+ 9.3. Ledger Entry Structure . . . . . . . . . . . . . . . . . 24
+ 10. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 10.1. Medical Device SDLC Workflow . . . . . . . . . . . . . . 25
+ 10.1.1. FDA Audit with DAG Reconstruction . . . . . . . . . 26
+ 10.2. Financial Trading Workflow . . . . . . . . . . . . . . . 27
+ 10.3. Compensation and Rollback . . . . . . . . . . . . . . . 27
+ 10.4. Autonomous Logistics Coordination . . . . . . . . . . . 28
+ 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29
+ 11.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 29
+ 11.2. Self-Assertion Limitation . . . . . . . . . . . . . . . 30
+ 11.2.1. Witness Attestation Model . . . . . . . . . . . . . 30
+ 11.3. Organizational Prerequisites . . . . . . . . . . . . . . 31
+ 11.4. Signature Verification . . . . . . . . . . . . . . . . . 31
+ 11.5. Replay Attack Prevention . . . . . . . . . . . . . . . . 32
+ 11.6. Man-in-the-Middle Protection . . . . . . . . . . . . . . 32
+ 11.7. Key Compromise . . . . . . . . . . . . . . . . . . . . . 32
+ 11.8. Collusion and False Claims . . . . . . . . . . . . . . . 33
+ 11.9. Denial of Service . . . . . . . . . . . . . . . . . . . 33
+ 11.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 34
+ 11.11. ECT Size Constraints . . . . . . . . . . . . . . . . . . 34
+ 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34
+ 12.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . 34
+ 12.2. Data Minimization . . . . . . . . . . . . . . . . . . . 35
+ 12.3. Storage and Access Control . . . . . . . . . . . . . . . 35
+ 12.4. Regulatory Access . . . . . . . . . . . . . . . . . . . 35
+ 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
+ 13.1. Media Type Registration . . . . . . . . . . . . . . . . 35
+ 13.2. HTTP Header Field Registration . . . . . . . . . . . . . 36
+ 13.3. JWT Claims Registration . . . . . . . . . . . . . . . . 37
+ 13.4. ECT Policy Decision Values Registry . . . . . . . . . . 38
+ 13.5. ECT Regulated Domain Values Registry . . . . . . . . . . 39
+ 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
+ 14.1. Normative References . . . . . . . . . . . . . . . . . . 39
+ 14.2. Informative References . . . . . . . . . . . . . . . . . 40
+ Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 42
+ WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 42
+ OAuth 2.0 Token Exchange and the "act" Claim . . . . . . . . . 42
+ Transaction Tokens . . . . . . . . . . . . . . . . . . . . . . 43
+ Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 43
+ Blockchain and Distributed Ledgers . . . . . . . . . . . . . . 44
+ SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 44
+ W3C Verifiable Credentials . . . . . . . . . . . . . . . . . . 44
@@ -170,13 +170,18 @@ Nennemann Expires 28 August 2026 [Page 3]
Internet-Draft WIMSE Execution Context February 2026
- Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . . 43
- Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
- Example 1: Simple Two-Agent Workflow . . . . . . . . . . . . . 44
- Example 2: Medical Device SDLC with Release Approval . . . . . 45
- Example 3: Parallel Execution with Join . . . . . . . . . . . . 48
- Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49
+ Implementation Guidance . . . . . . . . . . . . . . . . . . . . . 44
+ Minimal Implementation . . . . . . . . . . . . . . . . . . . . 44
+ Storage Recommendations . . . . . . . . . . . . . . . . . . . . 45
+ Performance Considerations . . . . . . . . . . . . . . . . . . 45
+ Interoperability . . . . . . . . . . . . . . . . . . . . . . . 45
+ Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . . 46
+ Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
+ Example 1: Simple Two-Agent Workflow . . . . . . . . . . . . . 46
+ Example 2: Medical Device SDLC with Release Approval . . . . . 48
+ Example 3: Parallel Execution with Join . . . . . . . . . . . . 51
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 52
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction
@@ -213,11 +218,6 @@ Internet-Draft WIMSE Execution Context February 2026
orders that are sufficient to enable supervisory authorities to
monitor compliance.
- * The Digital Operational Resilience Act (DORA) [DORA] Article 12
- requires financial entities to have logging policies that record
- ICT activities and anomalies.
-
-
@@ -226,6 +226,10 @@ Nennemann Expires 28 August 2026 [Page 4]
Internet-Draft WIMSE Execution Context February 2026
+ * The Digital Operational Resilience Act (DORA) [DORA] Article 12
+ requires financial entities to have logging policies that record
+ ICT activities and anomalies.
+
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
@@ -270,10 +274,6 @@ Internet-Draft WIMSE Execution Context February 2026
* An HTTP header for ECT transport (Section 5)
- * Audit ledger interface requirements (Section 8)
-
- The following are out of scope and are handled by WIMSE:
-
@@ -282,6 +282,12 @@ Nennemann Expires 28 August 2026 [Page 5]
Internet-Draft WIMSE Execution Context February 2026
+ * Operational modes including ledger-optional deployment (Section 8)
+
+ * Audit ledger interface requirements (Section 9)
+
+ The following are out of scope and are handled by WIMSE:
+
* Workload authentication and identity provisioning
* Key distribution and management
@@ -324,12 +330,6 @@ Internet-Draft WIMSE Execution Context February 2026
Agent: An autonomous workload, as defined by WIMSE
[I-D.ietf-wimse-arch], that executes tasks within a workflow.
- Task: A discrete unit of agent work that consumes inputs and
- produces outputs.
-
- Directed Acyclic Graph (DAG): A graph structure representing task
- dependency ordering where edges are directed and no cycles exist.
-
@@ -338,6 +338,12 @@ Nennemann Expires 28 August 2026 [Page 6]
Internet-Draft WIMSE Execution Context February 2026
+ Task: A discrete unit of agent work that consumes inputs and
+ produces outputs.
+
+ Directed Acyclic Graph (DAG): A graph structure representing task
+ dependency ordering where edges are directed and no cycles exist.
+
Execution Context Token (ECT): A JSON Web Token [RFC7519] defined by
this specification that records task execution details and policy
evaluation outcomes.
@@ -380,12 +386,6 @@ Internet-Draft WIMSE Execution Context February 2026
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
-
- * Recording policy evaluation outcomes at each hop
-
- * Maintaining structured execution records
@@ -394,6 +394,13 @@ Nennemann Expires 28 August 2026 [Page 7]
Internet-Draft WIMSE Execution Context February 2026
+ * Recording what agents actually do with their authenticated
+ identity
+
+ * Recording policy evaluation outcomes at each hop
+
+ * Maintaining structured execution records
+
* Linking compensation or rollback actions to original tasks
3.2. Extension Model
@@ -434,6 +441,15 @@ Internet-Draft WIMSE Execution Context February 2026
* The ECT JOSE header "kid" parameter MUST reference the public key
identifier from the agent's WIT.
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 8]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
* The ECT "iss" claim MUST use the WIMSE workload identifier format
(a SPIFFE ID [SPIFFE]).
@@ -443,13 +459,6 @@ Internet-Draft WIMSE Execution Context February 2026
* The ECT signing algorithm (JOSE header "alg" parameter) MUST match
the algorithm used in the corresponding WIT.
-
-
-Nennemann Expires 28 August 2026 [Page 8]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
When an agent makes an HTTP request to another agent, the three
tokens are carried in their respective HTTP header fields:
@@ -489,6 +498,14 @@ Internet-Draft WIMSE Execution Context February 2026
Figure 3: ECT JOSE Header Example
alg: REQUIRED. The digital signature algorithm used to sign the
+
+
+
+Nennemann Expires 28 August 2026 [Page 9]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
ECT. MUST match the algorithm in the corresponding WIT.
Implementations MUST support ES256 [RFC7518]. The "alg" value
MUST NOT be "none". Symmetric algorithms (e.g., HS256, HS384,
@@ -499,13 +516,6 @@ Internet-Draft WIMSE Execution Context February 2026
from other JWT types, consistent with the WIMSE convention for
type parameter values.
-
-
-Nennemann Expires 28 August 2026 [Page 9]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
kid: REQUIRED. The key identifier referencing the public key from
the agent's WIT [RFC7517]. Used by verifiers to look up the
correct public key for signature verification.
@@ -545,16 +555,6 @@ Internet-Draft WIMSE Execution Context February 2026
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.
-
-
-
-
Nennemann Expires 28 August 2026 [Page 10]
@@ -562,6 +562,13 @@ Nennemann Expires 28 August 2026 [Page 10]
Internet-Draft WIMSE Execution Context February 2026
+ * *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
@@ -603,13 +610,6 @@ Internet-Draft WIMSE Execution Context February 2026
is absent, uniqueness MUST be enforced globally across the ledger.
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].
-
- par: REQUIRED. Array of strings. Parent task identifiers
-
@@ -618,6 +618,12 @@ Nennemann Expires 28 August 2026 [Page 11]
Internet-Draft WIMSE Execution Context February 2026
+ 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].
+
+ par: REQUIRED. Array of strings. Parent task identifiers
representing DAG dependencies. Each element MUST be a valid "tid"
from a previously executed task. An empty array indicates a root
task with no dependencies. A workflow MAY contain multiple root
@@ -632,7 +638,7 @@ Internet-Draft WIMSE Execution Context February 2026
pol_decision: REQUIRED. String. The result of the policy
evaluation. MUST be one of the values registered in the ECT
- Policy Decision Values registry (Section 12.4). Initial values
+ Policy Decision Values registry (Section 13.4). Initial values
are:
* "approved": The policy evaluation succeeded and the task was
@@ -660,12 +666,6 @@ Internet-Draft WIMSE Execution Context February 2026
decision was made. When present, MUST be equal to or earlier than
the "iat" claim.
- This specification intentionally defines only the recording of policy
- evaluation outcomes. The mechanisms by which policies are defined,
- distributed to agents, and evaluated are out of scope. The "pol"
- claim is an opaque identifier referencing an external policy; the
- semantics and enforcement of that policy are determined by the
- deployment environment. Implementations may use any policy engine or
@@ -674,6 +674,12 @@ Nennemann Expires 28 August 2026 [Page 12]
Internet-Draft WIMSE Execution Context February 2026
+ This specification intentionally defines only the recording of policy
+ evaluation outcomes. The mechanisms by which policies are defined,
+ distributed to agents, and evaluated are out of scope. The "pol"
+ claim is an opaque identifier referencing an external policy; the
+ semantics and enforcement of that policy are determined by the
+ deployment environment. Implementations may use any policy engine or
framework (e.g., OPA/Rego, Cedar, XACML, or custom solutions)
provided that the evaluation outcome is faithfully recorded in the
ECT claims defined above.
@@ -711,17 +717,11 @@ Internet-Draft WIMSE Execution Context February 2026
regulated_domain: OPTIONAL. String. The regulatory domain
applicable to this task. Values MUST be registered in the ECT
- Regulated Domain Values registry (Section 12.5).
+ Regulated Domain Values registry (Section 13.5).
model_version: OPTIONAL. String. The version identifier of the AI
or ML model used to perform the task, if applicable.
-4.2.6. Witness Claims
-
- witnessed_by: OPTIONAL. Array of StringOrURI. Identifiers of
- third-party entities that the issuing agent claims observed or
- attested to the execution of this task. When present, each
- element SHOULD use SPIFFE ID format. Note that this claim is
@@ -730,13 +730,19 @@ Nennemann Expires 28 August 2026 [Page 13]
Internet-Draft WIMSE Execution Context February 2026
+4.2.6. Witness Claims
+
+ witnessed_by: OPTIONAL. Array of StringOrURI. Identifiers of
+ third-party entities that the issuing agent claims observed or
+ attested to the execution of this task. When present, each
+ element SHOULD use SPIFFE ID format. Note that this claim is
self-asserted by the ECT issuer; witnesses listed here do not co-
sign this ECT. For stronger assurance, witnesses SHOULD submit
independent signed ECTs to the ledger attesting to their
- observation (see Section 10.2.1). In regulated environments,
+ observation (see Section 11.2.1). In regulated environments,
implementations SHOULD use witness attestation for critical
decision points to mitigate the risk of single-agent false claims.
- See also Section 10.2 for the security implications of self-
+ See also Section 11.2 for the security implications of self-
asserted witness claims.
4.2.7. Compensation Claims
@@ -749,7 +755,7 @@ Internet-Draft WIMSE Execution Context February 2026
"compensation_required" is true. Values SHOULD use structured
identifiers (e.g., "policy_violation_in_parent_trade") rather than
free-form text to minimize the risk of embedding sensitive
- information. See Section 11.2 for privacy guidance. If
+ information. See Section 12.2 for privacy guidance. If
"compensation_reason" is present, "compensation_required" MUST be
true.
@@ -773,12 +779,6 @@ Internet-Draft WIMSE Execution Context February 2026
within the "ext" object SHOULD NOT exceed 5 levels. Implementations
SHOULD reject ECTs whose "ext" claim exceeds these limits.
-4.3. Complete ECT Example
-
- The following is a complete ECT payload example:
-
-
-
Nennemann Expires 28 August 2026 [Page 14]
@@ -786,6 +786,10 @@ Nennemann Expires 28 August 2026 [Page 14]
Internet-Draft WIMSE Execution Context February 2026
+4.3. Complete ECT Example
+
+ The following is a complete ECT payload example:
+
{
"iss": "spiffe://example.com/agent/clinical",
"sub": "spiffe://example.com/agent/clinical",
@@ -829,10 +833,6 @@ Internet-Draft WIMSE Execution Context February 2026
[RFC7515]. The value consists of three Base64url-encoded parts
separated by period (".") characters.
- An agent sending a request to another agent includes the Execution-
- Context header alongside the WIMSE Workload-Identity and Workload-
- Proof-Token headers:
-
@@ -842,6 +842,10 @@ Nennemann Expires 28 August 2026 [Page 15]
Internet-Draft WIMSE Execution Context February 2026
+ An agent sending a request to another agent includes the Execution-
+ Context header alongside the WIMSE Workload-Identity and Workload-
+ Proof-Token headers:
+
GET /api/safety-check HTTP/1.1
Host: safety-agent.example.com
Workload-Identity: eyJhbGci...WIT...
@@ -871,25 +875,21 @@ Internet-Draft WIMSE Execution Context February 2026
auditors to reconstruct the complete workflow and verify that
required predecessor tasks were recorded before dependent tasks.
+ DAG validation can be performed against an audit ledger (when
+ available) or against parent ECTs received inline via Execution-
+ Context headers (in point-to-point mode per Section 8). The
+ validation rules below use the term "ECT store" to refer to either
+ the ledger or the set of inline parent ECTs available to the
+ verifier.
+
6.2. Validation Rules
When receiving and verifying an ECT, implementations MUST perform the
following DAG validation steps:
- 1. Task ID Uniqueness: The "tid" claim MUST be unique within the
- applicable scope (the workflow identified by "wid", or the entire
- ledger if "wid" is absent). If a task with the same "tid"
- already exists, the ECT MUST be rejected.
- 2. Parent Existence: Every task identifier listed in the "par" array
- MUST correspond to a task that has been previously recorded in
- the ledger. If any parent task is not found, the ECT MUST be
- rejected.
- 3. Temporal Ordering: The "iat" value of every parent task MUST NOT
- be greater than the "iat" value of the current task plus a
- configurable clock skew tolerance (RECOMMENDED: 30 seconds).
- That is, for each parent: parent.iat < child.iat +
+
@@ -898,10 +898,25 @@ Nennemann Expires 28 August 2026 [Page 16]
Internet-Draft WIMSE Execution Context February 2026
+ 1. Task ID Uniqueness: The "tid" claim MUST be unique within the
+ applicable scope (the workflow identified by "wid", or the entire
+ ECT store if "wid" is absent). If a task with the same "tid"
+ already exists, the ECT MUST be rejected.
+
+ 2. Parent Existence: Every task identifier listed in the "par" array
+ MUST correspond to a task that is available in the ECT store
+ (either previously recorded in the ledger or received inline as a
+ verified parent ECT). If any parent task is not found, the ECT
+ MUST be rejected.
+
+ 3. Temporal Ordering: The "iat" value of every parent task MUST NOT
+ be greater than the "iat" value of the current task plus a
+ configurable clock skew tolerance (RECOMMENDED: 30 seconds).
+ That is, for each parent: parent.iat < child.iat +
clock_skew_tolerance. The tolerance accounts for clock skew
between agents; it does not guarantee strict causal ordering from
timestamps alone. Causal ordering is primarily enforced by the
- DAG structure (parent existence in the ledger), not by
+ DAG structure (parent existence in the ECT store), not by
timestamps. If any parent task violates this constraint, the ECT
MUST be rejected.
@@ -929,21 +944,6 @@ Internet-Draft WIMSE Execution Context February 2026
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@@ -954,14 +954,15 @@ Nennemann Expires 28 August 2026 [Page 17]
Internet-Draft WIMSE Execution Context February 2026
- function validate_dag(ect, ledger, clock_skew_tolerance):
+ function validate_dag(ect, ect_store, clock_skew_tolerance):
+ // ect_store: ledger or local cache of verified ECTs
// Step 1: Uniqueness check
- if ledger.contains(ect.tid, ect.wid):
- return error("Task ID already exists in ledger")
+ if ect_store.contains(ect.tid, ect.wid):
+ return error("Task ID already exists")
// Step 2: Parent existence and temporal ordering
for parent_id in ect.par:
- parent = ledger.get(parent_id)
+ parent = ect_store.get(parent_id)
if parent is null:
return error("Parent task not found: " + parent_id)
if parent.iat >= ect.iat + clock_skew_tolerance:
@@ -969,15 +970,15 @@ Internet-Draft WIMSE Execution Context February 2026
// Step 3: Cycle detection (with traversal limit)
visited = set()
- result = has_cycle(ect.tid, ect.par, ledger, visited,
+ result = has_cycle(ect.tid, ect.par, ect_store, visited,
max_ancestor_limit)
if result is error or result is true:
return error("Circular dependency or depth limit exceeded")
return success
- function has_cycle(target_tid, parent_ids, ledger, visited,
- max_depth):
+ function has_cycle(target_tid, parent_ids, ect_store,
+ visited, max_depth):
if visited.size() >= max_depth:
return error("Maximum ancestor traversal limit exceeded")
for parent_id in parent_ids:
@@ -986,9 +987,9 @@ Internet-Draft WIMSE Execution Context February 2026
if parent_id in visited:
continue
visited.add(parent_id)
- parent = ledger.get(parent_id)
+ parent = ect_store.get(parent_id)
if parent is not null:
- result = has_cycle(target_tid, parent.par, ledger,
+ result = has_cycle(target_tid, parent.par, ect_store,
visited, max_depth)
if result is error or result is true:
return result
@@ -1001,7 +1002,6 @@ Internet-Draft WIMSE Execution Context February 2026
of ancestor nodes reachable from the current task's parent
references. For typical workflows with shallow DAGs, this is
efficient. To prevent denial-of-service via extremely deep or wide
- DAGs, implementations SHOULD enforce a maximum ancestor traversal
@@ -1010,6 +1010,7 @@ Nennemann Expires 28 August 2026 [Page 18]
Internet-Draft WIMSE Execution Context February 2026
+ DAGs, 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.
Implementations SHOULD cache cycle detection results for previously
@@ -1060,7 +1061,6 @@ Internet-Draft WIMSE Execution Context February 2026
-
Nennemann Expires 28 August 2026 [Page 19]
Internet-Draft WIMSE Execution Context February 2026
@@ -1080,8 +1080,10 @@ Internet-Draft WIMSE Execution Context February 2026
14. Perform DAG validation per Section 6.
- 15. If all checks pass, the ECT MUST be appended to the audit
- ledger.
+ 15. If all checks pass and an audit ledger is available, the ECT
+ SHOULD be appended to the audit ledger. In point-to-point mode
+ (Section 8), the verified ECT is retained locally by the
+ receiving agent.
If any verification step fails, the ECT MUST be rejected and the
failure MUST be logged for audit purposes. Error messages SHOULD NOT
@@ -1112,8 +1114,6 @@ Internet-Draft WIMSE Execution Context February 2026
// Look up public key
public_key = trust_domain_keys.get(header.kid)
- if public_key is null:
- return reject("Unknown key identifier")
@@ -1122,6 +1122,9 @@ Nennemann Expires 28 August 2026 [Page 20]
Internet-Draft WIMSE Execution Context February 2026
+ if public_key is null:
+ return reject("Unknown key identifier")
+
// Verify signature
if not verify_jws_signature(header, payload,
signature, public_key):
@@ -1165,11 +1168,8 @@ Internet-Draft WIMSE Execution Context February 2026
["approved", "rejected", "pending_human_review"]:
return reject("Invalid pol_decision value")
- // Validate DAG
- result = validate_dag(payload, ledger,
- clock_skew_tolerance)
- if result is error:
- return reject("DAG validation failed")
+ // Validate DAG (against ledger or inline parent ECTs)
+ result = validate_dag(payload, ect_store,
@@ -1178,17 +1178,100 @@ Nennemann Expires 28 August 2026 [Page 21]
Internet-Draft WIMSE Execution Context February 2026
- // All checks passed; append to ledger
- ledger.append(payload)
+ clock_skew_tolerance)
+ if result is error:
+ return reject("DAG validation failed")
+
+ // All checks passed
+ if ledger is available:
+ ledger.append(payload)
+ else:
+ // Point-to-point mode: retain locally
+ local_ect_cache.store(payload)
return accept
Figure 7: ECT Verification Pseudocode
-8. Audit Ledger Interface
+8. Operational Modes
-8.1. Overview
+ ECTs can be deployed in three operational modes depending on the
+ availability and requirements of the deployment environment. All
+ modes use the same ECT format and verification procedure; they differ
+ in how parent ECTs are resolved during DAG validation and where
+ verified ECTs are stored.
- ECTs are designed to be recorded in an immutable audit ledger for
+8.1. Point-to-Point Mode
+
+ In point-to-point mode, agents pass parent ECTs directly to
+ downstream agents via multiple Execution-Context HTTP headers. No
+ centralized ledger is required. The receiving agent verifies each
+ parent ECT independently and validates the DAG against the set of
+ ECTs received in the request.
+
+ This mode is suitable for:
+
+ * Cross-organizational workflows where no shared ledger exists
+
+ * Lightweight deployments where infrastructure is constrained
+
+ * Early adoption scenarios before ledger infrastructure is available
+
+ Limitations of point-to-point mode:
+
+ * No persistent audit trail unless agents independently retain ECTs
+
+ * Global replay detection relies solely on "jti" caches at each
+ agent; there is no centralized "tid" uniqueness check
+
+ * The parent ECT chain grows with each hop, increasing HTTP header
+ size
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 22]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
+ * Post-hoc audit reconstruction requires collecting ECTs from
+ multiple agents
+
+ Agents operating in point-to-point mode MUST retain verified parent
+ ECTs for at least the duration of the workflow to support DAG
+ validation of downstream requests. Agents SHOULD persist ECTs
+ locally for audit purposes even when no centralized ledger is
+ available.
+
+8.2. Deferred Ledger Mode
+
+ In deferred ledger mode, agents create and verify ECTs in-flight
+ using point-to-point delivery, and submit collected ECTs to an audit
+ ledger after the workflow completes or at periodic intervals.
+
+ This mode decouples real-time workflow execution from ledger
+ availability. DAG validation during execution uses inline parent
+ ECTs; full DAG validation against the complete workflow is performed
+ at ledger submission time.
+
+ Agents MUST include all collected ECTs when submitting to the ledger.
+ The ledger MUST re-validate the complete DAG upon submission.
+
+8.3. Full Ledger Mode
+
+ In full ledger mode, every verified ECT is immediately appended to an
+ audit ledger. DAG validation is performed against the ledger, which
+ serves as the authoritative ECT store. This is the RECOMMENDED mode
+ for regulated environments where persistent, centralized audit trails
+ are required.
+
+9. Audit Ledger Interface
+
+9.1. Overview
+
+ Use of an audit ledger is RECOMMENDED for regulated environments and
+ any deployment requiring persistent, centralized audit trails. ECTs
+ are designed to be recorded in an immutable audit ledger for
compliance verification and post-hoc analysis. This specification
defines the logical interface for the ledger but does not mandate a
specific storage technology. Implementations MAY use append-only
@@ -1196,7 +1279,18 @@ Internet-Draft WIMSE Execution Context February 2026
ledgers, or any storage mechanism that provides the required
properties.
-8.2. Required Properties
+
+
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 23]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
+9.2. Required Properties
An audit ledger implementation MUST provide:
@@ -1216,24 +1310,10 @@ Internet-Draft WIMSE Execution Context February 2026
The ledger SHOULD be maintained by an entity independent of the
workflow agents to reduce the risk of collusion.
-8.3. Ledger Entry Structure
+9.3. Ledger Entry Structure
Each ledger entry is a logical record containing:
-
-
-
-
-
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 22]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
{
"ledger_sequence": 42,
"task_id": "550e8400-e29b-41d4-a716-446655440001",
@@ -1257,7 +1337,16 @@ Internet-Draft WIMSE Execution Context February 2026
desynchronization between the authoritative JWS and the indexed
fields.
-9. Use Cases
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 24]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
+10. Use Cases
This section describes representative use cases demonstrating how
ECTs provide execution records in regulated environments. These
@@ -1269,7 +1358,7 @@ Internet-Draft WIMSE Execution Context February 2026
readability. In production, all "tid" values are required to be
UUIDs per Section 4.2.2.
-9.1. Medical Device SDLC Workflow
+10.1. Medical Device SDLC Workflow
In a medical device software development lifecycle (SDLC), AI agents
assist across multiple phases from requirements analysis through
@@ -1277,19 +1366,6 @@ Internet-Draft WIMSE Execution Context February 2026
Section 11.10(e) and [EU-MDR] require audit trails documenting the
complete development process for software used in medical devices.
-
-
-
-
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 23]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
Agent A (Spec Reviewer):
tid: task-001 par: []
exec_act: review_requirements_spec
@@ -1319,33 +1395,26 @@ Internet-Draft WIMSE Execution Context February 2026
Figure 9: Medical Device SDLC Workflow
+
+
+Nennemann Expires 28 August 2026 [Page 25]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
ECTs record that requirements were reviewed before implementation
began, that tests were executed against the implemented code, that
the build artifact was validated, and that a human release manager
explicitly approved the release. The DAG structure ensures no phase
was skipped or reordered.
-9.1.1. FDA Audit with DAG Reconstruction
+10.1.1. FDA Audit with DAG Reconstruction
During a regulatory audit, an FDA reviewer requests evidence of the
development process for a specific software release. The auditing
authority retrieves all ECTs sharing the same workflow identifier
("wid") from the audit ledger and reconstructs the complete DAG:
-
-
-
-
-
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 24]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
task-001 (review_requirements_spec)
|
v
@@ -1380,6 +1449,15 @@ Internet-Draft WIMSE Execution Context February 2026
* [FDA-21CFR11] Section 11.10(e): Computer-generated audit trails
that record the date, time, and identity of the operator.
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 26]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
* [EU-MDR] Annex II: Technical documentation traceability for the
software development lifecycle.
@@ -1389,19 +1467,12 @@ Internet-Draft WIMSE Execution Context February 2026
* [EU-AI-ACT] Article 14: ECTs can record evidence that human
oversight events occurred during the release process.
-9.2. Financial Trading Workflow
+10.2. Financial Trading Workflow
In a financial trading workflow, agents perform risk assessment,
compliance verification, and trade execution. The DAG structure
records that compliance checks were evaluated before trade execution.
-
-
-Nennemann Expires 28 August 2026 [Page 25]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
Agent A (Risk Assessment):
tid: task-001 par: []
exec_act: calculate_risk_exposure
@@ -1429,7 +1500,7 @@ Internet-Draft WIMSE Execution Context February 2026
* [EU-AI-ACT] Article 12: Logging of decisions made by AI-driven
systems.
-9.3. Compensation and Rollback
+10.3. Compensation and Rollback
When a compliance violation is discovered after execution, ECTs
provide a mechanism to record authorized compensation actions with a
@@ -1438,22 +1509,7 @@ Internet-Draft WIMSE Execution Context February 2026
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 26]
+Nennemann Expires 28 August 2026 [Page 27]
Internet-Draft WIMSE Execution Context February 2026
@@ -1464,6 +1520,7 @@ Internet-Draft WIMSE Execution Context February 2026
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772150550,
"exp": 1772151150,
+ "jti": "e4f5a6b7-c8d9-0123-ef01-234567890abc",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"tid": "550e8400-e29b-41d4-a716-446655440099",
"exec_act": "initiate_trade_rollback",
@@ -1481,7 +1538,7 @@ Internet-Draft WIMSE Execution Context February 2026
creating an auditable chain from execution through violation
discovery to remediation.
-9.4. Autonomous Logistics Coordination
+10.4. Autonomous Logistics Coordination
In a logistics workflow, multiple compliance checks complete before
shipment commitment. The DAG structure records that all required
@@ -1508,8 +1565,7 @@ Internet-Draft WIMSE Execution Context February 2026
-
-Nennemann Expires 28 August 2026 [Page 27]
+Nennemann Expires 28 August 2026 [Page 28]
Internet-Draft WIMSE Execution Context February 2026
@@ -1545,12 +1601,12 @@ Internet-Draft WIMSE Execution Context February 2026
execute in parallel. Task 004 depends on both, demonstrating the
DAG's ability to represent parallel execution with a join point.
-10. Security Considerations
+11. Security Considerations
This section addresses security considerations following the guidance
in [RFC3552].
-10.1. Threat Model
+11.1. Threat Model
The following threat actors are considered:
@@ -1565,7 +1621,7 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 28]
+Nennemann Expires 28 August 2026 [Page 29]
Internet-Draft WIMSE Execution Context February 2026
@@ -1573,7 +1629,7 @@ Internet-Draft WIMSE Execution Context February 2026
* Time manipulator: An entity attempting to manipulate timestamps to
alter perceived execution ordering.
-10.2. Self-Assertion Limitation
+11.2. Self-Assertion Limitation
ECTs are self-asserted by the executing agent. The agent claims what
it did, and this claim is signed with its private key. A compromised
@@ -1600,7 +1656,7 @@ Internet-Draft WIMSE Execution Context February 2026
observed the task. An issuing agent could list witnesses that did
not participate.
-10.2.1. Witness Attestation Model
+11.2.1. Witness Attestation Model
To address the self-assertion limitation of the "witnessed_by" claim,
witnesses SHOULD submit their own independent signed ECTs to the
@@ -1621,7 +1677,7 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 29]
+Nennemann Expires 28 August 2026 [Page 30]
Internet-Draft WIMSE Execution Context February 2026
@@ -1637,7 +1693,7 @@ Internet-Draft WIMSE Execution Context February 2026
independently signs their own ECT using their own key, and the ledger
records both the original task ECT and the witness attestation ECTs.
-10.3. Organizational Prerequisites
+11.3. Organizational Prerequisites
ECTs operate within a broader trust framework. The guarantees
provided by ECTs are only meaningful when the following
@@ -1655,7 +1711,7 @@ Internet-Draft WIMSE Execution Context February 2026
* Agent deployment governance: Agents are deployed and maintained in
a manner that preserves their integrity.
-10.4. Signature Verification
+11.4. Signature Verification
ECTs MUST be signed with the agent's private key using JWS [RFC7515].
The signature algorithm MUST match the algorithm specified in the
@@ -1677,12 +1733,12 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 30]
+Nennemann Expires 28 August 2026 [Page 31]
Internet-Draft WIMSE Execution Context February 2026
-10.5. Replay Attack Prevention
+11.5. Replay Attack Prevention
ECTs include short expiration times (RECOMMENDED: 5-15 minutes) to
limit the window for replay attacks. The "aud" claim restricts
@@ -1698,7 +1754,7 @@ Internet-Draft WIMSE Execution Context February 2026
to detect replayed ECTs within the expiration window. An ECT with a
duplicate "jti" value MUST be rejected.
-10.6. Man-in-the-Middle Protection
+11.6. 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
@@ -1716,7 +1772,7 @@ Internet-Draft WIMSE Execution Context February 2026
* ECT (execution accountability layer): Records what the agent did
and under what policy.
-10.7. Key Compromise
+11.7. 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:
@@ -1733,7 +1789,7 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 31]
+Nennemann Expires 28 August 2026 [Page 32]
Internet-Draft WIMSE Execution Context February 2026
@@ -1746,7 +1802,7 @@ Internet-Draft WIMSE Execution Context February 2026
flagged in the ledger as "signed with subsequently revoked key" for
audit purposes.
-10.8. Collusion and False Claims
+11.8. Collusion and False Claims
A single malicious agent cannot forge parent task references because
DAG validation requires parent tasks to exist in the ledger.
@@ -1767,7 +1823,7 @@ Internet-Draft WIMSE Execution Context February 2026
* Out-of-band audit: External auditors periodically verify ledger
contents against expected workflow patterns.
-10.9. Denial of Service
+11.9. Denial of Service
ECT signature verification is computationally inexpensive
(approximately 1ms per ECT on modern hardware for ES256). DAG
@@ -1789,12 +1845,12 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 32]
+Nennemann Expires 28 August 2026 [Page 33]
Internet-Draft WIMSE Execution Context February 2026
-10.10. Timestamp Accuracy
+11.10. Timestamp Accuracy
ECTs rely on timestamps ("iat", "exp") for temporal ordering. Clock
skew between agents can lead to incorrect ordering judgments.
@@ -1811,7 +1867,7 @@ Internet-Draft WIMSE Execution Context February 2026
The temporal ordering check in DAG validation incorporates the clock
skew tolerance to account for minor clock differences between agents.
-10.11. ECT Size Constraints
+11.11. 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
@@ -1820,9 +1876,9 @@ Internet-Draft WIMSE Execution Context February 2026
SHOULD NOT exceed 4096 bytes when serialized as JSON and SHOULD NOT
exceed a nesting depth of 5 levels (see also Section 4.2.8).
-11. Privacy Considerations
+12. Privacy Considerations
-11.1. Data Exposure in ECTs
+12.1. Data Exposure in ECTs
ECTs necessarily reveal:
@@ -1845,7 +1901,7 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 33]
+Nennemann Expires 28 August 2026 [Page 34]
Internet-Draft WIMSE Execution Context February 2026
@@ -1854,7 +1910,7 @@ Internet-Draft WIMSE Execution Context February 2026
* Personally identifiable information (PII)
-11.2. Data Minimization
+12.2. Data Minimization
Implementations SHOULD minimize the information included in ECTs.
The "exec_act" claim SHOULD use structured identifiers (e.g.,
@@ -1871,7 +1927,7 @@ Internet-Draft WIMSE Execution Context February 2026
SHOULD review "compensation_reason" values for potential information
leakage before deploying to production.
-11.3. Storage and Access Control
+12.3. Storage and Access Control
ECTs stored in audit ledgers SHOULD be access-controlled so that only
authorized auditors and regulators can read them. Implementations
@@ -1883,15 +1939,15 @@ Internet-Draft WIMSE Execution Context February 2026
controls, since auditors may need to verify hash correctness but
general access to the data values is not needed.
-11.4. Regulatory Access
+12.4. Regulatory Access
ECTs are designed for interpretation by qualified human auditors and
regulators. ECTs provide structural records of execution ordering
and policy evaluation; they are not intended for public disclosure.
-12. IANA Considerations
+13. IANA Considerations
-12.1. Media Type Registration
+13.1. Media Type Registration
This document requests registration of the following media type in
the "Media Types" registry maintained by IANA:
@@ -1901,7 +1957,7 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 34]
+Nennemann Expires 28 August 2026 [Page 35]
Internet-Draft WIMSE Execution Context February 2026
@@ -1941,7 +1997,7 @@ Internet-Draft WIMSE Execution Context February 2026
Change controller: IETF
-12.2. HTTP Header Field Registration
+13.2. HTTP Header Field Registration
This document requests registration of the following header field in
the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
@@ -1957,12 +2013,12 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 35]
+Nennemann Expires 28 August 2026 [Page 36]
Internet-Draft WIMSE Execution Context February 2026
-12.3. JWT Claims Registration
+13.3. JWT Claims Registration
This document requests registration of the following claims in the
"JSON Web Token Claims" registry maintained by IANA:
@@ -2013,7 +2069,7 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 36]
+Nennemann Expires 28 August 2026 [Page 37]
Internet-Draft WIMSE Execution Context February 2026
@@ -2036,7 +2092,7 @@ Internet-Draft WIMSE Execution Context February 2026
Table 1: JWT Claims Registrations
-12.4. ECT Policy Decision Values Registry
+13.4. ECT Policy Decision Values Registry
This document establishes the "ECT Policy Decision Values" registry
under the "JSON Web Token (JWT)" group. Registration policy is
@@ -2069,12 +2125,12 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 37]
+Nennemann Expires 28 August 2026 [Page 38]
Internet-Draft WIMSE Execution Context February 2026
-12.5. ECT Regulated Domain Values Registry
+13.5. ECT Regulated Domain Values Registry
This document establishes the "ECT Regulated Domain Values" registry
under the "JSON Web Token (JWT)" group. Registration policy is
@@ -2097,9 +2153,9 @@ Internet-Draft WIMSE Execution Context February 2026
Table 3: ECT Regulated Domain Values
-13. References
+14. References
-13.1. Normative References
+14.1. Normative References
[I-D.ietf-wimse-arch]
Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
@@ -2125,7 +2181,7 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 38]
+Nennemann Expires 28 August 2026 [Page 39]
Internet-Draft WIMSE Execution Context February 2026
@@ -2164,7 +2220,7 @@ Internet-Draft WIMSE Execution Context February 2026
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, .
-13.2. Informative References
+14.2. Informative References
[DORA] European Parliament and Council of the European Union,
"Regulation (EU) 2022/2554 on digital operational
@@ -2181,7 +2237,7 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 39]
+Nennemann Expires 28 August 2026 [Page 40]
Internet-Draft WIMSE Execution Context February 2026
@@ -2196,6 +2252,16 @@ Internet-Draft WIMSE Execution Context February 2026
Electronic Signatures", .
+ [I-D.ietf-oauth-transaction-tokens]
+ Tulshibagwale, A., Fletcher, G., and P. Kasselman,
+ "Transaction Tokens", Work in Progress, Internet-Draft,
+ draft-ietf-oauth-transaction-tokens-07, 24 January 2026,
+ .
+
+ [I-D.ietf-oauth-transaction-tokens-for-agents]
+ "*** BROKEN REFERENCE ***".
+
[I-D.ietf-scitt-architecture]
Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
@@ -2222,6 +2288,16 @@ Internet-Draft WIMSE Execution Context February 2026
Specification",
.
+
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 41]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
@@ -2232,16 +2308,6 @@ Internet-Draft WIMSE Execution Context February 2026
DOI 10.17487/RFC8693, January 2020,
.
-
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 40]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, .
@@ -2262,15 +2328,68 @@ WIMSE Workload Identity
they form an identity-plus-accountability framework for regulated
agentic systems.
-OAuth 2.0 Token Exchange
+OAuth 2.0 Token Exchange and the "act" Claim
[RFC8693] defines the OAuth 2.0 Token Exchange protocol and registers
- the "act" (Actor) claim in the JWT Claims registry. ECTs
- intentionally use the distinct claim name "exec_act" for the action/
- task type to avoid collision with the "act" claim. Transaction
- tokens in OAuth establish API authorization context; ECTs serve the
- complementary purpose of recording execution accountability across
- multi-step workflows.
+ the "act" (Actor) claim in the JWT Claims registry. The "act" claim
+ creates nested JSON objects representing a delegation chain: "who is
+ acting on behalf of whom." While the nesting superficially resembles
+ a chain, it is strictly linear (each "act" object contains at most
+ one nested "act"), represents authorization delegation rather than
+ task execution, and carries no task identifiers, policy decisions, or
+ input/output integrity data. The "act" chain cannot represent
+ branching (fan-out) or convergence (fan-in) and therefore cannot form
+ a DAG.
+
+ ECTs intentionally use the distinct claim name "exec_act" for the
+ action/task type to avoid collision with the "act" claim. The two
+ concepts are orthogonal: "act" records "who authorized whom," ECTs
+ record "what was done, in what order, with what policy outcomes."
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 42]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
+Transaction Tokens
+
+ OAuth Transaction Tokens [I-D.ietf-oauth-transaction-tokens]
+ propagate authorization context across workload call chains. The
+ Txn-Token "req_wl" claim accumulates a comma-separated list of
+ workloads that requested replacement tokens, which is the closest
+ existing mechanism to call-chain recording.
+
+ However, "req_wl" cannot form a DAG because:
+
+ * It is linear: a comma-separated string with no branching or
+ merging representation. When a workload fans out to multiple
+ downstream services, each receives the same "req_wl" value and the
+ branching is invisible.
+
+ * It is incomplete: only workloads that request a replacement token
+ from the Transaction Token Service appear in "req_wl"; workloads
+ that forward the token unchanged are not recorded.
+
+ * It carries no task-level granularity, no parent references, no
+ policy evaluation outcomes, and no execution content.
+
+ Extensions for agentic use cases
+ ([I-D.ietf-oauth-transaction-tokens-for-agents]) add agent identity
+ and constraints ("agentic_ctx") but no execution ordering or DAG
+ structure.
+
+ ECTs and Transaction Tokens are complementary: a Txn-Token propagates
+ authorization context ("this request is authorized for scope X on
+ behalf of user Y"), while an ECT records execution accountability
+ ("task T was performed, depending on tasks P1 and P2, with policy Z
+ evaluated and approved"). An agent request could carry both a Txn-
+ Token for authorization and an ECT for execution recording. The WPT
+ "tth" claim defined in [I-D.ietf-wimse-s2s-protocol] can hash-bind a
+ WPT to a co-present Txn-Token; a similar binding mechanism for ECTs
+ is a potential future extension.
Distributed Tracing (OpenTelemetry)
@@ -2283,21 +2402,17 @@ Distributed Tracing (OpenTelemetry)
OpenTelemetry data is typically controlled by the platform operator
and can be modified or deleted without detection. ECTs and
distributed traces are complementary: traces provide observability
- while ECTs provide signed execution records. ECTs may reference
- OpenTelemetry trace identifiers in the "ext" claim for correlation.
-
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 41]
+Nennemann Expires 28 August 2026 [Page 43]
Internet-Draft WIMSE Execution Context February 2026
+ while ECTs provide signed execution records. ECTs may reference
+ OpenTelemetry trace identifiers in the "ext" claim for correlation.
+
Blockchain and Distributed Ledgers
Both ECTs and blockchain systems provide immutable records. This
@@ -2305,7 +2420,7 @@ Blockchain and Distributed Ledgers
agnostic to the storage mechanism. ECTs can be stored in append-only
logs, databases with cryptographic commitments, blockchain networks,
or any storage providing the required properties defined in
- Section 8.
+ Section 9.
SCITT (Supply Chain Integrity, Transparency, and Trust)
@@ -2344,22 +2459,23 @@ Minimal Implementation
1. Create JWTs with all required claims ("iss", "aud", "iat", "exp",
"jti", "tid", "exec_act", "par", "pol", "pol_decision").
- 2. Sign ECTs with the agent's private key using an algorithm
- matching the WIT (ES256 recommended).
-
-Nennemann Expires 28 August 2026 [Page 42]
+Nennemann Expires 28 August 2026 [Page 44]
Internet-Draft WIMSE Execution Context February 2026
+ 2. Sign ECTs with the agent's private key using an algorithm
+ matching the WIT (ES256 recommended).
+
3. Verify ECT signatures against WIT public keys.
4. Perform DAG validation (parent existence, temporal ordering,
cycle detection).
- 5. Append verified ECTs to an audit ledger.
+ 5. Store verified ECTs (append to audit ledger in full ledger mode,
+ or retain locally in point-to-point mode per Section 8).
Storage Recommendations
@@ -2395,6 +2511,17 @@ Interoperability
expected to be tested against multiple JWT libraries to ensure
interoperability.
+
+
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 45]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
Regulatory Compliance Mapping
The following table summarizes how ECTs can contribute to compliance
@@ -2402,14 +2529,6 @@ Regulatory Compliance Mapping
block; achieving compliance requires additional organizational
measures beyond this specification.
-
-
-
-Nennemann Expires 28 August 2026 [Page 43]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
+============+========================+==========================+
| Regulation | Requirement | ECT Contribution |
+============+========================+==========================+
@@ -2450,6 +2569,15 @@ Example 1: Simple Two-Agent Workflow
ECT JOSE Header:
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 46]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
{
"alg": "ES256",
"typ": "wimse-exec+jwt",
@@ -2458,20 +2586,13 @@ Example 1: Simple Two-Agent Workflow
ECT Payload:
-
-
-
-Nennemann Expires 28 August 2026 [Page 44]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
{
"iss": "spiffe://example.com/agent/data-retrieval",
"sub": "spiffe://example.com/agent/data-retrieval",
"aud": "spiffe://example.com/agent/validator",
"iat": 1772064150,
"exp": 1772064750,
+ "jti": "1a2b3c4d-e5f6-7890-abcd-ef0123456701",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"tid": "550e8400-e29b-41d4-a716-446655440001",
"exec_act": "fetch_patient_data",
@@ -2493,6 +2614,7 @@ Internet-Draft WIMSE Execution Context February 2026
"aud": "spiffe://example.com/system/ledger",
"iat": 1772064160,
"exp": 1772064760,
+ "jti": "2b3c4d5e-f6a7-8901-bcde-f01234567802",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"tid": "550e8400-e29b-41d4-a716-446655440002",
"exec_act": "validate_safety",
@@ -2505,6 +2627,13 @@ Internet-Draft WIMSE Execution Context February 2026
The resulting DAG:
+
+
+Nennemann Expires 28 August 2026 [Page 47]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
task-...-0001 (fetch_patient_data)
|
v
@@ -2515,13 +2644,6 @@ Example 2: Medical Device SDLC with Release Approval
A multi-step medical device software lifecycle workflow with
autonomous agents and human release approval:
-
-
-Nennemann Expires 28 August 2026 [Page 45]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
Task 1 (Spec Review Agent):
{
@@ -2530,6 +2652,7 @@ Internet-Draft WIMSE Execution Context February 2026
"aud": "spiffe://meddev.example/agent/code-gen",
"iat": 1772064150,
"exp": 1772064750,
+ "jti": "3c4d5e6f-a7b8-9012-cdef-012345678903",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000001",
"exec_act": "review_requirements_spec",
@@ -2544,12 +2667,36 @@ Internet-Draft WIMSE Execution Context February 2026
Task 2 (Code Generation Agent):
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 48]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
{
"iss": "spiffe://meddev.example/agent/code-gen",
"sub": "spiffe://meddev.example/agent/code-gen",
"aud": "spiffe://meddev.example/agent/test-runner",
"iat": 1772064200,
"exp": 1772064800,
+ "jti": "4d5e6f7a-b8c9-0123-def0-123456789004",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000002",
"exec_act": "implement_module",
@@ -2562,28 +2709,13 @@ Internet-Draft WIMSE Execution Context February 2026
Task 3 (Autonomous Test Agent):
-
-
-
-
-
-
-
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 46]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
{
"iss": "spiffe://meddev.example/agent/test-runner",
"sub": "spiffe://meddev.example/agent/test-runner",
"aud": "spiffe://meddev.example/agent/build",
"iat": 1772064260,
"exp": 1772064860,
+ "jti": "5e6f7a8b-c9d0-1234-ef01-234567890005",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000003",
"exec_act": "execute_test_suite",
@@ -2596,12 +2728,31 @@ Internet-Draft WIMSE Execution Context February 2026
Task 4 (Build Agent):
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 49]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
{
"iss": "spiffe://meddev.example/agent/build",
"sub": "spiffe://meddev.example/agent/build",
"aud": "spiffe://meddev.example/human/release-mgr-42",
"iat": 1772064310,
"exp": 1772064910,
+ "jti": "6f7a8b9c-d0e1-2345-f012-345678900006",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000004",
"exec_act": "build_release_artifact",
@@ -2614,32 +2765,13 @@ Internet-Draft WIMSE Execution Context February 2026
Task 5 (Human Release Manager Approval):
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 47]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
{
"iss": "spiffe://meddev.example/human/release-mgr-42",
"sub": "spiffe://meddev.example/human/release-mgr-42",
"aud": "spiffe://meddev.example/system/ledger",
"iat": 1772064510,
"exp": 1772065110,
+ "jti": "7a8b9c0d-e1f2-3456-0123-456789000007",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000005",
"exec_act": "approve_release",
@@ -2658,6 +2790,18 @@ Internet-Draft WIMSE Execution Context February 2026
build, and a human release manager approved the final release with
independent witness attestation.
+
+
+
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 50]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
task-...-0001 (review_requirements_spec)
|
v
@@ -2683,13 +2827,6 @@ Example 3: Parallel Execution with Join
A workflow where two tasks execute in parallel and a third task
depends on both:
-
-
-Nennemann Expires 28 August 2026 [Page 48]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
task-...-0001 (assess_risk)
| \
v v
@@ -2702,12 +2839,32 @@ Internet-Draft WIMSE Execution Context February 2026
Task 004 ECT payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 51]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
{
"iss": "spiffe://bank.example/agent/execution",
"sub": "spiffe://bank.example/agent/execution",
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772064250,
"exp": 1772064850,
+ "jti": "8b9c0d1e-f2a3-4567-1234-567890000008",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"tid": "f1e2d3c4-0004-0000-0000-000000000004",
"exec_act": "execute_trade",
@@ -2741,4 +2898,15 @@ Author's Address
-Nennemann Expires 28 August 2026 [Page 49]
+
+
+
+
+
+
+
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 52]
diff --git a/draft-nennemann-wimse-execution-context-00.xml b/draft-nennemann-wimse-execution-context-00.xml
index 9204ce2..301d638 100644
--- a/draft-nennemann-wimse-execution-context-00.xml
+++ b/draft-nennemann-wimse-execution-context-00.xml
@@ -32,7 +32,7 @@
-
+
This document defines Execution Context Tokens (ECTs), an extension
to the Workload Identity in Multi System Environments (WIMSE)
@@ -64,7 +64,7 @@ regulatory frameworks.
-
+
Introduction
@@ -149,6 +149,8 @@ regulatory audit scenarios.
Integration with the WIMSE identity framework
()An HTTP header for ECT transport ()
+ Operational modes including ledger-optional deployment
+()Audit ledger interface requirements ()
@@ -795,6 +797,13 @@ enabling auditors to reconstruct the complete workflow and verify
that required predecessor tasks were recorded before dependent
tasks.
+DAG validation can be performed against an audit ledger (when
+available) or against parent ECTs received inline via
+Execution-Context headers (in point-to-point mode per
+). The validation rules below use the term
+"ECT store" to refer to either the ledger or the set of inline
+parent ECTs available to the verifier.
+
Validation Rules
@@ -804,12 +813,13 @@ the following DAG validation steps:
Task ID Uniqueness: The "tid" claim MUST be unique within the
applicable scope (the workflow identified by "wid", or the
-entire ledger if "wid" is absent). If a task with the same
+entire ECT store if "wid" is absent). If a task with the same
"tid" already exists, the ECT MUST be rejected.Parent Existence: Every task identifier listed in the "par"
-array MUST correspond to a task that has been previously
-recorded in the ledger. If any parent task is not found, the
-ECT MUST be rejected.
+array MUST correspond to a task that is available in the ECT
+store (either previously recorded in the ledger or received
+inline as a verified parent ECT). If any parent task is not
+found, the ECT MUST be rejected.Temporal Ordering: The "iat" value of every parent task MUST
NOT be greater than the "iat" value of the current task plus a
configurable clock skew tolerance (RECOMMENDED: 30 seconds).
@@ -817,7 +827,7 @@ That is, for each parent: parent.iat < child.iat +
clock_skew_tolerance. The tolerance accounts for clock skew
between agents; it does not guarantee strict causal ordering
from timestamps alone. Causal ordering is primarily enforced
-by the DAG structure (parent existence in the ledger), not by
+by the DAG structure (parent existence in the ECT store), not by
timestamps. If any parent task violates this constraint, the
ECT MUST be rejected.Acyclicity: Following the chain of parent references MUST NOT
@@ -841,14 +851,15 @@ relationship has been established.The following pseudocode describes the DAG validation procedure:= ect.iat + clock_skew_tolerance:
@@ -856,15 +867,15 @@ function validate_dag(ect, ledger, clock_skew_tolerance):
// Step 3: Cycle detection (with traversal limit)
visited = set()
- result = has_cycle(ect.tid, ect.par, ledger, visited,
+ result = has_cycle(ect.tid, ect.par, ect_store, visited,
max_ancestor_limit)
if result is error or result is true:
return error("Circular dependency or depth limit exceeded")
return success
-function has_cycle(target_tid, parent_ids, ledger, visited,
- max_depth):
+function has_cycle(target_tid, parent_ids, ect_store,
+ visited, max_depth):
if visited.size() >= max_depth:
return error("Maximum ancestor traversal limit exceeded")
for parent_id in parent_ids:
@@ -873,9 +884,9 @@ function has_cycle(target_tid, parent_ids, ledger, visited,
if parent_id in visited:
continue
visited.add(parent_id)
- parent = ledger.get(parent_id)
+ parent = ect_store.get(parent_id)
if parent is not null:
- result = has_cycle(target_tid, parent.par, ledger,
+ result = has_cycle(target_tid, parent.par, ect_store,
visited, max_depth)
if result is error or result is true:
return result
@@ -938,8 +949,10 @@ verifier's current time, to account for clock skew).
Verify "pol_decision" is one of "approved", "rejected", or
"pending_human_review".Perform DAG validation per .
- If all checks pass, the ECT MUST be appended to the audit
-ledger.
+ If all checks pass and an audit ledger is available, the ECT
+SHOULD be appended to the audit ledger. In point-to-point
+mode (), the verified ECT is retained
+locally by the receiving agent.If any verification step fails, the ECT MUST be rejected and the
@@ -1020,24 +1033,101 @@ function verify_ect(ect_jws, verifier_id,
["approved", "rejected", "pending_human_review"]:
return reject("Invalid pol_decision value")
- // Validate DAG
- result = validate_dag(payload, ledger,
+ // Validate DAG (against ledger or inline parent ECTs)
+ result = validate_dag(payload, ect_store,
clock_skew_tolerance)
if result is error:
return reject("DAG validation failed")
- // All checks passed; append to ledger
- ledger.append(payload)
+ // All checks passed
+ if ledger is available:
+ ledger.append(payload)
+ else:
+ // Point-to-point mode: retain locally
+ local_ect_cache.store(payload)
return accept
]]>
+
+
+Operational Modes
+
+ECTs can be deployed in three operational modes depending on the
+availability and requirements of the deployment environment. All
+modes use the same ECT format and verification procedure; they
+differ in how parent ECTs are resolved during DAG validation and
+where verified ECTs are stored.
+
+Point-to-Point Mode
+
+In point-to-point mode, agents pass parent ECTs directly to
+downstream agents via multiple Execution-Context HTTP headers.
+No centralized ledger is required. The receiving agent verifies
+each parent ECT independently and validates the DAG against the
+set of ECTs received in the request.
+
+This mode is suitable for:
+
+
+ Cross-organizational workflows where no shared ledger exists
+ Lightweight deployments where infrastructure is constrained
+ Early adoption scenarios before ledger infrastructure is
+available
+
+
+Limitations of point-to-point mode:
+
+
+ No persistent audit trail unless agents independently retain
+ECTs
+ Global replay detection relies solely on "jti" caches at each
+agent; there is no centralized "tid" uniqueness check
+ The parent ECT chain grows with each hop, increasing HTTP
+header size
+ Post-hoc audit reconstruction requires collecting ECTs from
+multiple agents
+
+
+Agents operating in point-to-point mode MUST retain verified
+parent ECTs for at least the duration of the workflow to support
+DAG validation of downstream requests. Agents SHOULD persist
+ECTs locally for audit purposes even when no centralized ledger
+is available.
+
+
+Deferred Ledger Mode
+
+In deferred ledger mode, agents create and verify ECTs in-flight
+using point-to-point delivery, and submit collected ECTs to an
+audit ledger after the workflow completes or at periodic intervals.
+
+This mode decouples real-time workflow execution from ledger
+availability. DAG validation during execution uses inline parent
+ECTs; full DAG validation against the complete workflow is
+performed at ledger submission time.
+
+Agents MUST include all collected ECTs when submitting to the
+ledger. The ledger MUST re-validate the complete DAG upon
+submission.
+
+
+Full Ledger Mode
+
+In full ledger mode, every verified ECT is immediately appended
+to an audit ledger. DAG validation is performed against the
+ledger, which serves as the authoritative ECT store. This is
+the RECOMMENDED mode for regulated environments where persistent,
+centralized audit trails are required.
+
Audit Ledger InterfaceOverview
-ECTs are designed to be recorded in an immutable audit ledger for
+Use of an audit ledger is RECOMMENDED for regulated environments
+and any deployment requiring persistent, centralized audit trails.
+ECTs are designed to be recorded in an immutable audit ledger for
compliance verification and post-hoc analysis. This specification
defines the logical interface for the ledger but does not mandate
a specific storage technology. Implementations MAY use
@@ -1249,6 +1339,7 @@ a cryptographic link to the original task:
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772150550,
"exp": 1772151150,
+ "jti": "e4f5a6b7-c8d9-0123-ef01-234567890abc",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"tid": "550e8400-e29b-41d4-a716-446655440099",
"exec_act": "initiate_trade_rollback",
@@ -2243,6 +2334,36 @@ been incorporated into this document. This document obsoletes RFC
+
+
+ Transaction Tokens
+
+ SGNL
+
+
+ Practical Identity LLC
+
+
+ Defakto Security
+
+
+
+ Transaction Tokens (Txn-Tokens) are designed to maintain and
+ propagate user identity and authorization context across workloads
+ within a trusted domain during the processing of external requests,
+ such as API calls. They ensure that this context is preserved
+ throughout the call chain, even when new transactions are initiated
+ internally, thereby enhancing security and consistency in complex,
+ multi-service architectures.
+
+
+
+
+
+
+
+*** BROKEN REFERENCE ***
+
@@ -2250,7 +2371,7 @@ been incorporated into this document. This document obsoletes RFC
-
+
Related Work
@@ -2265,15 +2386,64 @@ evaluated?" Together they form an identity-plus-accountability
framework for regulated agentic systems.
-OAuth 2.0 Token Exchange
+OAuth 2.0 Token Exchange and the "act" Claim defines the OAuth 2.0 Token Exchange protocol and
registers the "act" (Actor) claim in the JWT Claims registry.
-ECTs intentionally use the distinct claim name "exec_act" for the
-action/task type to avoid collision with the "act" claim.
-Transaction tokens in OAuth establish API authorization context;
-ECTs serve the complementary purpose of recording execution
-accountability across multi-step workflows.
+The "act" claim creates nested JSON objects representing a
+delegation chain: "who is acting on behalf of whom." While
+the nesting superficially resembles a chain, it is strictly
+linear (each "act" object contains at most one nested "act"),
+represents authorization delegation rather than task execution,
+and carries no task identifiers, policy decisions, or
+input/output integrity data. The "act" chain cannot represent
+branching (fan-out) or convergence (fan-in) and therefore
+cannot form a DAG.
+
+ECTs intentionally use the distinct claim name "exec_act" for the
+action/task type to avoid collision with the "act" claim. The
+two concepts are orthogonal: "act" records "who authorized whom,"
+ECTs record "what was done, in what order, with what policy
+outcomes."
+
+
+Transaction Tokens
+
+OAuth Transaction Tokens
+propagate authorization context across workload call chains.
+The Txn-Token "req_wl" claim accumulates a comma-separated list
+of workloads that requested replacement tokens, which is the
+closest existing mechanism to call-chain recording.
+
+However, "req_wl" cannot form a DAG because:
+
+
+ It is linear: a comma-separated string with no branching or
+merging representation. When a workload fans out to multiple
+downstream services, each receives the same "req_wl" value and
+the branching is invisible.
+ It is incomplete: only workloads that request a replacement
+token from the Transaction Token Service appear in "req_wl";
+workloads that forward the token unchanged are not recorded.
+ It carries no task-level granularity, no parent references,
+no policy evaluation outcomes, and no execution content.
+
+
+Extensions for agentic use cases
+() add agent
+identity and constraints ("agentic_ctx") but no execution
+ordering or DAG structure.
+
+ECTs and Transaction Tokens are complementary: a Txn-Token
+propagates authorization context ("this request is authorized
+for scope X on behalf of user Y"), while an ECT records
+execution accountability ("task T was performed, depending on
+tasks P1 and P2, with policy Z evaluated and approved"). An
+agent request could carry both a Txn-Token for authorization
+and an ECT for execution recording. The WPT "tth" claim
+defined in can hash-bind a
+WPT to a co-present Txn-Token; a similar binding mechanism
+for ECTs is a potential future extension.Distributed Tracing (OpenTelemetry)
@@ -2348,7 +2518,9 @@ matching the WIT (ES256 recommended).
Verify ECT signatures against WIT public keys.Perform DAG validation (parent existence, temporal ordering,
cycle detection).
- Append verified ECTs to an audit ledger.
+ Store verified ECTs (append to audit ledger in full ledger
+mode, or retain locally in point-to-point mode per
+).
@@ -2447,6 +2619,7 @@ Agent B:
"aud": "spiffe://example.com/agent/validator",
"iat": 1772064150,
"exp": 1772064750,
+ "jti": "1a2b3c4d-e5f6-7890-abcd-ef0123456701",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"tid": "550e8400-e29b-41d4-a716-446655440001",
"exec_act": "fetch_patient_data",
@@ -2470,6 +2643,7 @@ task, and creates its own ECT:
"aud": "spiffe://example.com/system/ledger",
"iat": 1772064160,
"exp": 1772064760,
+ "jti": "2b3c4d5e-f6a7-8901-bcde-f01234567802",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"tid": "550e8400-e29b-41d4-a716-446655440002",
"exec_act": "validate_safety",
@@ -2505,6 +2679,7 @@ autonomous agents and human release approval:
"aud": "spiffe://meddev.example/agent/code-gen",
"iat": 1772064150,
"exp": 1772064750,
+ "jti": "3c4d5e6f-a7b8-9012-cdef-012345678903",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000001",
"exec_act": "review_requirements_spec",
@@ -2527,6 +2702,7 @@ autonomous agents and human release approval:
"aud": "spiffe://meddev.example/agent/test-runner",
"iat": 1772064200,
"exp": 1772064800,
+ "jti": "4d5e6f7a-b8c9-0123-def0-123456789004",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000002",
"exec_act": "implement_module",
@@ -2547,6 +2723,7 @@ autonomous agents and human release approval:
"aud": "spiffe://meddev.example/agent/build",
"iat": 1772064260,
"exp": 1772064860,
+ "jti": "5e6f7a8b-c9d0-1234-ef01-234567890005",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000003",
"exec_act": "execute_test_suite",
@@ -2567,6 +2744,7 @@ autonomous agents and human release approval:
"aud": "spiffe://meddev.example/human/release-mgr-42",
"iat": 1772064310,
"exp": 1772064910,
+ "jti": "6f7a8b9c-d0e1-2345-f012-345678900006",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000004",
"exec_act": "build_release_artifact",
@@ -2587,6 +2765,7 @@ autonomous agents and human release approval:
"aud": "spiffe://meddev.example/system/ledger",
"iat": 1772064510,
"exp": 1772065110,
+ "jti": "7a8b9c0d-e1f2-3456-0123-456789000007",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000005",
"exec_act": "approve_release",
@@ -2655,6 +2834,7 @@ task-...-0004 (execute_trade)
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772064250,
"exp": 1772064850,
+ "jti": "8b9c0d1e-f2a3-4567-1234-567890000008",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"tid": "f1e2d3c4-0004-0000-0000-000000000004",
"exec_act": "execute_trade",
@@ -2688,529 +2868,579 @@ tracing is built.