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

Move use cases section to appendix

Browse Source 
Use cases (medtech SDLC, financial trading, logistics) are
motivating examples, not protocol definition. Moving them to
the appendix keeps the normative body focused on format,
transport, validation, and security.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Christian Nennemann
2026-02-25 16:53:18 +01:00
parent e62b62ff99
commit 907e823a4d
4 changed files with 1796 additions and 1790 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1374
draft-nennemann-wimse-execution-context-00.html
View File

File diff suppressed because it is too large Load Diff

336
draft-nennemann-wimse-execution-context-00.md
View File

@@ -885,171 +885,6 @@ When an audit ledger is deployed, the implementation MUST provide:
The ledger SHOULD be maintained by an entity independent of the
workflow agents to reduce the risk of collusion.
# 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
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
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.
## 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
Agent B (Compliance):
jti: task-002 par: [task-001]
exec_act: verify_compliance
Agent C (Execution):
jti: task-003 par: [task-002]
exec_act: execute_trade
~~~
{: #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
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
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.
# Security Considerations
This section addresses security considerations following the
@@ -1376,6 +1211,177 @@ registry are defined in
--- 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.
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.
## Financial Trading Workflow
{:numbered="false"}
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
Agent B (Compliance):
jti: task-002 par: [task-001]
exec_act: verify_compliance
Agent C (Execution):
jti: task-003 par: [task-002]
exec_act: execute_trade
~~~
{: #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
{: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"}

584
draft-nennemann-wimse-execution-context-00.txt
View File

@@ -103,9 +103,9 @@ Table of Contents
7.1. Verification Procedure . . . . . . . . . . . . . . . . . 17
7.2. Verification Pseudocode . . . . . . . . . . . . . . . . . 18
8. Audit Ledger Interface . . . . . . . . . . . . . . . . . . . 20
9. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Medical Device SDLC Workflow . . . . . . . . . . . . . . 20
9.1.1. FDA Audit with DAG Reconstruction . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 20
9.2. Self-Assertion Limitation . . . . . . . . . . . . . . . . 21
@@ -114,33 +114,33 @@ Nennemann Expires 29 August 2026 [Page 2]
Internet-Draft WIMSE Execution Context February 2026
9.2. Financial Trading Workflow . . . . . . . . . . . . . . . 22
9.3. Compensation and Rollback . . . . . . . . . . . . . . . . 23
9.4. Autonomous Logistics Coordination . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 24
10.2. Self-Assertion Limitation . . . . . . . . . . . . . . . 25
10.3. Organizational Prerequisites . . . . . . . . . . . . . . 25
10.4. Signature Verification . . . . . . . . . . . . . . . . . 26
10.5. Replay Attack Prevention . . . . . . . . . . . . . . . . 26
10.6. Man-in-the-Middle Protection . . . . . . . . . . . . . . 26
10.7. Key Compromise . . . . . . . . . . . . . . . . . . . . . 27
10.8. Collusion and False Claims . . . . . . . . . . . . . . . 27
10.9. Denial of Service . . . . . . . . . . . . . . . . . . . 28
10.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 28
10.11. ECT Size Constraints . . . . . . . . . . . . . . . . . . 28
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28
11.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . 28
11.2. Data Minimization . . . . . . . . . . . . . . . . . . . 29
11.3. Storage and Access Control . . . . . . . . . . . . . . . 29
11.4. Regulatory Access . . . . . . . . . . . . . . . . . . . 29
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
12.1. Media Type Registration . . . . . . . . . . . . . . . . 29
12.2. HTTP Header Field Registration . . . . . . . . . . . . . 30
12.3. JWT Claims Registration . . . . . . . . . . . . . . . . 31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . 32
9.3. Organizational Prerequisites . . . . . . . . . . . . . . 21
9.4. Signature Verification . . . . . . . . . . . . . . . . . 22
9.5. Replay Attack Prevention . . . . . . . . . . . . . . . . 22
9.6. Man-in-the-Middle Protection . . . . . . . . . . . . . . 22
9.7. Key Compromise . . . . . . . . . . . . . . . . . . . . . 23
9.8. Collusion and False Claims . . . . . . . . . . . . . . . 23
9.9. Denial of Service . . . . . . . . . . . . . . . . . . . . 24
9.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 24
9.11. ECT Size Constraints . . . . . . . . . . . . . . . . . . 24
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
10.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . 24
10.2. Data Minimization . . . . . . . . . . . . . . . . . . . 25
10.3. Storage and Access Control . . . . . . . . . . . . . . . 25
10.4. Regulatory Access . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11.1. Media Type Registration . . . . . . . . . . . . . . . . 25
11.2. HTTP Header Field Registration . . . . . . . . . . . . . 26
11.3. JWT Claims Registration . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 28
Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Medical Device SDLC Workflow . . . . . . . . . . . . . . . . . 30
FDA Audit with DAG Reconstruction . . . . . . . . . . . . . . 31
Financial Trading Workflow . . . . . . . . . . . . . . . . . . 32
Compensation and Rollback . . . . . . . . . . . . . . . . . . . 33
Autonomous Logistics Coordination . . . . . . . . . . . . . . . 33
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 34
WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 34
OAuth 2.0 Token Exchange and the "act" Claim . . . . . . . . . 34
@@ -1094,234 +1094,12 @@ Internet-Draft WIMSE Execution Context February 2026
The ledger SHOULD be maintained by an entity independent of the
workflow agents to reduce the risk of collusion.
9. 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 Section 4.2.2.
9.1. 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.
Nennemann Expires 29 August 2026 [Page 20]
Internet-Draft WIMSE Execution Context February 2026
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)
Figure 8: 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.
9.1.1. FDA Audit with DAG Reconstruction
During a regulatory audit, an FDA reviewer requests evidence of the
development process for a specific software release. The auditing
authority retrieves all ECTs sharing the same workflow identifier
("wid") from the audit ledger and reconstructs the complete DAG:
Nennemann Expires 29 August 2026 [Page 21]
Internet-Draft WIMSE Execution Context February 2026
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]
Figure 9: 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.
9.2. Financial Trading Workflow
In a financial trading workflow, agents perform risk assessment,
compliance verification, and trade execution. The DAG structure
records that compliance checks were evaluated before trade execution.
Nennemann Expires 29 August 2026 [Page 22]
Internet-Draft WIMSE Execution Context February 2026
Agent A (Risk Assessment):
jti: task-001 par: []
exec_act: calculate_risk_exposure
Agent B (Compliance):
jti: task-002 par: [task-001]
exec_act: verify_compliance
Agent C (Execution):
jti: task-003 par: [task-002]
exec_act: execute_trade
Figure 10: 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.
9.3. Compensation and Rollback
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.
9.4. Autonomous Logistics Coordination
In a logistics workflow, multiple compliance checks complete before
shipment commitment. The DAG structure records that all required
checks were completed:
Nennemann Expires 29 August 2026 [Page 23]
Internet-Draft WIMSE Execution Context February 2026
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
Figure 11: 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.
10. Security Considerations
9. Security Considerations
This section addresses security considerations following the guidance
in [RFC3552].
10.1. Threat Model
9.1. Threat Model
The following threat actors are considered:
@@ -1339,14 +1117,12 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 29 August 2026 [Page 24]
Nennemann Expires 29 August 2026 [Page 20]
Internet-Draft WIMSE Execution Context February 2026
10.2. Self-Assertion Limitation
9.2. Self-Assertion Limitation
ECTs are self-asserted by the executing agent. The agent claims what
it did, and this claim is signed with its private key. A compromised
@@ -1377,7 +1153,7 @@ Internet-Draft WIMSE Execution Context February 2026
check the "witnessed_by" extension against independent witness ECTs
in the ECT store.
10.3. Organizational Prerequisites
9.3. Organizational Prerequisites
ECTs operate within a broader trust framework. The guarantees
provided by ECTs are only meaningful when the following
@@ -1397,12 +1173,12 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 29 August 2026 [Page 25]
Nennemann Expires 29 August 2026 [Page 21]
Internet-Draft WIMSE Execution Context February 2026
10.4. Signature Verification
9.4. Signature Verification
ECTs MUST be signed with the agent's private key using JWS [RFC7515].
The signature algorithm MUST match the algorithm specified in the
@@ -1418,7 +1194,7 @@ Internet-Draft WIMSE Execution Context February 2026
Implementations MUST use established JWS libraries and MUST NOT
implement custom signature verification.
10.5. Replay Attack Prevention
9.5. Replay Attack Prevention
ECTs include short expiration times (RECOMMENDED: 5-15 minutes) to
limit the window for replay attacks. The "aud" claim restricts
@@ -1434,7 +1210,7 @@ Internet-Draft WIMSE Execution Context February 2026
to detect replayed ECTs within the expiration window. An ECT with a
duplicate "jti" value MUST be rejected.
10.6. Man-in-the-Middle Protection
9.6. Man-in-the-Middle Protection
ECTs do not replace transport-layer security. ECTs MUST be
transmitted over TLS or mTLS connections. When used with the WIMSE
@@ -1453,12 +1229,12 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 29 August 2026 [Page 26]
Nennemann Expires 29 August 2026 [Page 22]
Internet-Draft WIMSE Execution Context February 2026
10.7. Key Compromise
9.7. Key Compromise
If an agent's private key is compromised, an attacker can forge ECTs
that appear to originate from that agent. To mitigate this risk:
@@ -1479,7 +1255,7 @@ Internet-Draft WIMSE Execution Context February 2026
flagged in the ledger as "signed with subsequently revoked key" for
audit purposes.
10.8. Collusion and False Claims
9.8. Collusion and False Claims
A single malicious agent cannot forge parent task references because
DAG validation requires parent tasks to exist in the ledger.
@@ -1509,12 +1285,12 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 29 August 2026 [Page 27]
Nennemann Expires 29 August 2026 [Page 23]
Internet-Draft WIMSE Execution Context February 2026
10.9. Denial of Service
9.9. Denial of Service
ECT signature verification is computationally inexpensive
(approximately 1ms per ECT on modern hardware for ES256). DAG
@@ -1527,7 +1303,7 @@ Internet-Draft WIMSE Execution Context February 2026
performed after signature verification to avoid wasting resources on
unsigned or incorrectly signed tokens.
10.10. Timestamp Accuracy
9.10. Timestamp Accuracy
ECTs rely on timestamps ("iat", "exp") for temporal ordering. Clock
skew between agents can lead to incorrect ordering judgments.
@@ -1544,7 +1320,7 @@ Internet-Draft WIMSE Execution Context February 2026
The temporal ordering check in DAG validation incorporates the clock
skew tolerance to account for minor clock differences between agents.
10.11. ECT Size Constraints
9.11. ECT Size Constraints
ECTs with many parent tasks or large extension objects can increase
HTTP header size. Implementations SHOULD limit the "par" array to a
@@ -1553,9 +1329,9 @@ Internet-Draft WIMSE Execution Context February 2026
SHOULD NOT exceed 4096 bytes when serialized as JSON and SHOULD NOT
exceed a nesting depth of 5 levels (see also Section 4.2.5).
11. Privacy Considerations
10. Privacy Considerations
11.1. Data Exposure in ECTs
10.1. Data Exposure in ECTs
ECTs necessarily reveal:
@@ -1565,7 +1341,7 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 29 August 2026 [Page 28]
Nennemann Expires 29 August 2026 [Page 24]
Internet-Draft WIMSE Execution Context February 2026
@@ -1583,7 +1359,7 @@ Internet-Draft WIMSE Execution Context February 2026
* Personally identifiable information (PII)
11.2. Data Minimization
10.2. Data Minimization
Implementations SHOULD minimize the information included in ECTs.
The "exec_act" claim SHOULD use structured identifiers (e.g.,
@@ -1592,7 +1368,7 @@ Internet-Draft WIMSE Execution Context February 2026
human-readable values risk exposing sensitive operational details.
See Section 4.2.5 for guidance on using structured identifiers.
11.3. Storage and Access Control
10.3. Storage and Access Control
ECTs stored in audit ledgers SHOULD be access-controlled so that only
authorized auditors and regulators can read them. Implementations
@@ -1604,15 +1380,15 @@ Internet-Draft WIMSE Execution Context February 2026
controls, since auditors may need to verify hash correctness but
general access to the data values is not needed.
11.4. Regulatory Access
10.4. 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.
12. IANA Considerations
11. IANA Considerations
12.1. Media Type Registration
11.1. Media Type Registration
This document requests registration of the following media type in
the "Media Types" registry maintained by IANA:
@@ -1621,7 +1397,7 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 29 August 2026 [Page 29]
Nennemann Expires 29 August 2026 [Page 25]
Internet-Draft WIMSE Execution Context February 2026
@@ -1661,7 +1437,7 @@ Internet-Draft WIMSE Execution Context February 2026
Change controller: IETF
12.2. HTTP Header Field Registration
11.2. HTTP Header Field Registration
This document requests registration of the following header field in
the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
@@ -1677,12 +1453,12 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 29 August 2026 [Page 30]
Nennemann Expires 29 August 2026 [Page 26]
Internet-Draft WIMSE Execution Context February 2026
12.3. JWT Claims Registration
11.3. JWT Claims Registration
This document requests registration of the following claims in the
"JSON Web Token Claims" registry maintained by IANA:
@@ -1714,9 +1490,9 @@ Internet-Draft WIMSE Execution Context February 2026
Policy evaluation claims and the ECT Policy Decision Values registry
are defined in [I-D.nennemann-wimse-ect-pol].
13. References
12. References
13.1. Normative References
12.1. Normative References
[I-D.ietf-wimse-arch]
Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
@@ -1733,7 +1509,7 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 29 August 2026 [Page 31]
Nennemann Expires 29 August 2026 [Page 27]
Internet-Draft WIMSE Execution Context February 2026
@@ -1776,7 +1552,7 @@ Internet-Draft WIMSE Execution Context February 2026
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/rfc/rfc9562>.
13.2. Informative References
12.2. Informative References
[DORA] European Parliament and Council of the European Union,
"Regulation (EU) 2022/2554 on digital operational
@@ -1789,7 +1565,7 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 29 August 2026 [Page 32]
Nennemann Expires 29 August 2026 [Page 28]
Internet-Draft WIMSE Execution Context February 2026
@@ -1845,7 +1621,7 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 29 August 2026 [Page 33]
Nennemann Expires 29 August 2026 [Page 29]
Internet-Draft WIMSE Execution Context February 2026
@@ -1879,6 +1655,227 @@ Internet-Draft WIMSE Execution Context February 2026
(SPIFFE)",
<https://spiffe.io/docs/latest/spiffe-about/overview/>.
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 Section 4.2.2.
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.
Nennemann Expires 29 August 2026 [Page 30]
Internet-Draft WIMSE Execution Context February 2026
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)
Figure 8: 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:
Nennemann Expires 29 August 2026 [Page 31]
Internet-Draft WIMSE Execution Context February 2026
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]
Figure 9: 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.
Financial Trading Workflow
In a financial trading workflow, agents perform risk assessment,
compliance verification, and trade execution. The DAG structure
records that compliance checks were evaluated before trade execution.
Nennemann Expires 29 August 2026 [Page 32]
Internet-Draft WIMSE Execution Context February 2026
Agent A (Risk Assessment):
jti: task-001 par: []
exec_act: calculate_risk_exposure
Agent B (Compliance):
jti: task-002 par: [task-001]
exec_act: verify_compliance
Agent C (Execution):
jti: task-003 par: [task-002]
exec_act: execute_trade
Figure 10: 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
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
In a logistics workflow, multiple compliance checks complete before
shipment commitment. The DAG structure records that all required
checks were completed:
Nennemann Expires 29 August 2026 [Page 33]
Internet-Draft WIMSE Execution Context February 2026
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
Figure 11: 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
WIMSE Workload Identity
@@ -1898,6 +1895,9 @@ OAuth 2.0 Token Exchange and the "act" Claim
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 branching (fan-out)
or convergence (fan-in) and therefore cannot form a DAG.
@@ -1906,10 +1906,6 @@ Nennemann Expires 29 August 2026 [Page 34]
Internet-Draft WIMSE Execution Context February 2026
task execution, 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.
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
@@ -1957,6 +1953,10 @@ Transaction Tokens
Nennemann Expires 29 August 2026 [Page 35]
Internet-Draft WIMSE Execution Context February 2026

1292
draft-nennemann-wimse-execution-context-00.xml
View File

File diff suppressed because it is too large Load Diff