Christian Nennemann
102a120d65
- Eliminate the "tid" claim; "jti" now serves as both token ID (for replay detection) and task ID (for DAG parent references in "par") - Make "pol" and "pol_decision" OPTIONAL (must be paired when present) - Regulated deployments SHOULD still include policy claims - Reduces required ECT-specific claims to just "exec_act" and "par" - Remove "tid" from IANA JWT Claims registration - Update all examples, pseudocode, and DAG validation rules Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2190 lines
79 KiB
Markdown
2190 lines
79 KiB
Markdown
---
|
|
title: "Execution Context Tokens for Distributed Agentic Workflows"
|
|
abbrev: "WIMSE Execution Context"
|
|
category: std
|
|
docname: draft-nennemann-wimse-execution-context-00
|
|
submissiontype: IETF
|
|
number:
|
|
date:
|
|
v: 3
|
|
area: "Security"
|
|
workgroup: "WIMSE"
|
|
keyword:
|
|
- execution context
|
|
- workload identity
|
|
- agentic workflows
|
|
- audit trail
|
|
- compliance
|
|
- regulated systems
|
|
|
|
author:
|
|
-
|
|
fullname: Christian Nennemann
|
|
organization: Independent Researcher
|
|
email: ietf@nennemann.de
|
|
|
|
normative:
|
|
RFC7515:
|
|
RFC7517:
|
|
RFC7519:
|
|
RFC7518:
|
|
RFC9562:
|
|
RFC9110:
|
|
I-D.ietf-wimse-arch:
|
|
I-D.ietf-wimse-s2s-protocol:
|
|
|
|
informative:
|
|
RFC3552:
|
|
RFC8693:
|
|
RFC9421:
|
|
I-D.ni-wimse-ai-agent-identity:
|
|
SPIFFE:
|
|
title: "Secure Production Identity Framework for Everyone (SPIFFE)"
|
|
target: https://spiffe.io/docs/latest/spiffe-about/overview/
|
|
date: false
|
|
EU-AI-ACT:
|
|
title: "Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)"
|
|
target: https://eur-lex.europa.eu/eli/reg/2024/1689
|
|
date: 2024-06-13
|
|
author:
|
|
- org: European Parliament and Council of the European Union
|
|
FDA-21CFR11:
|
|
title: "Title 21, Code of Federal Regulations, Part 11: Electronic Records; Electronic Signatures"
|
|
target: https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
|
|
date: false
|
|
author:
|
|
- org: U.S. Food and Drug Administration
|
|
MIFID-II:
|
|
title: "Directive 2014/65/EU of the European Parliament and of the Council on markets in financial instruments (MiFID II)"
|
|
target: https://eur-lex.europa.eu/eli/dir/2014/65
|
|
date: 2014-05-15
|
|
author:
|
|
- org: European Parliament and Council of the European Union
|
|
DORA:
|
|
title: "Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)"
|
|
target: https://eur-lex.europa.eu/eli/reg/2022/2554
|
|
date: 2022-12-14
|
|
author:
|
|
- org: European Parliament and Council of the European Union
|
|
EU-MDR:
|
|
title: "Regulation (EU) 2017/745 on medical devices (MDR)"
|
|
target: https://eur-lex.europa.eu/eli/reg/2017/745
|
|
date: 2017-04-05
|
|
author:
|
|
- org: European Parliament and Council of the European Union
|
|
OPENTELEMETRY:
|
|
title: "OpenTelemetry Specification"
|
|
target: https://opentelemetry.io/docs/specs/otel/
|
|
date: false
|
|
author:
|
|
- org: Cloud Native Computing Foundation
|
|
I-D.ietf-scitt-architecture:
|
|
I-D.ietf-oauth-transaction-tokens:
|
|
I-D.oauth-transaction-tokens-for-agents:
|
|
|
|
--- abstract
|
|
|
|
This document defines Execution Context Tokens (ECTs), an extension
|
|
to the Workload Identity in Multi System Environments (WIMSE)
|
|
architecture for distributed agentic workflows in regulated
|
|
environments. ECTs provide cryptographic proof of task execution
|
|
order, policy enforcement decisions, and compliance state across
|
|
agent-to-agent communication. By extending WIMSE Workload Identity
|
|
Tokens with execution context claims in JSON Web Token (JWT)
|
|
format, this specification enables regulated systems to maintain
|
|
structured audit trails that support compliance verification.
|
|
ECTs use a directed acyclic graph (DAG) structure to represent task
|
|
dependencies, record policy evaluation outcomes at each decision
|
|
point, and integrate with WIMSE Workload Identity Tokens (WIT) and
|
|
Workload Proof Tokens (WPT) using the same signing model and
|
|
cryptographic primitives. A new HTTP header field,
|
|
Execution-Context, is defined for transporting ECTs alongside
|
|
existing WIMSE headers. ECTs are a technical building block that
|
|
supports, but does not by itself constitute, compliance with
|
|
regulatory frameworks.
|
|
|
|
--- middle
|
|
|
|
# Introduction
|
|
|
|
## Motivation
|
|
|
|
The Workload Identity in Multi System Environments (WIMSE)
|
|
framework {{I-D.ietf-wimse-arch}} provides robust workload
|
|
authentication through Workload Identity Tokens (WIT) and Workload
|
|
Proof Tokens (WPT). The WIMSE service-to-service protocol
|
|
{{I-D.ietf-wimse-s2s-protocol}} defines how workloads authenticate
|
|
each other across call chains using the Workload-Identity and
|
|
Workload-Proof-Token HTTP headers.
|
|
|
|
However, workload identity alone does not address execution
|
|
accountability. Knowing who performed an action does not prove
|
|
what was done, what policy was applied, or whether compliance
|
|
requirements were satisfied at each decision point.
|
|
|
|
Regulated environments increasingly deploy autonomous agents that
|
|
coordinate across organizational boundaries. Multiple regulatory
|
|
frameworks motivate the need for structured execution records:
|
|
|
|
- The EU Artificial Intelligence Act {{EU-AI-ACT}} Article 12
|
|
requires high-risk AI systems to be designed with capabilities
|
|
enabling automatic recording of events ("logs") while the
|
|
system is operating.
|
|
|
|
- The U.S. FDA 21 CFR Part 11 {{FDA-21CFR11}} requires
|
|
computer-generated, timestamped audit trails that independently
|
|
record the date, time, operator identity, and actions taken
|
|
(Section 11.10(e)).
|
|
|
|
- The Markets in Financial Instruments Directive (MiFID II)
|
|
{{MIFID-II}} requires firms to maintain records of transactions
|
|
and 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.
|
|
|
|
This document defines an extension to the WIMSE architecture that
|
|
addresses the gap between workload identity and execution
|
|
accountability. WIMSE authenticates agents; this extension records
|
|
what they did, in what order, and what policy was evaluated.
|
|
|
|
As identified in {{I-D.ni-wimse-ai-agent-identity}}, call context
|
|
in agentic workflows needs to be visible and preserved. ECTs
|
|
provide a mechanism to address this requirement with cryptographic
|
|
assurances.
|
|
|
|
## Problem Statement
|
|
|
|
Three core gaps exist in current approaches to regulated agentic
|
|
systems:
|
|
|
|
1. WIMSE authenticates agents but does not record what they
|
|
actually did. A WIT proves "Agent A is authorized" but not
|
|
"Agent A executed Task X, under Policy Y, producing Output Z."
|
|
|
|
2. No standard mechanism exists to record policy evaluation
|
|
outcomes at each decision point in a multi-agent workflow.
|
|
|
|
3. No mechanism exists to cryptographically link compensation and
|
|
rollback decisions to original actions.
|
|
|
|
Existing observability tools such as distributed tracing
|
|
{{OPENTELEMETRY}} provide visibility for debugging and monitoring
|
|
but do not provide cryptographic assurances. Tracing data is not
|
|
cryptographically signed, not tamper-evident, and not designed for
|
|
regulatory audit scenarios.
|
|
|
|
## Scope and Applicability
|
|
|
|
This document defines:
|
|
|
|
- The Execution Context Token (ECT) format ({{ect-format}})
|
|
- DAG structure for task dependency ordering ({{dag-validation}})
|
|
- Policy checkpoint recording ({{policy-claims}})
|
|
- Integration with the WIMSE identity framework
|
|
({{wimse-integration}})
|
|
- An HTTP header for ECT transport ({{http-header}})
|
|
- Operational modes including ledger-optional deployment
|
|
({{operational-modes}})
|
|
- Audit ledger interface requirements ({{ledger-interface}})
|
|
|
|
The following are out of scope and are handled by WIMSE:
|
|
|
|
- Workload authentication and identity provisioning
|
|
- Key distribution and management
|
|
- Trust domain establishment and management
|
|
- Credential lifecycle management
|
|
|
|
## Relationship to Regulatory Compliance
|
|
|
|
ECTs are a technical mechanism that can support compliance programs
|
|
by providing structured, cryptographically signed execution
|
|
records. ECTs do not by themselves constitute compliance with any
|
|
regulatory framework referenced in this document.
|
|
|
|
Compliance with each referenced regulation requires organizational
|
|
controls, policies, procedures, validation, and governance measures
|
|
beyond the scope of this specification. The regulatory references
|
|
in this document are intended to motivate the design requirements,
|
|
not to claim that implementing ECTs satisfies these regulations.
|
|
|
|
ECTs provide evidence of claimed execution ordering and policy
|
|
evaluation. They do not independently verify that the claimed
|
|
execution actually occurred as described, that the policy
|
|
evaluation was correct, or that the agent faithfully performed the
|
|
stated action. The trustworthiness of ECT claims depends on the
|
|
trustworthiness of the signing agent and the integrity of the
|
|
broader deployment environment.
|
|
|
|
# Conventions and Definitions
|
|
|
|
{::boilerplate bcp14-tagged}
|
|
|
|
The following terms are used in this document:
|
|
|
|
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.
|
|
|
|
Execution Context Token (ECT):
|
|
: A JSON Web Token {{RFC7519}} defined by this specification that
|
|
records task execution details and policy evaluation outcomes.
|
|
|
|
Audit Ledger:
|
|
: An append-only, immutable log of all ECTs within a workflow or
|
|
set of workflows, used for regulatory audit and compliance
|
|
verification.
|
|
|
|
Policy Checkpoint:
|
|
: A point in a workflow where a policy evaluation outcome is
|
|
recorded within an ECT.
|
|
|
|
Workload Identity Token (WIT):
|
|
: A WIMSE credential proving a workload's identity within a trust
|
|
domain.
|
|
|
|
Workload Proof Token (WPT):
|
|
: A WIMSE proof-of-possession token used for request-level
|
|
authentication.
|
|
|
|
Trust Domain:
|
|
: A WIMSE concept representing an organizational boundary with a
|
|
shared identity issuer, corresponding to a SPIFFE {{SPIFFE}}
|
|
trust domain.
|
|
|
|
Witness:
|
|
: A third-party entity that observes and attests to the execution
|
|
of a task, providing additional accountability.
|
|
|
|
# WIMSE Architecture Integration {#wimse-integration}
|
|
|
|
## WIMSE Foundation
|
|
|
|
The WIMSE architecture {{I-D.ietf-wimse-arch}} defines:
|
|
|
|
- Workload Identity Tokens (WIT) that prove a workload's identity
|
|
within a trust domain ("I am Agent X in trust domain Y")
|
|
- Workload Proof Tokens (WPT) that prove possession of the private
|
|
key associated with a WIT ("I control the key for Agent X")
|
|
- Multi-hop authentication via the service-to-service protocol
|
|
{{I-D.ietf-wimse-s2s-protocol}}
|
|
|
|
The following execution accountability needs are complementary to
|
|
the WIMSE scope and are not addressed by workload identity alone:
|
|
|
|
- Recording what agents actually do with their authenticated
|
|
identity
|
|
- Recording policy evaluation outcomes at each hop
|
|
- Maintaining structured execution records
|
|
- Linking compensation or rollback actions to original tasks
|
|
|
|
## Extension Model
|
|
|
|
ECTs extend WIMSE by adding an execution accountability layer
|
|
between the identity layer and the application layer:
|
|
|
|
~~~ ascii-art
|
|
+--------------------------------------------------+
|
|
| WIMSE Layer (Identity) |
|
|
| WIT: "I am Agent X (spiffe://td/agent/x)" |
|
|
| WPT: "I prove I control the key for Agent X" |
|
|
+--------------------------------------------------+
|
|
|
|
|
v
|
|
+--------------------------------------------------+
|
|
| ECT Layer (Execution Accountability) [This Spec]|
|
|
| ECT: "Task executed, dependencies met, |
|
|
| policy evaluated, outcome recorded" |
|
|
+--------------------------------------------------+
|
|
|
|
|
v
|
|
+--------------------------------------------------+
|
|
| Ledger Layer (Immutable Record) |
|
|
| "All ECTs appended to audit ledger" |
|
|
+--------------------------------------------------+
|
|
~~~
|
|
{: #fig-layers title="WIMSE Extension Architecture Layers"}
|
|
|
|
This extension reuses the WIMSE signing model, extends JWT claims
|
|
using standard JWT extensibility {{RFC7519}}, and maintains WIMSE
|
|
concepts including trust domains and workload identifiers.
|
|
|
|
## Integration Points {#integration-points}
|
|
|
|
An ECT integrates with the WIMSE identity framework through the
|
|
following mechanisms:
|
|
|
|
- The ECT JOSE header "kid" parameter MUST reference the public
|
|
key identifier from the agent's WIT.
|
|
|
|
- The ECT "iss" claim MUST use the WIMSE workload identifier
|
|
format (a SPIFFE ID {{SPIFFE}}).
|
|
|
|
- The ECT MUST be signed with the same private key used to
|
|
generate the agent's WPT.
|
|
|
|
- The ECT signing algorithm (JOSE header "alg" parameter) MUST
|
|
match the algorithm used in the corresponding WIT.
|
|
|
|
When an agent makes an HTTP request to another agent, the three
|
|
tokens are carried in their respective HTTP header fields:
|
|
|
|
~~~ ascii-art
|
|
HTTP Request from Agent A to Agent B:
|
|
Workload-Identity: <WIT for Agent A>
|
|
Workload-Proof-Token: <WPT proving A controls key>
|
|
Execution-Context: <ECT recording what A did>
|
|
~~~
|
|
{: #fig-http-headers title="HTTP Header Stacking"}
|
|
|
|
The receiving agent (Agent B) verifies in order:
|
|
|
|
1. WIT and WPT (WIMSE layer): Proves who Agent A is and that the
|
|
request is authentic.
|
|
|
|
2. ECT (this extension): Records what Agent A did, what policy was
|
|
evaluated, and what precedent tasks exist.
|
|
|
|
3. Ledger: Appends the verified ECT to the audit ledger.
|
|
|
|
# Execution Context Token Format {#ect-format}
|
|
|
|
An Execution Context Token is a JSON Web Token (JWT) {{RFC7519}}
|
|
signed as a JSON Web Signature (JWS) {{RFC7515}} using the Compact
|
|
Serialization. JWS JSON Serialization MUST NOT be used for ECTs.
|
|
|
|
## JOSE Header {#jose-header}
|
|
|
|
The ECT JOSE header MUST contain the following parameters:
|
|
|
|
~~~json
|
|
{
|
|
"alg": "ES256",
|
|
"typ": "wimse-exec+jwt",
|
|
"kid": "agent-a-key-id-123"
|
|
}
|
|
~~~
|
|
{: #fig-header title="ECT JOSE Header Example"}
|
|
|
|
alg:
|
|
: REQUIRED. The digital signature algorithm used to sign the 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, HS512) MUST NOT be used, as ECTs require asymmetric
|
|
signatures for non-repudiation.
|
|
|
|
typ:
|
|
: REQUIRED. MUST be set to "wimse-exec+jwt" to distinguish ECTs
|
|
from other JWT types, consistent with the WIMSE convention for
|
|
type parameter values.
|
|
|
|
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.
|
|
|
|
## JWT Claims {#jwt-claims}
|
|
|
|
The ECT payload contains both WIMSE-compatible standard JWT claims
|
|
and execution context claims defined by this specification.
|
|
|
|
### Standard JWT Claims
|
|
|
|
The following standard JWT claims {{RFC7519}} MUST be present in
|
|
every ECT:
|
|
|
|
iss:
|
|
: REQUIRED. StringOrURI. The issuer of the ECT, which MUST be
|
|
the workload's SPIFFE ID in the format
|
|
`spiffe://<trust-domain>/<path>`. This MUST match the "sub"
|
|
claim of the agent's WIT.
|
|
|
|
sub:
|
|
: OPTIONAL. StringOrURI. The subject of the ECT. When present,
|
|
MUST equal the "iss" claim. This claim is included for
|
|
compatibility with JWT libraries and frameworks that expect a
|
|
"sub" claim to be present.
|
|
|
|
aud:
|
|
: REQUIRED. StringOrURI or array of StringOrURI. The intended
|
|
recipient(s) of the ECT. Because ECTs serve as both inter-agent
|
|
messages and audit records, the "aud" claim SHOULD contain the
|
|
identifiers of all entities that will verify the ECT. In
|
|
practice this means:
|
|
|
|
* **Point-to-point delivery**: when an ECT is sent from one
|
|
agent to a single next agent, "aud" contains that agent's
|
|
workload identity. The receiving agent verifies the ECT and
|
|
forwards it to the ledger on behalf of the issuer.
|
|
|
|
* **Direct-to-ledger submission**: when an ECT is submitted
|
|
directly to the audit ledger (e.g., after a join or at
|
|
workflow completion), "aud" contains the ledger's identity.
|
|
|
|
* **Multi-audience**: when an ECT must be verified by both the
|
|
next agent and the ledger independently, "aud" MUST be an
|
|
array containing both identifiers (e.g.,
|
|
\["spiffe://example.com/agent/next",
|
|
"spiffe://example.com/system/ledger"\]). Each verifier checks
|
|
that its own identity appears in the array.
|
|
|
|
In multi-parent (join) scenarios where a task depends on ECTs
|
|
from multiple parent agents, the joining agent creates a new ECT
|
|
with the parent task IDs in "par". The "aud" of this new ECT
|
|
is set according to the rules above based on where the ECT will
|
|
be delivered — it is independent of the "aud" values in the
|
|
parent ECTs.
|
|
|
|
iat:
|
|
: REQUIRED. NumericDate. The time at which the ECT was issued.
|
|
The ECT records a completed action, so the "iat" value reflects
|
|
when the record was created, not when task execution began.
|
|
|
|
exp:
|
|
: REQUIRED. NumericDate. The expiration time of the ECT.
|
|
Implementations SHOULD set this to 5 to 15 minutes after "iat"
|
|
to limit the replay window while allowing for reasonable clock
|
|
skew and processing time.
|
|
|
|
The standard JWT "nbf" (Not Before) claim is not used in ECTs
|
|
because ECTs record completed actions and are valid immediately
|
|
upon issuance.
|
|
|
|
jti:
|
|
: REQUIRED. String. A globally unique identifier for both the
|
|
ECT and the task it records, in UUID format {{RFC9562}}. Since
|
|
each ECT represents exactly one task, "jti" serves as both the
|
|
token identifier (for replay detection) and the task identifier
|
|
(for DAG parent references in "par"). Receivers MUST reject
|
|
ECTs whose "jti" has already been seen within the expiration
|
|
window. When "wid" is present, uniqueness is scoped to the
|
|
workflow; when "wid" is absent, uniqueness MUST be enforced
|
|
globally across the ECT store.
|
|
|
|
### Execution Context {#exec-claims}
|
|
|
|
The following claims are defined by this specification:
|
|
|
|
wid:
|
|
: OPTIONAL. String. A workflow identifier that groups related
|
|
ECTs into a single workflow. When present, MUST be a UUID
|
|
{{RFC9562}}.
|
|
|
|
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
|
|
representing DAG dependencies. Each element MUST be the "jti"
|
|
value of a previously verified ECT. An empty array indicates
|
|
a root task with no dependencies. A workflow MAY contain
|
|
multiple root tasks.
|
|
|
|
### Policy Evaluation {#policy-claims}
|
|
|
|
The following claims record policy evaluation outcomes:
|
|
|
|
pol:
|
|
: OPTIONAL. String. The identifier of the policy rule that was
|
|
evaluated for this task (e.g.,
|
|
"clinical_data_access_policy_v1"). MUST be present when
|
|
"pol_decision" is present.
|
|
|
|
pol_decision:
|
|
: OPTIONAL. String. The result of the policy evaluation. When
|
|
present, MUST be one of the values registered in the ECT Policy
|
|
Decision Values registry ({{pol-decision-registry}}). MUST be
|
|
present when "pol" is present. Initial values are:
|
|
|
|
* "approved": The policy evaluation succeeded and the task
|
|
was authorized to proceed.
|
|
|
|
* "rejected": The policy evaluation failed. A "rejected" ECT
|
|
MUST still be recorded for accountability. An ECT with
|
|
"pol_decision" of "rejected" MAY appear as a parent in the
|
|
"par" array of a subsequent ECT, but only for compensation,
|
|
rollback, or remediation tasks. Agents MUST NOT proceed
|
|
with normal workflow execution based on a parent ECT whose
|
|
"pol_decision" is "rejected".
|
|
|
|
* "pending_human_review": The policy evaluation requires human
|
|
judgment before proceeding. Agents MUST NOT proceed with
|
|
dependent tasks until a subsequent ECT from a human reviewer
|
|
records an "approved" decision referencing this task as a
|
|
parent.
|
|
|
|
When "pol" and "pol_decision" are absent, the ECT records task
|
|
execution without a policy checkpoint. Regulated deployments
|
|
SHOULD include policy claims on all ECTs to maintain complete
|
|
audit trails.
|
|
|
|
pol_enforcer:
|
|
: OPTIONAL. StringOrURI. The identity of the entity (system or
|
|
person) that evaluated the policy decision. When present,
|
|
SHOULD use SPIFFE ID format.
|
|
|
|
pol_timestamp:
|
|
: OPTIONAL. NumericDate. The time at which the policy 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 framework (e.g., OPA/Rego, Cedar, XACML,
|
|
or custom solutions) provided that the evaluation outcome is
|
|
faithfully recorded in the ECT claims defined above.
|
|
|
|
### Data Integrity {#data-integrity-claims}
|
|
|
|
The following claims provide integrity verification for task
|
|
inputs and outputs without revealing the data itself:
|
|
|
|
inp_hash:
|
|
: OPTIONAL. String. A cryptographic hash of the input data,
|
|
formatted as "hash-algorithm:base64url-encoded-hash" (e.g.,
|
|
"sha-256:n4bQgYhMfWWaL-qgxVrQFaO\_TxsrC4Is0V1sFbDwCgg"). The
|
|
hash algorithm identifier MUST be a lowercase value from the
|
|
IANA Named Information Hash Algorithm Registry (e.g., "sha-256",
|
|
"sha-384", "sha-512"). Implementations MUST support "sha-256"
|
|
and SHOULD use "sha-256" unless a stronger algorithm is
|
|
required. Implementations MUST NOT accept hash algorithms
|
|
weaker than SHA-256 (e.g., MD5, SHA-1). The hash MUST be
|
|
computed over the raw octets of the input data.
|
|
|
|
out_hash:
|
|
: OPTIONAL. String. A cryptographic hash of the output data,
|
|
using the same format and algorithm requirements as "inp_hash".
|
|
|
|
inp_classification:
|
|
: OPTIONAL. String. The data sensitivity classification of the
|
|
input (e.g., "public", "confidential", "restricted").
|
|
|
|
### Task Metadata {#operational-claims}
|
|
|
|
The following claims provide additional context about task
|
|
execution:
|
|
|
|
exec_time_ms:
|
|
: OPTIONAL. Integer. The execution duration of the task in
|
|
milliseconds. MUST be a non-negative integer.
|
|
|
|
regulated_domain:
|
|
: OPTIONAL. String. The regulatory domain applicable to this
|
|
task. Values MUST be registered in the ECT Regulated Domain
|
|
Values registry ({{regulated-domain-registry}}).
|
|
|
|
model_version:
|
|
: OPTIONAL. String. The version identifier of the AI or ML model
|
|
used to perform the task, if applicable.
|
|
|
|
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
|
|
{{witness-attestation-model}}). In regulated environments,
|
|
implementations SHOULD use witness attestation for critical
|
|
decision points to mitigate the risk of single-agent false
|
|
claims. See also {{self-assertion-limitation}} for the security
|
|
implications of self-asserted witness claims.
|
|
|
|
### Compensation and Rollback {#compensation-claims}
|
|
|
|
compensation_required:
|
|
: OPTIONAL. Boolean. Indicates whether this task is a
|
|
compensation or rollback action for a previous task.
|
|
|
|
compensation_reason:
|
|
: OPTIONAL. String. A human-readable reason for the compensation
|
|
action. MUST be present if "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
|
|
{{data-minimization}} for privacy guidance.
|
|
If "compensation_reason" is present, "compensation_required"
|
|
MUST be true.
|
|
|
|
Note: compensation ECTs reference historical parent tasks via the
|
|
"par" claim. The referenced parent ECTs may have passed their own
|
|
"exp" time; ECT expiration applies to the verification window of
|
|
the ECT itself, not to its validity as a parent reference in the
|
|
ledger.
|
|
|
|
### Extensions {#extension-claims}
|
|
|
|
ext:
|
|
: OPTIONAL. Object. An extension object for domain-specific
|
|
claims not defined by this specification. Implementations
|
|
that do not understand extension claims MUST ignore them.
|
|
|
|
To avoid key collisions between different domains, extension
|
|
key names MUST use reverse domain notation (e.g.,
|
|
"com.example.custom_field"). Implementations MUST NOT use
|
|
unqualified key names within the "ext" object. To prevent
|
|
abuse and excessive token size, the serialized JSON
|
|
representation of the "ext" object SHOULD NOT exceed 4096
|
|
bytes, and the JSON nesting depth within the "ext" object
|
|
SHOULD NOT exceed 5 levels. Implementations SHOULD reject
|
|
ECTs whose "ext" claim exceeds these limits.
|
|
|
|
## Complete ECT Example
|
|
|
|
The following is a complete ECT payload example:
|
|
|
|
~~~json
|
|
{
|
|
"iss": "spiffe://example.com/agent/clinical",
|
|
"sub": "spiffe://example.com/agent/clinical",
|
|
"aud": "spiffe://example.com/agent/safety",
|
|
"iat": 1772064150,
|
|
"exp": 1772064750,
|
|
"jti": "550e8400-e29b-41d4-a716-446655440001",
|
|
|
|
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
|
|
"exec_act": "recommend_treatment",
|
|
"par": [],
|
|
|
|
"pol": "clinical_reasoning_policy_v2",
|
|
"pol_decision": "approved",
|
|
"pol_enforcer": "spiffe://example.com/policy/clinical-engine",
|
|
"pol_timestamp": 1772064145,
|
|
|
|
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
|
|
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
|
|
"inp_classification": "confidential",
|
|
"exec_time_ms": 245,
|
|
"regulated_domain": "medtech",
|
|
"model_version": "clinical-reasoning-v4.2",
|
|
|
|
"witnessed_by": [
|
|
"spiffe://example.com/audit/observer-1"
|
|
]
|
|
}
|
|
~~~
|
|
{: #fig-full-ect title="Complete ECT Payload Example"}
|
|
|
|
# HTTP Header Transport {#http-header}
|
|
|
|
## Execution-Context Header Field
|
|
|
|
This specification defines the Execution-Context HTTP header field
|
|
{{RFC9110}} for transporting ECTs between agents.
|
|
|
|
The header field value is the ECT in JWS Compact Serialization
|
|
format {{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:
|
|
|
|
~~~
|
|
GET /api/safety-check HTTP/1.1
|
|
Host: safety-agent.example.com
|
|
Workload-Identity: eyJhbGci...WIT...
|
|
Workload-Proof-Token: eyJhbGci...WPT...
|
|
Execution-Context: eyJhbGci...ECT...
|
|
~~~
|
|
{: #fig-http-example title="HTTP Request with ECT Header"}
|
|
|
|
When multiple parent tasks contribute context to a single request,
|
|
multiple Execution-Context header field lines MAY be included, each
|
|
carrying a separate ECT in JWS Compact Serialization format.
|
|
|
|
When a receiver processes multiple Execution-Context headers, it
|
|
MUST individually verify each ECT per the procedure in
|
|
{{verification}}. If any single ECT fails verification, the
|
|
receiver MUST reject the entire request. The set of verified
|
|
parent task IDs across all received ECTs represents the complete
|
|
set of parent dependencies available for the receiving agent's
|
|
subsequent ECT.
|
|
|
|
# DAG Validation {#dag-validation}
|
|
|
|
## Overview
|
|
|
|
ECTs form a Directed Acyclic Graph (DAG) where each task
|
|
references its parent tasks via the "par" claim. This structure
|
|
provides a cryptographically signed record of execution ordering,
|
|
enabling auditors to reconstruct the complete workflow and verify
|
|
that required predecessor tasks were recorded before dependent
|
|
tasks.
|
|
|
|
DAG validation 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
|
|
{{operational-modes}}). 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
|
|
|
|
When receiving and verifying an ECT, implementations MUST perform
|
|
the following DAG validation steps:
|
|
|
|
1. Task ID Uniqueness: The "jti" claim MUST be unique within the
|
|
applicable scope (the workflow identified by "wid", or the
|
|
entire ECT store if "wid" is absent). If an ECT with the same
|
|
"jti" 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 ECT store), not by
|
|
timestamps. If any parent task violates this constraint, the
|
|
ECT MUST be rejected.
|
|
|
|
4. Acyclicity: Following the chain of parent references MUST NOT
|
|
lead back to the current ECT's "jti". If a cycle is detected,
|
|
the ECT MUST be rejected.
|
|
|
|
5. Parent Policy Decision: If any parent ECT contains a
|
|
"pol_decision" of "rejected" or "pending_human_review", the
|
|
current ECT's "exec_act" MUST indicate a compensation,
|
|
rollback, remediation, or human review action.
|
|
Implementations MUST NOT accept an ECT representing normal
|
|
workflow continuation when a parent's "pol_decision" is not
|
|
"approved", unless the current ECT has "compensation_required"
|
|
set to true. This rule only applies when the parent ECT
|
|
contains policy claims.
|
|
|
|
6. Trust Domain Consistency: Parent tasks SHOULD belong to the
|
|
same trust domain or to a trust domain with which a federation
|
|
relationship has been established.
|
|
|
|
## DAG Validation Algorithm
|
|
|
|
The following pseudocode describes the DAG validation procedure:
|
|
|
|
~~~ pseudocode
|
|
function validate_dag(ect, ect_store, clock_skew_tolerance):
|
|
// ect_store: ledger or local cache of verified ECTs
|
|
// Step 1: Uniqueness check
|
|
if ect_store.contains(ect.jti, ect.wid):
|
|
return error("ECT ID already exists")
|
|
|
|
// Step 2: Parent existence and temporal ordering
|
|
for parent_id in ect.par:
|
|
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:
|
|
return error("Parent task not earlier than current")
|
|
|
|
// Step 3: Cycle detection (with traversal limit)
|
|
visited = set()
|
|
result = has_cycle(ect.jti, 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_jti, 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:
|
|
if parent_id == target_jti:
|
|
return true
|
|
if parent_id in visited:
|
|
continue
|
|
visited.add(parent_id)
|
|
parent = ect_store.get(parent_id)
|
|
if parent is not null:
|
|
result = has_cycle(target_jti, parent.par, ect_store,
|
|
visited, max_depth)
|
|
if result is error or result is true:
|
|
return result
|
|
return false
|
|
~~~
|
|
{: #fig-dag-validation title="DAG Validation Pseudocode"}
|
|
|
|
The cycle detection traverses the ancestor graph rooted at the
|
|
current task's parents. The complexity is O(V) where V is the
|
|
number 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 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 verified tasks to avoid redundant traversals.
|
|
|
|
# Signature and Token Verification {#verification}
|
|
|
|
## Verification Procedure
|
|
|
|
When an agent receives an ECT, it MUST perform the following
|
|
verification steps in order:
|
|
|
|
1. Parse the JWS Compact Serialization to extract the JOSE header,
|
|
payload, and signature components per {{RFC7515}}.
|
|
|
|
2. Verify that the "typ" header parameter is "wimse-exec+jwt".
|
|
|
|
3. Verify that the "alg" header parameter is not "none" and is
|
|
not a symmetric algorithm.
|
|
|
|
4. Verify the "kid" header parameter references a known, valid
|
|
public key from a WIT within the trust domain.
|
|
|
|
5. Retrieve the public key identified by "kid" and verify the JWS
|
|
signature per {{RFC7515}} Section 5.2.
|
|
|
|
6. Verify that the signing key identified by "kid" has not been
|
|
revoked within the trust domain. Implementations MUST check
|
|
the key's revocation status using the trust domain's key
|
|
lifecycle mechanism (e.g., certificate revocation list, OCSP,
|
|
or SPIFFE trust bundle updates).
|
|
|
|
7. Verify the "alg" header parameter matches the algorithm in the
|
|
corresponding WIT.
|
|
|
|
8. Verify the "iss" claim matches the "sub" claim of the WIT
|
|
associated with the "kid" public key.
|
|
|
|
9. Verify the "aud" claim contains the verifier's own workload
|
|
identity. When "aud" is an array, it is sufficient that the
|
|
verifier's identity appears as one element; the presence of
|
|
other audience values does not cause verification failure.
|
|
When the verifier is the audit ledger, the ledger's own
|
|
identity MUST appear in "aud".
|
|
|
|
10. Verify the "exp" claim indicates the ECT has not expired.
|
|
|
|
11. Verify the "iat" claim is not unreasonably far in the past
|
|
(implementation-specific threshold, RECOMMENDED maximum of
|
|
15 minutes) and is not unreasonably far in the future
|
|
(RECOMMENDED: no more than 30 seconds ahead of the
|
|
verifier's current time, to account for clock skew).
|
|
|
|
12. Verify all required claims ("jti", "exec_act", "par") are
|
|
present and well-formed.
|
|
|
|
13. If "pol" or "pol_decision" is present, verify that both are
|
|
present and that "pol_decision" is one of "approved",
|
|
"rejected", or "pending_human_review".
|
|
|
|
14. Perform DAG validation per {{dag-validation}}.
|
|
|
|
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
|
|
SHOULD NOT reveal whether specific parent task IDs exist in the
|
|
ledger, to prevent information disclosure.
|
|
|
|
When ECT verification fails during HTTP request processing, the
|
|
receiving agent SHOULD respond with HTTP 403 (Forbidden) if the
|
|
WIT and WPT are valid but the ECT is invalid, and HTTP 401
|
|
(Unauthorized) if the ECT signature verification fails. The
|
|
response body SHOULD include a generic error indicator without
|
|
revealing which specific verification step failed. The receiving
|
|
agent MUST NOT process the requested action when ECT verification
|
|
fails.
|
|
|
|
## Verification Pseudocode
|
|
|
|
~~~ pseudocode
|
|
function verify_ect(ect_jws, verifier_id,
|
|
trust_domain_keys, ledger):
|
|
// Parse JWS
|
|
(header, payload, signature) = parse_jws(ect_jws)
|
|
|
|
// Verify header
|
|
if header.typ != "wimse-exec+jwt":
|
|
return reject("Invalid typ parameter")
|
|
|
|
if header.alg == "none" or is_symmetric(header.alg):
|
|
return reject("Prohibited algorithm")
|
|
|
|
// Look up public key
|
|
public_key = trust_domain_keys.get(header.kid)
|
|
if public_key is null:
|
|
return reject("Unknown key identifier")
|
|
|
|
// Verify signature
|
|
if not verify_jws_signature(header, payload,
|
|
signature, public_key):
|
|
return reject("Invalid signature")
|
|
|
|
// Verify key not revoked
|
|
if is_key_revoked(header.kid, trust_domain_keys):
|
|
return reject("Signing key has been revoked")
|
|
|
|
// Verify algorithm alignment
|
|
wit = get_wit_for_key(header.kid)
|
|
if header.alg != wit.alg:
|
|
return reject("Algorithm mismatch with WIT")
|
|
|
|
// Verify issuer matches WIT subject
|
|
if payload.iss != wit.sub:
|
|
return reject("Issuer does not match WIT subject")
|
|
|
|
// Verify audience
|
|
if verifier_id not in payload.aud:
|
|
return reject("ECT not intended for this recipient")
|
|
|
|
// Verify not expired
|
|
if payload.exp < current_time():
|
|
return reject("ECT has expired")
|
|
|
|
// Verify iat freshness (not too old, not in the future)
|
|
if payload.iat < current_time() - max_age_threshold:
|
|
return reject("ECT issued too long ago")
|
|
if payload.iat > current_time() + clock_skew_tolerance:
|
|
return reject("ECT issued in the future")
|
|
|
|
// Verify required claims
|
|
for claim in ["jti", "exec_act", "par"]:
|
|
if claim not in payload:
|
|
return reject("Missing required claim: " + claim)
|
|
|
|
// Validate policy claims (optional, but must be paired)
|
|
if "pol" in payload or "pol_decision" in payload:
|
|
if "pol" not in payload or "pol_decision" not in payload:
|
|
return reject("pol and pol_decision must both be present")
|
|
if payload.pol_decision not in
|
|
["approved", "rejected", "pending_human_review"]:
|
|
return reject("Invalid pol_decision value")
|
|
|
|
// 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
|
|
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 "jti" 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
|
|
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.
|
|
|
|
## Required Properties
|
|
|
|
An audit ledger implementation MUST provide:
|
|
|
|
1. Append-only semantics: Once an ECT is recorded, it MUST NOT be
|
|
modified or deleted.
|
|
|
|
2. Ordering: The ledger MUST maintain a total ordering of ECT
|
|
entries via a monotonically increasing sequence number.
|
|
|
|
3. Lookup by task ID: The ledger MUST support efficient retrieval
|
|
of ECT entries by "jti" value.
|
|
|
|
4. Integrity verification: The ledger SHOULD provide a mechanism
|
|
to verify that no entries have been tampered with (e.g.,
|
|
hash chains or Merkle trees).
|
|
|
|
The ledger SHOULD be maintained by an entity independent of the
|
|
workflow agents to reduce the risk of collusion.
|
|
|
|
## Ledger Entry Structure
|
|
|
|
Each ledger entry is a logical record containing:
|
|
|
|
~~~json
|
|
{
|
|
"ledger_sequence": 42,
|
|
"ect_jti": "550e8400-e29b-41d4-a716-446655440001",
|
|
"agent_id": "spiffe://example.com/agent/clinical",
|
|
"action": "recommend_treatment",
|
|
"parents": [],
|
|
"ect_jws": "eyJhbGciOiJFUzI1NiIs...<complete JWS>",
|
|
"signature_verified": true,
|
|
"verification_timestamp": "2026-02-24T15:42:31.000Z",
|
|
"stored_timestamp": "2026-02-24T15:42:31.050Z"
|
|
}
|
|
~~~
|
|
{: #fig-ledger-entry title="Ledger Entry Example"}
|
|
|
|
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.
|
|
|
|
# Use Cases {#use-cases}
|
|
|
|
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
|
|
readability. In production, all "jti" values are required to be
|
|
UUIDs per {{exec-claims}}.
|
|
|
|
## Medical Device SDLC Workflow
|
|
|
|
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):
|
|
jti: task-001 par: []
|
|
exec_act: review_requirements_spec
|
|
pol: spec_review_policy_v2 pol_decision: approved
|
|
|
|
Agent B (Code Generator):
|
|
jti: task-002 par: [task-001]
|
|
exec_act: implement_module
|
|
pol: coding_standards_v3 pol_decision: approved
|
|
|
|
Agent C (Test Agent):
|
|
jti: task-003 par: [task-002]
|
|
exec_act: execute_test_suite
|
|
pol: test_coverage_policy_v1 pol_decision: approved
|
|
|
|
Agent D (Build Agent):
|
|
jti: task-004 par: [task-003]
|
|
exec_act: build_release_artifact
|
|
pol: build_validation_v2 pol_decision: approved
|
|
|
|
Human Release Manager:
|
|
jti: task-005 par: [task-004]
|
|
exec_act: approve_release
|
|
pol: release_approval_policy pol_decision: approved
|
|
pol_enforcer: spiffe://meddev.example/human/release-mgr-42
|
|
witnessed_by: [spiffe://meddev.example/audit/qa-observer-1]
|
|
~~~
|
|
{: #fig-medtech-sdlc title="Medical Device SDLC Workflow"}
|
|
|
|
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.
|
|
|
|
### 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:
|
|
|
|
~~~
|
|
task-001 (review_requirements_spec)
|
|
|
|
|
v
|
|
task-002 (implement_module)
|
|
|
|
|
v
|
|
task-003 (execute_test_suite)
|
|
|
|
|
v
|
|
task-004 (build_release_artifact)
|
|
|
|
|
v
|
|
task-005 (approve_release) [human, witnessed]
|
|
~~~
|
|
{: #fig-fda-audit title="Reconstructed DAG for FDA Audit"}
|
|
|
|
The reconstructed DAG provides cryptographic evidence that:
|
|
|
|
- Each phase was executed by an identified and authenticated agent.
|
|
- Policy checkpoints were evaluated at every phase transition.
|
|
- The execution sequence was maintained (no step was bypassed).
|
|
- A human-in-the-loop approved the final release, with independent
|
|
witness attestation.
|
|
- Timestamps and execution durations are recorded for each step.
|
|
|
|
This can contribute to compliance with:
|
|
|
|
- {{FDA-21CFR11}} Section 11.10(e): Computer-generated audit trails
|
|
that record the date, time, and identity of the operator.
|
|
- {{EU-MDR}} Annex II: Technical documentation traceability for the
|
|
software development lifecycle.
|
|
- {{EU-AI-ACT}} Article 12: Automatic logging capabilities for
|
|
high-risk AI systems involved in the development process.
|
|
- {{EU-AI-ACT}} Article 14: ECTs can record evidence that human
|
|
oversight events occurred during the release process.
|
|
|
|
## 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.
|
|
|
|
~~~
|
|
Agent A (Risk Assessment):
|
|
jti: task-001 par: []
|
|
exec_act: calculate_risk_exposure
|
|
pol: risk_limits_policy_v2 pol_decision: approved
|
|
|
|
Agent B (Compliance):
|
|
jti: task-002 par: [task-001]
|
|
exec_act: verify_compliance
|
|
pol: compliance_check_v1 pol_decision: approved
|
|
|
|
Agent C (Execution):
|
|
jti: task-003 par: [task-002]
|
|
exec_act: execute_trade
|
|
pol: execution_policy_v3 pol_decision: approved
|
|
~~~
|
|
{: #fig-finance title="Financial Trading Workflow"}
|
|
|
|
This can contribute to compliance with:
|
|
|
|
- {{MIFID-II}}: ECTs provide cryptographic records of the execution
|
|
sequence that can support transaction audit requirements.
|
|
- {{DORA}} Article 12: ECTs contribute to ICT activity logging.
|
|
- {{EU-AI-ACT}} Article 12: Logging of decisions made by AI-driven
|
|
systems.
|
|
|
|
## Compensation and Rollback
|
|
|
|
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:
|
|
|
|
~~~json
|
|
{
|
|
"iss": "spiffe://bank.example/agent/operations",
|
|
"sub": "spiffe://bank.example/agent/operations",
|
|
"aud": "spiffe://bank.example/system/ledger",
|
|
"iat": 1772150550,
|
|
"exp": 1772151150,
|
|
"jti": "550e8400-e29b-41d4-a716-446655440099",
|
|
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
|
|
"exec_act": "initiate_trade_rollback",
|
|
"par": ["550e8400-e29b-41d4-a716-446655440003"],
|
|
"pol": "compensation_policy_v1",
|
|
"pol_decision": "approved",
|
|
"pol_enforcer": "spiffe://bank.example/human/compliance-officer",
|
|
"compensation_required": true,
|
|
"compensation_reason": "policy_violation_in_parent_trade"
|
|
}
|
|
~~~
|
|
{: #fig-compensation title="Compensation ECT Example"}
|
|
|
|
The "par" claim links the compensation action to the original
|
|
trade, creating an auditable chain from execution through
|
|
violation discovery to remediation.
|
|
|
|
## Autonomous Logistics Coordination
|
|
|
|
In a logistics workflow, multiple compliance checks complete
|
|
before shipment commitment. The DAG structure records that all
|
|
required checks were completed:
|
|
|
|
~~~
|
|
Agent A (Route Planning):
|
|
jti: task-001 par: []
|
|
exec_act: plan_route
|
|
pol: route_policy_v1 pol_decision: approved
|
|
|
|
Agent B (Customs):
|
|
jti: task-002 par: [task-001]
|
|
exec_act: validate_customs
|
|
pol: customs_policy_v2 pol_decision: approved
|
|
|
|
Agent C (Safety):
|
|
jti: task-003 par: [task-001]
|
|
exec_act: verify_cargo_safety
|
|
pol: safety_policy_v1 pol_decision: approved
|
|
|
|
Agent D (Payment):
|
|
jti: task-004 par: [task-002, task-003]
|
|
exec_act: authorize_payment
|
|
pol: payment_policy_v3 pol_decision: approved
|
|
|
|
System (Commitment):
|
|
jti: task-005 par: [task-004]
|
|
exec_act: commit_shipment
|
|
pol: commitment_policy_v1 pol_decision: approved
|
|
~~~
|
|
{: #fig-logistics title="Logistics Workflow with Parallel Tasks"}
|
|
|
|
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.
|
|
|
|
# Security Considerations
|
|
|
|
This section addresses security considerations following the
|
|
guidance in {{RFC3552}}.
|
|
|
|
## Threat Model
|
|
|
|
The following threat actors are considered:
|
|
|
|
- Malicious agent (insider threat): An agent within the trust
|
|
domain that intentionally creates false ECT claims.
|
|
- Compromised agent (external attacker): An agent whose private
|
|
key has been obtained by an external attacker.
|
|
- Ledger tamperer: An entity attempting to modify or delete ledger
|
|
entries after they have been recorded.
|
|
- Time manipulator: An entity attempting to manipulate timestamps
|
|
to alter perceived execution ordering.
|
|
|
|
## Self-Assertion Limitation {#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 or malicious agent could create ECTs with false claims
|
|
(e.g., setting "pol_decision" to "approved" without actually
|
|
evaluating the policy).
|
|
|
|
ECTs do not independently verify that:
|
|
|
|
- The claimed execution actually occurred as described
|
|
- The policy evaluation was correctly performed
|
|
- The input/output hashes correspond to the actual data processed
|
|
- The agent faithfully performed the stated action
|
|
|
|
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
|
|
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.
|
|
|
|
### Witness Attestation Model {#witness-attestation-model}
|
|
|
|
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 "exec_act" to "witness_attestation" (or a domain-
|
|
specific equivalent).
|
|
- MUST include the observed task's "jti" in the "par" array,
|
|
linking the attestation to the original task.
|
|
- 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,
|
|
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
|
|
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.
|
|
|
|
## Organizational Prerequisites
|
|
|
|
ECTs operate within a broader trust framework. The guarantees
|
|
provided by ECTs are only meaningful when the following
|
|
organizational controls are in place:
|
|
|
|
- Key management governance: Controls over who provisions agent
|
|
keys and how keys are protected.
|
|
- Ledger integrity governance: The ledger is maintained by an
|
|
entity independent of the workflow agents.
|
|
- Policy lifecycle management: Policy identifiers in ECTs map to
|
|
actual, validated policy rules.
|
|
- Agent deployment governance: Agents are deployed and maintained
|
|
in a manner that preserves their integrity.
|
|
|
|
## 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 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
|
|
{{verification}}).
|
|
|
|
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.
|
|
|
|
## Replay Attack Prevention
|
|
|
|
ECTs include short expiration times (RECOMMENDED: 5-15 minutes) to
|
|
limit the window for replay attacks. The "aud" claim restricts
|
|
replay to unintended recipients: an ECT intended for Agent B
|
|
will be rejected by Agent C. The "iat" claim enables receivers to
|
|
reject ECTs that are too old, even if not yet expired.
|
|
|
|
The DAG structure provides additional replay protection: an ECT
|
|
referencing parent tasks that already have a recorded child task
|
|
with the same action can be flagged as a potential replay.
|
|
|
|
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.
|
|
|
|
## Man-in-the-Middle Protection
|
|
|
|
ECTs do not replace transport-layer security. ECTs MUST be
|
|
transmitted over TLS or mTLS connections. When used with the WIMSE
|
|
service-to-service protocol {{I-D.ietf-wimse-s2s-protocol}},
|
|
transport security is already established. HTTP Message Signatures
|
|
{{RFC9421}} provide an alternative channel binding mechanism.
|
|
|
|
The defense-in-depth model provides:
|
|
|
|
- TLS/mTLS (transport layer): Prevents network-level tampering.
|
|
- WIT/WPT (WIMSE identity layer): Proves agent identity and
|
|
request authorization.
|
|
- ECT (execution accountability layer): Records what the agent did
|
|
and under what policy.
|
|
|
|
## 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:
|
|
|
|
- Implementations SHOULD use short-lived keys and rotate them
|
|
frequently (hours to days, not months).
|
|
- Private keys SHOULD be stored in Hardware Security Modules (HSMs)
|
|
or equivalent secure key storage.
|
|
- Trust domains MUST support rapid key revocation.
|
|
- Upon suspected compromise, the trust domain MUST revoke the
|
|
compromised key and issue a new WIT with a fresh key pair.
|
|
|
|
ECTs signed with a compromised key that were recorded in the
|
|
ledger before revocation remain valid historical records but SHOULD
|
|
be flagged in the ledger as "signed with subsequently revoked key"
|
|
for audit purposes.
|
|
|
|
## Collusion and False Claims
|
|
|
|
A single malicious agent cannot forge parent task references
|
|
because DAG validation requires parent tasks to exist in the
|
|
ledger. However, multiple colluding agents could potentially
|
|
create a false execution history if they control the ledger.
|
|
|
|
Mitigations include:
|
|
|
|
- Independent ledger maintenance: The ledger SHOULD be maintained
|
|
by an entity independent of the workflow agents.
|
|
- Witness attestation: Using the "witnessed_by" claim to include
|
|
independent third-party observers.
|
|
- Cross-verification: Multiple independent ledger replicas can be
|
|
compared for consistency.
|
|
- Out-of-band audit: External auditors periodically verify ledger
|
|
contents against expected workflow patterns.
|
|
|
|
## Denial of Service
|
|
|
|
ECT signature verification is computationally inexpensive
|
|
(approximately 1ms per ECT on modern hardware for ES256). DAG
|
|
validation complexity is O(V) where V is the number of ancestor
|
|
nodes reachable from the parent references; for typical shallow
|
|
DAGs this is efficient.
|
|
|
|
Implementations SHOULD apply rate limiting at the API layer to
|
|
prevent excessive ECT submissions. DAG validation SHOULD be
|
|
performed after signature verification to avoid wasting resources
|
|
on unsigned or incorrectly signed tokens.
|
|
|
|
## Timestamp Accuracy
|
|
|
|
ECTs rely on timestamps ("iat", "exp") for temporal ordering.
|
|
Clock skew between agents can lead to incorrect ordering
|
|
judgments. Implementations SHOULD use synchronized time sources
|
|
(e.g., NTP) and SHOULD allow a configurable clock skew tolerance
|
|
(RECOMMENDED: 30 seconds).
|
|
|
|
Cross-organizational deployments where agents span multiple trust
|
|
domains with independent time sources MAY require a higher clock
|
|
skew tolerance. Deployments using trust domain federation SHOULD
|
|
document their configured clock skew tolerance value and SHOULD
|
|
ensure all participating trust domains agree on a common tolerance.
|
|
|
|
The temporal ordering check in DAG validation incorporates the
|
|
clock skew tolerance to account for minor clock differences
|
|
between agents.
|
|
|
|
## ECT Size Constraints
|
|
|
|
ECTs with many parent tasks or large extension objects can
|
|
increase HTTP header size. Implementations SHOULD limit the "par"
|
|
array to a maximum of 256 entries. Workflows requiring more
|
|
parent references SHOULD introduce intermediate aggregation
|
|
tasks. The "ext" object SHOULD NOT exceed 4096 bytes when
|
|
serialized as JSON and SHOULD NOT exceed a nesting depth of
|
|
5 levels (see also {{extension-claims}}).
|
|
|
|
# Privacy Considerations
|
|
|
|
## Data Exposure in ECTs
|
|
|
|
ECTs necessarily reveal:
|
|
|
|
- Agent identities ("iss", "aud") for accountability purposes
|
|
- Action descriptions ("exec_act") for audit trail completeness
|
|
- Policy evaluation outcomes ("pol", "pol_decision") for
|
|
compliance verification
|
|
- Timestamps ("iat", "exp") for temporal ordering
|
|
|
|
ECTs are designed to NOT reveal:
|
|
|
|
- Actual input or output data values (replaced with cryptographic
|
|
hashes via "inp_hash" and "out_hash")
|
|
- Internal computation details or intermediate steps
|
|
- Proprietary algorithms or intellectual property
|
|
- Personally identifiable information (PII)
|
|
|
|
## Data Minimization {#data-minimization}
|
|
|
|
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 ({{compensation-claims}})
|
|
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
|
|
SHOULD use short, structured reason codes (e.g.,
|
|
"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.
|
|
|
|
## Storage and Access Control
|
|
|
|
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)
|
|
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.
|
|
|
|
## 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.
|
|
|
|
# IANA Considerations
|
|
|
|
## Media Type Registration
|
|
|
|
This document requests registration of the following media type
|
|
in the "Media Types" registry maintained by IANA:
|
|
|
|
Type name:
|
|
: application
|
|
|
|
Subtype name:
|
|
: wimse-exec+jwt
|
|
|
|
Required parameters:
|
|
: none
|
|
|
|
Optional parameters:
|
|
: none
|
|
|
|
Encoding considerations:
|
|
: 8bit; an ECT is a JWT that is a JWS using the Compact
|
|
Serialization, which is a sequence of Base64url-encoded values
|
|
separated by period characters.
|
|
|
|
Security considerations:
|
|
: See the Security Considerations section of this document.
|
|
|
|
Interoperability considerations:
|
|
: none
|
|
|
|
Published specification:
|
|
: This document
|
|
|
|
Applications that use this media type:
|
|
: Applications that implement regulated agentic workflows requiring
|
|
execution context tracing and audit trails.
|
|
|
|
Additional information:
|
|
: Magic number(s): none
|
|
File extension(s): none
|
|
Macintosh file type code(s): none
|
|
|
|
Person and email address to contact for further information:
|
|
: Christian Nennemann, ietf@nennemann.de
|
|
|
|
Intended usage:
|
|
: COMMON
|
|
|
|
Restrictions on usage:
|
|
: none
|
|
|
|
Author:
|
|
: Christian Nennemann
|
|
|
|
Change controller:
|
|
: IETF
|
|
|
|
## HTTP Header Field Registration {#header-registration}
|
|
|
|
This document requests registration of the following header field
|
|
in the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
|
|
maintained by IANA:
|
|
|
|
Field name:
|
|
: Execution-Context
|
|
|
|
Status:
|
|
: permanent
|
|
|
|
Specification document:
|
|
: This document, {{http-header}}
|
|
|
|
## JWT Claims Registration {#claims-registration}
|
|
|
|
This document requests registration of the following claims in
|
|
the "JSON Web Token Claims" registry maintained by IANA:
|
|
|
|
| Claim Name | Claim Description | Change Controller | Reference |
|
|
|:---:|:---|:---:|:---:|
|
|
| wid | Workflow Identifier | IETF | {{exec-claims}} |
|
|
| exec_act | Action/Task Type | IETF | {{exec-claims}} |
|
|
| par | Parent Task Identifiers | IETF | {{exec-claims}} |
|
|
| pol | Policy Rule Identifier | IETF | {{policy-claims}} |
|
|
| pol_decision | Policy Decision Result | IETF | {{policy-claims}} |
|
|
| pol_enforcer | Policy Enforcer Identity | IETF | {{policy-claims}} |
|
|
| pol_timestamp | Policy Decision Timestamp | IETF | {{policy-claims}} |
|
|
| inp_hash | Input Data Hash | IETF | {{data-integrity-claims}} |
|
|
| out_hash | Output Data Hash | IETF | {{data-integrity-claims}} |
|
|
| inp_classification | Input Data Classification | IETF | {{data-integrity-claims}} |
|
|
| exec_time_ms | Execution Time (ms) | IETF | {{operational-claims}} |
|
|
| witnessed_by | Witness Identities | IETF | {{operational-claims}} |
|
|
| regulated_domain | Regulatory Domain | IETF | {{operational-claims}} |
|
|
| model_version | AI/ML Model Version | IETF | {{operational-claims}} |
|
|
| compensation_required | Compensation Flag | IETF | {{compensation-claims}} |
|
|
| compensation_reason | Compensation Reason | IETF | {{compensation-claims}} |
|
|
| ext | Extension Object | IETF | {{extension-claims}} |
|
|
{: #table-claims title="JWT Claims Registrations"}
|
|
|
|
## ECT Policy Decision Values Registry {#pol-decision-registry}
|
|
|
|
This document establishes the "ECT Policy Decision Values"
|
|
registry under the "JSON Web Token (JWT)" group. Registration
|
|
policy is Specification Required per {{!RFC8126}}.
|
|
|
|
The initial contents of the registry are:
|
|
|
|
| Value | Description | Change Controller | Reference |
|
|
|:---:|:---|:---:|:---:|
|
|
| approved | Policy evaluation succeeded | IETF | {{policy-claims}} |
|
|
| rejected | Policy evaluation failed | IETF | {{policy-claims}} |
|
|
| pending_human_review | Awaiting human judgment | IETF | {{policy-claims}} |
|
|
{: #table-pol-decision title="ECT Policy Decision Values"}
|
|
|
|
## ECT Regulated Domain Values Registry {#regulated-domain-registry}
|
|
|
|
This document establishes the "ECT Regulated Domain Values"
|
|
registry under the "JSON Web Token (JWT)" group. Registration
|
|
policy is Specification Required per {{!RFC8126}}.
|
|
|
|
The initial contents of the registry are:
|
|
|
|
| Value | Description | Change Controller | Reference |
|
|
|:---:|:---|:---:|:---:|
|
|
| medtech | Medical technology and devices | IETF | {{operational-claims}} |
|
|
| finance | Financial services and trading | IETF | {{operational-claims}} |
|
|
| military | Military and defense | IETF | {{operational-claims}} |
|
|
{: #table-regulated-domain title="ECT Regulated Domain Values"}
|
|
|
|
--- back
|
|
|
|
# Related Work
|
|
{:numbered="false"}
|
|
|
|
## WIMSE Workload Identity
|
|
{:numbered="false"}
|
|
|
|
The WIMSE architecture {{I-D.ietf-wimse-arch}} and service-to-
|
|
service protocol {{I-D.ietf-wimse-s2s-protocol}} provide the
|
|
identity foundation upon which ECTs are built. WIT/WPT answer
|
|
"who is this agent?" and "does it control the claimed key?" while
|
|
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 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. 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.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"}
|
|
|
|
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
|
|
tamper-evident through JWS signatures; ECTs enforce DAG validation
|
|
rules; and ECTs are designed for regulatory audit rather than
|
|
operational monitoring. 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.
|
|
|
|
## Blockchain and Distributed Ledgers
|
|
{:numbered="false"}
|
|
|
|
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 {{ledger-interface}}.
|
|
|
|
## SCITT (Supply Chain Integrity, Transparency, and Trust)
|
|
{:numbered="false"}
|
|
|
|
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
|
|
"wid" (Workflow Identifier) claim can serve as a correlation
|
|
identifier referenced in SCITT Signed Statements, linking a
|
|
complete ECT audit trail to a supply chain transparency record.
|
|
For example, in a regulated manufacturing workflow, each agent
|
|
step produces an ECT (recording what was done, by whom, under
|
|
what policy), while the overall workflow identified by "wid" is
|
|
registered as a SCITT Signed Statement on a Transparency Service.
|
|
This enables auditors to verify both the individual execution
|
|
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 ({{exec-claims}})
|
|
can carry SCITT-specific metadata such as Transparency Service
|
|
identifiers or Receipt references for tighter integration.
|
|
|
|
## W3C Verifiable Credentials
|
|
{:numbered="false"}
|
|
|
|
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.
|
|
|
|
# Implementation Guidance
|
|
{:numbered="false"}
|
|
|
|
## Minimal Implementation
|
|
{:numbered="false"}
|
|
|
|
A minimal conforming implementation needs to:
|
|
|
|
1. Create JWTs with all required claims ("iss", "aud", "iat",
|
|
"exp", "jti", "exec_act", "par") and policy claims ("pol",
|
|
"pol_decision") when policy evaluation was performed.
|
|
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. 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"}
|
|
|
|
- Append-only log: Simplest approach; immutability by design.
|
|
- Database with hash chains: Periodic cryptographic commitments
|
|
over batches of entries.
|
|
- Distributed ledger: Maximum immutability guarantees for
|
|
cross-organizational audit.
|
|
- Hybrid: Hot storage in a database, cold archive in immutable
|
|
storage.
|
|
|
|
## Performance Considerations
|
|
{:numbered="false"}
|
|
|
|
- ES256 signature verification: approximately 1ms per ECT on
|
|
modern hardware.
|
|
- DAG validation: O(V) where V is the number of reachable ancestor
|
|
nodes (typically small for shallow workflows).
|
|
- JSON serialization: sub-millisecond per ECT.
|
|
- Total per-request overhead: approximately 5-10ms, acceptable
|
|
for regulated workflows where correctness is prioritized over
|
|
latency.
|
|
|
|
## Interoperability
|
|
{:numbered="false"}
|
|
|
|
Implementations are expected to use established JWT/JWS libraries
|
|
(JOSE) for token creation and verification. Custom cryptographic
|
|
implementations are strongly discouraged. Implementations are
|
|
expected to be tested against multiple JWT libraries to ensure
|
|
interoperability.
|
|
|
|
# Regulatory Compliance Mapping
|
|
{:numbered="false"}
|
|
|
|
The following table summarizes how ECTs can contribute to
|
|
compliance with various regulatory frameworks. ECTs are a
|
|
technical building block; achieving compliance requires
|
|
additional organizational measures beyond this specification.
|
|
|
|
| Regulation | Requirement | ECT Contribution |
|
|
|:---|:---|:---|
|
|
| FDA 21 CFR Part 11 | Audit trails recording date, time, operator, actions (11.10(e)) | Cryptographic signatures and append-only ledger contribute to audit trail requirements |
|
|
| EU MDR | Technical documentation traceability (Annex II) | ECTs provide signed records of AI-assisted decision sequences |
|
|
| EU AI Act Art. 12 | Automatic logging capabilities for high-risk AI | ECTs contribute cryptographic activity logging |
|
|
| EU AI Act Art. 14 | Human oversight capability | ECTs can record evidence that human oversight events occurred |
|
|
| MiFID II | Transaction records for supervisory authorities | ECTs provide cryptographic execution sequence records |
|
|
| DORA Art. 12 | ICT activity logging policies | ECT ledger contributes to ICT activity audit trail |
|
|
{: #table-regulatory title="Regulatory Compliance Mapping"}
|
|
|
|
# Examples
|
|
{:numbered="false"}
|
|
|
|
## Example 1: Simple Two-Agent Workflow
|
|
{:numbered="false"}
|
|
|
|
Agent A executes a data retrieval task and sends the ECT to
|
|
Agent B:
|
|
|
|
ECT JOSE Header:
|
|
|
|
~~~json
|
|
{
|
|
"alg": "ES256",
|
|
"typ": "wimse-exec+jwt",
|
|
"kid": "agent-a-key-2026-02"
|
|
}
|
|
~~~
|
|
|
|
ECT Payload:
|
|
|
|
~~~json
|
|
{
|
|
"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": "550e8400-e29b-41d4-a716-446655440001",
|
|
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
|
|
"exec_act": "fetch_patient_data",
|
|
"par": [],
|
|
"pol": "clinical_data_access_policy_v1",
|
|
"pol_decision": "approved",
|
|
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
|
|
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
|
|
"exec_time_ms": 142,
|
|
"regulated_domain": "medtech"
|
|
}
|
|
~~~
|
|
|
|
Agent B receives the ECT, verifies it, executes a validation
|
|
task, and creates its own ECT:
|
|
|
|
~~~json
|
|
{
|
|
"iss": "spiffe://example.com/agent/validator",
|
|
"sub": "spiffe://example.com/agent/validator",
|
|
"aud": "spiffe://example.com/system/ledger",
|
|
"iat": 1772064160,
|
|
"exp": 1772064760,
|
|
"jti": "550e8400-e29b-41d4-a716-446655440002",
|
|
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
|
|
"exec_act": "validate_safety",
|
|
"par": ["550e8400-e29b-41d4-a716-446655440001"],
|
|
"pol": "safety_validation_policy_v2",
|
|
"pol_decision": "approved",
|
|
"exec_time_ms": 89,
|
|
"regulated_domain": "medtech"
|
|
}
|
|
~~~
|
|
|
|
The resulting DAG:
|
|
|
|
~~~
|
|
task-...-0001 (fetch_patient_data)
|
|
|
|
|
v
|
|
task-...-0002 (validate_safety)
|
|
~~~
|
|
|
|
## Example 2: Medical Device SDLC with Release Approval
|
|
{:numbered="false"}
|
|
|
|
A multi-step medical device software lifecycle workflow with
|
|
autonomous agents and human release approval:
|
|
|
|
Task 1 (Spec Review Agent):
|
|
|
|
~~~json
|
|
{
|
|
"iss": "spiffe://meddev.example/agent/spec-reviewer",
|
|
"sub": "spiffe://meddev.example/agent/spec-reviewer",
|
|
"aud": "spiffe://meddev.example/agent/code-gen",
|
|
"iat": 1772064150,
|
|
"exp": 1772064750,
|
|
"jti": "a1b2c3d4-0001-0000-0000-000000000001",
|
|
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
|
|
"exec_act": "review_requirements_spec",
|
|
"par": [],
|
|
"pol": "spec_review_policy_v2",
|
|
"pol_decision": "approved",
|
|
"regulated_domain": "medtech",
|
|
"model_version": "spec-review-v3.1",
|
|
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
|
|
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
|
|
}
|
|
~~~
|
|
|
|
Task 2 (Code Generation Agent):
|
|
|
|
~~~json
|
|
{
|
|
"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": "a1b2c3d4-0001-0000-0000-000000000002",
|
|
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
|
|
"exec_act": "implement_module",
|
|
"par": ["a1b2c3d4-0001-0000-0000-000000000001"],
|
|
"pol": "coding_standards_v3",
|
|
"pol_decision": "approved",
|
|
"regulated_domain": "medtech",
|
|
"model_version": "codegen-v2.4"
|
|
}
|
|
~~~
|
|
|
|
Task 3 (Autonomous Test Agent):
|
|
|
|
~~~json
|
|
{
|
|
"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": "a1b2c3d4-0001-0000-0000-000000000003",
|
|
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
|
|
"exec_act": "execute_test_suite",
|
|
"par": ["a1b2c3d4-0001-0000-0000-000000000002"],
|
|
"pol": "test_coverage_policy_v1",
|
|
"pol_decision": "approved",
|
|
"regulated_domain": "medtech",
|
|
"exec_time_ms": 4523
|
|
}
|
|
~~~
|
|
|
|
Task 4 (Build Agent):
|
|
|
|
~~~json
|
|
{
|
|
"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": "a1b2c3d4-0001-0000-0000-000000000004",
|
|
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
|
|
"exec_act": "build_release_artifact",
|
|
"par": ["a1b2c3d4-0001-0000-0000-000000000003"],
|
|
"pol": "build_validation_v2",
|
|
"pol_decision": "approved",
|
|
"regulated_domain": "medtech",
|
|
"out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc"
|
|
}
|
|
~~~
|
|
|
|
Task 5 (Human Release Manager Approval):
|
|
|
|
~~~json
|
|
{
|
|
"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": "a1b2c3d4-0001-0000-0000-000000000005",
|
|
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
|
|
"exec_act": "approve_release",
|
|
"par": ["a1b2c3d4-0001-0000-0000-000000000004"],
|
|
"pol": "release_approval_policy",
|
|
"pol_decision": "approved",
|
|
"pol_enforcer": "spiffe://meddev.example/human/release-mgr-42",
|
|
"witnessed_by": [
|
|
"spiffe://meddev.example/audit/qa-observer-1"
|
|
],
|
|
"regulated_domain": "medtech"
|
|
}
|
|
~~~
|
|
|
|
The resulting DAG records the complete SDLC: spec review preceded
|
|
implementation, implementation preceded testing, testing preceded
|
|
build, and a human release manager approved the final release
|
|
with independent witness attestation.
|
|
|
|
~~~
|
|
task-...-0001 (review_requirements_spec)
|
|
|
|
|
v
|
|
task-...-0002 (implement_module)
|
|
|
|
|
v
|
|
task-...-0003 (execute_test_suite)
|
|
|
|
|
v
|
|
task-...-0004 (build_release_artifact)
|
|
|
|
|
v
|
|
task-...-0005 (approve_release) [human, witnessed]
|
|
~~~
|
|
|
|
An FDA auditor reconstructs this DAG by querying the audit ledger
|
|
for all ECTs with wid "c2d3e4f5-a6b7-8901-cdef-012345678901" and
|
|
verifying each signature. The DAG provides cryptographic evidence
|
|
that the SDLC followed the prescribed process with human oversight
|
|
at the release gate.
|
|
|
|
## Example 3: Parallel Execution with Join
|
|
{:numbered="false"}
|
|
|
|
A workflow where two tasks execute in parallel and a third task
|
|
depends on both:
|
|
|
|
~~~
|
|
task-...-0001 (assess_risk)
|
|
| \
|
|
v v
|
|
task-...-0002 task-...-0003
|
|
(check (verify
|
|
compliance) liquidity)
|
|
| /
|
|
v v
|
|
task-...-0004 (execute_trade)
|
|
~~~
|
|
|
|
Task 004 ECT payload:
|
|
|
|
~~~json
|
|
{
|
|
"iss": "spiffe://bank.example/agent/execution",
|
|
"sub": "spiffe://bank.example/agent/execution",
|
|
"aud": "spiffe://bank.example/system/ledger",
|
|
"iat": 1772064250,
|
|
"exp": 1772064850,
|
|
"jti": "f1e2d3c4-0004-0000-0000-000000000004",
|
|
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
|
|
"exec_act": "execute_trade",
|
|
"par": [
|
|
"f1e2d3c4-0002-0000-0000-000000000002",
|
|
"f1e2d3c4-0003-0000-0000-000000000003"
|
|
],
|
|
"pol": "trade_execution_policy_v3",
|
|
"pol_decision": "approved",
|
|
"regulated_domain": "finance"
|
|
}
|
|
~~~
|
|
|
|
The "par" array with two entries records that both compliance
|
|
checking and liquidity verification were completed before trade
|
|
execution.
|
|
|
|
# Acknowledgments
|
|
{:numbered="false"}
|
|
|
|
The author thanks the WIMSE working group for their foundational
|
|
work on workload identity in multi-system environments. The
|
|
concepts of Workload Identity Tokens and Workload Proof Tokens
|
|
provide the identity foundation upon which execution context
|
|
tracing is built.
|