Christian Nennemann
bf0f94ab30
- Remove sub claim (always equals iss, added no information) - Move compensation_required and compensation_reason to ext keys - Move pol, pol_decision, pol_enforcer to ext keys - IANA JWT Claims table reduced from 11 to 6 registered claims - Trim witness attestation section to concise guidance - Fix remaining ledger-mandatory language in verification step 15 and minimal implementation guidance Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
4480 lines
216 KiB
HTML
4480 lines
216 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en" class="Internet-Draft">
|
||
<head>
|
||
<meta charset="utf-8">
|
||
<meta content="Common,Latin" name="scripts">
|
||
<meta content="initial-scale=1.0" name="viewport">
|
||
<title>Execution Context Tokens for Distributed Agentic Workflows</title>
|
||
<meta content="Christian Nennemann" name="author">
|
||
<meta content="
|
||
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, policy evaluation outcomes, and compliance state
|
||
across
|
||
agent-to-agent communication. By extending WIMSE Workload Identity
|
||
Tokens with execution context claims in JSON Web Token (JWT)
|
||
format, this specification enables regulated systems to maintain
|
||
structured audit trails that support compliance verification.
|
||
ECTs use a directed acyclic graph (DAG) structure to represent task
|
||
dependencies, record policy evaluation outcomes at each decision
|
||
point, and integrate with WIMSE Workload Identity Tokens (WIT)
|
||
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.
|
||
" name="description">
|
||
<meta content="xml2rfc 3.31.0" name="generator">
|
||
<meta content="execution context" name="keyword">
|
||
<meta content="workload identity" name="keyword">
|
||
<meta content="agentic workflows" name="keyword">
|
||
<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">
|
||
<!-- Generator version information:
|
||
xml2rfc 3.31.0
|
||
Python 3.9.6
|
||
ConfigArgParse 1.7.1
|
||
google-i18n-address 3.1.1
|
||
intervaltree 3.2.1
|
||
Jinja2 3.1.6
|
||
lxml 6.0.2
|
||
platformdirs 4.4.0
|
||
pycountry 24.6.1
|
||
PyYAML 6.0.3
|
||
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="#copyright" rel="license">
|
||
<style type="text/css">/*
|
||
|
||
NOTE: Changes at the bottom of this file overrides some earlier settings.
|
||
|
||
Once the style has stabilized and has been adopted as an official RFC style,
|
||
this can be consolidated so that style settings occur only in one place, but
|
||
for now the contents of this file consists first of the initial CSS work as
|
||
provided to the RFC Formatter (xml2rfc) work, followed by itemized and
|
||
commented changes found necessary during the development of the v3
|
||
formatters.
|
||
|
||
*/
|
||
|
||
/* fonts */
|
||
@import url('https://static.ietf.org/fonts/noto-sans/import.css'); /* Sans-serif */
|
||
@import url('https://static.ietf.org/fonts/noto-serif/import.css'); /* Serif (print) */
|
||
@import url('https://static.ietf.org/fonts/roboto-mono/import.css'); /* Monospace */
|
||
|
||
:root {
|
||
--font-sans: 'Noto Sans', Arial, Helvetica, sans-serif;
|
||
--font-serif: 'Noto Serif', 'Times', 'Times New Roman', serif;
|
||
--font-mono: 'Roboto Mono', Courier, 'Courier New', monospace;
|
||
}
|
||
|
||
@viewport {
|
||
zoom: 1.0;
|
||
}
|
||
@-ms-viewport {
|
||
width: extend-to-zoom;
|
||
zoom: 1.0;
|
||
}
|
||
/* general and mobile first */
|
||
html {
|
||
}
|
||
body {
|
||
max-width: 90%;
|
||
margin: 1.5em auto;
|
||
color: #222;
|
||
background-color: #fff;
|
||
font-size: 14px;
|
||
font-family: var(--font-sans);
|
||
line-height: 1.6;
|
||
scroll-behavior: smooth;
|
||
overflow-wrap: break-word;
|
||
}
|
||
.ears {
|
||
display: none;
|
||
}
|
||
|
||
/* headings */
|
||
#title, h1, h2, h3, h4, h5, h6 {
|
||
margin: 1em 0 0.5em;
|
||
font-weight: bold;
|
||
line-height: 1.3;
|
||
}
|
||
#title {
|
||
clear: both;
|
||
border-bottom: 1px solid #ddd;
|
||
margin: 0 0 0.5em 0;
|
||
padding: 1em 0 0.5em;
|
||
}
|
||
.author {
|
||
padding-bottom: 4px;
|
||
}
|
||
h1 {
|
||
font-size: 26px;
|
||
margin: 1em 0;
|
||
}
|
||
h2 {
|
||
font-size: 22px;
|
||
margin-top: -20px; /* provide offset for in-page anchors */
|
||
padding-top: 33px;
|
||
}
|
||
h3 {
|
||
font-size: 18px;
|
||
margin-top: -36px; /* provide offset for in-page anchors */
|
||
padding-top: 42px;
|
||
}
|
||
h4 {
|
||
font-size: 16px;
|
||
margin-top: -36px; /* provide offset for in-page anchors */
|
||
padding-top: 42px;
|
||
}
|
||
h5, h6 {
|
||
font-size: 14px;
|
||
}
|
||
#n-copyright-notice {
|
||
border-bottom: 1px solid #ddd;
|
||
padding-bottom: 1em;
|
||
margin-bottom: 1em;
|
||
}
|
||
/* general structure */
|
||
p {
|
||
padding: 0;
|
||
margin: 0 0 1em 0;
|
||
text-align: left;
|
||
}
|
||
div, span {
|
||
position: relative;
|
||
}
|
||
div {
|
||
margin: 0;
|
||
}
|
||
.alignRight.art-text {
|
||
background-color: #f9f9f9;
|
||
border: 1px solid #eee;
|
||
border-radius: 3px;
|
||
padding: 1em 1em 0;
|
||
margin-bottom: 1.5em;
|
||
}
|
||
.alignRight.art-text pre {
|
||
padding: 0;
|
||
}
|
||
.alignRight {
|
||
margin: 1em 0;
|
||
}
|
||
.alignRight > *:first-child {
|
||
border: none;
|
||
margin: 0;
|
||
float: right;
|
||
clear: both;
|
||
}
|
||
.alignRight > *:nth-child(2) {
|
||
clear: both;
|
||
display: block;
|
||
border: none;
|
||
}
|
||
svg {
|
||
display: block;
|
||
}
|
||
@media print {
|
||
svg {
|
||
max-height: 850px;
|
||
max-width: 660px;
|
||
}
|
||
}
|
||
svg[font-family~="serif" i], svg [font-family~="serif" i] {
|
||
font-family: var(--font-serif);
|
||
}
|
||
svg[font-family~="sans-serif" i], svg [font-family~="sans-serif" i] {
|
||
font-family: var(--font-sans);
|
||
}
|
||
svg[font-family~="monospace" i], svg [font-family~="monospace" i] {
|
||
font-family: var(--font-mono);
|
||
}
|
||
.alignCenter.art-text {
|
||
background-color: #f9f9f9;
|
||
border: 1px solid #eee;
|
||
border-radius: 3px;
|
||
padding: 1em 1em 0;
|
||
margin-bottom: 1.5em;
|
||
}
|
||
.alignCenter.art-text pre {
|
||
padding: 0;
|
||
}
|
||
.alignCenter {
|
||
margin: 1em 0;
|
||
}
|
||
.alignCenter > *:first-child {
|
||
display: table;
|
||
border: none;
|
||
margin: 0 auto;
|
||
}
|
||
|
||
/* lists */
|
||
ol, ul {
|
||
padding: 0;
|
||
margin: 0 0 1em 2em;
|
||
}
|
||
ol ol, ul ul, ol ul, ul ol {
|
||
margin-left: 1em;
|
||
}
|
||
li {
|
||
margin: 0 0 0.25em 0;
|
||
}
|
||
.ulCompact li {
|
||
margin: 0;
|
||
}
|
||
ul.empty, .ulEmpty {
|
||
list-style-type: none;
|
||
}
|
||
ul.empty li, .ulEmpty li {
|
||
margin-top: 0.5em;
|
||
}
|
||
ul.ulBare, li.ulBare {
|
||
margin-left: 0em !important;
|
||
}
|
||
ul.compact, .ulCompact,
|
||
ol.compact, .olCompact {
|
||
line-height: 100%;
|
||
margin: 0 0 0 2em;
|
||
}
|
||
|
||
/* definition lists */
|
||
dl {
|
||
}
|
||
dl > dt {
|
||
float: left;
|
||
margin-right: 1em;
|
||
}
|
||
/*
|
||
dl.nohang > dt {
|
||
float: none;
|
||
}
|
||
*/
|
||
dl > dd {
|
||
margin-bottom: .8em;
|
||
min-height: 1.3em;
|
||
}
|
||
dl.compact > dd, .dlCompact > dd {
|
||
margin-bottom: 0em;
|
||
}
|
||
dl > dd > dl {
|
||
margin-top: 0.5em;
|
||
margin-bottom: 0em;
|
||
}
|
||
|
||
/* links */
|
||
a {
|
||
text-decoration: none;
|
||
}
|
||
a[href] {
|
||
color: #22e; /* Arlen: WCAG 2019 */
|
||
}
|
||
a[href]:hover {
|
||
background-color: #f2f2f2;
|
||
}
|
||
figcaption a[href],
|
||
a[href].selfRef {
|
||
color: #222;
|
||
}
|
||
/* XXX probably not this:
|
||
a.selfRef:hover {
|
||
background-color: transparent;
|
||
cursor: default;
|
||
} */
|
||
|
||
/* Figures */
|
||
tt, code, pre {
|
||
background-color: #f9f9f9;
|
||
font-family: var(--font-mono);
|
||
}
|
||
pre {
|
||
border: 1px solid #eee;
|
||
margin: 0;
|
||
padding: 1em;
|
||
}
|
||
img {
|
||
max-width: 100%;
|
||
}
|
||
figure {
|
||
margin: 0;
|
||
}
|
||
figure blockquote {
|
||
margin: 0.8em 0.4em 0.4em;
|
||
}
|
||
figcaption {
|
||
font-style: italic;
|
||
margin: 0 0 1em 0;
|
||
}
|
||
@media screen {
|
||
pre {
|
||
overflow-x: auto;
|
||
max-width: 100%;
|
||
max-width: calc(100% - 22px);
|
||
}
|
||
}
|
||
|
||
/* aside, blockquote */
|
||
aside, blockquote {
|
||
margin-left: 0;
|
||
padding: 1.2em 2em;
|
||
}
|
||
blockquote {
|
||
background-color: #f9f9f9;
|
||
color: #111; /* Arlen: WCAG 2019 */
|
||
border: 1px solid #ddd;
|
||
border-radius: 3px;
|
||
margin: 1em 0;
|
||
}
|
||
blockquote > *:last-child {
|
||
margin-bottom: 0;
|
||
}
|
||
cite {
|
||
display: block;
|
||
text-align: right;
|
||
font-style: italic;
|
||
}
|
||
.xref {
|
||
overflow-wrap: normal;
|
||
}
|
||
|
||
/* tables */
|
||
table {
|
||
width: 100%;
|
||
margin: 0 0 1em;
|
||
border-collapse: collapse;
|
||
border: 1px solid #eee;
|
||
}
|
||
th, td {
|
||
text-align: left;
|
||
vertical-align: top;
|
||
padding: 0.5em 0.75em;
|
||
}
|
||
th {
|
||
text-align: left;
|
||
background-color: #e9e9e9;
|
||
}
|
||
tr:nth-child(2n+1) > td {
|
||
background-color: #f5f5f5;
|
||
}
|
||
table caption {
|
||
font-style: italic;
|
||
margin: 0;
|
||
padding: 0;
|
||
text-align: left;
|
||
}
|
||
table p {
|
||
/* XXX to avoid bottom margin on table row signifiers. If paragraphs should
|
||
be allowed within tables more generally, it would be far better to select on a class. */
|
||
margin: 0;
|
||
}
|
||
|
||
/* pilcrow */
|
||
a.pilcrow {
|
||
color: #666; /* Arlen: AHDJ 2019 */
|
||
text-decoration: none;
|
||
visibility: hidden;
|
||
user-select: none;
|
||
-ms-user-select: none;
|
||
-o-user-select:none;
|
||
-moz-user-select: none;
|
||
-khtml-user-select: none;
|
||
-webkit-user-select: none;
|
||
-webkit-touch-callout: none;
|
||
}
|
||
@media screen {
|
||
aside:hover > a.pilcrow,
|
||
p:hover > a.pilcrow,
|
||
blockquote:hover > a.pilcrow,
|
||
div:hover > a.pilcrow,
|
||
li:hover > a.pilcrow,
|
||
pre:hover > a.pilcrow {
|
||
visibility: visible;
|
||
}
|
||
a.pilcrow:hover {
|
||
background-color: transparent;
|
||
}
|
||
}
|
||
|
||
/* misc */
|
||
hr {
|
||
border: 0;
|
||
border-top: 1px solid #eee;
|
||
}
|
||
.bcp14 {
|
||
font-variant: small-caps;
|
||
}
|
||
|
||
.role {
|
||
font-variant: all-small-caps;
|
||
}
|
||
|
||
/* info block */
|
||
#identifiers {
|
||
margin: 0;
|
||
font-size: 0.9em;
|
||
}
|
||
#identifiers dt {
|
||
width: 3em;
|
||
clear: left;
|
||
}
|
||
#identifiers dd {
|
||
float: left;
|
||
margin-bottom: 0;
|
||
}
|
||
/* Fix PDF info block run off issue */
|
||
@media print {
|
||
#identifiers dd {
|
||
max-width: 100%;
|
||
}
|
||
}
|
||
#identifiers .authors .author {
|
||
display: inline-block;
|
||
margin-right: 1.5em;
|
||
}
|
||
#identifiers .authors .org {
|
||
font-style: italic;
|
||
}
|
||
|
||
/* The prepared/rendered info at the very bottom of the page */
|
||
.docInfo {
|
||
color: #666; /* Arlen: WCAG 2019 */
|
||
font-size: 0.9em;
|
||
font-style: italic;
|
||
margin-top: 2em;
|
||
}
|
||
.docInfo .prepared {
|
||
float: left;
|
||
}
|
||
.docInfo .prepared {
|
||
float: right;
|
||
}
|
||
|
||
/* table of contents */
|
||
#toc {
|
||
padding: 0.75em 0 2em 0;
|
||
margin-bottom: 1em;
|
||
}
|
||
nav.toc ul {
|
||
margin: 0 0.5em 0 0;
|
||
padding: 0;
|
||
list-style: none;
|
||
}
|
||
nav.toc li {
|
||
line-height: 1.3em;
|
||
margin: 0.75em 0;
|
||
padding-left: 1.2em;
|
||
text-indent: -1.2em;
|
||
}
|
||
/* references */
|
||
.references dt {
|
||
text-align: right;
|
||
font-weight: bold;
|
||
min-width: 7em;
|
||
}
|
||
.references dd {
|
||
margin-left: 8em;
|
||
overflow: auto;
|
||
}
|
||
|
||
.refInstance {
|
||
margin-bottom: 1.25em;
|
||
}
|
||
|
||
.refSubseries {
|
||
margin-bottom: 1.25em;
|
||
}
|
||
|
||
.references .ascii {
|
||
margin-bottom: 0.25em;
|
||
}
|
||
|
||
/* index */
|
||
.index ul {
|
||
margin: 0 0 0 1em;
|
||
padding: 0;
|
||
list-style: none;
|
||
}
|
||
.index ul ul {
|
||
margin: 0;
|
||
}
|
||
.index li {
|
||
margin: 0;
|
||
text-indent: -2em;
|
||
padding-left: 2em;
|
||
padding-bottom: 5px;
|
||
}
|
||
.indexIndex {
|
||
margin: 0.5em 0 1em;
|
||
}
|
||
.index a {
|
||
font-weight: 700;
|
||
}
|
||
/* make the index two-column on all but the smallest screens */
|
||
@media (min-width: 600px) {
|
||
.index ul {
|
||
-moz-column-count: 2;
|
||
-moz-column-gap: 20px;
|
||
}
|
||
.index ul ul {
|
||
-moz-column-count: 1;
|
||
-moz-column-gap: 0;
|
||
}
|
||
}
|
||
|
||
/* authors */
|
||
address.vcard {
|
||
font-style: normal;
|
||
margin: 1em 0;
|
||
}
|
||
|
||
address.vcard .nameRole {
|
||
font-weight: 700;
|
||
margin-left: 0;
|
||
}
|
||
address.vcard .label {
|
||
font-family: var(--font-sans);
|
||
margin: 0.5em 0;
|
||
}
|
||
address.vcard .type {
|
||
display: none;
|
||
}
|
||
.alternative-contact {
|
||
margin: 1.5em 0 1em;
|
||
}
|
||
hr.addr {
|
||
border-top: 1px dashed;
|
||
margin: 0;
|
||
color: #ddd;
|
||
max-width: calc(100% - 16px);
|
||
}
|
||
|
||
/* temporary notes */
|
||
.rfcEditorRemove::before {
|
||
position: absolute;
|
||
top: 0.2em;
|
||
right: 0.2em;
|
||
padding: 0.2em;
|
||
content: "The RFC Editor will remove this note";
|
||
color: #9e2a00; /* Arlen: WCAG 2019 */
|
||
background-color: #ffd; /* Arlen: WCAG 2019 */
|
||
}
|
||
.rfcEditorRemove {
|
||
position: relative;
|
||
padding-top: 1.8em;
|
||
background-color: #ffd; /* Arlen: WCAG 2019 */
|
||
border-radius: 3px;
|
||
}
|
||
.cref {
|
||
background-color: #ffd; /* Arlen: WCAG 2019 */
|
||
padding: 2px 4px;
|
||
}
|
||
.crefSource {
|
||
font-style: italic;
|
||
}
|
||
/* alternative layout for smaller screens */
|
||
@media screen and (max-width: 1023px) {
|
||
body {
|
||
padding-top: 2em;
|
||
}
|
||
#title {
|
||
padding: 1em 0;
|
||
}
|
||
h1 {
|
||
font-size: 24px;
|
||
}
|
||
h2 {
|
||
font-size: 20px;
|
||
margin-top: -18px; /* provide offset for in-page anchors */
|
||
padding-top: 38px;
|
||
}
|
||
#identifiers dd {
|
||
max-width: 60%;
|
||
}
|
||
#toc {
|
||
position: fixed;
|
||
z-index: 2;
|
||
top: 0;
|
||
right: 0;
|
||
padding: 0;
|
||
margin: 0;
|
||
background-color: inherit;
|
||
border-bottom: 1px solid #ccc;
|
||
}
|
||
#toc h2 {
|
||
margin: -1px 0 0 0;
|
||
padding: 4px 0 4px 6px;
|
||
padding-right: 1em;
|
||
min-width: 190px;
|
||
font-size: 1.1em;
|
||
text-align: right;
|
||
background-color: #444;
|
||
color: white;
|
||
cursor: pointer;
|
||
}
|
||
#toc h2::before { /* css hamburger */
|
||
float: right;
|
||
position: relative;
|
||
width: 1em;
|
||
height: 1px;
|
||
left: -164px;
|
||
margin: 6px 0 0 0;
|
||
background: white none repeat scroll 0 0;
|
||
box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
|
||
content: "";
|
||
}
|
||
#toc nav {
|
||
display: none;
|
||
padding: 0.5em 1em 1em;
|
||
overflow: auto;
|
||
height: calc(100vh - 48px);
|
||
border-left: 1px solid #ddd;
|
||
}
|
||
}
|
||
|
||
/* alternative layout for wide screens */
|
||
@media screen and (min-width: 1024px) {
|
||
body {
|
||
max-width: 724px;
|
||
margin: 42px auto;
|
||
padding-left: 1.5em;
|
||
padding-right: 29em;
|
||
}
|
||
#toc {
|
||
position: fixed;
|
||
top: 42px;
|
||
right: 42px;
|
||
width: 25%;
|
||
margin: 0;
|
||
padding: 0 1em;
|
||
z-index: 1;
|
||
}
|
||
#toc h2 {
|
||
border-top: none;
|
||
border-bottom: 1px solid #ddd;
|
||
font-size: 1em;
|
||
font-weight: normal;
|
||
margin: 0;
|
||
padding: 0.25em 1em 1em 0;
|
||
}
|
||
#toc nav {
|
||
display: block;
|
||
height: calc(90vh - 84px);
|
||
bottom: 0;
|
||
padding: 0.5em 0 0;
|
||
overflow: auto;
|
||
}
|
||
img { /* future proofing */
|
||
max-width: 100%;
|
||
height: auto;
|
||
}
|
||
}
|
||
|
||
/* pagination */
|
||
@media print {
|
||
body {
|
||
width: 100%;
|
||
}
|
||
p {
|
||
orphans: 3;
|
||
widows: 3;
|
||
}
|
||
#n-copyright-notice {
|
||
border-bottom: none;
|
||
}
|
||
#toc, #n-introduction {
|
||
page-break-before: always;
|
||
}
|
||
#toc {
|
||
border-top: none;
|
||
padding-top: 0;
|
||
}
|
||
figure, pre {
|
||
page-break-inside: avoid;
|
||
}
|
||
figure {
|
||
overflow: scroll;
|
||
}
|
||
.breakable pre {
|
||
break-inside: auto;
|
||
}
|
||
h1, h2, h3, h4, h5, h6 {
|
||
page-break-after: avoid;
|
||
}
|
||
h2+*, h3+*, h4+*, h5+*, h6+* {
|
||
page-break-before: avoid;
|
||
}
|
||
pre {
|
||
white-space: pre-wrap;
|
||
word-wrap: break-word;
|
||
font-size: 10pt;
|
||
}
|
||
table {
|
||
border: 1px solid #ddd;
|
||
}
|
||
td {
|
||
border-top: 1px solid #ddd;
|
||
}
|
||
}
|
||
|
||
/* This is commented out here, as the string-set: doesn't
|
||
pass W3C validation currently */
|
||
/*
|
||
.ears thead .left {
|
||
string-set: ears-top-left content();
|
||
}
|
||
|
||
.ears thead .center {
|
||
string-set: ears-top-center content();
|
||
}
|
||
|
||
.ears thead .right {
|
||
string-set: ears-top-right content();
|
||
}
|
||
|
||
.ears tfoot .left {
|
||
string-set: ears-bottom-left content();
|
||
}
|
||
|
||
.ears tfoot .center {
|
||
string-set: ears-bottom-center content();
|
||
}
|
||
|
||
.ears tfoot .right {
|
||
string-set: ears-bottom-right content();
|
||
}
|
||
*/
|
||
|
||
@page :first {
|
||
padding-top: 0;
|
||
@top-left {
|
||
content: normal;
|
||
border: none;
|
||
}
|
||
@top-center {
|
||
content: normal;
|
||
border: none;
|
||
}
|
||
@top-right {
|
||
content: normal;
|
||
border: none;
|
||
}
|
||
}
|
||
|
||
@page {
|
||
size: A4;
|
||
margin-bottom: 45mm;
|
||
padding-top: 20px;
|
||
/* The following is commented out here, but set appropriately by in code, as
|
||
the content depends on the document */
|
||
/*
|
||
@top-left {
|
||
content: 'Internet-Draft';
|
||
vertical-align: bottom;
|
||
border-bottom: solid 1px #ccc;
|
||
}
|
||
@top-left {
|
||
content: string(ears-top-left);
|
||
vertical-align: bottom;
|
||
border-bottom: solid 1px #ccc;
|
||
}
|
||
@top-center {
|
||
content: string(ears-top-center);
|
||
vertical-align: bottom;
|
||
border-bottom: solid 1px #ccc;
|
||
}
|
||
@top-right {
|
||
content: string(ears-top-right);
|
||
vertical-align: bottom;
|
||
border-bottom: solid 1px #ccc;
|
||
}
|
||
@bottom-left {
|
||
content: string(ears-bottom-left);
|
||
vertical-align: top;
|
||
border-top: solid 1px #ccc;
|
||
}
|
||
@bottom-center {
|
||
content: string(ears-bottom-center);
|
||
vertical-align: top;
|
||
border-top: solid 1px #ccc;
|
||
}
|
||
@bottom-right {
|
||
content: '[Page ' counter(page) ']';
|
||
vertical-align: top;
|
||
border-top: solid 1px #ccc;
|
||
}
|
||
*/
|
||
|
||
}
|
||
|
||
/* Changes introduced to fix issues found during implementation */
|
||
/* Make sure links are clickable even if overlapped by following H* */
|
||
a {
|
||
z-index: 2;
|
||
}
|
||
/* Separate body from document info even without intervening H1 */
|
||
section {
|
||
clear: both;
|
||
}
|
||
|
||
|
||
/* Top align author divs, to avoid names without organization dropping level with org names */
|
||
.author {
|
||
vertical-align: top;
|
||
}
|
||
|
||
/* Leave room in document info to show Internet-Draft on one line */
|
||
#identifiers dt {
|
||
width: 8em;
|
||
}
|
||
|
||
/* Don't waste quite as much whitespace between label and value in doc info */
|
||
#identifiers dd {
|
||
margin-left: 1em;
|
||
}
|
||
|
||
/* Give floating toc a background color (needed when it's a div inside section */
|
||
#toc {
|
||
background-color: white;
|
||
}
|
||
|
||
/* Make the collapsed ToC header render white on gray also when it's a link */
|
||
@media screen and (max-width: 1023px) {
|
||
#toc h2 a,
|
||
#toc h2 a:link,
|
||
#toc h2 a:focus,
|
||
#toc h2 a:hover,
|
||
#toc a.toplink,
|
||
#toc a.toplink:hover {
|
||
color: white;
|
||
background-color: #444;
|
||
text-decoration: none;
|
||
}
|
||
}
|
||
|
||
/* Give the bottom of the ToC some whitespace */
|
||
@media screen and (min-width: 1024px) {
|
||
#toc {
|
||
padding: 0 0 1em 1em;
|
||
}
|
||
}
|
||
|
||
/* Style section numbers with more space between number and title */
|
||
.section-number {
|
||
padding-right: 0.5em;
|
||
}
|
||
|
||
/* prevent monospace from becoming overly large */
|
||
tt, code, pre {
|
||
font-size: 95%;
|
||
}
|
||
|
||
/* Fix the height/width aspect for ascii art*/
|
||
.sourcecode pre,
|
||
.art-text pre {
|
||
line-height: 1.12;
|
||
}
|
||
|
||
|
||
/* Add styling for a link in the ToC that points to the top of the document */
|
||
a.toplink {
|
||
float: right;
|
||
margin-right: 0.5em;
|
||
}
|
||
|
||
/* Fix the dl styling to match the RFC 7992 attributes */
|
||
dl > dt,
|
||
dl.dlParallel > dt {
|
||
float: left;
|
||
margin-right: 1em;
|
||
}
|
||
dl.dlNewline > dt {
|
||
float: none;
|
||
}
|
||
|
||
/* Provide styling for table cell text alignment */
|
||
table td.text-left,
|
||
table th.text-left {
|
||
text-align: left;
|
||
}
|
||
table td.text-center,
|
||
table th.text-center {
|
||
text-align: center;
|
||
}
|
||
table td.text-right,
|
||
table th.text-right {
|
||
text-align: right;
|
||
}
|
||
|
||
/* Make the alternative author contact information look less like just another
|
||
author, and group it closer with the primary author contact information */
|
||
.alternative-contact {
|
||
margin: 0.5em 0 0.25em 0;
|
||
}
|
||
address .non-ascii {
|
||
margin: 0 0 0 2em;
|
||
}
|
||
|
||
/* With it being possible to set tables with alignment
|
||
left, center, and right, { width: 100%; } does not make sense */
|
||
table {
|
||
width: auto;
|
||
}
|
||
|
||
/* Avoid reference text that sits in a block with very wide left margin,
|
||
because of a long floating dt label.*/
|
||
.references dd {
|
||
overflow: visible;
|
||
}
|
||
|
||
/* Control caption placement */
|
||
caption {
|
||
caption-side: bottom;
|
||
}
|
||
|
||
/* Limit the width of the author address vcard, so names in right-to-left
|
||
script don't end up on the other side of the page. */
|
||
|
||
address.vcard {
|
||
max-width: 30em;
|
||
margin-right: auto;
|
||
}
|
||
|
||
/* For address alignment dependent on LTR or RTL scripts */
|
||
address div.left {
|
||
text-align: left;
|
||
}
|
||
address div.right {
|
||
text-align: right;
|
||
}
|
||
|
||
/* Provide table alignment support. We can't use the alignX classes above
|
||
since they do unwanted things with caption and other styling. */
|
||
table.right {
|
||
margin-left: auto;
|
||
margin-right: 0;
|
||
}
|
||
table.center {
|
||
margin-left: auto;
|
||
margin-right: auto;
|
||
}
|
||
table.left {
|
||
margin-left: 0;
|
||
margin-right: auto;
|
||
}
|
||
|
||
/* Give the table caption label the same styling as the figcaption */
|
||
caption a[href] {
|
||
color: #222;
|
||
}
|
||
|
||
@media print {
|
||
.toplink {
|
||
display: none;
|
||
}
|
||
|
||
/* avoid overwriting the top border line with the ToC header */
|
||
#toc {
|
||
padding-top: 1px;
|
||
}
|
||
|
||
/* Avoid page breaks inside dl and author address entries */
|
||
.vcard {
|
||
page-break-inside: avoid;
|
||
}
|
||
|
||
}
|
||
/* Tweak the bcp14 keyword presentation */
|
||
.bcp14 {
|
||
font-variant: small-caps;
|
||
font-weight: bold;
|
||
font-size: 0.9em;
|
||
}
|
||
/* Tweak the invisible space above H* in order not to overlay links in text above */
|
||
h2 {
|
||
margin-top: -18px; /* provide offset for in-page anchors */
|
||
padding-top: 31px;
|
||
}
|
||
h3 {
|
||
margin-top: -18px; /* provide offset for in-page anchors */
|
||
padding-top: 24px;
|
||
}
|
||
h4 {
|
||
margin-top: -18px; /* provide offset for in-page anchors */
|
||
padding-top: 24px;
|
||
}
|
||
/* Float artwork pilcrow to the right */
|
||
@media screen {
|
||
.artwork a.pilcrow {
|
||
display: block;
|
||
line-height: 0.7;
|
||
margin-top: 0.15em;
|
||
}
|
||
}
|
||
/* Make pilcrows on dd visible */
|
||
@media screen {
|
||
dd:hover > a.pilcrow {
|
||
visibility: visible;
|
||
}
|
||
}
|
||
/* Make the placement of figcaption match that of a table's caption
|
||
by removing the figure's added bottom margin */
|
||
.alignLeft.art-text,
|
||
.alignCenter.art-text,
|
||
.alignRight.art-text {
|
||
margin-bottom: 0;
|
||
}
|
||
.alignLeft,
|
||
.alignCenter,
|
||
.alignRight {
|
||
margin: 1em 0 0 0;
|
||
}
|
||
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
|
||
possibly even requiring a new line */
|
||
@media print {
|
||
a.pilcrow {
|
||
display: none;
|
||
}
|
||
}
|
||
/* Styling for the external metadata */
|
||
div#external-metadata {
|
||
background-color: #eee;
|
||
padding: 0.5em;
|
||
margin-bottom: 0.5em;
|
||
display: none;
|
||
}
|
||
div#internal-metadata {
|
||
padding: 0.5em; /* to match the external-metadata padding */
|
||
}
|
||
/* Styling for title RFC Number */
|
||
h1#rfcnum {
|
||
clear: both;
|
||
margin: 0 0 -1em;
|
||
padding: 1em 0 0 0;
|
||
}
|
||
/* Make .olPercent look the same as <ol><li> */
|
||
dl.olPercent > dd {
|
||
margin-bottom: 0.25em;
|
||
min-height: initial;
|
||
}
|
||
/* Give aside some styling to set it apart */
|
||
aside {
|
||
border-left: 1px solid #ddd;
|
||
margin: 1em 0 1em 2em;
|
||
padding: 0.2em 2em;
|
||
}
|
||
aside > dl,
|
||
aside > ol,
|
||
aside > ul,
|
||
aside > table,
|
||
aside > p {
|
||
margin-bottom: 0.5em;
|
||
}
|
||
/* Additional page break settings */
|
||
@media print {
|
||
figcaption, table caption {
|
||
page-break-before: avoid;
|
||
}
|
||
}
|
||
/* Font size adjustments for print */
|
||
@media print {
|
||
body { font-size: 10pt; line-height: normal; max-width: 96%; }
|
||
h1 { font-size: 1.72em; padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
|
||
h2 { font-size: 1.44em; padding-top: 1.5em; } /* 1*1.2*1.2 */
|
||
h3 { font-size: 1.2em; padding-top: 1.5em; } /* 1*1.2 */
|
||
h4 { font-size: 1em; padding-top: 1.5em; }
|
||
h5, h6 { font-size: 1em; margin: initial; padding: 0.5em 0 0.3em; }
|
||
}
|
||
/* Sourcecode margin in print, when there's no pilcrow */
|
||
@media print {
|
||
.artwork,
|
||
.artwork > pre,
|
||
.sourcecode {
|
||
margin-bottom: 1em;
|
||
}
|
||
}
|
||
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
|
||
table {
|
||
min-width: 20em;
|
||
}
|
||
/* ol type a */
|
||
ol.type-a { list-style-type: lower-alpha; }
|
||
ol.type-A { list-style-type: upper-alpha; }
|
||
ol.type-i { list-style-type: lower-roman; }
|
||
ol.type-I { list-style-type: upper-roman; }
|
||
/* Apply the print table and row borders in general, on request from the RPC,
|
||
and increase the contrast between border and odd row background slightly */
|
||
table {
|
||
border: 1px solid #ddd;
|
||
}
|
||
td {
|
||
border-top: 1px solid #ddd;
|
||
}
|
||
tr {
|
||
break-inside: avoid;
|
||
}
|
||
tr:nth-child(2n+1) > td {
|
||
background-color: #f8f8f8;
|
||
}
|
||
/* Use style rules to govern display of the TOC. */
|
||
@media screen and (max-width: 1023px) {
|
||
#toc nav { display: none; }
|
||
#toc.active nav { display: block; }
|
||
}
|
||
/* Add support for keepWithNext */
|
||
.keepWithNext {
|
||
break-after: avoid-page;
|
||
break-after: avoid-page;
|
||
}
|
||
/* Add support for keepWithPrevious */
|
||
.keepWithPrevious {
|
||
break-before: avoid-page;
|
||
}
|
||
/* Change the approach to avoiding breaks inside artwork etc. */
|
||
figure, pre, table, .artwork, .sourcecode {
|
||
break-before: auto;
|
||
break-after: auto;
|
||
}
|
||
/* Avoid breaks between <dt> and <dd> */
|
||
dl {
|
||
break-before: auto;
|
||
break-inside: auto;
|
||
}
|
||
dt {
|
||
break-before: auto;
|
||
break-after: avoid-page;
|
||
}
|
||
dd {
|
||
break-before: avoid-page;
|
||
break-after: auto;
|
||
orphans: 3;
|
||
widows: 3
|
||
}
|
||
span.break, dd.break {
|
||
margin-bottom: 0;
|
||
min-height: 0;
|
||
break-before: auto;
|
||
break-inside: auto;
|
||
break-after: auto;
|
||
}
|
||
/* Undo break-before ToC */
|
||
@media print {
|
||
#toc {
|
||
break-before: auto;
|
||
}
|
||
}
|
||
/* Text in compact lists should not get extra bottom margin space,
|
||
since that would makes the list not compact */
|
||
ul.compact p, .ulCompact p,
|
||
ol.compact p, .olCompact p {
|
||
margin: 0;
|
||
}
|
||
/* But the list as a whole needs the extra space at the end */
|
||
section ul.compact,
|
||
section .ulCompact,
|
||
section ol.compact,
|
||
section .olCompact {
|
||
margin-bottom: 1em; /* same as p not within ul.compact etc. */
|
||
}
|
||
/* The tt and code background above interferes with for instance table cell
|
||
backgrounds. Changed to something a bit more selective. */
|
||
tt, code {
|
||
background-color: transparent;
|
||
}
|
||
p tt, p code, li tt, li code, dt tt, dt code {
|
||
background-color: #f8f8f8;
|
||
}
|
||
/* Tweak the pre margin -- 0px doesn't come out well */
|
||
pre {
|
||
margin-top: 0.5px;
|
||
}
|
||
/* Tweak the compact list text */
|
||
ul.compact, .ulCompact,
|
||
ol.compact, .olCompact,
|
||
dl.compact, .dlCompact {
|
||
line-height: normal;
|
||
}
|
||
/* Don't add top margin for nested lists */
|
||
li > ul, li > ol, li > dl,
|
||
dd > ul, dd > ol, dd > dl,
|
||
dl > dd > dl {
|
||
margin-top: initial;
|
||
}
|
||
/* Elements that should not be rendered on the same line as a <dt> */
|
||
/* This should match the element list in writer.text.TextWriter.render_dl() */
|
||
dd > div.artwork:first-child,
|
||
dd > aside:first-child,
|
||
dd > blockquote:first-child,
|
||
dd > figure:first-child,
|
||
dd > ol:first-child,
|
||
dd > div.sourcecode:first-child,
|
||
dd > table:first-child,
|
||
dd > ul:first-child {
|
||
clear: left;
|
||
}
|
||
/* fix for weird browser behaviour when <dd/> is empty */
|
||
dt+dd:empty::before{
|
||
content: "\00a0";
|
||
}
|
||
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
|
||
li > p {
|
||
margin-bottom: 0.5em
|
||
}
|
||
/* Don't let p margin spill out from inside list items */
|
||
li > p:last-of-type:only-child {
|
||
margin-bottom: 0;
|
||
}
|
||
</style>
|
||
<link href="rfc-local.css" rel="stylesheet" type="text/css">
|
||
<script type="application/javascript">async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(let t=0;t<e.length;t++)if(/#identifiers/.exec(e[t].selectorText)){const a=e[t].cssText.replace("#identifiers","#external-updates");document.styleSheets[0].insertRule(a,document.styleSheets[0].cssRules.length)}}catch(e){console.log(e)}const e=document.getElementById("external-metadata");if(e)try{var t,a="",o=function(e){const t=document.getElementsByTagName("meta");for(let a=0;a<t.length;a++)if(t[a].getAttribute("name")===e)return t[a].getAttribute("content");return""}("rfc.number");if(o){t="https://www.rfc-editor.org/rfc/rfc"+o+".json";try{const e=await fetch(t);a=await e.json()}catch(e){t=document.URL.indexOf("html")>=0?document.URL.replace(/html$/,"json"):document.URL+".json";const o=await fetch(t);a=await o.json()}}if(!a)return;e.style.display="block";const s="",d="https://datatracker.ietf.org/doc",n="https://datatracker.ietf.org/ipr/search",c="https://www.rfc-editor.org/info",l=a.doc_id.toLowerCase(),i=a.doc_id.slice(0,3).toLowerCase(),f=a.doc_id.slice(3).replace(/^0+/,""),u={status:"Status",obsoletes:"Obsoletes",obsoleted_by:"Obsoleted By",updates:"Updates",updated_by:"Updated By",see_also:"See Also",errata_url:"Errata"};let h="<dl style='overflow:hidden' id='external-updates'>";["status","obsoletes","obsoleted_by","updates","updated_by","see_also","errata_url"].forEach(e=>{if("status"==e){a[e]=a[e].toLowerCase();var t=a[e].split(" "),o=t.length,w="",p=1;for(let e=0;e<o;e++)p<o?w=w+r(t[e])+" ":w+=r(t[e]),p++;a[e]=w}else if("obsoletes"==e||"obsoleted_by"==e||"updates"==e||"updated_by"==e){var g,m="",b=1;g=a[e].length;for(let t=0;t<g;t++)a[e][t]&&(a[e][t]=String(a[e][t]).toLowerCase(),m=b<g?m+"<a href='"+s+"/rfc/".concat(a[e][t])+"'>"+a[e][t].slice(3)+"</a>, ":m+"<a href='"+s+"/rfc/".concat(a[e][t])+"'>"+a[e][t].slice(3)+"</a>",b++);a[e]=m}else if("see_also"==e){var y,L="",C=1;y=a[e].length;for(let t=0;t<y;t++)if(a[e][t]){a[e][t]=String(a[e][t]);var _=a[e][t].slice(0,3),v=a[e][t].slice(3).replace(/^0+/,"");L=C<y?"RFC"!=_?L+"<a href='"+s+"/info/"+_.toLowerCase().concat(v.toLowerCase())+"'>"+_+" "+v+"</a>, ":L+"<a href='"+s+"/info/"+_.toLowerCase().concat(v.toLowerCase())+"'>"+v+"</a>, ":"RFC"!=_?L+"<a href='"+s+"/info/"+_.toLowerCase().concat(v.toLowerCase())+"'>"+_+" "+v+"</a>":L+"<a href='"+s+"/info/"+_.toLowerCase().concat(v.toLowerCase())+"'>"+v+"</a>",C++}a[e]=L}else if("errata_url"==e){var R="";R=a[e]?R+"<a href='"+a[e]+"'>Errata exist</a> | <a href='"+d+"/"+l+"'>Datatracker</a>| <a href='"+n+"/?"+i+"="+f+"&submit="+i+"'>IPR</a> | <a href='"+c+"/"+l+"'>Info page</a>":"<a href='"+d+"/"+l+"'>Datatracker</a> | <a href='"+n+"/?"+i+"="+f+"&submit="+i+"'>IPR</a> | <a href='"+c+"/"+l+"'>Info page</a>",a[e]=R}""!=a[e]?"Errata"==u[e]?h+=`<dt>More info:</dt><dd>${a[e]}</dd>`:h+=`<dt>${u[e]}:</dt><dd>${a[e]}</dd>`:"Errata"==u[e]&&(h+=`<dt>More info:</dt><dd>${a[e]}</dd>`)}),h+="</dl>",e.innerHTML=h}catch(e){console.log(e)}else console.log("Could not locate metadata <div> element");function r(e){return e.charAt(0).toUpperCase()+e.slice(1)}}window.removeEventListener("load",addMetadata),window.addEventListener("load",addMetadata);</script>
|
||
</head>
|
||
<body class="xml2rfc">
|
||
<table class="ears">
|
||
<thead><tr>
|
||
<td class="left">Internet-Draft</td>
|
||
<td class="center">WIMSE Execution Context</td>
|
||
<td class="right">February 2026</td>
|
||
</tr></thead>
|
||
<tfoot><tr>
|
||
<td class="left">Nennemann</td>
|
||
<td class="center">Expires 29 August 2026</td>
|
||
<td class="right">[Page]</td>
|
||
</tr></tfoot>
|
||
</table>
|
||
<div id="external-metadata" class="document-information"></div>
|
||
<div id="internal-metadata" class="document-information">
|
||
<dl id="identifiers">
|
||
<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>
|
||
<dt class="label-published">Published:</dt>
|
||
<dd class="published">
|
||
<time datetime="2026-02-25" class="published">25 February 2026</time>
|
||
</dd>
|
||
<dt class="label-intended-status">Intended Status:</dt>
|
||
<dd class="intended-status">Standards Track</dd>
|
||
<dt class="label-expires">Expires:</dt>
|
||
<dd class="expires"><time datetime="2026-08-29">29 August 2026</time></dd>
|
||
<dt class="label-authors">Author:</dt>
|
||
<dd class="authors">
|
||
<div class="author">
|
||
<div class="author-name">C. Nennemann</div>
|
||
<div class="org">Independent Researcher</div>
|
||
</div>
|
||
</dd>
|
||
</dl>
|
||
</div>
|
||
<h1 id="title">Execution Context Tokens for Distributed Agentic Workflows</h1>
|
||
<section id="section-abstract">
|
||
<h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
|
||
<p id="section-abstract-1">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, policy evaluation outcomes, and compliance state
|
||
across
|
||
agent-to-agent communication. By extending WIMSE Workload Identity
|
||
Tokens with execution context claims in JSON Web Token (JWT)
|
||
format, this specification enables regulated systems to maintain
|
||
structured audit trails that support compliance verification.
|
||
ECTs use a directed acyclic graph (DAG) structure to represent task
|
||
dependencies, record policy evaluation outcomes at each decision
|
||
point, and integrate with WIMSE Workload Identity Tokens (WIT)
|
||
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.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
<div id="status-of-memo">
|
||
<section id="section-boilerplate.1">
|
||
<h2 id="name-status-of-this-memo">
|
||
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
|
||
</h2>
|
||
<p id="section-boilerplate.1-1">
|
||
This Internet-Draft is submitted in full conformance with the
|
||
provisions of BCP 78 and BCP 79.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
|
||
<p id="section-boilerplate.1-2">
|
||
Internet-Drafts are working documents of the Internet Engineering Task
|
||
Force (IETF). Note that other groups may also distribute working
|
||
documents as Internet-Drafts. The list of current Internet-Drafts is
|
||
at <span><a href="https://datatracker.ietf.org/drafts/current/">https://datatracker.ietf.org/drafts/current/</a></span>.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
|
||
<p id="section-boilerplate.1-3">
|
||
Internet-Drafts are draft documents valid for a maximum of six months
|
||
and may be updated, replaced, or obsoleted by other documents at any
|
||
time. It is inappropriate to use Internet-Drafts as reference
|
||
material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
|
||
<p id="section-boilerplate.1-4">
|
||
This Internet-Draft will expire on 29 August 2026.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="copyright">
|
||
<section id="section-boilerplate.2">
|
||
<h2 id="name-copyright-notice">
|
||
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
|
||
</h2>
|
||
<p id="section-boilerplate.2-1">
|
||
Copyright (c) 2026 IETF Trust and the persons identified as the
|
||
document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
|
||
<p id="section-boilerplate.2-2">
|
||
This document is subject to BCP 78 and the IETF Trust's Legal
|
||
Provisions Relating to IETF Documents
|
||
(<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
|
||
publication of this document. Please review these documents
|
||
carefully, as they describe your rights and restrictions with
|
||
respect to this document. Code Components extracted from this
|
||
document must include Revised BSD License text as described in
|
||
Section 4.e of the Trust Legal Provisions and are provided without
|
||
warranty as described in the Revised BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="toc">
|
||
<section id="section-toc.1">
|
||
<a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
|
||
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
|
||
</h2>
|
||
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
|
||
<p id="section-toc.1-1.1.1"><a href="#section-1" class="auto internal xref">1</a>. <a href="#name-introduction" class="internal xref">Introduction</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1">
|
||
<p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="auto internal xref">1.1</a>. <a href="#name-motivation" class="internal xref">Motivation</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.2">
|
||
<p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="auto internal xref">1.2</a>. <a href="#name-problem-statement" class="internal xref">Problem Statement</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.3">
|
||
<p id="section-toc.1-1.1.2.3.1" class="keepWithNext"><a href="#section-1.3" class="auto internal xref">1.3</a>. <a href="#name-scope-and-applicability" class="internal xref">Scope and Applicability</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.4">
|
||
<p id="section-toc.1-1.1.2.4.1"><a href="#section-1.4" class="auto internal xref">1.4</a>. <a href="#name-relationship-to-regulatory-" class="internal xref">Relationship to Regulatory Compliance</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
|
||
<p id="section-toc.1-1.2.1"><a href="#section-2" class="auto internal xref">2</a>. <a href="#name-conventions-and-definitions" class="internal xref">Conventions and Definitions</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
|
||
<p id="section-toc.1-1.3.1"><a href="#section-3" class="auto internal xref">3</a>. <a href="#name-wimse-architecture-integrat" class="internal xref">WIMSE Architecture Integration</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
|
||
<p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="auto internal xref">3.1</a>. <a href="#name-wimse-foundation" class="internal xref">WIMSE Foundation</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
|
||
<p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="auto internal xref">3.2</a>. <a href="#name-extension-model" class="internal xref">Extension Model</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
|
||
<p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="auto internal xref">3.3</a>. <a href="#name-integration-points" class="internal xref">Integration Points</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
|
||
<p id="section-toc.1-1.4.1"><a href="#section-4" class="auto internal xref">4</a>. <a href="#name-execution-context-token-for" class="internal xref">Execution Context Token Format</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1">
|
||
<p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="auto internal xref">4.1</a>. <a href="#name-jose-header" class="internal xref">JOSE Header</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2">
|
||
<p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="auto internal xref">4.2</a>. <a href="#name-jwt-claims" class="internal xref">JWT Claims</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.1">
|
||
<p id="section-toc.1-1.4.2.2.2.1.1"><a href="#section-4.2.1" class="auto internal xref">4.2.1</a>. <a href="#name-standard-jwt-claims" class="internal xref">Standard JWT Claims</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.2">
|
||
<p id="section-toc.1-1.4.2.2.2.2.1"><a href="#section-4.2.2" class="auto internal xref">4.2.2</a>. <a href="#name-execution-context" class="internal xref">Execution Context</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.3">
|
||
<p id="section-toc.1-1.4.2.2.2.3.1"><a href="#section-4.2.3" class="auto internal xref">4.2.3</a>. <a href="#name-policy-evaluation-extension" class="internal xref">Policy Evaluation Extension Keys</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.4">
|
||
<p id="section-toc.1-1.4.2.2.2.4.1"><a href="#section-4.2.4" class="auto internal xref">4.2.4</a>. <a href="#name-data-integrity" class="internal xref">Data Integrity</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.5">
|
||
<p id="section-toc.1-1.4.2.2.2.5.1"><a href="#section-4.2.5" class="auto internal xref">4.2.5</a>. <a href="#name-compensation-and-rollback" class="internal xref">Compensation and Rollback</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.6">
|
||
<p id="section-toc.1-1.4.2.2.2.6.1"><a href="#section-4.2.6" class="auto internal xref">4.2.6</a>. <a href="#name-extensions" class="internal xref">Extensions</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3">
|
||
<p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="auto internal xref">4.3</a>. <a href="#name-complete-ect-example" class="internal xref">Complete ECT Example</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
|
||
<p id="section-toc.1-1.5.1"><a href="#section-5" class="auto internal xref">5</a>. <a href="#name-http-header-transport" class="internal xref">HTTP Header Transport</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.1">
|
||
<p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="auto internal xref">5.1</a>. <a href="#name-execution-context-header-fi" class="internal xref">Execution-Context Header Field</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
|
||
<p id="section-toc.1-1.6.1"><a href="#section-6" class="auto internal xref">6</a>. <a href="#name-dag-validation" class="internal xref">DAG Validation</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
|
||
<p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="auto internal xref">6.1</a>. <a href="#name-overview" class="internal xref">Overview</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
|
||
<p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="auto internal xref">6.2</a>. <a href="#name-validation-rules" class="internal xref">Validation Rules</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3">
|
||
<p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="auto internal xref">6.3</a>. <a href="#name-dag-validation-algorithm" class="internal xref">DAG Validation Algorithm</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
|
||
<p id="section-toc.1-1.7.1"><a href="#section-7" class="auto internal xref">7</a>. <a href="#name-signature-and-token-verific" class="internal xref">Signature and Token Verification</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
|
||
<p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="auto internal xref">7.1</a>. <a href="#name-verification-procedure" class="internal xref">Verification Procedure</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
|
||
<p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="auto internal xref">7.2</a>. <a href="#name-verification-pseudocode" class="internal xref">Verification Pseudocode</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
|
||
<p id="section-toc.1-1.8.1"><a href="#section-8" class="auto internal xref">8</a>. <a href="#name-audit-ledger-interface" class="internal xref">Audit Ledger Interface</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
|
||
<p id="section-toc.1-1.9.1"><a href="#section-9" class="auto internal xref">9</a>. <a href="#name-use-cases" class="internal xref">Use Cases</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.1">
|
||
<p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="auto internal xref">9.1</a>. <a href="#name-medical-device-sdlc-workflo" class="internal xref">Medical Device SDLC Workflow</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.1.2.1">
|
||
<p id="section-toc.1-1.9.2.1.2.1.1"><a href="#section-9.1.1" class="auto internal xref">9.1.1</a>. <a href="#name-fda-audit-with-dag-reconstr" class="internal xref">FDA Audit with DAG Reconstruction</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.2">
|
||
<p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="auto internal xref">9.2</a>. <a href="#name-financial-trading-workflow" class="internal xref">Financial Trading Workflow</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.3">
|
||
<p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3" class="auto internal xref">9.3</a>. <a href="#name-compensation-and-rollback-2" class="internal xref">Compensation and Rollback</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.4">
|
||
<p id="section-toc.1-1.9.2.4.1"><a href="#section-9.4" class="auto internal xref">9.4</a>. <a href="#name-autonomous-logistics-coordi" class="internal xref">Autonomous Logistics Coordination</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
|
||
<p id="section-toc.1-1.10.1"><a href="#section-10" class="auto internal xref">10</a>. <a href="#name-security-considerations" class="internal xref">Security Considerations</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1">
|
||
<p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="auto internal xref">10.1</a>. <a href="#name-threat-model" class="internal xref">Threat Model</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2">
|
||
<p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="auto internal xref">10.2</a>. <a href="#name-self-assertion-limitation" class="internal xref">Self-Assertion Limitation</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.3">
|
||
<p id="section-toc.1-1.10.2.3.1"><a href="#section-10.3" class="auto internal xref">10.3</a>. <a href="#name-organizational-prerequisite" class="internal xref">Organizational Prerequisites</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.4">
|
||
<p id="section-toc.1-1.10.2.4.1"><a href="#section-10.4" class="auto internal xref">10.4</a>. <a href="#name-signature-verification" class="internal xref">Signature Verification</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.5">
|
||
<p id="section-toc.1-1.10.2.5.1"><a href="#section-10.5" class="auto internal xref">10.5</a>. <a href="#name-replay-attack-prevention" class="internal xref">Replay Attack Prevention</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.6">
|
||
<p id="section-toc.1-1.10.2.6.1"><a href="#section-10.6" class="auto internal xref">10.6</a>. <a href="#name-man-in-the-middle-protectio" class="internal xref">Man-in-the-Middle Protection</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.7">
|
||
<p id="section-toc.1-1.10.2.7.1"><a href="#section-10.7" class="auto internal xref">10.7</a>. <a href="#name-key-compromise" class="internal xref">Key Compromise</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.8">
|
||
<p id="section-toc.1-1.10.2.8.1"><a href="#section-10.8" class="auto internal xref">10.8</a>. <a href="#name-collusion-and-false-claims" class="internal xref">Collusion and False Claims</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.9">
|
||
<p id="section-toc.1-1.10.2.9.1"><a href="#section-10.9" class="auto internal xref">10.9</a>. <a href="#name-denial-of-service" class="internal xref">Denial of Service</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.10">
|
||
<p id="section-toc.1-1.10.2.10.1"><a href="#section-10.10" class="auto internal xref">10.10</a>. <a href="#name-timestamp-accuracy" class="internal xref">Timestamp Accuracy</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.11">
|
||
<p id="section-toc.1-1.10.2.11.1"><a href="#section-10.11" class="auto internal xref">10.11</a>. <a href="#name-ect-size-constraints" class="internal xref">ECT Size Constraints</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
|
||
<p id="section-toc.1-1.11.1"><a href="#section-11" class="auto internal xref">11</a>. <a href="#name-privacy-considerations" class="internal xref">Privacy Considerations</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.1">
|
||
<p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="auto internal xref">11.1</a>. <a href="#name-data-exposure-in-ects" class="internal xref">Data Exposure in ECTs</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.2">
|
||
<p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="auto internal xref">11.2</a>. <a href="#name-data-minimization" class="internal xref">Data Minimization</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.3">
|
||
<p id="section-toc.1-1.11.2.3.1"><a href="#section-11.3" class="auto internal xref">11.3</a>. <a href="#name-storage-and-access-control" class="internal xref">Storage and Access Control</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.4">
|
||
<p id="section-toc.1-1.11.2.4.1"><a href="#section-11.4" class="auto internal xref">11.4</a>. <a href="#name-regulatory-access" class="internal xref">Regulatory Access</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
|
||
<p id="section-toc.1-1.12.1"><a href="#section-12" class="auto internal xref">12</a>. <a href="#name-iana-considerations" class="internal xref">IANA Considerations</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.1">
|
||
<p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="auto internal xref">12.1</a>. <a href="#name-media-type-registration" class="internal xref">Media Type Registration</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.2">
|
||
<p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="auto internal xref">12.2</a>. <a href="#name-http-header-field-registrat" class="internal xref">HTTP Header Field Registration</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.3">
|
||
<p id="section-toc.1-1.12.2.3.1"><a href="#section-12.3" class="auto internal xref">12.3</a>. <a href="#name-jwt-claims-registration" class="internal xref">JWT Claims Registration</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.4">
|
||
<p id="section-toc.1-1.12.2.4.1"><a href="#section-12.4" class="auto internal xref">12.4</a>. <a href="#name-ect-policy-decision-values-" class="internal xref">ECT Policy Decision Values Registry</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
|
||
<p id="section-toc.1-1.13.1"><a href="#section-13" class="auto internal xref">13</a>. <a href="#name-references" class="internal xref">References</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.1">
|
||
<p id="section-toc.1-1.13.2.1.1"><a href="#section-13.1" class="auto internal xref">13.1</a>. <a href="#name-normative-references" class="internal xref">Normative References</a></p>
|
||
</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="#section-13.2" class="auto internal xref">13.2</a>. <a href="#name-informative-references" class="internal xref">Informative References</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14">
|
||
<p id="section-toc.1-1.14.1"><a href="#appendix-A" class="auto internal xref"></a><a href="#name-related-work" class="internal xref">Related Work</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14.2.1">
|
||
<p id="section-toc.1-1.14.2.1.1"><a href="#appendix-A.1" class="auto internal xref"></a><a href="#name-wimse-workload-identity" class="internal xref">WIMSE Workload Identity</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14.2.2">
|
||
<p id="section-toc.1-1.14.2.2.1"><a href="#appendix-A.2" class="auto internal xref"></a><a href="#name-oauth-20-token-exchange-and" class="internal xref">OAuth 2.0 Token Exchange and the "act" Claim</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14.2.3">
|
||
<p id="section-toc.1-1.14.2.3.1"><a href="#appendix-A.3" class="auto internal xref"></a><a href="#name-transaction-tokens" class="internal xref">Transaction Tokens</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14.2.4">
|
||
<p id="section-toc.1-1.14.2.4.1"><a href="#appendix-A.4" class="auto internal xref"></a><a href="#name-distributed-tracing-opentel" class="internal xref">Distributed Tracing (OpenTelemetry)</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14.2.5">
|
||
<p id="section-toc.1-1.14.2.5.1"><a href="#appendix-A.5" class="auto internal xref"></a><a href="#name-blockchain-and-distributed-" class="internal xref">Blockchain and Distributed Ledgers</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14.2.6">
|
||
<p id="section-toc.1-1.14.2.6.1"><a href="#appendix-A.6" class="auto internal xref"></a><a href="#name-scitt-supply-chain-integrit" class="internal xref">SCITT (Supply Chain Integrity, Transparency, and Trust)</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14.2.7">
|
||
<p id="section-toc.1-1.14.2.7.1"><a href="#appendix-A.7" class="auto internal xref"></a><a href="#name-w3c-verifiable-credentials" class="internal xref">W3C Verifiable Credentials</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15">
|
||
<p id="section-toc.1-1.15.1"><a href="#appendix-B" class="auto internal xref"></a><a href="#name-implementation-guidance" class="internal xref">Implementation Guidance</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15.2.1">
|
||
<p id="section-toc.1-1.15.2.1.1"><a href="#appendix-B.1" class="auto internal xref"></a><a href="#name-minimal-implementation" class="internal xref">Minimal Implementation</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15.2.2">
|
||
<p id="section-toc.1-1.15.2.2.1"><a href="#appendix-B.2" class="auto internal xref"></a><a href="#name-storage-recommendations" class="internal xref">Storage Recommendations</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15.2.3">
|
||
<p id="section-toc.1-1.15.2.3.1"><a href="#appendix-B.3" class="auto internal xref"></a><a href="#name-performance-considerations" class="internal xref">Performance Considerations</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15.2.4">
|
||
<p id="section-toc.1-1.15.2.4.1"><a href="#appendix-B.4" class="auto internal xref"></a><a href="#name-interoperability" class="internal xref">Interoperability</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16">
|
||
<p id="section-toc.1-1.16.1"><a href="#appendix-C" class="auto internal xref"></a><a href="#name-regulatory-compliance-mappi" class="internal xref">Regulatory Compliance Mapping</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17">
|
||
<p id="section-toc.1-1.17.1"><a href="#appendix-D" class="auto internal xref"></a><a href="#name-examples" class="internal xref">Examples</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17.2.1">
|
||
<p id="section-toc.1-1.17.2.1.1"><a href="#appendix-D.1" class="auto internal xref"></a><a href="#name-example-1-simple-two-agent-" class="internal xref">Example 1: Simple Two-Agent Workflow</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17.2.2">
|
||
<p id="section-toc.1-1.17.2.2.1"><a href="#appendix-D.2" class="auto internal xref"></a><a href="#name-example-2-medical-device-sd" class="internal xref">Example 2: Medical Device SDLC with Release Approval</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17.2.3">
|
||
<p id="section-toc.1-1.17.2.3.1"><a href="#appendix-D.3" class="auto internal xref"></a><a href="#name-example-3-parallel-executio" class="internal xref">Example 3: Parallel Execution with Join</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.18">
|
||
<p id="section-toc.1-1.18.1"><a href="#appendix-E" class="auto internal xref"></a><a href="#name-acknowledgments" class="internal xref">Acknowledgments</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.19">
|
||
<p id="section-toc.1-1.19.1"><a href="#appendix-F" class="auto internal xref"></a><a href="#name-authors-address" class="internal xref">Author's Address</a></p>
|
||
</li>
|
||
</ul>
|
||
</nav>
|
||
</section>
|
||
</div>
|
||
<div id="introduction">
|
||
<section id="section-1">
|
||
<h2 id="name-introduction">
|
||
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
|
||
</h2>
|
||
<div id="motivation">
|
||
<section id="section-1.1">
|
||
<h3 id="name-motivation">
|
||
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-motivation" class="section-name selfRef">Motivation</a>
|
||
</h3>
|
||
<p id="section-1.1-1">The Workload Identity in Multi System Environments (WIMSE)
|
||
framework <span>[<a href="#I-D.ietf-wimse-arch" class="cite xref">I-D.ietf-wimse-arch</a>]</span> provides robust workload
|
||
authentication through Workload Identity Tokens (WIT) and Workload
|
||
Proof Tokens (WPT). The WIMSE service-to-service protocol
|
||
<span>[<a href="#I-D.ietf-wimse-s2s-protocol" class="cite xref">I-D.ietf-wimse-s2s-protocol</a>]</span> defines how workloads authenticate
|
||
each other across call chains using the Workload-Identity and
|
||
Workload-Proof-Token HTTP headers.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
|
||
<p id="section-1.1-2">However, workload identity alone does not address execution
|
||
accountability. Knowing who performed an action does not record
|
||
what was done, what policy was applied, or whether compliance
|
||
requirements were evaluated at each decision point.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
|
||
<p id="section-1.1-3">Regulated environments increasingly deploy autonomous agents that
|
||
coordinate across organizational boundaries. Multiple regulatory
|
||
frameworks — including <span>[<a href="#EU-AI-ACT" class="cite xref">EU-AI-ACT</a>]</span>, <span>[<a href="#FDA-21CFR11" class="cite xref">FDA-21CFR11</a>]</span>, <span>[<a href="#MIFID-II" class="cite xref">MIFID-II</a>]</span>,
|
||
and <span>[<a href="#DORA" class="cite xref">DORA</a>]</span> — require structured, auditable records of automated
|
||
decision-making and execution (see <a href="#_table-regulatory" class="auto internal xref">Table 3</a> for a
|
||
detailed mapping).<a href="#section-1.1-3" class="pilcrow">¶</a></p>
|
||
<p id="section-1.1-4">This document defines an extension to the WIMSE architecture that
|
||
addresses the gap between workload identity and execution
|
||
accountability. WIMSE authenticates agents; this extension records
|
||
what they did, in what order, and what policy was evaluated.<a href="#section-1.1-4" class="pilcrow">¶</a></p>
|
||
<p id="section-1.1-5">As identified in <span>[<a href="#I-D.ni-wimse-ai-agent-identity" class="cite xref">I-D.ni-wimse-ai-agent-identity</a>]</span>, call context
|
||
in agentic workflows needs to be visible and preserved. ECTs
|
||
provide a mechanism to address this requirement with cryptographic
|
||
assurances.<a href="#section-1.1-5" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="problem-statement">
|
||
<section id="section-1.2">
|
||
<h3 id="name-problem-statement">
|
||
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-problem-statement" class="section-name selfRef">Problem Statement</a>
|
||
</h3>
|
||
<p id="section-1.2-1">Three core gaps exist in current approaches to regulated agentic
|
||
systems:<a href="#section-1.2-1" class="pilcrow">¶</a></p>
|
||
<ol start="1" type="1" class="normal type-1" id="section-1.2-2">
|
||
<li id="section-1.2-2.1">
|
||
<p id="section-1.2-2.1.1">WIMSE authenticates agents but does not record what they
|
||
actually did. A WIT proves "Agent A is authorized" but not
|
||
"Agent A executed Task X, under Policy Y, producing Output Z."<a href="#section-1.2-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-1.2-2.2">
|
||
<p id="section-1.2-2.2.1">No standard mechanism exists to record policy evaluation
|
||
outcomes at each decision point in a multi-agent workflow.<a href="#section-1.2-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-1.2-2.3">
|
||
<p id="section-1.2-2.3.1">No mechanism exists to cryptographically link compensation and
|
||
rollback decisions to original actions.<a href="#section-1.2-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ol>
|
||
<p id="section-1.2-3">Existing observability tools such as distributed tracing
|
||
<span>[<a href="#OPENTELEMETRY" class="cite xref">OPENTELEMETRY</a>]</span> provide visibility for debugging and monitoring
|
||
but do not provide cryptographic assurances. Tracing data is not
|
||
cryptographically signed, not tamper-evident, and not designed for
|
||
regulatory audit scenarios.<a href="#section-1.2-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="scope-and-applicability">
|
||
<section id="section-1.3">
|
||
<h3 id="name-scope-and-applicability">
|
||
<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-scope-and-applicability" class="section-name selfRef">Scope and Applicability</a>
|
||
</h3>
|
||
<p id="section-1.3-1">This document defines:<a href="#section-1.3-1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-1.3-2.1">
|
||
<p id="section-1.3-2.1.1">The Execution Context Token (ECT) format (<a href="#ect-format" class="auto internal xref">Section 4</a>)<a href="#section-1.3-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.3-2.2">
|
||
<p id="section-1.3-2.2.1">DAG structure for task dependency ordering (<a href="#dag-validation" class="auto internal xref">Section 6</a>)<a href="#section-1.3-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.3-2.3">
|
||
<p id="section-1.3-2.3.1">Policy checkpoint recording via extension keys (<a href="#policy-claims" class="auto internal xref">Section 4.2.3</a>)<a href="#section-1.3-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.3-2.4">
|
||
<p id="section-1.3-2.4.1">Integration with the WIMSE identity framework
|
||
(<a href="#wimse-integration" class="auto internal xref">Section 3</a>)<a href="#section-1.3-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.3-2.5">
|
||
<p id="section-1.3-2.5.1">An HTTP header for ECT transport (<a href="#http-header" class="auto internal xref">Section 5</a>)<a href="#section-1.3-2.5.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.3-2.6">
|
||
<p id="section-1.3-2.6.1">Audit ledger interface requirements (<a href="#ledger-interface" class="auto internal xref">Section 8</a>)<a href="#section-1.3-2.6.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-1.3-3">The following are out of scope and are handled by WIMSE:<a href="#section-1.3-3" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-1.3-4.1">
|
||
<p id="section-1.3-4.1.1">Workload authentication and identity provisioning<a href="#section-1.3-4.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.3-4.2">
|
||
<p id="section-1.3-4.2.1">Key distribution and management<a href="#section-1.3-4.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.3-4.3">
|
||
<p id="section-1.3-4.3.1">Trust domain establishment and management<a href="#section-1.3-4.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.3-4.4">
|
||
<p id="section-1.3-4.4.1">Credential lifecycle management<a href="#section-1.3-4.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="relationship-to-regulatory-compliance">
|
||
<section id="section-1.4">
|
||
<h3 id="name-relationship-to-regulatory-">
|
||
<a href="#section-1.4" class="section-number selfRef">1.4. </a><a href="#name-relationship-to-regulatory-" class="section-name selfRef">Relationship to Regulatory Compliance</a>
|
||
</h3>
|
||
<p id="section-1.4-1">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.<a href="#section-1.4-1" class="pilcrow">¶</a></p>
|
||
<p id="section-1.4-2">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.<a href="#section-1.4-2" class="pilcrow">¶</a></p>
|
||
<p id="section-1.4-3">ECTs provide evidence of claimed execution ordering and policy
|
||
evaluation. They do not independently verify that the claimed
|
||
execution actually occurred as described, that the policy
|
||
evaluation was correct, or that the agent faithfully performed the
|
||
stated action. The trustworthiness of ECT claims depends on the
|
||
trustworthiness of the signing agent and the integrity of the
|
||
broader deployment environment.<a href="#section-1.4-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="conventions-and-definitions">
|
||
<section id="section-2">
|
||
<h2 id="name-conventions-and-definitions">
|
||
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-conventions-and-definitions" class="section-name selfRef">Conventions and Definitions</a>
|
||
</h2>
|
||
<p id="section-2-1">The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
|
||
"<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
|
||
described in BCP 14 <span>[<a href="#RFC2119" class="cite xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="cite xref">RFC8174</a>]</span> when, and only when, they
|
||
appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
|
||
<p id="section-2-2">The following terms are used in this document:<a href="#section-2-2" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-2-3">
|
||
<dt id="section-2-3.1">Agent:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-2-3.2">
|
||
<p id="section-2-3.2.1">An autonomous workload, as defined by WIMSE
|
||
<span>[<a href="#I-D.ietf-wimse-arch" class="cite xref">I-D.ietf-wimse-arch</a>]</span>, that executes tasks within a workflow.<a href="#section-2-3.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-2-3.3">Task:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-2-3.4">
|
||
<p id="section-2-3.4.1">A discrete unit of agent work that consumes inputs and produces
|
||
outputs.<a href="#section-2-3.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-2-3.5">Directed Acyclic Graph (DAG):</dt>
|
||
<dd style="margin-left: 1.5em" id="section-2-3.6">
|
||
<p id="section-2-3.6.1">A graph structure representing task dependency ordering where
|
||
edges are directed and no cycles exist.<a href="#section-2-3.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-2-3.7">Execution Context Token (ECT):</dt>
|
||
<dd style="margin-left: 1.5em" id="section-2-3.8">
|
||
<p id="section-2-3.8.1">A JSON Web Token <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span> defined by this specification that
|
||
records task execution details and policy evaluation outcomes.<a href="#section-2-3.8.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-2-3.9">Audit Ledger:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-2-3.10">
|
||
<p id="section-2-3.10.1">An append-only, immutable log of all ECTs within a workflow or
|
||
set of workflows, used for regulatory audit and compliance
|
||
verification.<a href="#section-2-3.10.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-2-3.11">Policy Checkpoint:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-2-3.12">
|
||
<p id="section-2-3.12.1">A point in a workflow where a policy evaluation outcome is
|
||
recorded within an ECT.<a href="#section-2-3.12.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-2-3.13">Workload Identity Token (WIT):</dt>
|
||
<dd style="margin-left: 1.5em" id="section-2-3.14">
|
||
<p id="section-2-3.14.1">A WIMSE credential proving a workload's identity within a trust
|
||
domain.<a href="#section-2-3.14.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-2-3.15">Workload Proof Token (WPT):</dt>
|
||
<dd style="margin-left: 1.5em" id="section-2-3.16">
|
||
<p id="section-2-3.16.1">A WIMSE proof-of-possession token used for request-level
|
||
authentication.<a href="#section-2-3.16.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-2-3.17">Trust Domain:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-2-3.18">
|
||
<p id="section-2-3.18.1">A WIMSE concept representing an organizational boundary with a
|
||
shared identity issuer, corresponding to a SPIFFE <span>[<a href="#SPIFFE" class="cite xref">SPIFFE</a>]</span>
|
||
trust domain.<a href="#section-2-3.18.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-2-3.19">Witness:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-2-3.20">
|
||
<p id="section-2-3.20.1">A third-party entity that observes and attests to the execution
|
||
of a task, providing additional accountability.<a href="#section-2-3.20.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="wimse-integration">
|
||
<section id="section-3">
|
||
<h2 id="name-wimse-architecture-integrat">
|
||
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-wimse-architecture-integrat" class="section-name selfRef">WIMSE Architecture Integration</a>
|
||
</h2>
|
||
<div id="wimse-foundation">
|
||
<section id="section-3.1">
|
||
<h3 id="name-wimse-foundation">
|
||
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-wimse-foundation" class="section-name selfRef">WIMSE Foundation</a>
|
||
</h3>
|
||
<p id="section-3.1-1">The WIMSE architecture <span>[<a href="#I-D.ietf-wimse-arch" class="cite xref">I-D.ietf-wimse-arch</a>]</span> defines:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-3.1-2.1">
|
||
<p id="section-3.1-2.1.1">Workload Identity Tokens (WIT) that prove a workload's identity
|
||
within a trust domain ("I am Agent X in trust domain Y")<a href="#section-3.1-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-3.1-2.2">
|
||
<p id="section-3.1-2.2.1">Workload Proof Tokens (WPT) that prove possession of the private
|
||
key associated with a WIT ("I control the key for Agent X")<a href="#section-3.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-3.1-2.3">
|
||
<p id="section-3.1-2.3.1">Multi-hop authentication via the service-to-service protocol
|
||
<span>[<a href="#I-D.ietf-wimse-s2s-protocol" class="cite xref">I-D.ietf-wimse-s2s-protocol</a>]</span><a href="#section-3.1-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-3.1-3">The following execution accountability needs are complementary to
|
||
the WIMSE scope and are not addressed by workload identity alone:<a href="#section-3.1-3" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-3.1-4.1">
|
||
<p id="section-3.1-4.1.1">Recording what agents actually do with their authenticated
|
||
identity<a href="#section-3.1-4.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-3.1-4.2">
|
||
<p id="section-3.1-4.2.1">Recording policy evaluation outcomes at each hop<a href="#section-3.1-4.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-3.1-4.3">
|
||
<p id="section-3.1-4.3.1">Maintaining structured execution records<a href="#section-3.1-4.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-3.1-4.4">
|
||
<p id="section-3.1-4.4.1">Linking compensation or rollback actions to original tasks<a href="#section-3.1-4.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="extension-model">
|
||
<section id="section-3.2">
|
||
<h3 id="name-extension-model">
|
||
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-extension-model" class="section-name selfRef">Extension Model</a>
|
||
</h3>
|
||
<p id="section-3.2-1">ECTs extend WIMSE by adding an execution accountability layer
|
||
between the identity layer and the application layer:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
|
||
<span id="name-wimse-extension-architectur"></span><div id="fig-layers">
|
||
<figure id="figure-1">
|
||
<div class="alignLeft art-ascii-art art-text artwork" id="section-3.2-2.1">
|
||
<pre>
|
||
+--------------------------------------------------+
|
||
| WIMSE Layer (Identity) |
|
||
| WIT: "I am Agent X (spiffe://td/agent/x)" |
|
||
| WPT: "I prove I control the key for Agent X" |
|
||
+--------------------------------------------------+
|
||
|
|
||
v
|
||
+--------------------------------------------------+
|
||
| ECT Layer (Execution Accountability) [This Spec]|
|
||
| ECT: "Task executed, dependencies met, |
|
||
| policy evaluated, outcome recorded" |
|
||
+--------------------------------------------------+
|
||
|
|
||
v
|
||
+--------------------------------------------------+
|
||
| Optional: Audit Ledger (Immutable Record) |
|
||
| "ECTs MAY be appended to an audit ledger" |
|
||
+--------------------------------------------------+
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
|
||
<a href="#name-wimse-extension-architectur" class="selfRef">WIMSE Extension Architecture Layers</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
<p id="section-3.2-3">This extension reuses the WIMSE signing model, extends JWT claims
|
||
using standard JWT extensibility <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>, and maintains WIMSE
|
||
concepts including trust domains and workload identifiers.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="integration-points">
|
||
<section id="section-3.3">
|
||
<h3 id="name-integration-points">
|
||
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-integration-points" class="section-name selfRef">Integration Points</a>
|
||
</h3>
|
||
<p id="section-3.3-1">An ECT integrates with the WIMSE identity framework through the
|
||
following mechanisms:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-3.3-2.1">
|
||
<p id="section-3.3-2.1.1">The ECT JOSE header "kid" parameter <span class="bcp14">MUST</span> reference the public
|
||
key identifier from the agent's WIT.<a href="#section-3.3-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-3.3-2.2">
|
||
<p id="section-3.3-2.2.1">In WIMSE deployments, the ECT "iss" claim <span class="bcp14">SHOULD</span> use the WIMSE
|
||
workload identifier format (a SPIFFE ID <span>[<a href="#SPIFFE" class="cite xref">SPIFFE</a>]</span>).<a href="#section-3.3-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-3.3-2.3">
|
||
<p id="section-3.3-2.3.1">The ECT <span class="bcp14">MUST</span> be signed with the same private key associated
|
||
with the agent's WIT.<a href="#section-3.3-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-3.3-2.4">
|
||
<p id="section-3.3-2.4.1">The ECT signing algorithm (JOSE header "alg" parameter) <span class="bcp14">MUST</span>
|
||
match the algorithm used in the corresponding WIT.<a href="#section-3.3-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-3.3-3">When an agent makes an HTTP request to another agent, the
|
||
Execution-Context header is carried alongside WIMSE identity
|
||
headers:<a href="#section-3.3-3" class="pilcrow">¶</a></p>
|
||
<span id="name-http-header-stacking"></span><div id="fig-http-headers">
|
||
<figure id="figure-2">
|
||
<div class="alignLeft art-ascii-art art-text artwork" id="section-3.3-4.1">
|
||
<pre>
|
||
HTTP Request from Agent A to Agent B:
|
||
Workload-Identity: <WIT for Agent A>
|
||
Execution-Context: <ECT recording what A did>
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
|
||
<a href="#name-http-header-stacking" class="selfRef">HTTP Header Stacking</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
<p id="section-3.3-5">When a Workload Proof Token (WPT) is available per
|
||
<span>[<a href="#I-D.ietf-wimse-s2s-protocol" class="cite xref">I-D.ietf-wimse-s2s-protocol</a>]</span>, agents <span class="bcp14">SHOULD</span> include it
|
||
alongside the WIT and ECT. ECT verification does not depend
|
||
on the presence of a WPT; the ECT is independently verifiable
|
||
via the WIT public key.<a href="#section-3.3-5" class="pilcrow">¶</a></p>
|
||
<p id="section-3.3-6">The receiving agent (Agent B) verifies in order:<a href="#section-3.3-6" class="pilcrow">¶</a></p>
|
||
<ol start="1" type="1" class="normal type-1" id="section-3.3-7">
|
||
<li id="section-3.3-7.1">
|
||
<p id="section-3.3-7.1.1">WIT (WIMSE layer): Verifies Agent A's identity within the
|
||
trust domain. WPT verification, if present, per
|
||
<span>[<a href="#I-D.ietf-wimse-s2s-protocol" class="cite xref">I-D.ietf-wimse-s2s-protocol</a>]</span>.<a href="#section-3.3-7.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-3.3-7.2">
|
||
<p id="section-3.3-7.2.1">ECT (this extension): Records what Agent A did, what policy was
|
||
evaluated, and what precedent tasks exist.<a href="#section-3.3-7.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-3.3-7.3">
|
||
<p id="section-3.3-7.3.1">Ledger (if deployed): Appends the verified ECT to the audit
|
||
ledger.<a href="#section-3.3-7.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ol>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="ect-format">
|
||
<section id="section-4">
|
||
<h2 id="name-execution-context-token-for">
|
||
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-execution-context-token-for" class="section-name selfRef">Execution Context Token Format</a>
|
||
</h2>
|
||
<p id="section-4-1">An Execution Context Token is a JSON Web Token (JWT) <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>
|
||
signed as a JSON Web Signature (JWS) <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span> using the Compact
|
||
Serialization. JWS JSON Serialization <span class="bcp14">MUST NOT</span> be used for ECTs.<a href="#section-4-1" class="pilcrow">¶</a></p>
|
||
<div id="jose-header">
|
||
<section id="section-4.1">
|
||
<h3 id="name-jose-header">
|
||
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-jose-header" class="section-name selfRef">JOSE Header</a>
|
||
</h3>
|
||
<p id="section-4.1-1">The ECT JOSE header <span class="bcp14">MUST</span> contain the following parameters:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
|
||
<span id="name-ect-jose-header-example"></span><div id="fig-header">
|
||
<figure id="figure-3">
|
||
<div class="lang-json sourcecode" id="section-4.1-2.1">
|
||
<pre>
|
||
{
|
||
"alg": "ES256",
|
||
"typ": "wimse-exec+jwt",
|
||
"kid": "agent-a-key-id-123"
|
||
}
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
|
||
<a href="#name-ect-jose-header-example" class="selfRef">ECT JOSE Header Example</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
<span class="break"></span><dl class="dlParallel" id="section-4.1-3">
|
||
<dt id="section-4.1-3.1">alg:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.1-3.2">
|
||
<p id="section-4.1-3.2.1"><span class="bcp14">REQUIRED</span>. The digital signature algorithm used to sign the ECT.
|
||
<span class="bcp14">MUST</span> match the algorithm in the corresponding WIT.
|
||
Implementations <span class="bcp14">MUST</span> support ES256 <span>[<a href="#RFC7518" class="cite xref">RFC7518</a>]</span>. The "alg"
|
||
value <span class="bcp14">MUST NOT</span> be "none". Symmetric algorithms (e.g., HS256,
|
||
HS384, HS512) <span class="bcp14">MUST NOT</span> be used, as ECTs require asymmetric
|
||
signatures for non-repudiation.<a href="#section-4.1-3.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.1-3.3">typ:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.1-3.4">
|
||
<p id="section-4.1-3.4.1"><span class="bcp14">REQUIRED</span>. <span class="bcp14">MUST</span> be set to "wimse-exec+jwt" to distinguish ECTs
|
||
from other JWT types, consistent with the WIMSE convention for
|
||
type parameter values.<a href="#section-4.1-3.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.1-3.5">kid:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.1-3.6">
|
||
<p id="section-4.1-3.6.1"><span class="bcp14">REQUIRED</span>. The key identifier referencing the public key from
|
||
the agent's WIT <span>[<a href="#RFC7517" class="cite xref">RFC7517</a>]</span>. Used by verifiers to look up the
|
||
correct public key for signature verification.<a href="#section-4.1-3.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="jwt-claims">
|
||
<section id="section-4.2">
|
||
<h3 id="name-jwt-claims">
|
||
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-jwt-claims" class="section-name selfRef">JWT Claims</a>
|
||
</h3>
|
||
<p id="section-4.2-1">The ECT payload contains both WIMSE-compatible standard JWT claims
|
||
and execution context claims defined by this specification.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
|
||
<div id="standard-jwt-claims">
|
||
<section id="section-4.2.1">
|
||
<h4 id="name-standard-jwt-claims">
|
||
<a href="#section-4.2.1" class="section-number selfRef">4.2.1. </a><a href="#name-standard-jwt-claims" class="section-name selfRef">Standard JWT Claims</a>
|
||
</h4>
|
||
<p id="section-4.2.1-1">The following standard JWT claims <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span> <span class="bcp14">MUST</span> be present in
|
||
every ECT:<a href="#section-4.2.1-1" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-4.2.1-2">
|
||
<dt id="section-4.2.1-2.1">iss:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.1-2.2">
|
||
<p id="section-4.2.1-2.2.1"><span class="bcp14">REQUIRED</span>. StringOrURI. A URI identifying the issuer of the
|
||
ECT. In WIMSE deployments, this <span class="bcp14">SHOULD</span> be the workload's
|
||
SPIFFE ID in the format <code>spiffe://<trust-domain>/<path></code>,
|
||
matching the "sub" claim of the agent's WIT. Non-WIMSE
|
||
deployments <span class="bcp14">MAY</span> use other URI schemes (e.g., HTTPS URLs or
|
||
URN:UUID identifiers).<a href="#section-4.2.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.2.1-2.3">aud:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.1-2.4">
|
||
<p id="section-4.2.1-2.4.1"><span class="bcp14">REQUIRED</span>. StringOrURI or array of StringOrURI. The intended
|
||
recipient(s) of the ECT. Because ECTs serve as both inter-agent
|
||
messages and audit records, the "aud" claim <span class="bcp14">SHOULD</span> contain the
|
||
identifiers of all entities that will verify the ECT. In
|
||
practice this means:<a href="#section-4.2.1-2.4.1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-4.2.1-2.4.2.1">
|
||
<p id="section-4.2.1-2.4.2.1.1"><strong>Point-to-point delivery</strong>: when an ECT is sent from one
|
||
agent to a single next agent, "aud" contains that agent's
|
||
workload identity. The receiving agent verifies the ECT and
|
||
forwards it to the ledger on behalf of the issuer.<a href="#section-4.2.1-2.4.2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-4.2.1-2.4.2.2">
|
||
<p id="section-4.2.1-2.4.2.2.1"><strong>Direct-to-ledger submission</strong>: when an ECT is submitted
|
||
directly to the audit ledger (e.g., after a join or at
|
||
workflow completion), "aud" contains the ledger's identity.<a href="#section-4.2.1-2.4.2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-4.2.1-2.4.2.3">
|
||
<p id="section-4.2.1-2.4.2.3.1"><strong>Multi-audience</strong>: when an ECT must be verified by both the
|
||
next agent and the ledger independently, "aud" <span class="bcp14">MUST</span> be an
|
||
array containing both identifiers (e.g.,
|
||
["spiffe://example.com/agent/next",
|
||
"spiffe://example.com/system/ledger"]). Each verifier checks
|
||
that its own identity appears in the array.<a href="#section-4.2.1-2.4.2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-4.2.1-2.4.3">In multi-parent (join) scenarios where a task depends on ECTs
|
||
from multiple parent agents, the joining agent creates a new ECT
|
||
with the parent task IDs in "par". The "aud" of this new ECT
|
||
is set according to the rules above based on where the ECT will
|
||
be delivered — it is independent of the "aud" values in the
|
||
parent ECTs.<a href="#section-4.2.1-2.4.3" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.2.1-2.5">iat:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.1-2.6">
|
||
<p id="section-4.2.1-2.6.1"><span class="bcp14">REQUIRED</span>. NumericDate. The time at which the ECT was issued.
|
||
The ECT records a completed action, so the "iat" value reflects
|
||
when the record was created, not when task execution began.<a href="#section-4.2.1-2.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.2.1-2.7">exp:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.1-2.8">
|
||
<p id="section-4.2.1-2.8.1"><span class="bcp14">REQUIRED</span>. NumericDate. The expiration time of the ECT.
|
||
Implementations <span class="bcp14">SHOULD</span> set this to 5 to 15 minutes after "iat"
|
||
to limit the replay window while allowing for reasonable clock
|
||
skew and processing time.<a href="#section-4.2.1-2.8.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
<p id="section-4.2.1-3">The standard JWT "nbf" (Not Before) claim is not used in ECTs
|
||
because ECTs record completed actions and are valid immediately
|
||
upon issuance.<a href="#section-4.2.1-3" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-4.2.1-4">
|
||
<dt id="section-4.2.1-4.1">jti:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.1-4.2">
|
||
<p id="section-4.2.1-4.2.1"><span class="bcp14">REQUIRED</span>. String. A globally unique identifier for both the
|
||
ECT and the task it records, in UUID format <span>[<a href="#RFC9562" class="cite xref">RFC9562</a>]</span>. Since
|
||
each ECT represents exactly one task, "jti" serves as both the
|
||
token identifier (for replay detection) and the task identifier
|
||
(for DAG parent references in "par"). Receivers <span class="bcp14">MUST</span> reject
|
||
ECTs whose "jti" has already been seen within the expiration
|
||
window. When "wid" is present, uniqueness is scoped to the
|
||
workflow; when "wid" is absent, uniqueness <span class="bcp14">MUST</span> be enforced
|
||
globally across the ECT store.<a href="#section-4.2.1-4.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="exec-claims">
|
||
<section id="section-4.2.2">
|
||
<h4 id="name-execution-context">
|
||
<a href="#section-4.2.2" class="section-number selfRef">4.2.2. </a><a href="#name-execution-context" class="section-name selfRef">Execution Context</a>
|
||
</h4>
|
||
<p id="section-4.2.2-1">The following claims are defined by this specification:<a href="#section-4.2.2-1" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-4.2.2-2">
|
||
<dt id="section-4.2.2-2.1">wid:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.2-2.2">
|
||
<p id="section-4.2.2-2.2.1"><span class="bcp14">OPTIONAL</span>. String. A workflow identifier that groups related
|
||
ECTs into a single workflow. When present, <span class="bcp14">MUST</span> be a UUID
|
||
<span>[<a href="#RFC9562" class="cite xref">RFC9562</a>]</span>.<a href="#section-4.2.2-2.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.2.2-2.3">exec_act:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.2-2.4">
|
||
<p id="section-4.2.2-2.4.1"><span class="bcp14">REQUIRED</span>. String. The action or task type identifier describing
|
||
what the agent performed (e.g., "process_payment",
|
||
"validate_safety", "calculate_dosage"). Note: this claim is
|
||
intentionally named "exec_act" rather than "act" to avoid
|
||
collision with the "act" (Actor) claim registered by
|
||
<span>[<a href="#RFC8693" class="cite xref">RFC8693</a>]</span>.<a href="#section-4.2.2-2.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.2.2-2.5">par:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.2-2.6">
|
||
<p id="section-4.2.2-2.6.1"><span class="bcp14">REQUIRED</span>. Array of strings. Parent task identifiers
|
||
representing DAG dependencies. Each element <span class="bcp14">MUST</span> be the "jti"
|
||
value of a previously verified ECT. An empty array indicates
|
||
a root task with no dependencies. A workflow <span class="bcp14">MAY</span> contain
|
||
multiple root tasks.<a href="#section-4.2.2-2.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="policy-claims">
|
||
<section id="section-4.2.3">
|
||
<h4 id="name-policy-evaluation-extension">
|
||
<a href="#section-4.2.3" class="section-number selfRef">4.2.3. </a><a href="#name-policy-evaluation-extension" class="section-name selfRef">Policy Evaluation Extension Keys</a>
|
||
</h4>
|
||
<p id="section-4.2.3-1">Policy evaluation outcomes are recorded as extension keys within
|
||
the "ext" object (<a href="#extension-claims" class="auto internal xref">Section 4.2.6</a>). This keeps the core
|
||
registered claims focused on DAG structure and execution context,
|
||
while allowing deployments to add policy recording as needed.<a href="#section-4.2.3-1" class="pilcrow">¶</a></p>
|
||
<p id="section-4.2.3-2">The following extension keys are defined for policy evaluation:<a href="#section-4.2.3-2" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-4.2.3-3">
|
||
<dt id="section-4.2.3-3.1">"pol":</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.3-3.2">
|
||
<p id="section-4.2.3-3.2.1">String. The identifier of the policy rule that was evaluated
|
||
for this task (e.g., "clinical_data_access_policy_v1"). <span class="bcp14">MUST</span>
|
||
be present when "pol_decision" is present.<a href="#section-4.2.3-3.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.2.3-3.3">"pol_decision":</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.3-3.4">
|
||
<p id="section-4.2.3-3.4.1">String. The result of the policy evaluation. When present,
|
||
<span class="bcp14">MUST</span> be one of the values registered in the ECT Policy Decision
|
||
Values registry (<a href="#pol-decision-registry" class="auto internal xref">Section 12.4</a>). <span class="bcp14">MUST</span> be present
|
||
when "pol" is present. Initial values are:<a href="#section-4.2.3-3.4.1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-4.2.3-3.4.2.1">
|
||
<p id="section-4.2.3-3.4.2.1.1">"approved": The policy evaluation succeeded and the task
|
||
was authorized to proceed.<a href="#section-4.2.3-3.4.2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-4.2.3-3.4.2.2">
|
||
<p id="section-4.2.3-3.4.2.2.1">"rejected": The policy evaluation failed. A "rejected" ECT
|
||
<span class="bcp14">MUST</span> still be recorded for accountability. An ECT with
|
||
"pol_decision" of "rejected" <span class="bcp14">MAY</span> appear as a parent in the
|
||
"par" array of a subsequent ECT, but only for compensation,
|
||
rollback, or remediation tasks. Agents <span class="bcp14">MUST NOT</span> proceed
|
||
with normal workflow execution based on a parent ECT whose
|
||
"pol_decision" is "rejected".<a href="#section-4.2.3-3.4.2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-4.2.3-3.4.2.3">
|
||
<p id="section-4.2.3-3.4.2.3.1">"pending_human_review": The policy evaluation requires human
|
||
judgment before proceeding. Agents <span class="bcp14">MUST NOT</span> proceed with
|
||
dependent tasks until a subsequent ECT from a human reviewer
|
||
records an "approved" decision referencing this task as a
|
||
parent.<a href="#section-4.2.3-3.4.2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-4.2.3-3.4.3">When "pol" and "pol_decision" are absent from "ext", the ECT
|
||
records task execution without a policy checkpoint. Regulated
|
||
deployments <span class="bcp14">SHOULD</span> include policy keys on all ECTs to maintain
|
||
complete audit trails.<a href="#section-4.2.3-3.4.3" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.2.3-3.5">"pol_enforcer":</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.3-3.6">
|
||
<p id="section-4.2.3-3.6.1">StringOrURI. The identity of the entity (system or person)
|
||
that evaluated the policy decision. When present, <span class="bcp14">SHOULD</span> use
|
||
SPIFFE ID format.<a href="#section-4.2.3-3.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
<p id="section-4.2.3-4">This specification intentionally defines only the recording of
|
||
policy evaluation outcomes. The mechanisms by which policies are
|
||
defined, distributed to agents, and evaluated are out of scope.
|
||
The "pol" key is an opaque identifier referencing an external
|
||
policy; the semantics and enforcement of that policy are
|
||
determined by the deployment environment. Implementations may
|
||
use any policy engine or framework (e.g., OPA/Rego, Cedar, XACML,
|
||
or custom solutions) provided that the evaluation outcome is
|
||
faithfully recorded in the "ext" keys defined above.<a href="#section-4.2.3-4" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="data-integrity-claims">
|
||
<section id="section-4.2.4">
|
||
<h4 id="name-data-integrity">
|
||
<a href="#section-4.2.4" class="section-number selfRef">4.2.4. </a><a href="#name-data-integrity" class="section-name selfRef">Data Integrity</a>
|
||
</h4>
|
||
<p id="section-4.2.4-1">The following claims provide integrity verification for task
|
||
inputs and outputs without revealing the data itself:<a href="#section-4.2.4-1" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-4.2.4-2">
|
||
<dt id="section-4.2.4-2.1">inp_hash:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.4-2.2">
|
||
<p id="section-4.2.4-2.2.1"><span class="bcp14">OPTIONAL</span>. String. A cryptographic hash of the input data,
|
||
formatted as "hash-algorithm:base64url-encoded-hash" (e.g.,
|
||
"sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The
|
||
hash algorithm identifier <span class="bcp14">MUST</span> be a lowercase value from the
|
||
IANA Named Information Hash Algorithm Registry (e.g., "sha-256",
|
||
"sha-384", "sha-512"). Implementations <span class="bcp14">MUST</span> support "sha-256"
|
||
and <span class="bcp14">SHOULD</span> use "sha-256" unless a stronger algorithm is
|
||
required. Implementations <span class="bcp14">MUST NOT</span> accept hash algorithms
|
||
weaker than SHA-256 (e.g., MD5, SHA-1). The hash <span class="bcp14">MUST</span> be
|
||
computed over the raw octets of the input data.<a href="#section-4.2.4-2.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.2.4-2.3">out_hash:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.4-2.4">
|
||
<p id="section-4.2.4-2.4.1"><span class="bcp14">OPTIONAL</span>. String. A cryptographic hash of the output data,
|
||
using the same format and algorithm requirements as "inp_hash".<a href="#section-4.2.4-2.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="compensation-claims">
|
||
<section id="section-4.2.5">
|
||
<h4 id="name-compensation-and-rollback">
|
||
<a href="#section-4.2.5" class="section-number selfRef">4.2.5. </a><a href="#name-compensation-and-rollback" class="section-name selfRef">Compensation and Rollback</a>
|
||
</h4>
|
||
<p id="section-4.2.5-1">Compensation and rollback actions are recorded using the "par"
|
||
claim to reference the original task and the "exec_act" claim to
|
||
describe the remediation action. 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.<a href="#section-4.2.5-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="extension-claims">
|
||
<section id="section-4.2.6">
|
||
<h4 id="name-extensions">
|
||
<a href="#section-4.2.6" class="section-number selfRef">4.2.6. </a><a href="#name-extensions" class="section-name selfRef">Extensions</a>
|
||
</h4>
|
||
<span class="break"></span><dl class="dlParallel" id="section-4.2.6-1">
|
||
<dt id="section-4.2.6-1.1">ext:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.6-1.2">
|
||
<p id="section-4.2.6-1.2.1"><span class="bcp14">OPTIONAL</span>. Object. An extension object for domain-specific
|
||
claims not defined by this specification. Implementations
|
||
that do not understand extension claims <span class="bcp14">MUST</span> ignore them.<a href="#section-4.2.6-1.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
<p id="section-4.2.6-2">To avoid key collisions between different domains, extension
|
||
key names <span class="bcp14">SHOULD</span> use reverse domain notation (e.g.,
|
||
"com.example.custom_field") to avoid collisions between
|
||
independently developed extensions. To prevent abuse and
|
||
excessive token size, the serialized JSON representation of
|
||
the "ext" object <span class="bcp14">SHOULD NOT</span> exceed 4096 bytes, and the JSON
|
||
nesting depth within the "ext" object <span class="bcp14">SHOULD NOT</span> exceed 5
|
||
levels. Implementations <span class="bcp14">SHOULD</span> reject ECTs whose "ext" claim
|
||
exceeds these limits.<a href="#section-4.2.6-2" class="pilcrow">¶</a></p>
|
||
<p id="section-4.2.6-3">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.<a href="#section-4.2.6-3" class="pilcrow">¶</a></p>
|
||
<p id="section-4.2.6-4">Policy evaluation keys (see <a href="#policy-claims" class="auto internal xref">Section 4.2.3</a> for full
|
||
definitions and decision value semantics):<a href="#section-4.2.6-4" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-4.2.6-5.1">
|
||
<p id="section-4.2.6-5.1.1">"pol": String. Policy rule identifier.<a href="#section-4.2.6-5.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-4.2.6-5.2">
|
||
<p id="section-4.2.6-5.2.1">"pol_decision": String. Policy evaluation outcome
|
||
("approved", "rejected", or "pending_human_review").<a href="#section-4.2.6-5.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-4.2.6-5.3">
|
||
<p id="section-4.2.6-5.3.1">"pol_enforcer": StringOrURI. Identity of the policy
|
||
evaluator.<a href="#section-4.2.6-5.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-4.2.6-5.4">
|
||
<p id="section-4.2.6-5.4.1">"pol_timestamp": NumericDate. Time at which the policy
|
||
decision was made, if distinct from "iat".<a href="#section-4.2.6-5.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-4.2.6-6">Operational metadata keys:<a href="#section-4.2.6-6" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-4.2.6-7.1">
|
||
<p id="section-4.2.6-7.1.1">"exec_time_ms": Integer. Execution duration in milliseconds.<a href="#section-4.2.6-7.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-4.2.6-7.2">
|
||
<p id="section-4.2.6-7.2.1">"regulated_domain": String. Regulatory domain (e.g.,
|
||
"medtech", "finance", "military").<a href="#section-4.2.6-7.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-4.2.6-7.3">
|
||
<p id="section-4.2.6-7.3.1">"model_version": String. AI/ML model version.<a href="#section-4.2.6-7.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-4.2.6-7.4">
|
||
<p id="section-4.2.6-7.4.1">"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.<a href="#section-4.2.6-7.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-4.2.6-7.5">
|
||
<p id="section-4.2.6-7.5.1">"inp_classification": String. Data sensitivity classification
|
||
(e.g., "public", "confidential", "restricted").<a href="#section-4.2.6-7.5.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-4.2.6-7.6">
|
||
<p id="section-4.2.6-7.6.1">"compensation_required": Boolean. Indicates whether this task
|
||
is a compensation or rollback action.<a href="#section-4.2.6-7.6.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-4.2.6-7.7">
|
||
<p id="section-4.2.6-7.7.1">"compensation_reason": String. Structured reason code for the
|
||
compensation action (e.g., "policy_violation_in_parent_trade").
|
||
<span class="bcp14">SHOULD</span> use structured identifiers rather than free-form text
|
||
to minimize information leakage (see <a href="#data-minimization" class="auto internal xref">Section 11.2</a>).<a href="#section-4.2.6-7.7.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="complete-ect-example">
|
||
<section id="section-4.3">
|
||
<h3 id="name-complete-ect-example">
|
||
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-complete-ect-example" class="section-name selfRef">Complete ECT Example</a>
|
||
</h3>
|
||
<p id="section-4.3-1">The following is a complete ECT payload example:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
|
||
<span id="name-complete-ect-payload-exampl"></span><div id="fig-full-ect">
|
||
<figure id="figure-4">
|
||
<div class="lang-json sourcecode" id="section-4.3-2.1">
|
||
<pre>
|
||
{
|
||
"iss": "spiffe://example.com/agent/clinical",
|
||
"aud": "spiffe://example.com/agent/safety",
|
||
"iat": 1772064150,
|
||
"exp": 1772064750,
|
||
"jti": "550e8400-e29b-41d4-a716-446655440001",
|
||
|
||
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
|
||
"exec_act": "recommend_treatment",
|
||
"par": [],
|
||
|
||
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
|
||
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
|
||
|
||
"ext": {
|
||
"pol": "clinical_reasoning_policy_v2",
|
||
"pol_decision": "approved",
|
||
"pol_enforcer": "spiffe://example.com/policy/clinical-engine",
|
||
"pol_timestamp": 1772064145,
|
||
"exec_time_ms": 245,
|
||
"regulated_domain": "medtech",
|
||
"model_version": "clinical-reasoning-v4.2"
|
||
}
|
||
}
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
|
||
<a href="#name-complete-ect-payload-exampl" class="selfRef">Complete ECT Payload Example</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="http-header">
|
||
<section id="section-5">
|
||
<h2 id="name-http-header-transport">
|
||
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-http-header-transport" class="section-name selfRef">HTTP Header Transport</a>
|
||
</h2>
|
||
<div id="execution-context-header-field">
|
||
<section id="section-5.1">
|
||
<h3 id="name-execution-context-header-fi">
|
||
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-execution-context-header-fi" class="section-name selfRef">Execution-Context Header Field</a>
|
||
</h3>
|
||
<p id="section-5.1-1">This specification defines the Execution-Context HTTP header field
|
||
<span>[<a href="#RFC9110" class="cite xref">RFC9110</a>]</span> for transporting ECTs between agents.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
|
||
<p id="section-5.1-2">The header field value is the ECT in JWS Compact Serialization
|
||
format <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>. The value consists of three Base64url-encoded
|
||
parts separated by period (".") characters.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
|
||
<p id="section-5.1-3">An agent sending a request to another agent includes the
|
||
Execution-Context header alongside the WIMSE Workload-Identity
|
||
header:<a href="#section-5.1-3" class="pilcrow">¶</a></p>
|
||
<span id="name-http-request-with-ect-heade"></span><div id="fig-http-example">
|
||
<figure id="figure-5">
|
||
<div class="alignLeft art-text artwork" id="section-5.1-4.1">
|
||
<pre>
|
||
GET /api/safety-check HTTP/1.1
|
||
Host: safety-agent.example.com
|
||
Workload-Identity: eyJhbGci...WIT...
|
||
Execution-Context: eyJhbGci...ECT...
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
|
||
<a href="#name-http-request-with-ect-heade" class="selfRef">HTTP Request with ECT Header</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
<p id="section-5.1-5">When multiple parent tasks contribute context to a single request,
|
||
multiple Execution-Context header field lines <span class="bcp14">MAY</span> be included, each
|
||
carrying a separate ECT in JWS Compact Serialization format.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
|
||
<p id="section-5.1-6">When a receiver processes multiple Execution-Context headers, it
|
||
<span class="bcp14">MUST</span> individually verify each ECT per the procedure in
|
||
<a href="#verification" class="auto internal xref">Section 7</a>. If any single ECT fails verification, the
|
||
receiver <span class="bcp14">MUST</span> reject the entire request. The set of verified
|
||
parent task IDs across all received ECTs represents the complete
|
||
set of parent dependencies available for the receiving agent's
|
||
subsequent ECT.<a href="#section-5.1-6" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="dag-validation">
|
||
<section id="section-6">
|
||
<h2 id="name-dag-validation">
|
||
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-dag-validation" class="section-name selfRef">DAG Validation</a>
|
||
</h2>
|
||
<div id="overview">
|
||
<section id="section-6.1">
|
||
<h3 id="name-overview">
|
||
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-overview" class="section-name selfRef">Overview</a>
|
||
</h3>
|
||
<p id="section-6.1-1">ECTs form a Directed Acyclic Graph (DAG) where each task
|
||
references its parent tasks via the "par" claim. This structure
|
||
provides a cryptographically signed record of execution ordering,
|
||
enabling auditors to reconstruct the complete workflow and verify
|
||
that required predecessor tasks were recorded before dependent
|
||
tasks.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
|
||
<p id="section-6.1-2">DAG validation is performed against the ECT store — either an
|
||
audit ledger or the set of parent ECTs received inline.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="validation-rules">
|
||
<section id="section-6.2">
|
||
<h3 id="name-validation-rules">
|
||
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-validation-rules" class="section-name selfRef">Validation Rules</a>
|
||
</h3>
|
||
<p id="section-6.2-1">When receiving and verifying an ECT, implementations <span class="bcp14">MUST</span> perform
|
||
the following DAG validation steps:<a href="#section-6.2-1" class="pilcrow">¶</a></p>
|
||
<ol start="1" type="1" class="normal type-1" id="section-6.2-2">
|
||
<li id="section-6.2-2.1">
|
||
<p id="section-6.2-2.1.1">Task ID Uniqueness: The "jti" claim <span class="bcp14">MUST</span> be unique within the
|
||
applicable scope (the workflow identified by "wid", or the
|
||
entire ECT store if "wid" is absent). If an ECT with the same
|
||
"jti" already exists, the ECT <span class="bcp14">MUST</span> be rejected.<a href="#section-6.2-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.2-2.2">
|
||
<p id="section-6.2-2.2.1">Parent Existence: Every task identifier listed in the "par"
|
||
array <span class="bcp14">MUST</span> correspond to a task that is available in the ECT
|
||
store (either previously recorded in the ledger or received
|
||
inline as a verified parent ECT). If any parent task is not
|
||
found, the ECT <span class="bcp14">MUST</span> be rejected.<a href="#section-6.2-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.2-2.3">
|
||
<p id="section-6.2-2.3.1">Temporal Ordering: The "iat" value of every parent task <span class="bcp14">MUST NOT</span> be greater than the "iat" value of the current task plus a
|
||
configurable clock skew tolerance (<span class="bcp14">RECOMMENDED</span>: 30 seconds).
|
||
That is, for each parent: <code>parent.iat < child.iat +
|
||
clock_skew_tolerance</code>. The tolerance accounts for clock skew
|
||
between agents; it does not guarantee strict causal ordering
|
||
from timestamps alone. Causal ordering is primarily enforced
|
||
by the DAG structure (parent existence in the ECT store), not by
|
||
timestamps. If any parent task violates this constraint, the
|
||
ECT <span class="bcp14">MUST</span> be rejected.<a href="#section-6.2-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.2-2.4">
|
||
<p id="section-6.2-2.4.1">Acyclicity: Following the chain of parent references <span class="bcp14">MUST NOT</span>
|
||
lead back to the current ECT's "jti". If a cycle is detected,
|
||
the ECT <span class="bcp14">MUST</span> be rejected.<a href="#section-6.2-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.2-2.5">
|
||
<p id="section-6.2-2.5.1">Parent Policy Decision: If any parent ECT's "ext" object
|
||
contains a "pol_decision" of "rejected" or
|
||
"pending_human_review", the current ECT's "exec_act" <span class="bcp14">MUST</span>
|
||
indicate a compensation, rollback, remediation, or human
|
||
review action. Implementations <span class="bcp14">MUST NOT</span> accept an ECT
|
||
representing normal workflow continuation when a parent's
|
||
"pol_decision" is not "approved". This rule only applies
|
||
when the parent ECT's "ext" contains policy keys.<a href="#section-6.2-2.5.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.2-2.6">
|
||
<p id="section-6.2-2.6.1">Trust Domain Consistency: Parent tasks <span class="bcp14">SHOULD</span> belong to the
|
||
same trust domain or to a trust domain with which a federation
|
||
relationship has been established.<a href="#section-6.2-2.6.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ol>
|
||
</section>
|
||
</div>
|
||
<div id="dag-validation-algorithm">
|
||
<section id="section-6.3">
|
||
<h3 id="name-dag-validation-algorithm">
|
||
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-dag-validation-algorithm" class="section-name selfRef">DAG Validation Algorithm</a>
|
||
</h3>
|
||
<p id="section-6.3-1">The following pseudocode describes the DAG validation procedure:<a href="#section-6.3-1" class="pilcrow">¶</a></p>
|
||
<span id="name-dag-validation-pseudocode"></span><div id="fig-dag-validation">
|
||
<figure id="figure-6">
|
||
<div class="lang-pseudocode sourcecode" id="section-6.3-2.1">
|
||
<pre>
|
||
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
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
|
||
<a href="#name-dag-validation-pseudocode" class="selfRef">DAG Validation Pseudocode</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
<p id="section-6.3-3">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 <span class="bcp14">SHOULD</span> enforce a maximum ancestor
|
||
traversal limit (<span class="bcp14">RECOMMENDED</span>: 10000 nodes). If the limit is
|
||
reached before cycle detection completes, the ECT <span class="bcp14">SHOULD</span> be
|
||
rejected. Implementations <span class="bcp14">SHOULD</span> cache cycle detection results
|
||
for previously verified tasks to avoid redundant traversals.<a href="#section-6.3-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="verification">
|
||
<section id="section-7">
|
||
<h2 id="name-signature-and-token-verific">
|
||
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-signature-and-token-verific" class="section-name selfRef">Signature and Token Verification</a>
|
||
</h2>
|
||
<div id="verification-procedure">
|
||
<section id="section-7.1">
|
||
<h3 id="name-verification-procedure">
|
||
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-verification-procedure" class="section-name selfRef">Verification Procedure</a>
|
||
</h3>
|
||
<p id="section-7.1-1">When an agent receives an ECT, it <span class="bcp14">MUST</span> perform the following
|
||
verification steps in order:<a href="#section-7.1-1" class="pilcrow">¶</a></p>
|
||
<ol start="1" type="1" class="normal type-1" id="section-7.1-2">
|
||
<li id="section-7.1-2.1">
|
||
<p id="section-7.1-2.1.1">Parse the JWS Compact Serialization to extract the JOSE header,
|
||
payload, and signature components per <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>.<a href="#section-7.1-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.2">
|
||
<p id="section-7.1-2.2.1">Verify that the "typ" header parameter is "wimse-exec+jwt".<a href="#section-7.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.3">
|
||
<p id="section-7.1-2.3.1">Verify that the "alg" header parameter is not "none" and is
|
||
not a symmetric algorithm.<a href="#section-7.1-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.4">
|
||
<p id="section-7.1-2.4.1">Verify the "kid" header parameter references a known, valid
|
||
public key from a WIT within the trust domain.<a href="#section-7.1-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.5">
|
||
<p id="section-7.1-2.5.1">Retrieve the public key identified by "kid" and verify the JWS
|
||
signature per <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span> Section 5.2.<a href="#section-7.1-2.5.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.6">
|
||
<p id="section-7.1-2.6.1">Verify that the signing key identified by "kid" has not been
|
||
revoked within the trust domain. Implementations <span class="bcp14">MUST</span> check
|
||
the key's revocation status using the trust domain's key
|
||
lifecycle mechanism (e.g., certificate revocation list, OCSP,
|
||
or SPIFFE trust bundle updates).<a href="#section-7.1-2.6.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.7">
|
||
<p id="section-7.1-2.7.1">Verify the "alg" header parameter matches the algorithm in the
|
||
corresponding WIT.<a href="#section-7.1-2.7.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.8">
|
||
<p id="section-7.1-2.8.1">Verify the "iss" claim matches the "sub" claim of the WIT
|
||
associated with the "kid" public key.<a href="#section-7.1-2.8.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.9">
|
||
<p id="section-7.1-2.9.1">Verify the "aud" claim contains the verifier's own workload
|
||
identity. When "aud" is an array, it is sufficient that the
|
||
verifier's identity appears as one element; the presence of
|
||
other audience values does not cause verification failure.
|
||
When the verifier is the audit ledger, the ledger's own
|
||
identity <span class="bcp14">MUST</span> appear in "aud".<a href="#section-7.1-2.9.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.10">
|
||
<p id="section-7.1-2.10.1">Verify the "exp" claim indicates the ECT has not expired.<a href="#section-7.1-2.10.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.11">
|
||
<p id="section-7.1-2.11.1">Verify the "iat" claim is not unreasonably far in the past
|
||
(implementation-specific threshold, <span class="bcp14">RECOMMENDED</span> maximum of
|
||
15 minutes) and is not unreasonably far in the future
|
||
(<span class="bcp14">RECOMMENDED</span>: no more than 30 seconds ahead of the
|
||
verifier's current time, to account for clock skew).<a href="#section-7.1-2.11.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.12">
|
||
<p id="section-7.1-2.12.1">Verify all required claims ("jti", "exec_act", "par") are
|
||
present and well-formed.<a href="#section-7.1-2.12.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.13">
|
||
<p id="section-7.1-2.13.1">If "ext" is present and contains "pol" or "pol_decision",
|
||
verify that both are present and that "pol_decision" is one
|
||
of "approved", "rejected", or "pending_human_review".<a href="#section-7.1-2.13.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.14">
|
||
<p id="section-7.1-2.14.1">Perform DAG validation per <a href="#dag-validation" class="auto internal xref">Section 6</a>.<a href="#section-7.1-2.14.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.15">
|
||
<p id="section-7.1-2.15.1">If all checks pass and an audit ledger is deployed, the ECT
|
||
<span class="bcp14">SHOULD</span> be appended to the ledger.<a href="#section-7.1-2.15.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ol>
|
||
<p id="section-7.1-3">If any verification step fails, the ECT <span class="bcp14">MUST</span> be rejected and the
|
||
failure <span class="bcp14">MUST</span> be logged for audit purposes. Error messages
|
||
<span class="bcp14">SHOULD NOT</span> reveal whether specific parent task IDs exist in the
|
||
ECT store, to prevent information disclosure.<a href="#section-7.1-3" class="pilcrow">¶</a></p>
|
||
<p id="section-7.1-4">When ECT verification fails during HTTP request processing, the
|
||
receiving agent <span class="bcp14">SHOULD</span> respond with HTTP 403 (Forbidden) if the
|
||
WIT is valid but the ECT is invalid, and HTTP 401
|
||
(Unauthorized) if the ECT signature verification fails. The
|
||
response body <span class="bcp14">SHOULD</span> include a generic error indicator without
|
||
revealing which specific verification step failed. The receiving
|
||
agent <span class="bcp14">MUST NOT</span> process the requested action when ECT verification
|
||
fails.<a href="#section-7.1-4" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="verification-pseudocode">
|
||
<section id="section-7.2">
|
||
<h3 id="name-verification-pseudocode">
|
||
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-verification-pseudocode" class="section-name selfRef">Verification Pseudocode</a>
|
||
</h3>
|
||
<span id="name-ect-verification-pseudocode"></span><div id="fig-verification">
|
||
<figure id="figure-7">
|
||
<div class="breakable lang-pseudocode sourcecode" id="section-7.2-1.1">
|
||
<pre>
|
||
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 policy extension keys (optional, but must be paired)
|
||
ext = payload.ext or {}
|
||
if "pol" in ext or "pol_decision" in ext:
|
||
if "pol" not in ext or "pol_decision" not in ext:
|
||
return reject("pol and pol_decision must both be present")
|
||
if ext.pol_decision not in
|
||
["approved", "rejected", "pending_human_review"]:
|
||
return reject("Invalid pol_decision value")
|
||
|
||
// 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
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
|
||
<a href="#name-ect-verification-pseudocode" class="selfRef">ECT Verification Pseudocode</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="ledger-interface">
|
||
<section id="section-8">
|
||
<h2 id="name-audit-ledger-interface">
|
||
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-audit-ledger-interface" class="section-name selfRef">Audit Ledger Interface</a>
|
||
</h2>
|
||
<p id="section-8-1">ECTs <span class="bcp14">MAY</span> be recorded in an immutable audit ledger for compliance
|
||
verification and post-hoc analysis. A ledger is <span class="bcp14">RECOMMENDED</span> for
|
||
regulated environments but is not required for point-to-point
|
||
operation. This specification does not mandate a specific storage
|
||
technology. Implementations <span class="bcp14">MAY</span> use append-only logs, databases
|
||
with cryptographic commitment schemes, distributed ledgers, or
|
||
any storage mechanism that provides the required properties.<a href="#section-8-1" class="pilcrow">¶</a></p>
|
||
<p id="section-8-2">When an audit ledger is deployed, the implementation <span class="bcp14">MUST</span> provide:<a href="#section-8-2" class="pilcrow">¶</a></p>
|
||
<ol start="1" type="1" class="normal type-1" id="section-8-3">
|
||
<li id="section-8-3.1">
|
||
<p id="section-8-3.1.1">Append-only semantics: Once an ECT is recorded, it <span class="bcp14">MUST NOT</span> be
|
||
modified or deleted.<a href="#section-8-3.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-8-3.2">
|
||
<p id="section-8-3.2.1">Ordering: The ledger <span class="bcp14">MUST</span> maintain a total ordering of ECT
|
||
entries via a monotonically increasing sequence number.<a href="#section-8-3.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-8-3.3">
|
||
<p id="section-8-3.3.1">Lookup by ECT ID: The ledger <span class="bcp14">MUST</span> support efficient retrieval
|
||
of ECT entries by "jti" value.<a href="#section-8-3.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-8-3.4">
|
||
<p id="section-8-3.4.1">Integrity verification: The ledger <span class="bcp14">SHOULD</span> provide a mechanism
|
||
to verify that no entries have been tampered with (e.g.,
|
||
hash chains or Merkle trees).<a href="#section-8-3.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ol>
|
||
<p id="section-8-4">The ledger <span class="bcp14">SHOULD</span> be maintained by an entity independent of the
|
||
workflow agents to reduce the risk of collusion.<a href="#section-8-4" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="use-cases">
|
||
<section id="section-9">
|
||
<h2 id="name-use-cases">
|
||
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-use-cases" class="section-name selfRef">Use Cases</a>
|
||
</h2>
|
||
<p id="section-9-1">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.<a href="#section-9-1" class="pilcrow">¶</a></p>
|
||
<p id="section-9-2">Note: task identifiers in this section are abbreviated for
|
||
readability. In production, all "jti" values are required to be
|
||
UUIDs per <a href="#exec-claims" class="auto internal xref">Section 4.2.2</a>.<a href="#section-9-2" class="pilcrow">¶</a></p>
|
||
<div id="medical-device-sdlc-workflow">
|
||
<section id="section-9.1">
|
||
<h3 id="name-medical-device-sdlc-workflo">
|
||
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-medical-device-sdlc-workflo" class="section-name selfRef">Medical Device SDLC Workflow</a>
|
||
</h3>
|
||
<p id="section-9.1-1">In a medical device software development lifecycle (SDLC),
|
||
AI agents assist across multiple phases from requirements
|
||
analysis through release approval. Regulatory frameworks
|
||
including <span>[<a href="#FDA-21CFR11" class="cite xref">FDA-21CFR11</a>]</span> Section 11.10(e) and <span>[<a href="#EU-MDR" class="cite xref">EU-MDR</a>]</span> require
|
||
audit trails documenting the complete development process for
|
||
software used in medical devices.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
|
||
<span id="name-medical-device-sdlc-workflow"></span><div id="fig-medtech-sdlc">
|
||
<figure id="figure-8">
|
||
<div class="alignLeft art-text artwork" id="section-9.1-2.1">
|
||
<pre>
|
||
Agent A (Spec Reviewer):
|
||
jti: task-001 par: []
|
||
exec_act: review_requirements_spec
|
||
ext.pol: spec_review_policy_v2
|
||
ext.pol_decision: approved
|
||
|
||
Agent B (Code Generator):
|
||
jti: task-002 par: [task-001]
|
||
exec_act: implement_module
|
||
ext.pol: coding_standards_v3
|
||
ext.pol_decision: approved
|
||
|
||
Agent C (Test Agent):
|
||
jti: task-003 par: [task-002]
|
||
exec_act: execute_test_suite
|
||
ext.pol: test_coverage_policy_v1
|
||
ext.pol_decision: approved
|
||
|
||
Agent D (Build Agent):
|
||
jti: task-004 par: [task-003]
|
||
exec_act: build_release_artifact
|
||
ext.pol: build_validation_v2
|
||
ext.pol_decision: approved
|
||
|
||
Human Release Manager:
|
||
jti: task-005 par: [task-004]
|
||
exec_act: approve_release
|
||
ext.pol: release_approval_policy
|
||
ext.pol_decision: approved
|
||
ext.pol_enforcer: spiffe://meddev.example/human/release-mgr-42
|
||
ext.witnessed_by: [...]
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
|
||
<a href="#name-medical-device-sdlc-workflow" class="selfRef">Medical Device SDLC Workflow</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
<p id="section-9.1-3">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.<a href="#section-9.1-3" class="pilcrow">¶</a></p>
|
||
<div id="fda-audit-with-dag-reconstruction">
|
||
<section id="section-9.1.1">
|
||
<h4 id="name-fda-audit-with-dag-reconstr">
|
||
<a href="#section-9.1.1" class="section-number selfRef">9.1.1. </a><a href="#name-fda-audit-with-dag-reconstr" class="section-name selfRef">FDA Audit with DAG Reconstruction</a>
|
||
</h4>
|
||
<p id="section-9.1.1-1">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:<a href="#section-9.1.1-1" class="pilcrow">¶</a></p>
|
||
<span id="name-reconstructed-dag-for-fda-a"></span><div id="fig-fda-audit">
|
||
<figure id="figure-9">
|
||
<div class="alignLeft art-text artwork" id="section-9.1.1-2.1">
|
||
<pre>
|
||
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]
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
|
||
<a href="#name-reconstructed-dag-for-fda-a" class="selfRef">Reconstructed DAG for FDA Audit</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
<p id="section-9.1.1-3">The reconstructed DAG provides cryptographic evidence that:<a href="#section-9.1.1-3" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-9.1.1-4.1">
|
||
<p id="section-9.1.1-4.1.1">Each phase was executed by an identified and authenticated agent.<a href="#section-9.1.1-4.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.1.1-4.2">
|
||
<p id="section-9.1.1-4.2.1">Policy checkpoints were evaluated at every phase transition.<a href="#section-9.1.1-4.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.1.1-4.3">
|
||
<p id="section-9.1.1-4.3.1">The execution sequence was maintained (no step was bypassed).<a href="#section-9.1.1-4.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.1.1-4.4">
|
||
<p id="section-9.1.1-4.4.1">A human-in-the-loop approved the final release, with independent
|
||
witness attestation.<a href="#section-9.1.1-4.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.1.1-4.5">
|
||
<p id="section-9.1.1-4.5.1">Timestamps and execution durations are recorded for each step.<a href="#section-9.1.1-4.5.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-9.1.1-5">This can contribute to compliance with:<a href="#section-9.1.1-5" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-9.1.1-6.1">
|
||
<p id="section-9.1.1-6.1.1"><span>[<a href="#FDA-21CFR11" class="cite xref">FDA-21CFR11</a>]</span> Section 11.10(e): Computer-generated audit trails
|
||
that record the date, time, and identity of the operator.<a href="#section-9.1.1-6.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.1.1-6.2">
|
||
<p id="section-9.1.1-6.2.1"><span>[<a href="#EU-MDR" class="cite xref">EU-MDR</a>]</span> Annex II: Technical documentation traceability for the
|
||
software development lifecycle.<a href="#section-9.1.1-6.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.1.1-6.3">
|
||
<p id="section-9.1.1-6.3.1"><span>[<a href="#EU-AI-ACT" class="cite xref">EU-AI-ACT</a>]</span> Article 12: Automatic logging capabilities for
|
||
high-risk AI systems involved in the development process.<a href="#section-9.1.1-6.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.1.1-6.4">
|
||
<p id="section-9.1.1-6.4.1"><span>[<a href="#EU-AI-ACT" class="cite xref">EU-AI-ACT</a>]</span> Article 14: ECTs can record evidence that human
|
||
oversight events occurred during the release process.<a href="#section-9.1.1-6.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="financial-trading-workflow">
|
||
<section id="section-9.2">
|
||
<h3 id="name-financial-trading-workflow">
|
||
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-financial-trading-workflow" class="section-name selfRef">Financial Trading Workflow</a>
|
||
</h3>
|
||
<p id="section-9.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="#section-9.2-1" class="pilcrow">¶</a></p>
|
||
<span id="name-financial-trading-workflow-2"></span><div id="fig-finance">
|
||
<figure id="figure-10">
|
||
<div class="alignLeft art-text artwork" id="section-9.2-2.1">
|
||
<pre>
|
||
Agent A (Risk Assessment):
|
||
jti: task-001 par: []
|
||
exec_act: calculate_risk_exposure
|
||
ext.pol: risk_limits_policy_v2
|
||
ext.pol_decision: approved
|
||
|
||
Agent B (Compliance):
|
||
jti: task-002 par: [task-001]
|
||
exec_act: verify_compliance
|
||
ext.pol: compliance_check_v1
|
||
ext.pol_decision: approved
|
||
|
||
Agent C (Execution):
|
||
jti: task-003 par: [task-002]
|
||
exec_act: execute_trade
|
||
ext.pol: execution_policy_v3
|
||
ext.pol_decision: approved
|
||
</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>
|
||
</figcaption></figure>
|
||
</div>
|
||
<p id="section-9.2-3">This can contribute to compliance with:<a href="#section-9.2-3" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-9.2-4.1">
|
||
<p id="section-9.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="#section-9.2-4.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.2-4.2">
|
||
<p id="section-9.2-4.2.1"><span>[<a href="#DORA" class="cite xref">DORA</a>]</span> Article 12: ECTs contribute to ICT activity logging.<a href="#section-9.2-4.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.2-4.3">
|
||
<p id="section-9.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="#section-9.2-4.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="compensation-and-rollback">
|
||
<section id="section-9.3">
|
||
<h3 id="name-compensation-and-rollback-2">
|
||
<a href="#section-9.3" class="section-number selfRef">9.3. </a><a href="#name-compensation-and-rollback-2" class="section-name selfRef">Compensation and Rollback</a>
|
||
</h3>
|
||
<p id="section-9.3-1">When a compliance violation is discovered after execution, ECTs
|
||
provide a mechanism to record authorized compensation actions with
|
||
a cryptographic link to the original task:<a href="#section-9.3-1" class="pilcrow">¶</a></p>
|
||
<span id="name-compensation-ect-example"></span><div id="fig-compensation">
|
||
<figure id="figure-11">
|
||
<div class="lang-json sourcecode" id="section-9.3-2.1">
|
||
<pre>
|
||
{
|
||
"iss": "spiffe://bank.example/agent/operations",
|
||
"aud": "spiffe://bank.example/system/ledger",
|
||
"iat": 1772150550,
|
||
"exp": 1772151150,
|
||
"jti": "550e8400-e29b-41d4-a716-446655440099",
|
||
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
|
||
"exec_act": "initiate_trade_rollback",
|
||
"par": ["550e8400-e29b-41d4-a716-446655440003"],
|
||
"ext": {
|
||
"pol": "compensation_policy_v1",
|
||
"pol_decision": "approved",
|
||
"pol_enforcer": "spiffe://bank.example/human/compliance-officer",
|
||
"compensation_required": true,
|
||
"compensation_reason": "policy_violation_in_parent_trade"
|
||
}
|
||
}
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
|
||
<a href="#name-compensation-ect-example" class="selfRef">Compensation ECT Example</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
<p id="section-9.3-3">The "par" claim links the compensation action to the original
|
||
trade, creating an auditable chain from execution through
|
||
violation discovery to remediation.<a href="#section-9.3-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="autonomous-logistics-coordination">
|
||
<section id="section-9.4">
|
||
<h3 id="name-autonomous-logistics-coordi">
|
||
<a href="#section-9.4" class="section-number selfRef">9.4. </a><a href="#name-autonomous-logistics-coordi" class="section-name selfRef">Autonomous Logistics Coordination</a>
|
||
</h3>
|
||
<p id="section-9.4-1">In a logistics workflow, multiple compliance checks complete
|
||
before shipment commitment. The DAG structure records that all
|
||
required checks were completed:<a href="#section-9.4-1" class="pilcrow">¶</a></p>
|
||
<span id="name-logistics-workflow-with-par"></span><div id="fig-logistics">
|
||
<figure id="figure-12">
|
||
<div class="alignLeft art-text artwork" id="section-9.4-2.1">
|
||
<pre>
|
||
Agent A (Route Planning):
|
||
jti: task-001 par: []
|
||
exec_act: plan_route
|
||
ext.pol: route_policy_v1
|
||
ext.pol_decision: approved
|
||
|
||
Agent B (Customs):
|
||
jti: task-002 par: [task-001]
|
||
exec_act: validate_customs
|
||
ext.pol: customs_policy_v2
|
||
ext.pol_decision: approved
|
||
|
||
Agent C (Safety):
|
||
jti: task-003 par: [task-001]
|
||
exec_act: verify_cargo_safety
|
||
ext.pol: safety_policy_v1
|
||
ext.pol_decision: approved
|
||
|
||
Agent D (Payment):
|
||
jti: task-004 par: [task-002, task-003]
|
||
exec_act: authorize_payment
|
||
ext.pol: payment_policy_v3
|
||
ext.pol_decision: approved
|
||
|
||
System (Commitment):
|
||
jti: task-005 par: [task-004]
|
||
exec_act: commit_shipment
|
||
ext.pol: commitment_policy_v1
|
||
ext.pol_decision: approved
|
||
</pre>
|
||
</div>
|
||
<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>
|
||
<p id="section-9.4-3">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.<a href="#section-9.4-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="security-considerations">
|
||
<section id="section-10">
|
||
<h2 id="name-security-considerations">
|
||
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
|
||
</h2>
|
||
<p id="section-10-1">This section addresses security considerations following the
|
||
guidance in <span>[<a href="#RFC3552" class="cite xref">RFC3552</a>]</span>.<a href="#section-10-1" class="pilcrow">¶</a></p>
|
||
<div id="threat-model">
|
||
<section id="section-10.1">
|
||
<h3 id="name-threat-model">
|
||
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-threat-model" class="section-name selfRef">Threat Model</a>
|
||
</h3>
|
||
<p id="section-10.1-1">The following threat actors are considered:<a href="#section-10.1-1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-10.1-2.1">
|
||
<p id="section-10.1-2.1.1">Malicious agent (insider threat): An agent within the trust
|
||
domain that intentionally creates false ECT claims.<a href="#section-10.1-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.1-2.2">
|
||
<p id="section-10.1-2.2.1">Compromised agent (external attacker): An agent whose private
|
||
key has been obtained by an external attacker.<a href="#section-10.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.1-2.3">
|
||
<p id="section-10.1-2.3.1">Ledger tamperer: An entity attempting to modify or delete ledger
|
||
entries after they have been recorded.<a href="#section-10.1-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.1-2.4">
|
||
<p id="section-10.1-2.4.1">Time manipulator: An entity attempting to manipulate timestamps
|
||
to alter perceived execution ordering.<a href="#section-10.1-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="self-assertion-limitation">
|
||
<section id="section-10.2">
|
||
<h3 id="name-self-assertion-limitation">
|
||
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-self-assertion-limitation" class="section-name selfRef">Self-Assertion Limitation</a>
|
||
</h3>
|
||
<p id="section-10.2-1">ECTs are self-asserted by the executing agent. The agent claims
|
||
what it did, and this claim is signed with its private key. A
|
||
compromised or malicious agent could create ECTs with false claims
|
||
(e.g., setting "pol_decision" in "ext" to "approved" without
|
||
actually evaluating the policy).<a href="#section-10.2-1" class="pilcrow">¶</a></p>
|
||
<p id="section-10.2-2">ECTs do not independently verify that:<a href="#section-10.2-2" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-10.2-3.1">
|
||
<p id="section-10.2-3.1.1">The claimed execution actually occurred as described<a href="#section-10.2-3.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.2-3.2">
|
||
<p id="section-10.2-3.2.1">The policy evaluation was correctly performed<a href="#section-10.2-3.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.2-3.3">
|
||
<p id="section-10.2-3.3.1">The input/output hashes correspond to the actual data processed<a href="#section-10.2-3.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.2-3.4">
|
||
<p id="section-10.2-3.4.1">The agent faithfully performed the stated action<a href="#section-10.2-3.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-10.2-4">The trustworthiness of ECT claims depends on the trustworthiness
|
||
of the signing agent. To mitigate single-agent false claims,
|
||
regulated environments <span class="bcp14">SHOULD</span> 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.<a href="#section-10.2-4" class="pilcrow">¶</a></p>
|
||
<p id="section-10.2-5">To strengthen witness attestation beyond self-assertion, witnesses
|
||
<span class="bcp14">SHOULD</span> 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.<a href="#section-10.2-5" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="organizational-prerequisites">
|
||
<section id="section-10.3">
|
||
<h3 id="name-organizational-prerequisite">
|
||
<a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-organizational-prerequisite" class="section-name selfRef">Organizational Prerequisites</a>
|
||
</h3>
|
||
<p id="section-10.3-1">ECTs operate within a broader trust framework. The guarantees
|
||
provided by ECTs are only meaningful when the following
|
||
organizational controls are in place:<a href="#section-10.3-1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-10.3-2.1">
|
||
<p id="section-10.3-2.1.1">Key management governance: Controls over who provisions agent
|
||
keys and how keys are protected.<a href="#section-10.3-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.3-2.2">
|
||
<p id="section-10.3-2.2.1">Ledger integrity governance: The ledger is maintained by an
|
||
entity independent of the workflow agents.<a href="#section-10.3-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.3-2.3">
|
||
<p id="section-10.3-2.3.1">Policy lifecycle management: Policy identifiers in ECTs map to
|
||
actual, validated policy rules.<a href="#section-10.3-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.3-2.4">
|
||
<p id="section-10.3-2.4.1">Agent deployment governance: Agents are deployed and maintained
|
||
in a manner that preserves their integrity.<a href="#section-10.3-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="signature-verification">
|
||
<section id="section-10.4">
|
||
<h3 id="name-signature-verification">
|
||
<a href="#section-10.4" class="section-number selfRef">10.4. </a><a href="#name-signature-verification" class="section-name selfRef">Signature Verification</a>
|
||
</h3>
|
||
<p id="section-10.4-1">ECTs <span class="bcp14">MUST</span> be signed with the agent's private key using JWS
|
||
<span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>. The signature algorithm <span class="bcp14">MUST</span> match the algorithm
|
||
specified in the agent's WIT. Receivers <span class="bcp14">MUST</span> verify the ECT
|
||
signature against the WIT public key before processing any
|
||
claims. Receivers <span class="bcp14">MUST</span> verify that the signing key has not been
|
||
revoked within the trust domain (see step 6 in
|
||
<a href="#verification" class="auto internal xref">Section 7</a>).<a href="#section-10.4-1" class="pilcrow">¶</a></p>
|
||
<p id="section-10.4-2">If signature verification fails or if the signing key has been
|
||
revoked, the ECT <span class="bcp14">MUST</span> be rejected entirely and the failure <span class="bcp14">MUST</span>
|
||
be logged.<a href="#section-10.4-2" class="pilcrow">¶</a></p>
|
||
<p id="section-10.4-3">Implementations <span class="bcp14">MUST</span> use established JWS libraries and <span class="bcp14">MUST NOT</span>
|
||
implement custom signature verification.<a href="#section-10.4-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="replay-attack-prevention">
|
||
<section id="section-10.5">
|
||
<h3 id="name-replay-attack-prevention">
|
||
<a href="#section-10.5" class="section-number selfRef">10.5. </a><a href="#name-replay-attack-prevention" class="section-name selfRef">Replay Attack Prevention</a>
|
||
</h3>
|
||
<p id="section-10.5-1">ECTs include short expiration times (<span class="bcp14">RECOMMENDED</span>: 5-15 minutes) to
|
||
limit the window for replay attacks. The "aud" claim restricts
|
||
replay to unintended recipients: an ECT intended for Agent B
|
||
will be rejected by Agent C. The "iat" claim enables receivers to
|
||
reject ECTs that are too old, even if not yet expired.<a href="#section-10.5-1" class="pilcrow">¶</a></p>
|
||
<p id="section-10.5-2">The DAG structure provides additional replay protection: an ECT
|
||
referencing parent tasks that already have a recorded child task
|
||
with the same action can be flagged as a potential replay.<a href="#section-10.5-2" class="pilcrow">¶</a></p>
|
||
<p id="section-10.5-3">Implementations <span class="bcp14">MUST</span> maintain a cache of recently-seen "jti"
|
||
values to detect replayed ECTs within the expiration window.
|
||
An ECT with a duplicate "jti" value <span class="bcp14">MUST</span> be rejected.<a href="#section-10.5-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="man-in-the-middle-protection">
|
||
<section id="section-10.6">
|
||
<h3 id="name-man-in-the-middle-protectio">
|
||
<a href="#section-10.6" class="section-number selfRef">10.6. </a><a href="#name-man-in-the-middle-protectio" class="section-name selfRef">Man-in-the-Middle Protection</a>
|
||
</h3>
|
||
<p id="section-10.6-1">ECTs do not replace transport-layer security. ECTs <span class="bcp14">MUST</span> be
|
||
transmitted over TLS or mTLS connections. When used with the WIMSE
|
||
service-to-service protocol <span>[<a href="#I-D.ietf-wimse-s2s-protocol" class="cite xref">I-D.ietf-wimse-s2s-protocol</a>]</span>,
|
||
transport security is already established. HTTP Message Signatures
|
||
<span>[<a href="#RFC9421" class="cite xref">RFC9421</a>]</span> provide an alternative channel binding mechanism.<a href="#section-10.6-1" class="pilcrow">¶</a></p>
|
||
<p id="section-10.6-2">The defense-in-depth model provides:<a href="#section-10.6-2" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-10.6-3.1">
|
||
<p id="section-10.6-3.1.1">TLS/mTLS (transport layer): Prevents network-level tampering.<a href="#section-10.6-3.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.6-3.2">
|
||
<p id="section-10.6-3.2.1">WIT/WPT (WIMSE identity layer): Proves agent identity and
|
||
request authorization.<a href="#section-10.6-3.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.6-3.3">
|
||
<p id="section-10.6-3.3.1">ECT (execution accountability layer): Records what the agent did
|
||
and under what policy.<a href="#section-10.6-3.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="key-compromise">
|
||
<section id="section-10.7">
|
||
<h3 id="name-key-compromise">
|
||
<a href="#section-10.7" class="section-number selfRef">10.7. </a><a href="#name-key-compromise" class="section-name selfRef">Key Compromise</a>
|
||
</h3>
|
||
<p id="section-10.7-1">If an agent's private key is compromised, an attacker can forge
|
||
ECTs that appear to originate from that agent. To mitigate this
|
||
risk:<a href="#section-10.7-1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-10.7-2.1">
|
||
<p id="section-10.7-2.1.1">Implementations <span class="bcp14">SHOULD</span> use short-lived keys and rotate them
|
||
frequently (hours to days, not months).<a href="#section-10.7-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.7-2.2">
|
||
<p id="section-10.7-2.2.1">Private keys <span class="bcp14">SHOULD</span> be stored in Hardware Security Modules (HSMs)
|
||
or equivalent secure key storage.<a href="#section-10.7-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.7-2.3">
|
||
<p id="section-10.7-2.3.1">Trust domains <span class="bcp14">MUST</span> support rapid key revocation.<a href="#section-10.7-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.7-2.4">
|
||
<p id="section-10.7-2.4.1">Upon suspected compromise, the trust domain <span class="bcp14">MUST</span> revoke the
|
||
compromised key and issue a new WIT with a fresh key pair.<a href="#section-10.7-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-10.7-3">ECTs signed with a compromised key that were recorded in the
|
||
ledger before revocation remain valid historical records but <span class="bcp14">SHOULD</span>
|
||
be flagged in the ledger as "signed with subsequently revoked key"
|
||
for audit purposes.<a href="#section-10.7-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="collusion-and-false-claims">
|
||
<section id="section-10.8">
|
||
<h3 id="name-collusion-and-false-claims">
|
||
<a href="#section-10.8" class="section-number selfRef">10.8. </a><a href="#name-collusion-and-false-claims" class="section-name selfRef">Collusion and False Claims</a>
|
||
</h3>
|
||
<p id="section-10.8-1">A single malicious agent cannot forge parent task references
|
||
because DAG validation requires parent tasks to exist in the
|
||
ledger. However, multiple colluding agents could potentially
|
||
create a false execution history if they control the ledger.<a href="#section-10.8-1" class="pilcrow">¶</a></p>
|
||
<p id="section-10.8-2">Mitigations include:<a href="#section-10.8-2" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-10.8-3.1">
|
||
<p id="section-10.8-3.1.1">Independent ledger maintenance: The ledger <span class="bcp14">SHOULD</span> be maintained
|
||
by an entity independent of the workflow agents.<a href="#section-10.8-3.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.8-3.2">
|
||
<p id="section-10.8-3.2.1">Witness attestation: Using the "witnessed_by" extension
|
||
key in "ext" to include independent third-party observers.<a href="#section-10.8-3.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.8-3.3">
|
||
<p id="section-10.8-3.3.1">Cross-verification: Multiple independent ledger replicas can be
|
||
compared for consistency.<a href="#section-10.8-3.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.8-3.4">
|
||
<p id="section-10.8-3.4.1">Out-of-band audit: External auditors periodically verify ledger
|
||
contents against expected workflow patterns.<a href="#section-10.8-3.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="denial-of-service">
|
||
<section id="section-10.9">
|
||
<h3 id="name-denial-of-service">
|
||
<a href="#section-10.9" class="section-number selfRef">10.9. </a><a href="#name-denial-of-service" class="section-name selfRef">Denial of Service</a>
|
||
</h3>
|
||
<p id="section-10.9-1">ECT signature verification is computationally inexpensive
|
||
(approximately 1ms per ECT on modern hardware for ES256). DAG
|
||
validation complexity is O(V) where V is the number of ancestor
|
||
nodes reachable from the parent references; for typical shallow
|
||
DAGs this is efficient.<a href="#section-10.9-1" class="pilcrow">¶</a></p>
|
||
<p id="section-10.9-2">Implementations <span class="bcp14">SHOULD</span> apply rate limiting at the API layer to
|
||
prevent excessive ECT submissions. DAG validation <span class="bcp14">SHOULD</span> be
|
||
performed after signature verification to avoid wasting resources
|
||
on unsigned or incorrectly signed tokens.<a href="#section-10.9-2" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="timestamp-accuracy">
|
||
<section id="section-10.10">
|
||
<h3 id="name-timestamp-accuracy">
|
||
<a href="#section-10.10" class="section-number selfRef">10.10. </a><a href="#name-timestamp-accuracy" class="section-name selfRef">Timestamp Accuracy</a>
|
||
</h3>
|
||
<p id="section-10.10-1">ECTs rely on timestamps ("iat", "exp") for temporal ordering.
|
||
Clock skew between agents can lead to incorrect ordering
|
||
judgments. Implementations <span class="bcp14">SHOULD</span> use synchronized time sources
|
||
(e.g., NTP) and <span class="bcp14">SHOULD</span> allow a configurable clock skew tolerance
|
||
(<span class="bcp14">RECOMMENDED</span>: 30 seconds).<a href="#section-10.10-1" class="pilcrow">¶</a></p>
|
||
<p id="section-10.10-2">Cross-organizational deployments where agents span multiple trust
|
||
domains with independent time sources <span class="bcp14">MAY</span> require a higher clock
|
||
skew tolerance. Deployments using trust domain federation <span class="bcp14">SHOULD</span>
|
||
document their configured clock skew tolerance value and <span class="bcp14">SHOULD</span>
|
||
ensure all participating trust domains agree on a common tolerance.<a href="#section-10.10-2" class="pilcrow">¶</a></p>
|
||
<p id="section-10.10-3">The temporal ordering check in DAG validation incorporates the
|
||
clock skew tolerance to account for minor clock differences
|
||
between agents.<a href="#section-10.10-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="ect-size-constraints">
|
||
<section id="section-10.11">
|
||
<h3 id="name-ect-size-constraints">
|
||
<a href="#section-10.11" class="section-number selfRef">10.11. </a><a href="#name-ect-size-constraints" class="section-name selfRef">ECT Size Constraints</a>
|
||
</h3>
|
||
<p id="section-10.11-1">ECTs with many parent tasks or large extension objects can
|
||
increase HTTP header size. Implementations <span class="bcp14">SHOULD</span> limit the "par"
|
||
array to a maximum of 256 entries. Workflows requiring more
|
||
parent references <span class="bcp14">SHOULD</span> introduce intermediate aggregation
|
||
tasks. The "ext" object <span class="bcp14">SHOULD NOT</span> exceed 4096 bytes when
|
||
serialized as JSON and <span class="bcp14">SHOULD NOT</span> exceed a nesting depth of
|
||
5 levels (see also <a href="#extension-claims" class="auto internal xref">Section 4.2.6</a>).<a href="#section-10.11-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="privacy-considerations">
|
||
<section id="section-11">
|
||
<h2 id="name-privacy-considerations">
|
||
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
|
||
</h2>
|
||
<div id="data-exposure-in-ects">
|
||
<section id="section-11.1">
|
||
<h3 id="name-data-exposure-in-ects">
|
||
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-data-exposure-in-ects" class="section-name selfRef">Data Exposure in ECTs</a>
|
||
</h3>
|
||
<p id="section-11.1-1">ECTs necessarily reveal:<a href="#section-11.1-1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-11.1-2.1">
|
||
<p id="section-11.1-2.1.1">Agent identities ("iss", "aud") for accountability purposes<a href="#section-11.1-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-11.1-2.2">
|
||
<p id="section-11.1-2.2.1">Action descriptions ("exec_act") for audit trail completeness<a href="#section-11.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-11.1-2.3">
|
||
<p id="section-11.1-2.3.1">Policy evaluation outcomes (via "ext" keys "pol",
|
||
"pol_decision") when present, for compliance verification<a href="#section-11.1-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-11.1-2.4">
|
||
<p id="section-11.1-2.4.1">Timestamps ("iat", "exp") for temporal ordering<a href="#section-11.1-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-11.1-3">ECTs are designed to NOT reveal:<a href="#section-11.1-3" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-11.1-4.1">
|
||
<p id="section-11.1-4.1.1">Actual input or output data values (replaced with cryptographic
|
||
hashes via "inp_hash" and "out_hash")<a href="#section-11.1-4.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-11.1-4.2">
|
||
<p id="section-11.1-4.2.1">Internal computation details or intermediate steps<a href="#section-11.1-4.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-11.1-4.3">
|
||
<p id="section-11.1-4.3.1">Proprietary algorithms or intellectual property<a href="#section-11.1-4.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-11.1-4.4">
|
||
<p id="section-11.1-4.4.1">Personally identifiable information (PII)<a href="#section-11.1-4.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="data-minimization">
|
||
<section id="section-11.2">
|
||
<h3 id="name-data-minimization">
|
||
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-data-minimization" class="section-name selfRef">Data Minimization</a>
|
||
</h3>
|
||
<p id="section-11.2-1">Implementations <span class="bcp14">SHOULD</span> minimize the information included in ECTs.
|
||
The "exec_act" claim <span class="bcp14">SHOULD</span> use structured identifiers (e.g.,
|
||
"process_payment") rather than natural language descriptions.
|
||
The "pol" extension key <span class="bcp14">SHOULD</span> reference policy identifiers
|
||
rather than embedding policy content.<a href="#section-11.2-1" class="pilcrow">¶</a></p>
|
||
<p id="section-11.2-2">The "compensation_reason" extension key in "ext"
|
||
(<a href="#compensation-claims" class="auto internal xref">Section 4.2.5</a>) deserves particular attention: because
|
||
it is human-readable, it risks exposing sensitive operational
|
||
details. See <a href="#extension-claims" class="auto internal xref">Section 4.2.6</a> for guidance on using
|
||
structured identifiers.<a href="#section-11.2-2" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="storage-and-access-control">
|
||
<section id="section-11.3">
|
||
<h3 id="name-storage-and-access-control">
|
||
<a href="#section-11.3" class="section-number selfRef">11.3. </a><a href="#name-storage-and-access-control" class="section-name selfRef">Storage and Access Control</a>
|
||
</h3>
|
||
<p id="section-11.3-1">ECTs stored in audit ledgers <span class="bcp14">SHOULD</span> be access-controlled so that
|
||
only authorized auditors and regulators can read them.
|
||
Implementations <span class="bcp14">SHOULD</span> consider encryption at rest for ledger
|
||
storage containing sensitive regulatory data.<a href="#section-11.3-1" class="pilcrow">¶</a></p>
|
||
<p id="section-11.3-2">Full input and output data (corresponding to the hashes in ECTs)
|
||
<span class="bcp14">SHOULD</span> 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.<a href="#section-11.3-2" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="regulatory-access">
|
||
<section id="section-11.4">
|
||
<h3 id="name-regulatory-access">
|
||
<a href="#section-11.4" class="section-number selfRef">11.4. </a><a href="#name-regulatory-access" class="section-name selfRef">Regulatory Access</a>
|
||
</h3>
|
||
<p id="section-11.4-1">ECTs are designed for interpretation by qualified human auditors
|
||
and regulators. ECTs provide structural records of execution
|
||
ordering and policy evaluation; they are not intended for public
|
||
disclosure.<a href="#section-11.4-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="iana-considerations">
|
||
<section id="section-12">
|
||
<h2 id="name-iana-considerations">
|
||
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
|
||
</h2>
|
||
<div id="media-type-registration">
|
||
<section id="section-12.1">
|
||
<h3 id="name-media-type-registration">
|
||
<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-media-type-registration" class="section-name selfRef">Media Type Registration</a>
|
||
</h3>
|
||
<p id="section-12.1-1">This document requests registration of the following media type
|
||
in the "Media Types" registry maintained by IANA:<a href="#section-12.1-1" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-12.1-2">
|
||
<dt id="section-12.1-2.1">Type name:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.1-2.2">
|
||
<p id="section-12.1-2.2.1">application<a href="#section-12.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-12.1-2.3">Subtype name:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.1-2.4">
|
||
<p id="section-12.1-2.4.1">wimse-exec+jwt<a href="#section-12.1-2.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-12.1-2.5">Required parameters:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.1-2.6">
|
||
<p id="section-12.1-2.6.1">none<a href="#section-12.1-2.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-12.1-2.7">Optional parameters:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.1-2.8">
|
||
<p id="section-12.1-2.8.1">none<a href="#section-12.1-2.8.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-12.1-2.9">Encoding considerations:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.1-2.10">
|
||
<p id="section-12.1-2.10.1">8bit; an ECT is a JWT that is a JWS using the Compact
|
||
Serialization, which is a sequence of Base64url-encoded values
|
||
separated by period characters.<a href="#section-12.1-2.10.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-12.1-2.11">Security considerations:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.1-2.12">
|
||
<p id="section-12.1-2.12.1">See the Security Considerations section of this document.<a href="#section-12.1-2.12.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-12.1-2.13">Interoperability considerations:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.1-2.14">
|
||
<p id="section-12.1-2.14.1">none<a href="#section-12.1-2.14.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-12.1-2.15">Published specification:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.1-2.16">
|
||
<p id="section-12.1-2.16.1">This document<a href="#section-12.1-2.16.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-12.1-2.17">Applications that use this media type:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.1-2.18">
|
||
<p id="section-12.1-2.18.1">Applications that implement regulated agentic workflows requiring
|
||
execution context tracing and audit trails.<a href="#section-12.1-2.18.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-12.1-2.19">Additional information:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.1-2.20">
|
||
<p id="section-12.1-2.20.1">Magic number(s): none
|
||
File extension(s): none
|
||
Macintosh file type code(s): none<a href="#section-12.1-2.20.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-12.1-2.21">Person and email address to contact for further information:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.1-2.22">
|
||
<p id="section-12.1-2.22.1">Christian Nennemann, ietf@nennemann.de<a href="#section-12.1-2.22.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-12.1-2.23">Intended usage:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.1-2.24">
|
||
<p id="section-12.1-2.24.1">COMMON<a href="#section-12.1-2.24.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-12.1-2.25">Restrictions on usage:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.1-2.26">
|
||
<p id="section-12.1-2.26.1">none<a href="#section-12.1-2.26.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-12.1-2.27">Author:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.1-2.28">
|
||
<p id="section-12.1-2.28.1">Christian Nennemann<a href="#section-12.1-2.28.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-12.1-2.29">Change controller:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.1-2.30">
|
||
<p id="section-12.1-2.30.1">IETF<a href="#section-12.1-2.30.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="header-registration">
|
||
<section id="section-12.2">
|
||
<h3 id="name-http-header-field-registrat">
|
||
<a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-http-header-field-registrat" class="section-name selfRef">HTTP Header Field Registration</a>
|
||
</h3>
|
||
<p id="section-12.2-1">This document requests registration of the following header field
|
||
in the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
|
||
maintained by IANA:<a href="#section-12.2-1" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-12.2-2">
|
||
<dt id="section-12.2-2.1">Field name:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.2-2.2">
|
||
<p id="section-12.2-2.2.1">Execution-Context<a href="#section-12.2-2.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-12.2-2.3">Status:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.2-2.4">
|
||
<p id="section-12.2-2.4.1">permanent<a href="#section-12.2-2.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-12.2-2.5">Specification document:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-12.2-2.6">
|
||
<p id="section-12.2-2.6.1">This document, <a href="#http-header" class="auto internal xref">Section 5</a><a href="#section-12.2-2.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="claims-registration">
|
||
<section id="section-12.3">
|
||
<h3 id="name-jwt-claims-registration">
|
||
<a href="#section-12.3" class="section-number selfRef">12.3. </a><a href="#name-jwt-claims-registration" class="section-name selfRef">JWT Claims Registration</a>
|
||
</h3>
|
||
<p id="section-12.3-1">This document requests registration of the following claims in
|
||
the "JSON Web Token Claims" registry maintained by IANA:<a href="#section-12.3-1" class="pilcrow">¶</a></p>
|
||
<span id="name-jwt-claims-registrations"></span><div id="_table-claims">
|
||
<table class="center" id="table-1">
|
||
<caption>
|
||
<a href="#table-1" class="selfRef">Table 1</a>:
|
||
<a href="#name-jwt-claims-registrations" class="selfRef">JWT Claims Registrations</a>
|
||
</caption>
|
||
<thead>
|
||
<tr>
|
||
<th class="text-center" rowspan="1" colspan="1">Claim Name</th>
|
||
<th class="text-left" rowspan="1" colspan="1">Claim Description</th>
|
||
<th class="text-center" rowspan="1" colspan="1">Change Controller</th>
|
||
<th class="text-center" rowspan="1" colspan="1">Reference</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="text-center" rowspan="1" colspan="1">wid</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Workflow Identifier</td>
|
||
<td class="text-center" rowspan="1" colspan="1">IETF</td>
|
||
<td class="text-center" rowspan="1" colspan="1">
|
||
<a href="#exec-claims" class="auto internal xref">Section 4.2.2</a>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="text-center" rowspan="1" colspan="1">exec_act</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Action/Task Type</td>
|
||
<td class="text-center" rowspan="1" colspan="1">IETF</td>
|
||
<td class="text-center" rowspan="1" colspan="1">
|
||
<a href="#exec-claims" class="auto internal xref">Section 4.2.2</a>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="text-center" rowspan="1" colspan="1">par</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Parent Task Identifiers</td>
|
||
<td class="text-center" rowspan="1" colspan="1">IETF</td>
|
||
<td class="text-center" rowspan="1" colspan="1">
|
||
<a href="#exec-claims" class="auto internal xref">Section 4.2.2</a>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="text-center" rowspan="1" colspan="1">inp_hash</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Input Data Hash</td>
|
||
<td class="text-center" rowspan="1" colspan="1">IETF</td>
|
||
<td class="text-center" rowspan="1" colspan="1">
|
||
<a href="#data-integrity-claims" class="auto internal xref">Section 4.2.4</a>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="text-center" rowspan="1" colspan="1">out_hash</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Output Data Hash</td>
|
||
<td class="text-center" rowspan="1" colspan="1">IETF</td>
|
||
<td class="text-center" rowspan="1" colspan="1">
|
||
<a href="#data-integrity-claims" class="auto internal xref">Section 4.2.4</a>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="text-center" rowspan="1" colspan="1">ext</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Extension Object</td>
|
||
<td class="text-center" rowspan="1" colspan="1">IETF</td>
|
||
<td class="text-center" rowspan="1" colspan="1">
|
||
<a href="#extension-claims" class="auto internal xref">Section 4.2.6</a>
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p id="section-12.3-3">Note: Policy evaluation keys ("pol", "pol_decision",
|
||
"pol_enforcer") are carried within the "ext" object as
|
||
spec-defined extension keys (<a href="#policy-claims" class="auto internal xref">Section 4.2.3</a>) and do not
|
||
require separate JWT Claims registration.<a href="#section-12.3-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="pol-decision-registry">
|
||
<section id="section-12.4">
|
||
<h3 id="name-ect-policy-decision-values-">
|
||
<a href="#section-12.4" class="section-number selfRef">12.4. </a><a href="#name-ect-policy-decision-values-" class="section-name selfRef">ECT Policy Decision Values Registry</a>
|
||
</h3>
|
||
<p id="section-12.4-1">This document establishes the "ECT Policy Decision Values"
|
||
registry under the "JSON Web Token (JWT)" group. Registration
|
||
policy is Specification Required per <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>.<a href="#section-12.4-1" class="pilcrow">¶</a></p>
|
||
<p id="section-12.4-2">The initial contents of the registry are:<a href="#section-12.4-2" class="pilcrow">¶</a></p>
|
||
<span id="name-ect-policy-decision-values"></span><div id="_table-pol-decision">
|
||
<table class="center" id="table-2">
|
||
<caption>
|
||
<a href="#table-2" class="selfRef">Table 2</a>:
|
||
<a href="#name-ect-policy-decision-values" class="selfRef">ECT Policy Decision Values</a>
|
||
</caption>
|
||
<thead>
|
||
<tr>
|
||
<th class="text-center" rowspan="1" colspan="1">Value</th>
|
||
<th class="text-left" rowspan="1" colspan="1">Description</th>
|
||
<th class="text-center" rowspan="1" colspan="1">Change Controller</th>
|
||
<th class="text-center" rowspan="1" colspan="1">Reference</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="text-center" rowspan="1" colspan="1">approved</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Policy evaluation succeeded</td>
|
||
<td class="text-center" rowspan="1" colspan="1">IETF</td>
|
||
<td class="text-center" rowspan="1" colspan="1">
|
||
<a href="#policy-claims" class="auto internal xref">Section 4.2.3</a>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="text-center" rowspan="1" colspan="1">rejected</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Policy evaluation failed</td>
|
||
<td class="text-center" rowspan="1" colspan="1">IETF</td>
|
||
<td class="text-center" rowspan="1" colspan="1">
|
||
<a href="#policy-claims" class="auto internal xref">Section 4.2.3</a>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="text-center" rowspan="1" colspan="1">pending_human_review</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Awaiting human judgment</td>
|
||
<td class="text-center" rowspan="1" colspan="1">IETF</td>
|
||
<td class="text-center" rowspan="1" colspan="1">
|
||
<a href="#policy-claims" class="auto internal xref">Section 4.2.3</a>
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="sec-combined-references">
|
||
<section id="section-13">
|
||
<h2 id="name-references">
|
||
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-references" class="section-name selfRef">References</a>
|
||
</h2>
|
||
<div id="sec-normative-references">
|
||
<section id="section-13.1">
|
||
<h3 id="name-normative-references">
|
||
<a href="#section-13.1" class="section-number selfRef">13.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
|
||
</h3>
|
||
<dl class="references">
|
||
<dt id="I-D.ietf-wimse-arch">[I-D.ietf-wimse-arch]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Salowey, J. A.</span>, <span class="refAuthor">Rosomakho, Y.</span>, and <span class="refAuthor">H. Tschofenig</span>, <span class="refTitle">"Workload Identity in a Multi System Environment (WIMSE) Architecture"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-wimse-arch-06</span>, <time datetime="2025-09-30" class="refDate">30 September 2025</time>, <span><<a href="https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-06">https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-06</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="I-D.ietf-wimse-s2s-protocol">[I-D.ietf-wimse-s2s-protocol]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Campbell, B.</span>, <span class="refAuthor">Salowey, J. A.</span>, <span class="refAuthor">Schwenkschuster, A.</span>, and <span class="refAuthor">Y. Sheffer</span>, <span class="refTitle">"WIMSE Workload-to-Workload Authentication"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-wimse-s2s-protocol-07</span>, <time datetime="2025-10-16" class="refDate">16 October 2025</time>, <span><<a href="https://datatracker.ietf.org/doc/html/draft-ietf-wimse-s2s-protocol-07">https://datatracker.ietf.org/doc/html/draft-ietf-wimse-s2s-protocol-07</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="RFC2119">[RFC2119]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc2119">https://www.rfc-editor.org/rfc/rfc2119</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="RFC7515">[RFC7515]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">N. Sakimura</span>, <span class="refTitle">"JSON Web Signature (JWS)"</span>, <span class="seriesInfo">RFC 7515</span>, <span class="seriesInfo">DOI 10.17487/RFC7515</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc7515">https://www.rfc-editor.org/rfc/rfc7515</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="RFC7517">[RFC7517]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Jones, M.</span>, <span class="refTitle">"JSON Web Key (JWK)"</span>, <span class="seriesInfo">RFC 7517</span>, <span class="seriesInfo">DOI 10.17487/RFC7517</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc7517">https://www.rfc-editor.org/rfc/rfc7517</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="RFC7518">[RFC7518]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Jones, M.</span>, <span class="refTitle">"JSON Web Algorithms (JWA)"</span>, <span class="seriesInfo">RFC 7518</span>, <span class="seriesInfo">DOI 10.17487/RFC7518</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc7518">https://www.rfc-editor.org/rfc/rfc7518</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="RFC7519">[RFC7519]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">N. Sakimura</span>, <span class="refTitle">"JSON Web Token (JWT)"</span>, <span class="seriesInfo">RFC 7519</span>, <span class="seriesInfo">DOI 10.17487/RFC7519</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc7519">https://www.rfc-editor.org/rfc/rfc7519</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="RFC8126">[RFC8126]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc8126">https://www.rfc-editor.org/rfc/rfc8126</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="RFC8174">[RFC8174]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc8174">https://www.rfc-editor.org/rfc/rfc8174</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="RFC9110">[RFC9110]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Fielding, R., Ed.</span>, <span class="refAuthor">Nottingham, M., Ed.</span>, and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"HTTP Semantics"</span>, <span class="seriesInfo">STD 97</span>, <span class="seriesInfo">RFC 9110</span>, <span class="seriesInfo">DOI 10.17487/RFC9110</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc9110">https://www.rfc-editor.org/rfc/rfc9110</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="RFC9562">[RFC9562]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Davis, K.</span>, <span class="refAuthor">Peabody, B.</span>, and <span class="refAuthor">P. Leach</span>, <span class="refTitle">"Universally Unique IDentifiers (UUIDs)"</span>, <span class="seriesInfo">RFC 9562</span>, <span class="seriesInfo">DOI 10.17487/RFC9562</span>, <time datetime="2024-05" class="refDate">May 2024</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc9562">https://www.rfc-editor.org/rfc/rfc9562</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="sec-informative-references">
|
||
<section id="section-13.2">
|
||
<h3 id="name-informative-references">
|
||
<a href="#section-13.2" class="section-number selfRef">13.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
|
||
</h3>
|
||
<dl class="references">
|
||
<dt id="DORA">[DORA]</dt>
|
||
<dd>
|
||
<span class="refAuthor">European Parliament and Council of the European Union</span>, <span class="refTitle">"Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)"</span>, <time datetime="2022-12-14" class="refDate">14 December 2022</time>, <span><<a href="https://eur-lex.europa.eu/eli/reg/2022/2554">https://eur-lex.europa.eu/eli/reg/2022/2554</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="EU-AI-ACT">[EU-AI-ACT]</dt>
|
||
<dd>
|
||
<span class="refAuthor">European Parliament and Council of the European Union</span>, <span class="refTitle">"Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)"</span>, <time datetime="2024-06-13" class="refDate">13 June 2024</time>, <span><<a href="https://eur-lex.europa.eu/eli/reg/2024/1689">https://eur-lex.europa.eu/eli/reg/2024/1689</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="EU-MDR">[EU-MDR]</dt>
|
||
<dd>
|
||
<span class="refAuthor">European Parliament and Council of the European Union</span>, <span class="refTitle">"Regulation (EU) 2017/745 on medical devices (MDR)"</span>, <time datetime="2017-04-05" class="refDate">5 April 2017</time>, <span><<a href="https://eur-lex.europa.eu/eli/reg/2017/745">https://eur-lex.europa.eu/eli/reg/2017/745</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="FDA-21CFR11">[FDA-21CFR11]</dt>
|
||
<dd>
|
||
<span class="refAuthor">U.S. Food and Drug Administration</span>, <span class="refTitle">"Title 21, Code of Federal Regulations, Part 11: Electronic Records; Electronic Signatures"</span>, <span><<a href="https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11">https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="I-D.ietf-oauth-transaction-tokens">[I-D.ietf-oauth-transaction-tokens]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Tulshibagwale, A.</span>, <span class="refAuthor">Fletcher, G.</span>, and <span class="refAuthor">P. Kasselman</span>, <span class="refTitle">"Transaction Tokens"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-oauth-transaction-tokens-07</span>, <time datetime="2026-01-24" class="refDate">24 January 2026</time>, <span><<a href="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-07">https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-07</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="I-D.ietf-scitt-architecture">[I-D.ietf-scitt-architecture]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Birkholz, H.</span>, <span class="refAuthor">Delignat-Lavaud, A.</span>, <span class="refAuthor">Fournet, C.</span>, <span class="refAuthor">Deshpande, Y.</span>, and <span class="refAuthor">S. Lasker</span>, <span class="refTitle">"An Architecture for Trustworthy and Transparent Digital Supply Chains"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-scitt-architecture-22</span>, <time datetime="2025-10-10" class="refDate">10 October 2025</time>, <span><<a href="https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-22">https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-22</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="I-D.ni-wimse-ai-agent-identity">[I-D.ni-wimse-ai-agent-identity]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Yuan, N.</span> and <span class="refAuthor">P. C. Liu</span>, <span class="refTitle">"WIMSE Applicability for AI Agents"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ni-wimse-ai-agent-identity-01</span>, <time datetime="2025-10-20" class="refDate">20 October 2025</time>, <span><<a href="https://datatracker.ietf.org/doc/html/draft-ni-wimse-ai-agent-identity-01">https://datatracker.ietf.org/doc/html/draft-ni-wimse-ai-agent-identity-01</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="I-D.oauth-transaction-tokens-for-agents">[I-D.oauth-transaction-tokens-for-agents]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Raut, A.</span>, <span class="refTitle">"Transaction Tokens For Agents"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-oauth-transaction-tokens-for-agents-04</span>, <time datetime="2026-02-10" class="refDate">10 February 2026</time>, <span><<a href="https://datatracker.ietf.org/doc/html/draft-oauth-transaction-tokens-for-agents-04">https://datatracker.ietf.org/doc/html/draft-oauth-transaction-tokens-for-agents-04</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="MIFID-II">[MIFID-II]</dt>
|
||
<dd>
|
||
<span class="refAuthor">European Parliament and Council of the European Union</span>, <span class="refTitle">"Directive 2014/65/EU of the European Parliament and of the Council on markets in financial instruments (MiFID II)"</span>, <time datetime="2014-05-15" class="refDate">15 May 2014</time>, <span><<a href="https://eur-lex.europa.eu/eli/dir/2014/65">https://eur-lex.europa.eu/eli/dir/2014/65</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="OPENTELEMETRY">[OPENTELEMETRY]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Cloud Native Computing Foundation</span>, <span class="refTitle">"OpenTelemetry Specification"</span>, <span><<a href="https://opentelemetry.io/docs/specs/otel/">https://opentelemetry.io/docs/specs/otel/</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="RFC3552">[RFC3552]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Rescorla, E.</span> and <span class="refAuthor">B. Korver</span>, <span class="refTitle">"Guidelines for Writing RFC Text on Security Considerations"</span>, <span class="seriesInfo">BCP 72</span>, <span class="seriesInfo">RFC 3552</span>, <span class="seriesInfo">DOI 10.17487/RFC3552</span>, <time datetime="2003-07" class="refDate">July 2003</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc3552">https://www.rfc-editor.org/rfc/rfc3552</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="RFC8693">[RFC8693]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Nadalin, A.</span>, <span class="refAuthor">Campbell, B., Ed.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">C. Mortimore</span>, <span class="refTitle">"OAuth 2.0 Token Exchange"</span>, <span class="seriesInfo">RFC 8693</span>, <span class="seriesInfo">DOI 10.17487/RFC8693</span>, <time datetime="2020-01" class="refDate">January 2020</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc8693">https://www.rfc-editor.org/rfc/rfc8693</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="RFC9421">[RFC9421]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Backman, A., Ed.</span>, <span class="refAuthor">Richer, J., Ed.</span>, and <span class="refAuthor">M. Sporny</span>, <span class="refTitle">"HTTP Message Signatures"</span>, <span class="seriesInfo">RFC 9421</span>, <span class="seriesInfo">DOI 10.17487/RFC9421</span>, <time datetime="2024-02" class="refDate">February 2024</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc9421">https://www.rfc-editor.org/rfc/rfc9421</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="SPIFFE">[SPIFFE]</dt>
|
||
<dd>
|
||
<span class="refTitle">"Secure Production Identity Framework for Everyone (SPIFFE)"</span>, <span><<a href="https://spiffe.io/docs/latest/spiffe-about/overview/">https://spiffe.io/docs/latest/spiffe-about/overview/</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="related-work">
|
||
<section id="appendix-A">
|
||
<h2 id="name-related-work">
|
||
<a href="#name-related-work" class="section-name selfRef">Related Work</a>
|
||
</h2>
|
||
<div id="wimse-workload-identity">
|
||
<section id="appendix-A.1">
|
||
<h3 id="name-wimse-workload-identity">
|
||
<a href="#name-wimse-workload-identity" class="section-name selfRef">WIMSE Workload Identity</a>
|
||
</h3>
|
||
<p id="appendix-A.1-1">The WIMSE architecture <span>[<a href="#I-D.ietf-wimse-arch" class="cite xref">I-D.ietf-wimse-arch</a>]</span> and service-to-
|
||
service protocol <span>[<a href="#I-D.ietf-wimse-s2s-protocol" class="cite xref">I-D.ietf-wimse-s2s-protocol</a>]</span> provide the
|
||
identity foundation upon which ECTs are built. WIT/WPT answer
|
||
"who is this agent?" and "does it control the claimed key?" while
|
||
ECTs record "what did this agent do?" and "what policy was
|
||
evaluated?" Together they form an identity-plus-accountability
|
||
framework for regulated agentic systems.<a href="#appendix-A.1-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="oauth-20-token-exchange-and-the-act-claim">
|
||
<section id="appendix-A.2">
|
||
<h3 id="name-oauth-20-token-exchange-and">
|
||
<a href="#name-oauth-20-token-exchange-and" class="section-name selfRef">OAuth 2.0 Token Exchange and the "act" Claim</a>
|
||
</h3>
|
||
<p id="appendix-A.2-1"><span>[<a href="#RFC8693" class="cite xref">RFC8693</a>]</span> defines the OAuth 2.0 Token Exchange protocol and
|
||
registers the "act" (Actor) claim in the JWT Claims registry.
|
||
The "act" claim creates nested JSON objects representing a
|
||
delegation chain: "who is acting on behalf of whom." While
|
||
the nesting superficially resembles a chain, it is strictly
|
||
linear (each "act" object contains at most one nested "act"),
|
||
represents authorization delegation rather than task execution,
|
||
and carries no task identifiers, policy decisions, or
|
||
input/output integrity data. The "act" chain cannot represent
|
||
branching (fan-out) or convergence (fan-in) and therefore
|
||
cannot form a DAG.<a href="#appendix-A.2-1" class="pilcrow">¶</a></p>
|
||
<p id="appendix-A.2-2">ECTs intentionally use the distinct claim name "exec_act" for the
|
||
action/task type to avoid collision with the "act" claim. The
|
||
two concepts are orthogonal: "act" records "who authorized whom,"
|
||
ECTs record "what was done, in what order, with what policy
|
||
outcomes."<a href="#appendix-A.2-2" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="transaction-tokens">
|
||
<section id="appendix-A.3">
|
||
<h3 id="name-transaction-tokens">
|
||
<a href="#name-transaction-tokens" class="section-name selfRef">Transaction Tokens</a>
|
||
</h3>
|
||
<p id="appendix-A.3-1">OAuth Transaction Tokens <span>[<a href="#I-D.ietf-oauth-transaction-tokens" class="cite xref">I-D.ietf-oauth-transaction-tokens</a>]</span>
|
||
propagate authorization context across workload call chains.
|
||
The Txn-Token "req_wl" claim accumulates a comma-separated list
|
||
of workloads that requested replacement tokens, which is the
|
||
closest existing mechanism to call-chain recording.<a href="#appendix-A.3-1" class="pilcrow">¶</a></p>
|
||
<p id="appendix-A.3-2">However, "req_wl" cannot form a DAG because:<a href="#appendix-A.3-2" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="appendix-A.3-3.1">
|
||
<p id="appendix-A.3-3.1.1">It is linear: a comma-separated string with no branching or
|
||
merging representation. When a workload fans out to multiple
|
||
downstream services, each receives the same "req_wl" value and
|
||
the branching is invisible.<a href="#appendix-A.3-3.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="appendix-A.3-3.2">
|
||
<p id="appendix-A.3-3.2.1">It is incomplete: only workloads that request a replacement
|
||
token from the Transaction Token Service appear in "req_wl";
|
||
workloads that forward the token unchanged are not recorded.<a href="#appendix-A.3-3.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="appendix-A.3-3.3">
|
||
<p id="appendix-A.3-3.3.1">It carries no task-level granularity, no parent references,
|
||
no policy evaluation outcomes, and no execution content.<a href="#appendix-A.3-3.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="appendix-A.3-4">Extensions for agentic use cases
|
||
(<span>[<a href="#I-D.oauth-transaction-tokens-for-agents" class="cite xref">I-D.oauth-transaction-tokens-for-agents</a>]</span>) add agent
|
||
identity and constraints ("agentic_ctx") but no execution
|
||
ordering or DAG structure.<a href="#appendix-A.3-4" class="pilcrow">¶</a></p>
|
||
<p id="appendix-A.3-5">ECTs and Transaction Tokens are complementary: a Txn-Token
|
||
propagates authorization context ("this request is authorized
|
||
for scope X on behalf of user Y"), while an ECT records
|
||
execution accountability ("task T was performed, depending on
|
||
tasks P1 and P2, with policy Z evaluated and approved"). An
|
||
agent request could carry both a Txn-Token for authorization
|
||
and an ECT for execution recording. The WPT "tth" claim
|
||
defined in <span>[<a href="#I-D.ietf-wimse-s2s-protocol" class="cite xref">I-D.ietf-wimse-s2s-protocol</a>]</span> can hash-bind a
|
||
WPT to a co-present Txn-Token; a similar binding mechanism
|
||
for ECTs is a potential future extension.<a href="#appendix-A.3-5" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="distributed-tracing-opentelemetry">
|
||
<section id="appendix-A.4">
|
||
<h3 id="name-distributed-tracing-opentel">
|
||
<a href="#name-distributed-tracing-opentel" class="section-name selfRef">Distributed Tracing (OpenTelemetry)</a>
|
||
</h3>
|
||
<p id="appendix-A.4-1">OpenTelemetry <span>[<a href="#OPENTELEMETRY" class="cite xref">OPENTELEMETRY</a>]</span> and similar distributed tracing
|
||
systems provide observability for debugging and monitoring. ECTs
|
||
differ in several important ways: ECTs are cryptographically
|
||
signed per-task with the agent's private key; ECTs are
|
||
tamper-evident through JWS signatures; ECTs enforce DAG validation
|
||
rules; and ECTs are designed for regulatory audit rather than
|
||
operational monitoring. OpenTelemetry data is typically controlled
|
||
by the platform operator and can be modified or deleted without
|
||
detection. ECTs and distributed traces are complementary: traces
|
||
provide observability while ECTs provide signed execution records.
|
||
ECTs may reference OpenTelemetry trace identifiers in the "ext"
|
||
claim for correlation.<a href="#appendix-A.4-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="blockchain-and-distributed-ledgers">
|
||
<section id="appendix-A.5">
|
||
<h3 id="name-blockchain-and-distributed-">
|
||
<a href="#name-blockchain-and-distributed-" class="section-name selfRef">Blockchain and Distributed Ledgers</a>
|
||
</h3>
|
||
<p id="appendix-A.5-1">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 <a href="#ledger-interface" class="auto internal xref">Section 8</a>.<a href="#appendix-A.5-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="scitt-supply-chain-integrity-transparency-and-trust">
|
||
<section id="appendix-A.6">
|
||
<h3 id="name-scitt-supply-chain-integrit">
|
||
<a href="#name-scitt-supply-chain-integrit" class="section-name selfRef">SCITT (Supply Chain Integrity, Transparency, and Trust)</a>
|
||
</h3>
|
||
<p id="appendix-A.6-1">The SCITT architecture <span>[<a href="#I-D.ietf-scitt-architecture" class="cite xref">I-D.ietf-scitt-architecture</a>]</span> defines a
|
||
framework for creating transparent and auditable supply chain
|
||
records through Transparency Services, Signed Statements, and
|
||
Receipts. ECTs and SCITT are naturally complementary: the ECT
|
||
"wid" (Workflow Identifier) claim can serve as a correlation
|
||
identifier referenced in SCITT Signed Statements, linking a
|
||
complete ECT audit trail to a supply chain transparency record.
|
||
For example, in a regulated manufacturing workflow, each agent
|
||
step produces an ECT (recording what was done, by whom, under
|
||
what policy), while the overall workflow identified by "wid" is
|
||
registered as a SCITT Signed Statement on a Transparency Service.
|
||
This enables auditors to verify both the individual execution
|
||
steps (via ECT DAG validation) and the end-to-end supply chain
|
||
integrity (via SCITT Receipts) using the "wid" as the shared
|
||
correlation point. The "ext" claim in ECTs (<a href="#exec-claims" class="auto internal xref">Section 4.2.2</a>)
|
||
can carry SCITT-specific metadata such as Transparency Service
|
||
identifiers or Receipt references for tighter integration.<a href="#appendix-A.6-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="w3c-verifiable-credentials">
|
||
<section id="appendix-A.7">
|
||
<h3 id="name-w3c-verifiable-credentials">
|
||
<a href="#name-w3c-verifiable-credentials" class="section-name selfRef">W3C Verifiable Credentials</a>
|
||
</h3>
|
||
<p id="appendix-A.7-1">W3C Verifiable Credentials represent claims about subjects (e.g.,
|
||
identity, qualifications). ECTs represent execution records of
|
||
actions (what happened, in what order, under what policy). While
|
||
both use JWT/JWS as a serialization format, their semantics and
|
||
use cases are distinct.<a href="#appendix-A.7-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="implementation-guidance">
|
||
<section id="appendix-B">
|
||
<h2 id="name-implementation-guidance">
|
||
<a href="#name-implementation-guidance" class="section-name selfRef">Implementation Guidance</a>
|
||
</h2>
|
||
<div id="minimal-implementation">
|
||
<section id="appendix-B.1">
|
||
<h3 id="name-minimal-implementation">
|
||
<a href="#name-minimal-implementation" class="section-name selfRef">Minimal Implementation</a>
|
||
</h3>
|
||
<p id="appendix-B.1-1">A minimal conforming implementation needs to:<a href="#appendix-B.1-1" class="pilcrow">¶</a></p>
|
||
<ol start="1" type="1" class="normal type-1" id="appendix-B.1-2">
|
||
<li id="appendix-B.1-2.1">
|
||
<p id="appendix-B.1-2.1.1">Create JWTs with all required claims ("iss", "aud", "iat",
|
||
"exp", "jti", "exec_act", "par") and policy extension keys
|
||
("ext.pol", "ext.pol_decision") when policy evaluation was
|
||
performed.<a href="#appendix-B.1-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="appendix-B.1-2.2">
|
||
<p id="appendix-B.1-2.2.1">Sign ECTs with the agent's private key using an algorithm
|
||
matching the WIT (ES256 recommended).<a href="#appendix-B.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="appendix-B.1-2.3">
|
||
<p id="appendix-B.1-2.3.1">Verify ECT signatures against WIT public keys.<a href="#appendix-B.1-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="appendix-B.1-2.4">
|
||
<p id="appendix-B.1-2.4.1">Perform DAG validation (parent existence, temporal ordering,
|
||
cycle detection).<a href="#appendix-B.1-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="appendix-B.1-2.5">
|
||
<p id="appendix-B.1-2.5.1">If an audit ledger is deployed, append verified ECTs to it.<a href="#appendix-B.1-2.5.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ol>
|
||
</section>
|
||
</div>
|
||
<div id="storage-recommendations">
|
||
<section id="appendix-B.2">
|
||
<h3 id="name-storage-recommendations">
|
||
<a href="#name-storage-recommendations" class="section-name selfRef">Storage Recommendations</a>
|
||
</h3>
|
||
<ul class="normal">
|
||
<li class="normal" id="appendix-B.2-1.1">
|
||
<p id="appendix-B.2-1.1.1">Append-only log: Simplest approach; immutability by design.<a href="#appendix-B.2-1.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="appendix-B.2-1.2">
|
||
<p id="appendix-B.2-1.2.1">Database with hash chains: Periodic cryptographic commitments
|
||
over batches of entries.<a href="#appendix-B.2-1.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="appendix-B.2-1.3">
|
||
<p id="appendix-B.2-1.3.1">Distributed ledger: Maximum immutability guarantees for
|
||
cross-organizational audit.<a href="#appendix-B.2-1.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="appendix-B.2-1.4">
|
||
<p id="appendix-B.2-1.4.1">Hybrid: Hot storage in a database, cold archive in immutable
|
||
storage.<a href="#appendix-B.2-1.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="performance-considerations">
|
||
<section id="appendix-B.3">
|
||
<h3 id="name-performance-considerations">
|
||
<a href="#name-performance-considerations" class="section-name selfRef">Performance Considerations</a>
|
||
</h3>
|
||
<ul class="normal">
|
||
<li class="normal" id="appendix-B.3-1.1">
|
||
<p id="appendix-B.3-1.1.1">ES256 signature verification: approximately 1ms per ECT on
|
||
modern hardware.<a href="#appendix-B.3-1.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="appendix-B.3-1.2">
|
||
<p id="appendix-B.3-1.2.1">DAG validation: O(V) where V is the number of reachable ancestor
|
||
nodes (typically small for shallow workflows).<a href="#appendix-B.3-1.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="appendix-B.3-1.3">
|
||
<p id="appendix-B.3-1.3.1">JSON serialization: sub-millisecond per ECT.<a href="#appendix-B.3-1.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="appendix-B.3-1.4">
|
||
<p id="appendix-B.3-1.4.1">Total per-request overhead: approximately 5-10ms, acceptable
|
||
for regulated workflows where correctness is prioritized over
|
||
latency.<a href="#appendix-B.3-1.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="interoperability">
|
||
<section id="appendix-B.4">
|
||
<h3 id="name-interoperability">
|
||
<a href="#name-interoperability" class="section-name selfRef">Interoperability</a>
|
||
</h3>
|
||
<p id="appendix-B.4-1">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.<a href="#appendix-B.4-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="regulatory-compliance-mapping">
|
||
<section id="appendix-C">
|
||
<h2 id="name-regulatory-compliance-mappi">
|
||
<a href="#name-regulatory-compliance-mappi" class="section-name selfRef">Regulatory Compliance Mapping</a>
|
||
</h2>
|
||
<p id="appendix-C-1">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.<a href="#appendix-C-1" class="pilcrow">¶</a></p>
|
||
<span id="name-regulatory-compliance-mappin"></span><div id="_table-regulatory">
|
||
<table class="center" id="table-3">
|
||
<caption>
|
||
<a href="#table-3" class="selfRef">Table 3</a>:
|
||
<a href="#name-regulatory-compliance-mappin" class="selfRef">Regulatory Compliance Mapping</a>
|
||
</caption>
|
||
<thead>
|
||
<tr>
|
||
<th class="text-left" rowspan="1" colspan="1">Regulation</th>
|
||
<th class="text-left" rowspan="1" colspan="1">Requirement</th>
|
||
<th class="text-left" rowspan="1" colspan="1">ECT Contribution</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="text-left" rowspan="1" colspan="1">FDA 21 CFR Part 11</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Audit trails recording date, time, operator, actions (11.10(e))</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Cryptographic signatures and append-only ledger contribute to audit trail requirements</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="text-left" rowspan="1" colspan="1">EU MDR</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Technical documentation traceability (Annex II)</td>
|
||
<td class="text-left" rowspan="1" colspan="1">ECTs provide signed records of AI-assisted decision sequences</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="text-left" rowspan="1" colspan="1">EU AI Act Art. 12</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Automatic logging capabilities for high-risk AI</td>
|
||
<td class="text-left" rowspan="1" colspan="1">ECTs contribute cryptographic activity logging</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="text-left" rowspan="1" colspan="1">EU AI Act Art. 14</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Human oversight capability</td>
|
||
<td class="text-left" rowspan="1" colspan="1">ECTs can record evidence that human oversight events occurred</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="text-left" rowspan="1" colspan="1">MiFID II</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Transaction records for supervisory authorities</td>
|
||
<td class="text-left" rowspan="1" colspan="1">ECTs provide cryptographic execution sequence records</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="text-left" rowspan="1" colspan="1">DORA Art. 12</td>
|
||
<td class="text-left" rowspan="1" colspan="1">ICT activity logging policies</td>
|
||
<td class="text-left" rowspan="1" colspan="1">ECT ledger contributes to ICT activity audit trail</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="examples">
|
||
<section id="appendix-D">
|
||
<h2 id="name-examples">
|
||
<a href="#name-examples" class="section-name selfRef">Examples</a>
|
||
</h2>
|
||
<div id="example-1-simple-two-agent-workflow">
|
||
<section id="appendix-D.1">
|
||
<h3 id="name-example-1-simple-two-agent-">
|
||
<a href="#name-example-1-simple-two-agent-" class="section-name selfRef">Example 1: Simple Two-Agent Workflow</a>
|
||
</h3>
|
||
<p id="appendix-D.1-1">Agent A executes a data retrieval task and sends the ECT to
|
||
Agent B:<a href="#appendix-D.1-1" class="pilcrow">¶</a></p>
|
||
<p id="appendix-D.1-2">ECT JOSE Header:<a href="#appendix-D.1-2" class="pilcrow">¶</a></p>
|
||
<div class="lang-json sourcecode" id="appendix-D.1-3">
|
||
<pre>
|
||
{
|
||
"alg": "ES256",
|
||
"typ": "wimse-exec+jwt",
|
||
"kid": "agent-a-key-2026-02"
|
||
}
|
||
</pre><a href="#appendix-D.1-3" class="pilcrow">¶</a>
|
||
</div>
|
||
<p id="appendix-D.1-4">ECT Payload:<a href="#appendix-D.1-4" class="pilcrow">¶</a></p>
|
||
<div class="lang-json sourcecode" id="appendix-D.1-5">
|
||
<pre>
|
||
{
|
||
"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",
|
||
"ext": {
|
||
"pol": "clinical_data_access_policy_v1",
|
||
"pol_decision": "approved"
|
||
}
|
||
}
|
||
</pre><a href="#appendix-D.1-5" class="pilcrow">¶</a>
|
||
</div>
|
||
<p id="appendix-D.1-6">Agent B receives the ECT, verifies it, executes a validation
|
||
task, and creates its own ECT:<a href="#appendix-D.1-6" class="pilcrow">¶</a></p>
|
||
<div class="lang-json sourcecode" id="appendix-D.1-7">
|
||
<pre>
|
||
{
|
||
"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"],
|
||
"ext": {
|
||
"pol": "safety_validation_policy_v2",
|
||
"pol_decision": "approved"
|
||
}
|
||
}
|
||
</pre><a href="#appendix-D.1-7" class="pilcrow">¶</a>
|
||
</div>
|
||
<p id="appendix-D.1-8">The resulting DAG:<a href="#appendix-D.1-8" class="pilcrow">¶</a></p>
|
||
<div class="alignLeft art-text artwork" id="appendix-D.1-9">
|
||
<pre>
|
||
task-...-0001 (fetch_patient_data)
|
||
|
|
||
v
|
||
task-...-0002 (validate_safety)
|
||
</pre><a href="#appendix-D.1-9" class="pilcrow">¶</a>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="example-2-medical-device-sdlc-with-release-approval">
|
||
<section id="appendix-D.2">
|
||
<h3 id="name-example-2-medical-device-sd">
|
||
<a href="#name-example-2-medical-device-sd" class="section-name selfRef">Example 2: Medical Device SDLC with Release Approval</a>
|
||
</h3>
|
||
<p id="appendix-D.2-1">A multi-step medical device software lifecycle workflow with
|
||
autonomous agents and human release approval:<a href="#appendix-D.2-1" class="pilcrow">¶</a></p>
|
||
<p id="appendix-D.2-2">Task 1 (Spec Review Agent):<a href="#appendix-D.2-2" class="pilcrow">¶</a></p>
|
||
<div class="lang-json sourcecode" id="appendix-D.2-3">
|
||
<pre>
|
||
{
|
||
"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",
|
||
"ext": {
|
||
"pol": "spec_review_policy_v2",
|
||
"pol_decision": "approved"
|
||
}
|
||
}
|
||
</pre><a href="#appendix-D.2-3" class="pilcrow">¶</a>
|
||
</div>
|
||
<p id="appendix-D.2-4">Task 2 (Code Generation Agent):<a href="#appendix-D.2-4" class="pilcrow">¶</a></p>
|
||
<div class="lang-json sourcecode" id="appendix-D.2-5">
|
||
<pre>
|
||
{
|
||
"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"],
|
||
"ext": {
|
||
"pol": "coding_standards_v3",
|
||
"pol_decision": "approved"
|
||
}
|
||
}
|
||
</pre><a href="#appendix-D.2-5" class="pilcrow">¶</a>
|
||
</div>
|
||
<p id="appendix-D.2-6">Task 3 (Autonomous Test Agent):<a href="#appendix-D.2-6" class="pilcrow">¶</a></p>
|
||
<div class="lang-json sourcecode" id="appendix-D.2-7">
|
||
<pre>
|
||
{
|
||
"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"],
|
||
"ext": {
|
||
"pol": "test_coverage_policy_v1",
|
||
"pol_decision": "approved"
|
||
}
|
||
}
|
||
</pre><a href="#appendix-D.2-7" class="pilcrow">¶</a>
|
||
</div>
|
||
<p id="appendix-D.2-8">Task 4 (Build Agent):<a href="#appendix-D.2-8" class="pilcrow">¶</a></p>
|
||
<div class="lang-json sourcecode" id="appendix-D.2-9">
|
||
<pre>
|
||
{
|
||
"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",
|
||
"ext": {
|
||
"pol": "build_validation_v2",
|
||
"pol_decision": "approved"
|
||
}
|
||
}
|
||
</pre><a href="#appendix-D.2-9" class="pilcrow">¶</a>
|
||
</div>
|
||
<p id="appendix-D.2-10">Task 5 (Human Release Manager Approval):<a href="#appendix-D.2-10" class="pilcrow">¶</a></p>
|
||
<div class="lang-json sourcecode" id="appendix-D.2-11">
|
||
<pre>
|
||
{
|
||
"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": {
|
||
"pol": "release_approval_policy",
|
||
"pol_decision": "approved",
|
||
"pol_enforcer": "spiffe://meddev.example/human/release-mgr-42",
|
||
"witnessed_by": [
|
||
"spiffe://meddev.example/audit/qa-observer-1"
|
||
]
|
||
}
|
||
}
|
||
</pre><a href="#appendix-D.2-11" class="pilcrow">¶</a>
|
||
</div>
|
||
<p id="appendix-D.2-12">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.<a href="#appendix-D.2-12" class="pilcrow">¶</a></p>
|
||
<div class="alignLeft art-text artwork" id="appendix-D.2-13">
|
||
<pre>
|
||
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]
|
||
</pre><a href="#appendix-D.2-13" class="pilcrow">¶</a>
|
||
</div>
|
||
<p id="appendix-D.2-14">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.<a href="#appendix-D.2-14" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="example-3-parallel-execution-with-join">
|
||
<section id="appendix-D.3">
|
||
<h3 id="name-example-3-parallel-executio">
|
||
<a href="#name-example-3-parallel-executio" class="section-name selfRef">Example 3: Parallel Execution with Join</a>
|
||
</h3>
|
||
<p id="appendix-D.3-1">A workflow where two tasks execute in parallel and a third task
|
||
depends on both:<a href="#appendix-D.3-1" class="pilcrow">¶</a></p>
|
||
<div class="alignLeft art-text artwork" id="appendix-D.3-2">
|
||
<pre>
|
||
task-...-0001 (assess_risk)
|
||
| \
|
||
v v
|
||
task-...-0002 task-...-0003
|
||
(check (verify
|
||
compliance) liquidity)
|
||
| /
|
||
v v
|
||
task-...-0004 (execute_trade)
|
||
</pre><a href="#appendix-D.3-2" class="pilcrow">¶</a>
|
||
</div>
|
||
<p id="appendix-D.3-3">Task 004 ECT payload:<a href="#appendix-D.3-3" class="pilcrow">¶</a></p>
|
||
<div class="lang-json sourcecode" id="appendix-D.3-4">
|
||
<pre>
|
||
{
|
||
"iss": "spiffe://bank.example/agent/execution",
|
||
"aud": "spiffe://bank.example/system/ledger",
|
||
"iat": 1772064250,
|
||
"exp": 1772064850,
|
||
"jti": "f1e2d3c4-0004-0000-0000-000000000004",
|
||
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
|
||
"exec_act": "execute_trade",
|
||
"par": [
|
||
"f1e2d3c4-0002-0000-0000-000000000002",
|
||
"f1e2d3c4-0003-0000-0000-000000000003"
|
||
],
|
||
"ext": {
|
||
"pol": "trade_execution_policy_v3",
|
||
"pol_decision": "approved"
|
||
}
|
||
}
|
||
</pre><a href="#appendix-D.3-4" class="pilcrow">¶</a>
|
||
</div>
|
||
<p id="appendix-D.3-5">The "par" array with two entries records that both compliance
|
||
checking and liquidity verification were completed before trade
|
||
execution.<a href="#appendix-D.3-5" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="acknowledgments">
|
||
<section id="appendix-E">
|
||
<h2 id="name-acknowledgments">
|
||
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
|
||
</h2>
|
||
<p id="appendix-E-1">The author thanks the WIMSE working group for their foundational
|
||
work on workload identity in multi-system environments. The
|
||
concepts of Workload Identity Tokens and Workload Proof Tokens
|
||
provide the identity foundation upon which execution context
|
||
tracing is built.<a href="#appendix-E-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="authors-addresses">
|
||
<section id="appendix-F">
|
||
<h2 id="name-authors-address">
|
||
<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
|
||
</h2>
|
||
<address class="vcard">
|
||
<div dir="auto" class="left"><span class="fn nameRole">Christian Nennemann</span></div>
|
||
<div dir="auto" class="left"><span class="org">Independent Researcher</span></div>
|
||
<div class="email">
|
||
<span>Email:</span>
|
||
<a href="mailto:ietf@nennemann.de" class="email">ietf@nennemann.de</a>
|
||
</div>
|
||
</address>
|
||
</section>
|
||
</div>
|
||
<script>const toc = document.getElementById("toc");
|
||
toc.querySelector("h2").addEventListener("click", e => {
|
||
toc.classList.toggle("active");
|
||
});
|
||
toc.querySelector("nav").addEventListener("click", e => {
|
||
toc.classList.remove("active");
|
||
});
|
||
</script>
|
||
</body>
|
||
</html>
|