Rename draft to draft-nennemann-wimse-ect-00

Shorter, cleaner name matching the companion spec naming convention.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
2026-02-25 16:57:24 +01:00
parent 907e823a4d
commit 47f5f97c90
4 changed files with 810 additions and 674 deletions

View File

@@ -34,7 +34,7 @@ regulatory frameworks.
<meta content="audit trail" name="keyword">
<meta content="compliance" name="keyword">
<meta content="regulated systems" name="keyword">
<meta content="draft-nennemann-wimse-execution-context-00" name="ietf.draft">
<meta content="draft-nennemann-wimse-ect-00" name="ietf.draft">
<!-- Generator version information:
xml2rfc 3.31.0
Python 3.9.6
@@ -49,7 +49,7 @@ regulatory frameworks.
requests 2.32.5
wcwidth 0.6.0
-->
<link href="draft-nennemann-wimse-execution-context-00.xml" rel="alternate" type="application/rfc+xml">
<link href="draft-nennemann-wimse-ect-00.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*
@@ -1252,7 +1252,7 @@ li > p:last-of-type:only-child {
<dt class="label-workgroup">Workgroup:</dt>
<dd class="workgroup">WIMSE</dd>
<dt class="label-internet-draft">Internet-Draft:</dt>
<dd class="internet-draft">draft-nennemann-wimse-execution-context-00</dd>
<dd class="internet-draft">draft-nennemann-wimse-ect-00</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2026-02-25" class="published">25 February 2026</time>
@@ -1534,7 +1534,7 @@ regulatory frameworks.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</ul>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.2">
<p id="section-toc.1-1.13.2.2.1"><a href="#appendix-A.2" class="auto internal xref"></a><a href="#name-financial-trading-workflow" class="internal xref">Financial Trading Workflow</a></p>
<p id="section-toc.1-1.13.2.2.1"><a href="#appendix-A.2" class="auto internal xref"></a><a href="#name-cross-organization-financia" class="internal xref">Cross-Organization Financial Trading</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.3">
<p id="section-toc.1-1.13.2.3.1"><a href="#appendix-A.3" class="auto internal xref"></a><a href="#name-compensation-and-rollback-2" class="internal xref">Compensation and Rollback</a></p>
@@ -3492,48 +3492,85 @@ oversight events occurred during the release process.<a href="#appendix-A.1.1-6.
</div>
</section>
</div>
<div id="financial-trading-workflow">
<div id="cross-organization-financial-trading">
<section id="appendix-A.2">
<h3 id="name-financial-trading-workflow">
<a href="#name-financial-trading-workflow" class="section-name selfRef">Financial Trading Workflow</a>
<h3 id="name-cross-organization-financia">
<a href="#name-cross-organization-financia" class="section-name selfRef">Cross-Organization Financial Trading</a>
</h3>
<p id="appendix-A.2-1">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.<a href="#appendix-A.2-1" class="pilcrow"></a></p>
<span id="name-financial-trading-workflow-2"></span><div id="fig-finance">
<p id="appendix-A.2-1">In a cross-organization trading workflow, an investment bank's
agents coordinate with an external credit rating agency. The
agents operate in separate trust domains with a federation
relationship. The DAG records that independent assessments from
both organizations were completed before trade execution.<a href="#appendix-A.2-1" class="pilcrow"></a></p>
<span id="name-cross-organization-trading-"></span><div id="fig-finance">
<figure id="figure-10">
<div class="alignLeft art-text artwork" id="appendix-A.2-2.1">
<pre>
Agent A (Risk Assessment):
jti: task-001 par: []
exec_act: calculate_risk_exposure
Trust Domain: bank.example
Agent A1 (Portfolio Risk):
jti: task-001 par: []
iss: spiffe://bank.example/agent/risk
exec_act: analyze_portfolio_risk
Agent B (Compliance):
jti: task-002 par: [task-001]
exec_act: verify_compliance
Trust Domain: ratings.example (external)
Agent B1 (Credit Rating):
jti: task-002 par: []
iss: spiffe://ratings.example/agent/credit
exec_act: assess_credit_rating
Agent C (Execution):
jti: task-003 par: [task-002]
exec_act: execute_trade
Trust Domain: bank.example
Agent A2 (Compliance):
jti: task-003 par: [task-001, task-002]
iss: spiffe://bank.example/agent/compliance
exec_act: verify_trade_compliance
Agent A3 (Execution):
jti: task-004 par: [task-003]
iss: spiffe://bank.example/agent/execution
exec_act: execute_trade
</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
<a href="#name-financial-trading-workflow-2" class="selfRef">Financial Trading Workflow</a>
<a href="#name-cross-organization-trading-" class="selfRef">Cross-Organization Trading Workflow</a>
</figcaption></figure>
</div>
<p id="appendix-A.2-3">This can contribute to compliance with:<a href="#appendix-A.2-3" class="pilcrow"></a></p>
<p id="appendix-A.2-3">The resulting DAG:<a href="#appendix-A.2-3" class="pilcrow"></a></p>
<span id="name-cross-organization-dag"></span><div id="fig-finance-dag">
<figure id="figure-11">
<div class="alignLeft art-text artwork" id="appendix-A.2-4.1">
<pre>
task-001 (analyze_portfolio_risk) task-002 (assess_credit_rating)
[bank.example] [ratings.example]
\ /
v v
task-003 (verify_trade_compliance)
[bank.example]
|
v
task-004 (execute_trade)
[bank.example]
</pre>
</div>
<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
<a href="#name-cross-organization-dag" class="selfRef">Cross-Organization DAG</a>
</figcaption></figure>
</div>
<p id="appendix-A.2-5">Task 003 has two parents from different trust domains,
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.<a href="#appendix-A.2-5" class="pilcrow"></a></p>
<p id="appendix-A.2-6">This can contribute to compliance with:<a href="#appendix-A.2-6" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="appendix-A.2-4.1">
<p id="appendix-A.2-4.1.1"><span>[<a href="#MIFID-II" class="cite xref">MIFID-II</a>]</span>: ECTs provide cryptographic records of the execution
sequence that can support transaction audit requirements.<a href="#appendix-A.2-4.1.1" class="pilcrow"></a></p>
<li class="normal" id="appendix-A.2-7.1">
<p id="appendix-A.2-7.1.1"><span>[<a href="#MIFID-II" class="cite xref">MIFID-II</a>]</span>: ECTs provide cryptographic records of the execution
sequence that can support transaction audit requirements.<a href="#appendix-A.2-7.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="appendix-A.2-4.2">
<p id="appendix-A.2-4.2.1"><span>[<a href="#DORA" class="cite xref">DORA</a>]</span> Article 12: ECTs contribute to ICT activity logging.<a href="#appendix-A.2-4.2.1" class="pilcrow"></a></p>
<li class="normal" id="appendix-A.2-7.2">
<p id="appendix-A.2-7.2.1"><span>[<a href="#DORA" class="cite xref">DORA</a>]</span> Article 12: ECTs contribute to ICT activity logging.<a href="#appendix-A.2-7.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="appendix-A.2-4.3">
<p id="appendix-A.2-4.3.1"><span>[<a href="#EU-AI-ACT" class="cite xref">EU-AI-ACT</a>]</span> Article 12: Logging of decisions made by AI-driven
systems.<a href="#appendix-A.2-4.3.1" class="pilcrow"></a></p>
<li class="normal" id="appendix-A.2-7.3">
<p id="appendix-A.2-7.3.1"><span>[<a href="#EU-AI-ACT" class="cite xref">EU-AI-ACT</a>]</span> Article 12: Logging of decisions made by AI-driven
systems.<a href="#appendix-A.2-7.3.1" class="pilcrow"></a></p>
</li>
</ul>
</section>
@@ -3558,7 +3595,7 @@ which links a remediation ECT to the original task.<a href="#appendix-A.3-1" cla
before shipment commitment. The DAG structure records that all
required checks were completed:<a href="#appendix-A.4-1" class="pilcrow"></a></p>
<span id="name-logistics-workflow-with-par"></span><div id="fig-logistics">
<figure id="figure-11">
<figure id="figure-12">
<div class="alignLeft art-text artwork" id="appendix-A.4-2.1">
<pre>
Agent A (Route Planning):
@@ -3582,7 +3619,7 @@ System (Commitment):
exec_act: commit_shipment
</pre>
</div>
<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
<a href="#name-logistics-workflow-with-par" class="selfRef">Logistics Workflow with Parallel Tasks</a>
</figcaption></figure>
</div>

View File

@@ -2,7 +2,7 @@
title: "Execution Context Tokens for Distributed Agentic Workflows"
abbrev: "WIMSE Execution Context"
category: std
docname: draft-nennemann-wimse-execution-context-00
docname: draft-nennemann-wimse-ect-00
submissiontype: IETF
number:
date:
@@ -1309,28 +1309,61 @@ This can contribute to compliance with:
- {{EU-AI-ACT}} Article 14: ECTs can record evidence that human
oversight events occurred during the release process.
## Financial Trading Workflow
## Cross-Organization Financial Trading
{: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.
In a cross-organization trading workflow, an investment bank's
agents coordinate with an external credit rating agency. The
agents operate in separate trust domains with a federation
relationship. The DAG records that independent assessments from
both organizations were completed before trade execution.
~~~
Agent A (Risk Assessment):
jti: task-001 par: []
exec_act: calculate_risk_exposure
Trust Domain: bank.example
Agent A1 (Portfolio Risk):
jti: task-001 par: []
iss: spiffe://bank.example/agent/risk
exec_act: analyze_portfolio_risk
Agent B (Compliance):
jti: task-002 par: [task-001]
exec_act: verify_compliance
Trust Domain: ratings.example (external)
Agent B1 (Credit Rating):
jti: task-002 par: []
iss: spiffe://ratings.example/agent/credit
exec_act: assess_credit_rating
Agent C (Execution):
jti: task-003 par: [task-002]
exec_act: execute_trade
Trust Domain: bank.example
Agent A2 (Compliance):
jti: task-003 par: [task-001, task-002]
iss: spiffe://bank.example/agent/compliance
exec_act: verify_trade_compliance
Agent A3 (Execution):
jti: task-004 par: [task-003]
iss: spiffe://bank.example/agent/execution
exec_act: execute_trade
~~~
{: #fig-finance title="Financial Trading Workflow"}
{: #fig-finance title="Cross-Organization Trading Workflow"}
The resulting DAG:
~~~
task-001 (analyze_portfolio_risk) task-002 (assess_credit_rating)
[bank.example] [ratings.example]
\ /
v v
task-003 (verify_trade_compliance)
[bank.example]
|
v
task-004 (execute_trade)
[bank.example]
~~~
{: #fig-finance-dag title="Cross-Organization DAG"}
Task 003 has two parents from different trust domains,
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:
@@ -1753,45 +1786,72 @@ 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
## Example 3: Cross-Organization Fan-In
{:numbered="false"}
A workflow where two tasks execute in parallel and a third task
depends on both:
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-...-0001 (assess_risk)
| \
v v
task-...-0002 task-...-0003
(check (verify
compliance) liquidity)
| /
v v
task-...-0004 (execute_trade)
~~~
Task 004 ECT payload:
Task 001 (Bank's risk agent — root task):
~~~json
{
"iss": "spiffe://bank.example/agent/execution",
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772064250,
"exp": 1772064850,
"jti": "f1e2d3c4-0004-0000-0000-000000000004",
"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": "execute_trade",
"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-0002-0000-0000-000000000002",
"f1e2d3c4-0003-0000-0000-000000000003"
"f1e2d3c4-0001-0000-0000-000000000001",
"f1e2d3c4-0002-0000-0000-000000000002"
]
}
~~~
The "par" array with two entries records that both compliance
checking and liquidity verification were completed before trade
execution.
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.
# Acknowledgments
{:numbered="false"}

View File

@@ -9,7 +9,7 @@ Expires: 29 August 2026
Execution Context Tokens for Distributed Agentic Workflows
draft-nennemann-wimse-execution-context-00
draft-nennemann-wimse-ect-00
Abstract
@@ -138,21 +138,21 @@ Internet-Draft WIMSE Execution Context February 2026
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
Cross-Organization Financial Trading . . . . . . . . . . . . . 32
Compensation and Rollback . . . . . . . . . . . . . . . . . . . 34
Autonomous Logistics Coordination . . . . . . . . . . . . . . . 34
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 35
WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 35
OAuth 2.0 Token Exchange and the "act" Claim . . . . . . . . . 35
Transaction Tokens . . . . . . . . . . . . . . . . . . . . . . 35
Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 36
Blockchain and Distributed Ledgers . . . . . . . . . . . . . . 36
SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 36
SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 37
W3C Verifiable Credentials . . . . . . . . . . . . . . . . . . 37
Implementation Guidance . . . . . . . . . . . . . . . . . . . . . 37
Minimal Implementation . . . . . . . . . . . . . . . . . . . . 37
Storage Recommendations . . . . . . . . . . . . . . . . . . . . 37
Performance Considerations . . . . . . . . . . . . . . . . . . 37
Storage Recommendations . . . . . . . . . . . . . . . . . . . . 38
Performance Considerations . . . . . . . . . . . . . . . . . . 38
Interoperability . . . . . . . . . . . . . . . . . . . . . . . 38
Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . . 38
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
@@ -1779,13 +1779,13 @@ Internet-Draft WIMSE Execution Context February 2026
* [EU-AI-ACT] Article 14: ECTs can record evidence that human
oversight events occurred during the release process.
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.
Cross-Organization Financial Trading
In a cross-organization trading workflow, an investment bank's agents
coordinate with an external credit rating agency. The agents operate
in separate trust domains with a federation relationship. The DAG
records that independent assessments from both organizations were
completed before trade execution.
@@ -1794,22 +1794,62 @@ 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
Trust Domain: bank.example
Agent A1 (Portfolio Risk):
jti: task-001 par: []
iss: spiffe://bank.example/agent/risk
exec_act: analyze_portfolio_risk
Agent B (Compliance):
jti: task-002 par: [task-001]
exec_act: verify_compliance
Trust Domain: ratings.example (external)
Agent B1 (Credit Rating):
jti: task-002 par: []
iss: spiffe://ratings.example/agent/credit
exec_act: assess_credit_rating
Agent C (Execution):
jti: task-003 par: [task-002]
exec_act: execute_trade
Trust Domain: bank.example
Agent A2 (Compliance):
jti: task-003 par: [task-001, task-002]
iss: spiffe://bank.example/agent/compliance
exec_act: verify_trade_compliance
Figure 10: Financial Trading Workflow
Agent A3 (Execution):
jti: task-004 par: [task-003]
iss: spiffe://bank.example/agent/execution
exec_act: execute_trade
Figure 10: Cross-Organization Trading Workflow
The resulting DAG:
task-001 (analyze_portfolio_risk) task-002 (assess_credit_rating)
[bank.example] [ratings.example]
\ /
v v
task-003 (verify_trade_compliance)
[bank.example]
|
v
task-004 (execute_trade)
[bank.example]
Figure 11: Cross-Organization DAG
Task 003 has two parents from different trust domains, 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:
Nennemann Expires 29 August 2026 [Page 33]
Internet-Draft WIMSE Execution Context February 2026
* [MIFID-II]: ECTs provide cryptographic records of the execution
sequence that can support transaction audit requirements.
@@ -1831,25 +1871,6 @@ Autonomous Logistics Coordination
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
@@ -1870,12 +1891,21 @@ Internet-Draft WIMSE Execution Context February 2026
jti: task-005 par: [task-004]
exec_act: commit_shipment
Figure 11: Logistics Workflow with Parallel Tasks
Figure 12: 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.
Nennemann Expires 29 August 2026 [Page 34]
Internet-Draft WIMSE Execution Context February 2026
Related Work
WIMSE Workload Identity
@@ -1899,13 +1929,6 @@ OAuth 2.0 Token Exchange and the "act" Claim
integrity data. The "act" chain cannot represent branching (fan-out)
or convergence (fan-in) and therefore cannot form a DAG.
Nennemann Expires 29 August 2026 [Page 34]
Internet-Draft WIMSE Execution Context February 2026
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
@@ -1930,6 +1953,15 @@ Transaction Tokens
from the Transaction Token Service appear in "req_wl"; workloads
that forward the token unchanged are not recorded.
Nennemann Expires 29 August 2026 [Page 35]
Internet-Draft WIMSE Execution Context February 2026
* It carries no task-level granularity, no parent references, and no
execution content.
@@ -1948,20 +1980,6 @@ Transaction Tokens
Txn-Token; a similar binding mechanism for ECTs is a potential future
extension.
Nennemann Expires 29 August 2026 [Page 35]
Internet-Draft WIMSE Execution Context February 2026
Distributed Tracing (OpenTelemetry)
OpenTelemetry [OPENTELEMETRY] and similar distributed tracing systems
@@ -1985,6 +2003,21 @@ Blockchain and Distributed Ledgers
or any storage providing the required properties defined in
Section 8.
Nennemann Expires 29 August 2026 [Page 36]
Internet-Draft WIMSE Execution Context February 2026
SCITT (Supply Chain Integrity, Transparency, and Trust)
The SCITT architecture [I-D.ietf-scitt-architecture] defines a
@@ -2005,19 +2038,6 @@ SCITT (Supply Chain Integrity, Transparency, and Trust)
Transparency Service identifiers or Receipt references for tighter
integration.
Nennemann Expires 29 August 2026 [Page 36]
Internet-Draft WIMSE Execution Context February 2026
W3C Verifiable Credentials
W3C Verifiable Credentials represent claims about subjects (e.g.,
@@ -2044,6 +2064,16 @@ Minimal Implementation
5. If an audit ledger is deployed, append verified ECTs to it.
Nennemann Expires 29 August 2026 [Page 37]
Internet-Draft WIMSE Execution Context February 2026
Storage Recommendations
* Append-only log: Simplest approach; immutability by design.
@@ -2067,13 +2097,6 @@ Performance Considerations
* JSON serialization: sub-millisecond per ECT.
Nennemann Expires 29 August 2026 [Page 37]
Internet-Draft WIMSE Execution Context February 2026
* Total per-request overhead: approximately 5-10ms, acceptable for
regulated workflows where correctness is prioritized over latency.
@@ -2102,29 +2125,6 @@ Regulatory Compliance Mapping
Nennemann Expires 29 August 2026 [Page 38]
Internet-Draft WIMSE Execution Context February 2026