Slim down draft to core ECT mechanism for -00 submission
Remove all companion draft (ect-pol) references, regulatory compliance mappings, pre-defined extension keys, witness concept, pseudocode blocks, implementation guidance appendix, and redundant examples. Keep only the core token format, DAG validation, verification procedure, and one cross-organization use case. Draft reduced from ~40 pages to 27 pages. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -14,8 +14,6 @@ keyword:
|
||||
- workload identity
|
||||
- agentic workflows
|
||||
- audit trail
|
||||
- compliance
|
||||
- regulated systems
|
||||
|
||||
author:
|
||||
-
|
||||
@@ -38,46 +36,10 @@ informative:
|
||||
RFC8693:
|
||||
RFC9421:
|
||||
I-D.ni-wimse-ai-agent-identity:
|
||||
I-D.nennemann-wimse-ect-pol:
|
||||
title: "Policy Evaluation and Compensation Extensions for Execution Context Tokens"
|
||||
target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect-pol/
|
||||
date: false
|
||||
author:
|
||||
- fullname: Christian Nennemann
|
||||
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/
|
||||
@@ -92,23 +54,17 @@ informative:
|
||||
|
||||
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 signed, structured records of task
|
||||
execution order and compliance state across agent-to-agent
|
||||
communication. By extending WIMSE Workload Identity
|
||||
architecture for distributed agentic workflows. ECTs provide
|
||||
signed, structured records of task execution order across
|
||||
agent-to-agent communication. By extending WIMSE Workload Identity
|
||||
Tokens with execution context claims in JSON Web Token (JWT)
|
||||
format, this specification enables regulated systems to maintain
|
||||
structured audit trails that support compliance verification.
|
||||
ECTs use a directed acyclic graph (DAG) structure to represent task
|
||||
dependencies and integrate with WIMSE Workload Identity Tokens (WIT)
|
||||
using the same signing model and cryptographic primitives.
|
||||
Policy evaluation and compensation extensions are defined in
|
||||
{{I-D.nennemann-wimse-ect-pol}}. A new
|
||||
HTTP header field,
|
||||
format, this specification enables systems to maintain structured
|
||||
audit trails of agent execution. ECTs use a directed acyclic
|
||||
graph (DAG) structure to represent task dependencies and integrate
|
||||
with WIMSE Workload Identity Tokens (WIT) using the same signing
|
||||
model and cryptographic primitives. A new HTTP header field,
|
||||
Execution-Context, is defined for transporting ECTs alongside
|
||||
existing WIMSE headers. ECTs are a technical building block that
|
||||
supports, but does not by itself constitute, compliance with
|
||||
regulatory frameworks.
|
||||
existing WIMSE headers.
|
||||
|
||||
--- middle
|
||||
|
||||
@@ -132,8 +88,6 @@ Regulated environments increasingly deploy autonomous agents that
|
||||
coordinate across organizational boundaries. Domains such as
|
||||
healthcare, finance, and logistics require structured, auditable
|
||||
records of automated decision-making and execution.
|
||||
{{table-regulatory}} in the appendix illustrates how ECTs relate
|
||||
to specific regulatory frameworks.
|
||||
|
||||
This document defines an extension to the WIMSE architecture that
|
||||
addresses the gap between workload identity and execution
|
||||
@@ -176,8 +130,6 @@ This document defines:
|
||||
({{wimse-integration}})
|
||||
- An HTTP header for ECT transport ({{http-header}})
|
||||
- Audit ledger interface requirements ({{ledger-interface}})
|
||||
- Policy evaluation and compensation extensions are defined
|
||||
separately in {{I-D.nennemann-wimse-ect-pol}}
|
||||
|
||||
The following are out of scope and are handled by WIMSE:
|
||||
|
||||
@@ -186,26 +138,6 @@ The following are out of scope and are handled by WIMSE:
|
||||
- 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. They do not
|
||||
independently verify that the claimed execution actually occurred
|
||||
as described 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}
|
||||
@@ -230,8 +162,7 @@ Execution Context Token (ECT):
|
||||
|
||||
Audit Ledger:
|
||||
: An append-only, immutable log of all ECTs within a workflow or
|
||||
set of workflows, used for regulatory audit and compliance
|
||||
verification.
|
||||
set of workflows, used for audit and verification.
|
||||
|
||||
Workload Identity Token (WIT):
|
||||
: A WIMSE credential proving a workload's identity within a trust
|
||||
@@ -246,10 +177,6 @@ Trust Domain:
|
||||
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
|
||||
@@ -351,8 +278,10 @@ The receiving agent (Agent B) verifies in order:
|
||||
# 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.
|
||||
signed as a JSON Web Signature (JWS) {{RFC7515}}. ECTs MUST use
|
||||
JWS Compact Serialization (the base64url-encoded
|
||||
`header.payload.signature` format) so that they can be carried in
|
||||
a single HTTP header value.
|
||||
|
||||
## JOSE Header {#jose-header}
|
||||
|
||||
@@ -481,7 +410,10 @@ par:
|
||||
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.
|
||||
multiple root tasks. Parent ECTs may have passed their own
|
||||
"exp" time; ECT expiration applies to the verification window
|
||||
of the ECT itself, not to its validity as a parent reference
|
||||
in the ECT store.
|
||||
|
||||
### Data Integrity {#data-integrity-claims}
|
||||
|
||||
@@ -504,14 +436,6 @@ out_hash:
|
||||
: OPTIONAL. String. A cryptographic hash of the output data,
|
||||
using the same format and algorithm requirements as "inp_hash".
|
||||
|
||||
### Compensation and Rollback {#compensation-claims}
|
||||
|
||||
Compensation and rollback extensions are defined in
|
||||
{{I-D.nennemann-wimse-ect-pol}}. 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 ECT store.
|
||||
|
||||
### Extensions {#extension-claims}
|
||||
|
||||
ext:
|
||||
@@ -529,23 +453,8 @@ nesting depth within the "ext" object SHOULD NOT exceed 5
|
||||
levels. Implementations SHOULD reject ECTs whose "ext" claim
|
||||
exceeds these limits.
|
||||
|
||||
The following extension keys are defined by this specification
|
||||
for common use cases. Because these keys are documented here,
|
||||
they use short names without reverse domain prefixes:
|
||||
|
||||
- "exec\_time\_ms": Integer. Execution duration in milliseconds.
|
||||
- "regulated\_domain": String. Regulatory domain (e.g.,
|
||||
"medtech", "finance", "military").
|
||||
- "model\_version": String. AI/ML model version.
|
||||
- "witnessed\_by": Array of StringOrURI. Identifiers of
|
||||
third-party entities that the issuer claims observed the
|
||||
task. Note: this is self-asserted; for verifiable witness
|
||||
attestation, witnesses should submit independent signed ECTs.
|
||||
- "inp\_classification": String. Data sensitivity classification
|
||||
(e.g., "public", "confidential", "restricted").
|
||||
|
||||
Additional extension keys for policy evaluation and compensation
|
||||
are defined in {{I-D.nennemann-wimse-ect-pol}}.
|
||||
Extension keys for domain-specific use cases MAY be defined in
|
||||
future documents.
|
||||
|
||||
## Complete ECT Example
|
||||
|
||||
@@ -564,13 +473,7 @@ The following is a complete ECT payload example:
|
||||
"par": [],
|
||||
|
||||
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
|
||||
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
|
||||
|
||||
"ext": {
|
||||
"exec_time_ms": 245,
|
||||
"regulated_domain": "medtech",
|
||||
"model_version": "clinical-reasoning-v4.2"
|
||||
}
|
||||
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
|
||||
}
|
||||
~~~
|
||||
{: #fig-full-ect title="Complete ECT Payload Example"}
|
||||
@@ -659,63 +562,10 @@ the following DAG validation steps:
|
||||
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):
|
||||
// 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.
|
||||
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.
|
||||
|
||||
# Signature and Token Verification {#verification}
|
||||
|
||||
@@ -787,76 +637,6 @@ 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, ect_store):
|
||||
// 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 DAG (against ECT store 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; record if store is available
|
||||
if ect_store is not null:
|
||||
ect_store.append(payload)
|
||||
return accept
|
||||
~~~
|
||||
{: #fig-verification title="ECT Verification Pseudocode"}
|
||||
|
||||
# Audit Ledger Interface {#ledger-interface}
|
||||
|
||||
ECTs MAY be recorded in an immutable audit ledger for compliance
|
||||
@@ -917,21 +697,8 @@ ECTs do not independently verify that:
|
||||
- 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"
|
||||
extension key (carried in "ext") to include independent
|
||||
third-party observers at critical decision points. However,
|
||||
this value is self-asserted by the ECT issuer: the listed
|
||||
witnesses do not co-sign the ECT and there is no cryptographic
|
||||
evidence within a single ECT that the witnesses actually
|
||||
observed the task. An issuing agent could list witnesses that
|
||||
did not participate.
|
||||
|
||||
To strengthen witness attestation beyond self-assertion, witnesses
|
||||
SHOULD submit their own independent signed ECTs referencing the
|
||||
observed task's "jti" in the "par" array. Auditors can then
|
||||
cross-check the "witnessed_by" extension against independent
|
||||
witness ECTs in the ECT store.
|
||||
of the signing agent and the integrity of the broader deployment
|
||||
environment.
|
||||
|
||||
## Organizational Prerequisites
|
||||
|
||||
@@ -1024,8 +791,6 @@ Mitigations include:
|
||||
|
||||
- Independent ledger maintenance: The ledger SHOULD be maintained
|
||||
by an entity independent of the workflow agents.
|
||||
- Witness attestation: Using the "witnessed_by" extension
|
||||
key in "ext" 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
|
||||
@@ -1103,21 +868,16 @@ structured identifiers.
|
||||
## 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.
|
||||
only authorized auditors can read them. Implementations SHOULD
|
||||
consider encryption at rest for ledger storage. ECTs provide
|
||||
structural records of execution ordering; they are not intended
|
||||
for public disclosure.
|
||||
|
||||
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; they are not intended for public disclosure.
|
||||
|
||||
# IANA Considerations
|
||||
|
||||
## Media Type Registration
|
||||
@@ -1152,8 +912,8 @@ Published specification:
|
||||
: This document
|
||||
|
||||
Applications that use this media type:
|
||||
: Applications that implement regulated agentic workflows requiring
|
||||
execution context tracing and audit trails.
|
||||
: Applications that implement agentic workflows requiring execution
|
||||
context tracing and audit trails.
|
||||
|
||||
Additional information:
|
||||
: Magic number(s): none
|
||||
@@ -1205,110 +965,18 @@ the "JSON Web Token Claims" registry maintained by IANA:
|
||||
| ext | Extension Object | IETF | {{extension-claims}} |
|
||||
{: #table-claims title="JWT Claims Registrations"}
|
||||
|
||||
Policy evaluation claims and the ECT Policy Decision Values
|
||||
registry are defined in
|
||||
{{I-D.nennemann-wimse-ect-pol}}.
|
||||
|
||||
--- back
|
||||
|
||||
# Use Cases {#use-cases}
|
||||
{:numbered="false"}
|
||||
|
||||
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.
|
||||
This section describes a representative use case demonstrating how
|
||||
ECTs provide structured execution records.
|
||||
|
||||
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
|
||||
{:numbered="false"}
|
||||
|
||||
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
|
||||
|
||||
Agent B (Code Generator):
|
||||
jti: task-002 par: [task-001]
|
||||
exec_act: implement_module
|
||||
|
||||
Agent C (Test Agent):
|
||||
jti: task-003 par: [task-002]
|
||||
exec_act: execute_test_suite
|
||||
|
||||
Agent D (Build Agent):
|
||||
jti: task-004 par: [task-003]
|
||||
exec_act: build_release_artifact
|
||||
|
||||
Human Release Manager:
|
||||
jti: task-005 par: [task-004]
|
||||
exec_act: approve_release
|
||||
ext: {witnessed_by: [...]} (extension metadata)
|
||||
~~~
|
||||
{: #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
|
||||
{:numbered="false"}
|
||||
|
||||
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.
|
||||
- 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.
|
||||
|
||||
## Cross-Organization Financial Trading
|
||||
{:numbered="false"}
|
||||
|
||||
@@ -1365,56 +1033,6 @@ demonstrating cross-organizational fan-in. The compliance agent
|
||||
verifies both parent ECTs — one signed by a local key and one by
|
||||
a federated key from the rating agency's trust domain.
|
||||
|
||||
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
|
||||
{:numbered="false"}
|
||||
|
||||
Compensation and rollback use cases are described in
|
||||
{{I-D.nennemann-wimse-ect-pol}}. The core
|
||||
ECT mechanism supports compensation through the "par" claim,
|
||||
which links a remediation ECT to the original task.
|
||||
|
||||
## Autonomous Logistics Coordination
|
||||
{:numbered="false"}
|
||||
|
||||
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
|
||||
|
||||
Agent B (Customs):
|
||||
jti: task-002 par: [task-001]
|
||||
exec_act: validate_customs
|
||||
|
||||
Agent C (Safety):
|
||||
jti: task-003 par: [task-001]
|
||||
exec_act: verify_cargo_safety
|
||||
|
||||
Agent D (Payment):
|
||||
jti: task-004 par: [task-002, task-003]
|
||||
exec_act: authorize_payment
|
||||
|
||||
System (Commitment):
|
||||
jti: task-005 par: [task-004]
|
||||
exec_act: commit_shipment
|
||||
~~~
|
||||
{: #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.
|
||||
|
||||
# Related Work
|
||||
{:numbered="false"}
|
||||
|
||||
@@ -1439,7 +1057,8 @@ 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 or input/output integrity data. The "act" chain cannot represent
|
||||
and carries no task identifiers or input/output integrity
|
||||
data. The "act" chain cannot represent
|
||||
branching (fan-out) or convergence (fan-in) and therefore
|
||||
cannot form a DAG.
|
||||
|
||||
@@ -1501,357 +1120,14 @@ 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
|
||||
under what constraints), 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). 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").
|
||||
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. If an audit ledger is deployed, append verified ECTs to it.
|
||||
|
||||
## 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",
|
||||
"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": [],
|
||||
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
|
||||
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
|
||||
}
|
||||
~~~
|
||||
|
||||
Agent B receives the ECT, verifies it, executes a validation
|
||||
task, and creates its own ECT:
|
||||
|
||||
~~~json
|
||||
{
|
||||
"iss": "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"]
|
||||
}
|
||||
~~~
|
||||
|
||||
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",
|
||||
"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": [],
|
||||
"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",
|
||||
"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"]
|
||||
}
|
||||
~~~
|
||||
|
||||
Task 3 (Autonomous Test Agent):
|
||||
|
||||
~~~json
|
||||
{
|
||||
"iss": "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"]
|
||||
}
|
||||
~~~
|
||||
|
||||
Task 4 (Build Agent):
|
||||
|
||||
~~~json
|
||||
{
|
||||
"iss": "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"],
|
||||
"out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc"
|
||||
}
|
||||
~~~
|
||||
|
||||
Task 5 (Human Release Manager Approval):
|
||||
|
||||
~~~json
|
||||
{
|
||||
"iss": "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"],
|
||||
"ext": {
|
||||
"witnessed_by": [
|
||||
"spiffe://meddev.example/audit/qa-observer-1"
|
||||
]
|
||||
}
|
||||
}
|
||||
~~~
|
||||
|
||||
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.
|
||||
The "ext" object in task 5 carries witness metadata via
|
||||
the "witnessed_by" extension key.
|
||||
|
||||
~~~
|
||||
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]
|
||||
~~~
|
||||
|
||||
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: Cross-Organization Fan-In
|
||||
{:numbered="false"}
|
||||
|
||||
A cross-organization workflow where two independent root tasks
|
||||
from different trust domains feed into a compliance verification
|
||||
step. This demonstrates DAG fan-in across organizational
|
||||
boundaries.
|
||||
|
||||
Task 001 (Bank's risk agent — root task):
|
||||
|
||||
~~~json
|
||||
{
|
||||
"iss": "spiffe://bank.example/agent/risk",
|
||||
"aud": "spiffe://bank.example/agent/compliance",
|
||||
"iat": 1772064150,
|
||||
"exp": 1772064750,
|
||||
"jti": "f1e2d3c4-0001-0000-0000-000000000001",
|
||||
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
|
||||
"exec_act": "analyze_portfolio_risk",
|
||||
"par": [],
|
||||
"out_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"
|
||||
}
|
||||
~~~
|
||||
|
||||
Task 002 (External rating agency — root task, different trust
|
||||
domain):
|
||||
|
||||
~~~json
|
||||
{
|
||||
"iss": "spiffe://ratings.example/agent/credit",
|
||||
"aud": "spiffe://bank.example/agent/compliance",
|
||||
"iat": 1772064155,
|
||||
"exp": 1772064755,
|
||||
"jti": "f1e2d3c4-0002-0000-0000-000000000002",
|
||||
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
|
||||
"exec_act": "assess_credit_rating",
|
||||
"par": [],
|
||||
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
|
||||
}
|
||||
~~~
|
||||
|
||||
Task 003 (Bank's compliance agent — joins both parents):
|
||||
|
||||
~~~json
|
||||
{
|
||||
"iss": "spiffe://bank.example/agent/compliance",
|
||||
"aud": "spiffe://bank.example/agent/execution",
|
||||
"iat": 1772064200,
|
||||
"exp": 1772064800,
|
||||
"jti": "f1e2d3c4-0003-0000-0000-000000000003",
|
||||
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
|
||||
"exec_act": "verify_trade_compliance",
|
||||
"par": [
|
||||
"f1e2d3c4-0001-0000-0000-000000000001",
|
||||
"f1e2d3c4-0002-0000-0000-000000000002"
|
||||
]
|
||||
}
|
||||
~~~
|
||||
|
||||
The "par" array in task 003 references two parents from different
|
||||
trust domains: `spiffe://bank.example` and
|
||||
`spiffe://ratings.example`. The compliance agent verifies both
|
||||
parent ECTs — one signed by a local key and one by a federated
|
||||
key — before proceeding. This demonstrates how ECTs support
|
||||
cross-organizational workflows while maintaining cryptographic
|
||||
accountability.
|
||||
framework for transparent and auditable supply chain records.
|
||||
ECTs and SCITT are complementary: the ECT "wid" claim can serve
|
||||
as a correlation identifier in SCITT Signed Statements, linking
|
||||
an ECT audit trail to a supply chain transparency record.
|
||||
|
||||
# Acknowledgments
|
||||
{:numbered="false"}
|
||||
|
||||
Reference in New Issue
Block a user