2911 lines
132 KiB
HTML
2911 lines
132 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), a JWT-based
|
||
extension to the WIMSE architecture that records task execution
|
||
across distributed agentic workflows. Each ECT is a signed record
|
||
of a single task, linked to predecessor tasks through a directed
|
||
acyclic graph (DAG). ECTs reuse the WIMSE signing model and are
|
||
transported in a new Execution-Context HTTP header field alongside
|
||
existing WIMSE identity headers.
|
||
" 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="draft-nennemann-wimse-ect-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-ect-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-ect-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), a JWT-based
|
||
extension to the WIMSE architecture that records task execution
|
||
across distributed agentic workflows. Each ECT is a signed record
|
||
of a single task, linked to predecessor tasks through a directed
|
||
acyclic graph (DAG). ECTs reuse the WIMSE signing model and are
|
||
transported in a new Execution-Context HTTP header field alongside
|
||
existing WIMSE identity headers.<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" class="keepWithNext"><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-scope-and-applicability" class="internal xref">Scope and Applicability</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" class="keepWithNext"><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-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.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-jose-header" class="internal xref">JOSE Header</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-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.3.2.2.2.1">
|
||
<p id="section-toc.1-1.3.2.2.2.1.1"><a href="#section-3.2.1" class="auto internal xref">3.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.3.2.2.2.2">
|
||
<p id="section-toc.1-1.3.2.2.2.2.1"><a href="#section-3.2.2" class="auto internal xref">3.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.3.2.2.2.3">
|
||
<p id="section-toc.1-1.3.2.2.2.3.1"><a href="#section-3.2.3" class="auto internal xref">3.2.3</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.3.2.2.2.4">
|
||
<p id="section-toc.1-1.3.2.2.2.4.1"><a href="#section-3.2.4" class="auto internal xref">3.2.4</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.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-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.4">
|
||
<p id="section-toc.1-1.4.1"><a href="#section-4" class="auto internal xref">4</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.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-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.5">
|
||
<p id="section-toc.1-1.5.1"><a href="#section-5" class="auto internal xref">5</a>. <a href="#name-dag-validation" class="internal xref">DAG Validation</a></p>
|
||
</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-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.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-verification-procedure" class="internal xref">Verification Procedure</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-audit-ledger-interface" class="internal xref">Audit Ledger Interface</a></p>
|
||
</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-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.8.2.1">
|
||
<p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="auto internal xref">8.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.8.2.2">
|
||
<p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="auto internal xref">8.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.8.2.3">
|
||
<p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="auto internal xref">8.3</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.8.2.4">
|
||
<p id="section-toc.1-1.8.2.4.1"><a href="#section-8.4" class="auto internal xref">8.4</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.8.2.5">
|
||
<p id="section-toc.1-1.8.2.5.1"><a href="#section-8.5" class="auto internal xref">8.5</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.8.2.6">
|
||
<p id="section-toc.1-1.8.2.6.1"><a href="#section-8.6" class="auto internal xref">8.6</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.8.2.7">
|
||
<p id="section-toc.1-1.8.2.7.1"><a href="#section-8.7" class="auto internal xref">8.7</a>. <a href="#name-collusion-and-dag-integrity" class="internal xref">Collusion and DAG Integrity</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.8">
|
||
<p id="section-toc.1-1.8.2.8.1"><a href="#section-8.8" class="auto internal xref">8.8</a>. <a href="#name-privilege-escalation-via-ec" class="internal xref">Privilege Escalation via ECTs</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.9">
|
||
<p id="section-toc.1-1.8.2.9.1"><a href="#section-8.9" class="auto internal xref">8.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.8.2.10">
|
||
<p id="section-toc.1-1.8.2.10.1"><a href="#section-8.10" class="auto internal xref">8.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.8.2.11">
|
||
<p id="section-toc.1-1.8.2.11.1"><a href="#section-8.11" class="auto internal xref">8.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.9">
|
||
<p id="section-toc.1-1.9.1"><a href="#section-9" class="auto internal xref">9</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.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-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.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-data-minimization" class="internal xref">Data Minimization</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-storage-and-access-control" class="internal xref">Storage and Access Control</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-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.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-media-type-registration" class="internal xref">Media Type Registration</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-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.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-jwt-claims-registration" class="internal xref">JWT Claims Registration</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-references" class="internal xref">References</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-normative-references" class="internal xref">Normative References</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-informative-references" class="internal xref">Informative References</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="#appendix-A" class="auto internal xref"></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.12.2.1">
|
||
<p id="section-toc.1-1.12.2.1.1"><a href="#appendix-A.1" class="auto internal xref"></a><a href="#name-cross-organization-financia" class="internal xref">Cross-Organization Financial Trading</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="#appendix-B" 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.13.2.1">
|
||
<p id="section-toc.1-1.13.2.1.1"><a href="#appendix-B.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.13.2.2">
|
||
<p id="section-toc.1-1.13.2.2.1"><a href="#appendix-B.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.13.2.3">
|
||
<p id="section-toc.1-1.13.2.3.1"><a href="#appendix-B.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.13.2.4">
|
||
<p id="section-toc.1-1.13.2.4.1"><a href="#appendix-B.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.13.2.5">
|
||
<p id="section-toc.1-1.13.2.5.1"><a href="#appendix-B.5" class="auto internal xref"></a><a href="#name-w3c-provenance-data-model-p" class="internal xref">W3C Provenance Data Model (PROV)</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.6">
|
||
<p id="section-toc.1-1.13.2.6.1"><a href="#appendix-B.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>
|
||
</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-C" 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.15">
|
||
<p id="section-toc.1-1.15.1"><a href="#appendix-D" 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>
|
||
<p id="section-1-1">The WIMSE framework <span>[<a href="#I-D.ietf-wimse-arch" class="cite xref">I-D.ietf-wimse-arch</a>]</span> and its service-to-
|
||
service protocol <span>[<a href="#I-D.ietf-wimse-s2s-protocol" class="cite xref">I-D.ietf-wimse-s2s-protocol</a>]</span> authenticate
|
||
workloads across call chains but do not record what those
|
||
workloads actually did. This document defines Execution Context
|
||
Tokens (ECTs), a JWT-based extension that fills the gap between
|
||
workload identity and execution accountability. Each ECT is a
|
||
signed record of a single task, linked to predecessor tasks
|
||
through a directed acyclic graph (DAG).<a href="#section-1-1" class="pilcrow">¶</a></p>
|
||
<div id="scope-and-applicability">
|
||
<section id="section-1.1">
|
||
<h3 id="name-scope-and-applicability">
|
||
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-scope-and-applicability" class="section-name selfRef">Scope and Applicability</a>
|
||
</h3>
|
||
<p id="section-1.1-1">This document defines:<a href="#section-1.1-1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-1.1-2.1">
|
||
<p id="section-1.1-2.1.1">The Execution Context Token (ECT) format (<a href="#ect-format" class="auto internal xref">Section 3</a>)<a href="#section-1.1-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.1-2.2">
|
||
<p id="section-1.1-2.2.1">DAG structure for task dependency ordering (<a href="#dag-validation" class="auto internal xref">Section 5</a>)<a href="#section-1.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.1-2.3">
|
||
<p id="section-1.1-2.3.1">An HTTP header for ECT transport (<a href="#http-header" class="auto internal xref">Section 4</a>)<a href="#section-1.1-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.1-2.4">
|
||
<p id="section-1.1-2.4.1">Audit ledger interface requirements (<a href="#ledger-interface" class="auto internal xref">Section 7</a>)<a href="#section-1.1-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-1.1-3">The following are out of scope and are handled by WIMSE:<a href="#section-1.1-3" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-1.1-4.1">
|
||
<p id="section-1.1-4.1.1">Workload authentication and identity provisioning<a href="#section-1.1-4.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.1-4.2">
|
||
<p id="section-1.1-4.2.1">Key distribution and management<a href="#section-1.1-4.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.1-4.3">
|
||
<p id="section-1.1-4.3.1">Trust domain establishment and management<a href="#section-1.1-4.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.1-4.4">
|
||
<p id="section-1.1-4.4.1">Credential lifecycle management<a href="#section-1.1-4.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</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.<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 audit and verification.<a href="#section-2-3.10.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-2-3.11">Workload Identity Token (WIT):</dt>
|
||
<dd style="margin-left: 1.5em" id="section-2-3.12">
|
||
<p id="section-2-3.12.1">A WIMSE credential proving a workload's identity within a trust
|
||
domain.<a href="#section-2-3.12.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-2-3.13">Workload Proof Token (WPT):</dt>
|
||
<dd style="margin-left: 1.5em" id="section-2-3.14">
|
||
<p id="section-2-3.14.1">A WIMSE proof-of-possession token used for request-level
|
||
authentication.<a href="#section-2-3.14.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-2-3.15">Trust Domain:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-2-3.16">
|
||
<p id="section-2-3.16.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.16.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="ect-format">
|
||
<section id="section-3">
|
||
<h2 id="name-execution-context-token-for">
|
||
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-execution-context-token-for" class="section-name selfRef">Execution Context Token Format</a>
|
||
</h2>
|
||
<p id="section-3-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>. ECTs <span class="bcp14">MUST</span> use
|
||
JWS Compact Serialization (the base64url-encoded
|
||
<code>header.payload.signature</code> format) so that they can be carried in
|
||
a single HTTP header value.<a href="#section-3-1" class="pilcrow">¶</a></p>
|
||
<p id="section-3-2">ECTs reuse the WIMSE signing model. The ECT <span class="bcp14">MUST</span> be signed with
|
||
the same private key associated with the agent's WIT. The JOSE
|
||
header "kid" parameter <span class="bcp14">MUST</span> reference the public key identifier
|
||
from the agent's WIT, and the "alg" parameter <span class="bcp14">MUST</span> match the
|
||
algorithm used in the corresponding WIT. 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-2" class="pilcrow">¶</a></p>
|
||
<div id="jose-header">
|
||
<section id="section-3.1">
|
||
<h3 id="name-jose-header">
|
||
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-jose-header" class="section-name selfRef">JOSE Header</a>
|
||
</h3>
|
||
<p id="section-3.1-1">The ECT JOSE header <span class="bcp14">MUST</span> contain the following parameters:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
|
||
<span id="name-ect-jose-header-example"></span><div id="fig-header">
|
||
<figure id="figure-1">
|
||
<div class="lang-json sourcecode" id="section-3.1-2.1">
|
||
<pre>
|
||
{
|
||
"alg": "ES256",
|
||
"typ": "wimse-exec+jwt",
|
||
"kid": "agent-a-key-id-123"
|
||
}
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-1" class="selfRef">Figure 1</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-3.1-3">
|
||
<dt id="section-3.1-3.1">alg:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-3.1-3.2">
|
||
<p id="section-3.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-3.1-3.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-3.1-3.3">typ:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-3.1-3.4">
|
||
<p id="section-3.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-3.1-3.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-3.1-3.5">kid:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-3.1-3.6">
|
||
<p id="section-3.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-3.1-3.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="jwt-claims">
|
||
<section id="section-3.2">
|
||
<h3 id="name-jwt-claims">
|
||
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-jwt-claims" class="section-name selfRef">JWT Claims</a>
|
||
</h3>
|
||
<div id="standard-jwt-claims">
|
||
<section id="section-3.2.1">
|
||
<h4 id="name-standard-jwt-claims">
|
||
<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-standard-jwt-claims" class="section-name selfRef">Standard JWT Claims</a>
|
||
</h4>
|
||
<p id="section-3.2.1-1">An ECT <span class="bcp14">MUST</span> contain the following standard JWT claims <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>:<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-3.2.1-2">
|
||
<dt id="section-3.2.1-2.1">iss:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-3.2.1-2.2">
|
||
<p id="section-3.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-3.2.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-3.2.1-2.3">aud:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-3.2.1-2.4">
|
||
<p id="section-3.2.1-2.4.1"><span class="bcp14">REQUIRED</span>. StringOrURI or array of StringOrURI. The intended
|
||
recipient(s) of the ECT. The "aud" claim <span class="bcp14">SHOULD</span> contain the
|
||
identifiers of all entities that will verify the ECT. When
|
||
an ECT must be verified by both the next agent and the audit
|
||
ledger independently, "aud" <span class="bcp14">MUST</span> be an array containing both
|
||
identifiers. Each verifier checks that its own identity
|
||
appears in "aud".<a href="#section-3.2.1-2.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-3.2.1-2.5">iat:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-3.2.1-2.6">
|
||
<p id="section-3.2.1-2.6.1"><span class="bcp14">REQUIRED</span>. NumericDate. The time at which the ECT was issued.<a href="#section-3.2.1-2.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-3.2.1-2.7">exp:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-3.2.1-2.8">
|
||
<p id="section-3.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".<a href="#section-3.2.1-2.8.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-3.2.1-2.9">jti:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-3.2.1-2.10">
|
||
<p id="section-3.2.1-2.10.1"><span class="bcp14">REQUIRED</span>. String. A unique identifier for both the ECT and
|
||
the task it records, in UUID format <span>[<a href="#RFC9562" class="cite xref">RFC9562</a>]</span>. The "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-3.2.1-2.10.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="exec-claims">
|
||
<section id="section-3.2.2">
|
||
<h4 id="name-execution-context">
|
||
<a href="#section-3.2.2" class="section-number selfRef">3.2.2. </a><a href="#name-execution-context" class="section-name selfRef">Execution Context</a>
|
||
</h4>
|
||
<p id="section-3.2.2-1">The following claims are defined by this specification:<a href="#section-3.2.2-1" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-3.2.2-2">
|
||
<dt id="section-3.2.2-2.1">wid:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-3.2.2-2.2">
|
||
<p id="section-3.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-3.2.2-2.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-3.2.2-2.3">exec_act:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-3.2.2-2.4">
|
||
<p id="section-3.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"). This claim name avoids collision with the
|
||
"act" (Actor) claim registered by <span>[<a href="#RFC8693" class="cite xref">RFC8693</a>]</span>.<a href="#section-3.2.2-2.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-3.2.2-2.5">par:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-3.2.2-2.6">
|
||
<p id="section-3.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-3.2.2-2.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="data-integrity-claims">
|
||
<section id="section-3.2.3">
|
||
<h4 id="name-data-integrity">
|
||
<a href="#section-3.2.3" class="section-number selfRef">3.2.3. </a><a href="#name-data-integrity" class="section-name selfRef">Data Integrity</a>
|
||
</h4>
|
||
<p id="section-3.2.3-1">The following claims provide integrity verification for task
|
||
inputs and outputs without revealing the data itself:<a href="#section-3.2.3-1" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-3.2.3-2">
|
||
<dt id="section-3.2.3-2.1">inp_hash:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-3.2.3-2.2">
|
||
<p id="section-3.2.3-2.2.1"><span class="bcp14">OPTIONAL</span>. String. The base64url encoding (without padding) of
|
||
the SHA-256 hash of the input data, computed over the raw octets
|
||
of the input. SHA-256 is the mandatory algorithm with no
|
||
algorithm prefix in the value, consistent with <span>[<a href="#RFC9449" class="cite xref">RFC9449</a>]</span> and
|
||
<span>[<a href="#I-D.ietf-wimse-s2s-protocol" class="cite xref">I-D.ietf-wimse-s2s-protocol</a>]</span>.<a href="#section-3.2.3-2.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-3.2.3-2.3">out_hash:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-3.2.3-2.4">
|
||
<p id="section-3.2.3-2.4.1"><span class="bcp14">OPTIONAL</span>. String. The base64url encoding (without padding) of
|
||
the SHA-256 hash of the output data, using the same format as
|
||
"inp_hash".<a href="#section-3.2.3-2.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="extension-claims">
|
||
<section id="section-3.2.4">
|
||
<h4 id="name-extensions">
|
||
<a href="#section-3.2.4" class="section-number selfRef">3.2.4. </a><a href="#name-extensions" class="section-name selfRef">Extensions</a>
|
||
</h4>
|
||
<span class="break"></span><dl class="dlParallel" id="section-3.2.4-1">
|
||
<dt id="section-3.2.4-1.1">ext:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-3.2.4-1.2">
|
||
<p id="section-3.2.4-1.2.1"><span class="bcp14">OPTIONAL</span>. Object. A general-purpose 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. Extension key names <span class="bcp14">SHOULD</span> use reverse domain
|
||
notation (e.g., "com.example.custom_field") to avoid
|
||
collisions. The serialized "ext" object <span class="bcp14">SHOULD NOT</span> exceed
|
||
4096 bytes and <span class="bcp14">SHOULD NOT</span> exceed a nesting depth of 5 levels.<a href="#section-3.2.4-1.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="complete-ect-example">
|
||
<section id="section-3.3">
|
||
<h3 id="name-complete-ect-example">
|
||
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-complete-ect-example" class="section-name selfRef">Complete ECT Example</a>
|
||
</h3>
|
||
<p id="section-3.3-1">The following is a complete ECT payload example:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
|
||
<span id="name-complete-ect-payload-exampl"></span><div id="fig-full-ect">
|
||
<figure id="figure-2">
|
||
<div class="lang-json sourcecode" id="section-3.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": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
|
||
"out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
|
||
|
||
"ext": {
|
||
"com.example.trace_id": "abc123"
|
||
}
|
||
}
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-2" class="selfRef">Figure 2</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-4">
|
||
<h2 id="name-http-header-transport">
|
||
<a href="#section-4" class="section-number selfRef">4. </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-4.1">
|
||
<h3 id="name-execution-context-header-fi">
|
||
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-execution-context-header-fi" class="section-name selfRef">Execution-Context Header Field</a>
|
||
</h3>
|
||
<p id="section-4.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-4.1-1" class="pilcrow">¶</a></p>
|
||
<p id="section-4.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-4.1-2" class="pilcrow">¶</a></p>
|
||
<p id="section-4.1-3">An agent sending a request to another agent includes the
|
||
Execution-Context header alongside the WIMSE Workload-Identity
|
||
header. 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.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
|
||
<span id="name-http-request-with-ect-heade"></span><div id="fig-http-example">
|
||
<figure id="figure-3">
|
||
<div class="alignLeft art-text artwork" id="section-4.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-3" class="selfRef">Figure 3</a>:
|
||
<a href="#name-http-request-with-ect-heade" class="selfRef">HTTP Request with ECT Header</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
<p id="section-4.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-4.1-5" class="pilcrow">¶</a></p>
|
||
<p id="section-4.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 6</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-4.1-6" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="dag-validation">
|
||
<section id="section-5">
|
||
<h2 id="name-dag-validation">
|
||
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-dag-validation" class="section-name selfRef">DAG Validation</a>
|
||
</h2>
|
||
<p id="section-5-1">ECTs form a Directed Acyclic Graph (DAG) where each task
|
||
references its parent tasks via the "par" claim. DAG validation
|
||
is performed against the ECT store — either an audit ledger or
|
||
the set of parent ECTs received inline.<a href="#section-5-1" class="pilcrow">¶</a></p>
|
||
<p id="section-5-2">When receiving and verifying an ECT, implementations <span class="bcp14">MUST</span> perform
|
||
the following DAG validation steps:<a href="#section-5-2" class="pilcrow">¶</a></p>
|
||
<ol start="1" type="1" class="normal type-1" id="section-5-3">
|
||
<li id="section-5-3.1">
|
||
<p id="section-5-3.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-5-3.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-5-3.2">
|
||
<p id="section-5-3.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-5-3.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-5-3.3">
|
||
<p id="section-5-3.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-5-3.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-5-3.4">
|
||
<p id="section-5-3.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-5-3.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-5-3.5">
|
||
<p id="section-5-3.5.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-5-3.5.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ol>
|
||
<p id="section-5-4">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.<a href="#section-5-4" class="pilcrow">¶</a></p>
|
||
<p id="section-5-5">In distributed deployments, a parent ECT may not yet be available
|
||
locally due to replication lag. Implementations <span class="bcp14">MAY</span> defer
|
||
validation to allow parent ECTs to arrive, but <span class="bcp14">MUST NOT</span> treat
|
||
the ECT as verified until all parent references are resolved.<a href="#section-5-5" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="verification">
|
||
<section id="section-6">
|
||
<h2 id="name-signature-and-token-verific">
|
||
<a href="#section-6" class="section-number selfRef">6. </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-6.1">
|
||
<h3 id="name-verification-procedure">
|
||
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-verification-procedure" class="section-name selfRef">Verification Procedure</a>
|
||
</h3>
|
||
<p id="section-6.1-1">When an agent receives an ECT, it <span class="bcp14">MUST</span> perform the following
|
||
verification steps in order:<a href="#section-6.1-1" class="pilcrow">¶</a></p>
|
||
<ol start="1" type="1" class="normal type-1" id="section-6.1-2">
|
||
<li id="section-6.1-2.1">
|
||
<p id="section-6.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-6.1-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.1-2.2">
|
||
<p id="section-6.1-2.2.1">Verify that the "typ" header parameter is "wimse-exec+jwt".<a href="#section-6.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.1-2.3">
|
||
<p id="section-6.1-2.3.1">Verify that the "alg" header parameter appears in the
|
||
verifier's configured allowlist of accepted signing algorithms.
|
||
The allowlist <span class="bcp14">MUST NOT</span> include "none" or any symmetric
|
||
algorithm (e.g., HS256, HS384, HS512). Implementations <span class="bcp14">MUST</span>
|
||
include ES256 in the allowlist; additional asymmetric algorithms
|
||
<span class="bcp14">MAY</span> be included per deployment policy.<a href="#section-6.1-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.1-2.4">
|
||
<p id="section-6.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-6.1-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.1-2.5">
|
||
<p id="section-6.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-6.1-2.5.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.1-2.6">
|
||
<p id="section-6.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-6.1-2.6.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.1-2.7">
|
||
<p id="section-6.1-2.7.1">Verify the "alg" header parameter matches the algorithm in the
|
||
corresponding WIT.<a href="#section-6.1-2.7.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.1-2.8">
|
||
<p id="section-6.1-2.8.1">Verify the "iss" claim matches the "sub" claim of the WIT
|
||
associated with the "kid" public key.<a href="#section-6.1-2.8.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.1-2.9">
|
||
<p id="section-6.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-6.1-2.9.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.1-2.10">
|
||
<p id="section-6.1-2.10.1">Verify the "exp" claim indicates the ECT has not expired.<a href="#section-6.1-2.10.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.1-2.11">
|
||
<p id="section-6.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-6.1-2.11.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.1-2.12">
|
||
<p id="section-6.1-2.12.1">Verify all required claims ("jti", "exec_act", "par") are
|
||
present and well-formed.<a href="#section-6.1-2.12.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.1-2.13">
|
||
<p id="section-6.1-2.13.1">Perform DAG validation per <a href="#dag-validation" class="auto internal xref">Section 5</a>.<a href="#section-6.1-2.13.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.1-2.14">
|
||
<p id="section-6.1-2.14.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-6.1-2.14.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ol>
|
||
<p id="section-6.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-6.1-3" class="pilcrow">¶</a></p>
|
||
<p id="section-6.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-6.1-4" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="ledger-interface">
|
||
<section id="section-7">
|
||
<h2 id="name-audit-ledger-interface">
|
||
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-audit-ledger-interface" class="section-name selfRef">Audit Ledger Interface</a>
|
||
</h2>
|
||
<p id="section-7-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-7-1" class="pilcrow">¶</a></p>
|
||
<p id="section-7-2">When an audit ledger is deployed, the implementation <span class="bcp14">MUST</span> provide:<a href="#section-7-2" class="pilcrow">¶</a></p>
|
||
<ol start="1" type="1" class="normal type-1" id="section-7-3">
|
||
<li id="section-7-3.1">
|
||
<p id="section-7-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-7-3.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7-3.2">
|
||
<p id="section-7-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-7-3.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7-3.3">
|
||
<p id="section-7-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-7-3.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7-3.4">
|
||
<p id="section-7-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-7-3.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ol>
|
||
<p id="section-7-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-7-4" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="security-considerations">
|
||
<section id="section-8">
|
||
<h2 id="name-security-considerations">
|
||
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
|
||
</h2>
|
||
<div id="threat-model">
|
||
<section id="section-8.1">
|
||
<h3 id="name-threat-model">
|
||
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-threat-model" class="section-name selfRef">Threat Model</a>
|
||
</h3>
|
||
<p id="section-8.1-1">The threat model considers: (1) a malicious agent that creates
|
||
false ECT claims, (2) an agent whose private key has been
|
||
compromised, (3) a ledger tamperer attempting to modify recorded
|
||
entries, and (4) a time manipulator altering timestamps to affect
|
||
perceived ordering.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="self-assertion-limitation">
|
||
<section id="section-8.2">
|
||
<h3 id="name-self-assertion-limitation">
|
||
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-self-assertion-limitation" class="section-name selfRef">Self-Assertion Limitation</a>
|
||
</h3>
|
||
<p id="section-8.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., claiming an action was performed when it was not).<a href="#section-8.2-1" class="pilcrow">¶</a></p>
|
||
<p id="section-8.2-2">ECTs do not independently verify that:<a href="#section-8.2-2" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-8.2-3.1">
|
||
<p id="section-8.2-3.1.1">The claimed execution actually occurred as described<a href="#section-8.2-3.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-8.2-3.2">
|
||
<p id="section-8.2-3.2.1">The input/output hashes correspond to the actual data processed<a href="#section-8.2-3.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-8.2-3.3">
|
||
<p id="section-8.2-3.3.1">The agent faithfully performed the stated action<a href="#section-8.2-3.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-8.2-4">The trustworthiness of ECT claims depends on the trustworthiness
|
||
of the signing agent and the integrity of the broader deployment
|
||
environment. ECTs provide a technical mechanism for execution
|
||
recording; they do not by themselves satisfy any specific
|
||
regulatory compliance requirement.<a href="#section-8.2-4" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="signature-verification">
|
||
<section id="section-8.3">
|
||
<h3 id="name-signature-verification">
|
||
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-signature-verification" class="section-name selfRef">Signature Verification</a>
|
||
</h3>
|
||
<p id="section-8.3-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 6</a>).<a href="#section-8.3-1" class="pilcrow">¶</a></p>
|
||
<p id="section-8.3-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-8.3-2" class="pilcrow">¶</a></p>
|
||
<p id="section-8.3-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-8.3-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="replay-attack-prevention">
|
||
<section id="section-8.4">
|
||
<h3 id="name-replay-attack-prevention">
|
||
<a href="#section-8.4" class="section-number selfRef">8.4. </a><a href="#name-replay-attack-prevention" class="section-name selfRef">Replay Attack Prevention</a>
|
||
</h3>
|
||
<p id="section-8.4-1">ECTs include short expiration times (<span class="bcp14">RECOMMENDED</span>: 5-15 minutes)
|
||
and audience restriction via "aud" to limit replay attacks.
|
||
Implementations <span class="bcp14">MUST</span> maintain a cache of recently-seen "jti"
|
||
values and <span class="bcp14">MUST</span> reject ECTs with duplicate "jti" values. Each
|
||
ECT is cryptographically bound to the issuing agent via "kid";
|
||
verifiers <span class="bcp14">MUST</span> confirm that "kid" resolves to the "iss" agent's
|
||
key (step 8 in <a href="#verification" class="auto internal xref">Section 6</a>).<a href="#section-8.4-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="man-in-the-middle-protection">
|
||
<section id="section-8.5">
|
||
<h3 id="name-man-in-the-middle-protectio">
|
||
<a href="#section-8.5" class="section-number selfRef">8.5. </a><a href="#name-man-in-the-middle-protectio" class="section-name selfRef">Man-in-the-Middle Protection</a>
|
||
</h3>
|
||
<p id="section-8.5-1">ECTs <span class="bcp14">MUST</span> be transmitted over TLS or mTLS connections. When used
|
||
with <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.<a href="#section-8.5-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="key-compromise">
|
||
<section id="section-8.6">
|
||
<h3 id="name-key-compromise">
|
||
<a href="#section-8.6" class="section-number selfRef">8.6. </a><a href="#name-key-compromise" class="section-name selfRef">Key Compromise</a>
|
||
</h3>
|
||
<p id="section-8.6-1">If an agent's private key is compromised, an attacker can forge
|
||
ECTs that appear to originate from that agent. Mitigations:<a href="#section-8.6-1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-8.6-2.1">
|
||
<p id="section-8.6-2.1.1">Implementations <span class="bcp14">SHOULD</span> use short-lived keys and rotate them
|
||
frequently.<a href="#section-8.6-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-8.6-2.2">
|
||
<p id="section-8.6-2.2.1">Private keys <span class="bcp14">SHOULD</span> be stored in hardware security modules or
|
||
equivalent secure key storage.<a href="#section-8.6-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-8.6-2.3">
|
||
<p id="section-8.6-2.3.1">Trust domains <span class="bcp14">MUST</span> support rapid key revocation.<a href="#section-8.6-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-8.6-3">ECTs recorded before key revocation remain valid historical
|
||
records but <span class="bcp14">SHOULD</span> be flagged for audit purposes. New ECTs
|
||
<span class="bcp14">MUST NOT</span> reference a parent ECT whose signing key is known to
|
||
be revoked at creation time.<a href="#section-8.6-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="collusion-and-false-claims">
|
||
<section id="section-8.7">
|
||
<h3 id="name-collusion-and-dag-integrity">
|
||
<a href="#section-8.7" class="section-number selfRef">8.7. </a><a href="#name-collusion-and-dag-integrity" class="section-name selfRef">Collusion and DAG Integrity</a>
|
||
</h3>
|
||
<p id="section-8.7-1">A single malicious agent cannot forge parent task references
|
||
because DAG validation requires parent tasks to exist in the ECT
|
||
store. However, multiple colluding agents could create a false
|
||
execution history. Additionally, a malicious agent may omit
|
||
actual parent dependencies from "par" to hide influences on its
|
||
output; because ECTs are self-asserted
|
||
(<a href="#self-assertion-limitation" class="auto internal xref">Section 8.2</a>), no mechanism can force complete
|
||
dependency declaration.<a href="#section-8.7-1" class="pilcrow">¶</a></p>
|
||
<p id="section-8.7-2">Mitigations include:<a href="#section-8.7-2" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-8.7-3.1">
|
||
<p id="section-8.7-3.1.1">The ledger <span class="bcp14">SHOULD</span> be maintained by an entity independent of the
|
||
workflow agents.<a href="#section-8.7-3.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-8.7-3.2">
|
||
<p id="section-8.7-3.2.1">Multiple independent ledger replicas can be compared for
|
||
consistency.<a href="#section-8.7-3.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-8.7-3.3">
|
||
<p id="section-8.7-3.3.1">External auditors can compare the declared DAG against expected
|
||
workflow patterns.<a href="#section-8.7-3.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-8.7-4">Verifiers <span class="bcp14">SHOULD</span> validate that the declared "wid" of parent ECTs
|
||
matches the "wid" of the child ECT, rejecting cross-workflow
|
||
parent references unless explicitly permitted by deployment
|
||
policy.<a href="#section-8.7-4" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="privilege-escalation-via-ects">
|
||
<section id="section-8.8">
|
||
<h3 id="name-privilege-escalation-via-ec">
|
||
<a href="#section-8.8" class="section-number selfRef">8.8. </a><a href="#name-privilege-escalation-via-ec" class="section-name selfRef">Privilege Escalation via ECTs</a>
|
||
</h3>
|
||
<p id="section-8.8-1">ECTs record execution history; they do not convey authorization.
|
||
Verifiers <span class="bcp14">MUST NOT</span> interpret the presence of an ECT, or a
|
||
particular set of parent references in "par", as an authorization
|
||
grant. Authorization decisions <span class="bcp14">MUST</span> remain with the identity and
|
||
authorization layer (WIT, WPT, and deployment policy).<a href="#section-8.8-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="denial-of-service">
|
||
<section id="section-8.9">
|
||
<h3 id="name-denial-of-service">
|
||
<a href="#section-8.9" class="section-number selfRef">8.9. </a><a href="#name-denial-of-service" class="section-name selfRef">Denial of Service</a>
|
||
</h3>
|
||
<p id="section-8.9-1">Implementations <span class="bcp14">SHOULD</span> apply rate limiting to prevent excessive
|
||
ECT submissions. DAG validation <span class="bcp14">SHOULD</span> be performed after
|
||
signature verification to avoid wasting resources on unsigned
|
||
tokens.<a href="#section-8.9-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="timestamp-accuracy">
|
||
<section id="section-8.10">
|
||
<h3 id="name-timestamp-accuracy">
|
||
<a href="#section-8.10" class="section-number selfRef">8.10. </a><a href="#name-timestamp-accuracy" class="section-name selfRef">Timestamp Accuracy</a>
|
||
</h3>
|
||
<p id="section-8.10-1">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). Cross-organizational deployments <span class="bcp14">MAY</span> require a
|
||
higher tolerance and <span class="bcp14">SHOULD</span> document the configured value.<a href="#section-8.10-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="ect-size-constraints">
|
||
<section id="section-8.11">
|
||
<h3 id="name-ect-size-constraints">
|
||
<a href="#section-8.11" class="section-number selfRef">8.11. </a><a href="#name-ect-size-constraints" class="section-name selfRef">ECT Size Constraints</a>
|
||
</h3>
|
||
<p id="section-8.11-1">Implementations <span class="bcp14">SHOULD</span> limit the "par" array to a maximum of
|
||
256 entries. See <a href="#extension-claims" class="auto internal xref">Section 3.2.4</a> for "ext" size limits.<a href="#section-8.11-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="privacy-considerations">
|
||
<section id="section-9">
|
||
<h2 id="name-privacy-considerations">
|
||
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
|
||
</h2>
|
||
<div id="data-exposure-in-ects">
|
||
<section id="section-9.1">
|
||
<h3 id="name-data-exposure-in-ects">
|
||
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-data-exposure-in-ects" class="section-name selfRef">Data Exposure in ECTs</a>
|
||
</h3>
|
||
<p id="section-9.1-1">ECTs necessarily reveal:<a href="#section-9.1-1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-9.1-2.1">
|
||
<p id="section-9.1-2.1.1">Agent identities ("iss", "aud") for accountability purposes<a href="#section-9.1-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.1-2.2">
|
||
<p id="section-9.1-2.2.1">Action descriptions ("exec_act") for audit trail completeness<a href="#section-9.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.1-2.3">
|
||
<p id="section-9.1-2.3.1">Timestamps ("iat", "exp") for temporal ordering<a href="#section-9.1-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-9.1-3">ECTs are designed to NOT reveal:<a href="#section-9.1-3" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-9.1-4.1">
|
||
<p id="section-9.1-4.1.1">Actual input or output data values (replaced with cryptographic
|
||
hashes via "inp_hash" and "out_hash")<a href="#section-9.1-4.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.1-4.2">
|
||
<p id="section-9.1-4.2.1">Internal computation details or intermediate steps<a href="#section-9.1-4.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.1-4.3">
|
||
<p id="section-9.1-4.3.1">Proprietary algorithms or intellectual property<a href="#section-9.1-4.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.1-4.4">
|
||
<p id="section-9.1-4.4.1">Personally identifiable information (PII)<a href="#section-9.1-4.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="data-minimization">
|
||
<section id="section-9.2">
|
||
<h3 id="name-data-minimization">
|
||
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-data-minimization" class="section-name selfRef">Data Minimization</a>
|
||
</h3>
|
||
<p id="section-9.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.
|
||
Extension keys in "ext" (<a href="#extension-claims" class="auto internal xref">Section 3.2.4</a>) deserve particular
|
||
attention: human-readable values risk exposing sensitive operational
|
||
details. See <a href="#extension-claims" class="auto internal xref">Section 3.2.4</a> for guidance on using
|
||
structured identifiers.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="storage-and-access-control">
|
||
<section id="section-9.3">
|
||
<h3 id="name-storage-and-access-control">
|
||
<a href="#section-9.3" class="section-number selfRef">9.3. </a><a href="#name-storage-and-access-control" class="section-name selfRef">Storage and Access Control</a>
|
||
</h3>
|
||
<p id="section-9.3-1">ECTs stored in audit ledgers <span class="bcp14">SHOULD</span> be access-controlled so that
|
||
only authorized auditors can read them. Implementations <span class="bcp14">SHOULD</span>
|
||
consider encryption at rest for ledger storage. ECTs provide
|
||
structural records of execution ordering; they are not intended
|
||
for public disclosure.<a href="#section-9.3-1" class="pilcrow">¶</a></p>
|
||
<p id="section-9.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-9.3-2" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="iana-considerations">
|
||
<section id="section-10">
|
||
<h2 id="name-iana-considerations">
|
||
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
|
||
</h2>
|
||
<div id="media-type-registration">
|
||
<section id="section-10.1">
|
||
<h3 id="name-media-type-registration">
|
||
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-media-type-registration" class="section-name selfRef">Media Type Registration</a>
|
||
</h3>
|
||
<p id="section-10.1-1">This document requests registration of the following media type
|
||
in the "Media Types" registry maintained by IANA:<a href="#section-10.1-1" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-10.1-2">
|
||
<dt id="section-10.1-2.1">Type name:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.1-2.2">
|
||
<p id="section-10.1-2.2.1">application<a href="#section-10.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-10.1-2.3">Subtype name:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.1-2.4">
|
||
<p id="section-10.1-2.4.1">wimse-exec+jwt<a href="#section-10.1-2.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-10.1-2.5">Required parameters:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.1-2.6">
|
||
<p id="section-10.1-2.6.1">none<a href="#section-10.1-2.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-10.1-2.7">Optional parameters:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.1-2.8">
|
||
<p id="section-10.1-2.8.1">none<a href="#section-10.1-2.8.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-10.1-2.9">Encoding considerations:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.1-2.10">
|
||
<p id="section-10.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-10.1-2.10.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-10.1-2.11">Security considerations:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.1-2.12">
|
||
<p id="section-10.1-2.12.1">See the Security Considerations section of this document.<a href="#section-10.1-2.12.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-10.1-2.13">Interoperability considerations:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.1-2.14">
|
||
<p id="section-10.1-2.14.1">none<a href="#section-10.1-2.14.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-10.1-2.15">Published specification:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.1-2.16">
|
||
<p id="section-10.1-2.16.1">This document<a href="#section-10.1-2.16.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-10.1-2.17">Applications that use this media type:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.1-2.18">
|
||
<p id="section-10.1-2.18.1">Applications that implement agentic workflows requiring execution
|
||
context tracing and audit trails.<a href="#section-10.1-2.18.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-10.1-2.19">Additional information:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.1-2.20">
|
||
<p id="section-10.1-2.20.1">Magic number(s): none
|
||
File extension(s): none
|
||
Macintosh file type code(s): none<a href="#section-10.1-2.20.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-10.1-2.21">Person and email address to contact for further information:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.1-2.22">
|
||
<p id="section-10.1-2.22.1">Christian Nennemann, ietf@nennemann.de<a href="#section-10.1-2.22.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-10.1-2.23">Intended usage:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.1-2.24">
|
||
<p id="section-10.1-2.24.1">COMMON<a href="#section-10.1-2.24.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-10.1-2.25">Restrictions on usage:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.1-2.26">
|
||
<p id="section-10.1-2.26.1">none<a href="#section-10.1-2.26.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-10.1-2.27">Author:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.1-2.28">
|
||
<p id="section-10.1-2.28.1">Christian Nennemann<a href="#section-10.1-2.28.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-10.1-2.29">Change controller:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.1-2.30">
|
||
<p id="section-10.1-2.30.1">IETF<a href="#section-10.1-2.30.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="header-registration">
|
||
<section id="section-10.2">
|
||
<h3 id="name-http-header-field-registrat">
|
||
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-http-header-field-registrat" class="section-name selfRef">HTTP Header Field Registration</a>
|
||
</h3>
|
||
<p id="section-10.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-10.2-1" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-10.2-2">
|
||
<dt id="section-10.2-2.1">Field name:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.2-2.2">
|
||
<p id="section-10.2-2.2.1">Execution-Context<a href="#section-10.2-2.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-10.2-2.3">Status:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.2-2.4">
|
||
<p id="section-10.2-2.4.1">permanent<a href="#section-10.2-2.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-10.2-2.5">Specification document:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-10.2-2.6">
|
||
<p id="section-10.2-2.6.1">This document, <a href="#http-header" class="auto internal xref">Section 4</a><a href="#section-10.2-2.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="claims-registration">
|
||
<section id="section-10.3">
|
||
<h3 id="name-jwt-claims-registration">
|
||
<a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-jwt-claims-registration" class="section-name selfRef">JWT Claims Registration</a>
|
||
</h3>
|
||
<p id="section-10.3-1">This document requests registration of the following claims in
|
||
the "JSON Web Token Claims" registry maintained by IANA:<a href="#section-10.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 3.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 3.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 3.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 3.2.3</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 3.2.3</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 3.2.4</a>
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="sec-combined-references">
|
||
<section id="section-11">
|
||
<h2 id="name-references">
|
||
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-references" class="section-name selfRef">References</a>
|
||
</h2>
|
||
<div id="sec-normative-references">
|
||
<section id="section-11.1">
|
||
<h3 id="name-normative-references">
|
||
<a href="#section-11.1" class="section-number selfRef">11.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="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-11.2">
|
||
<h3 id="name-informative-references">
|
||
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
|
||
</h3>
|
||
<dl class="references">
|
||
<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.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="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="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="RFC9449">[RFC9449]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Fett, D.</span>, <span class="refAuthor">Campbell, B.</span>, <span class="refAuthor">Bradley, J.</span>, <span class="refAuthor">Lodderstedt, T.</span>, <span class="refAuthor">Jones, M.</span>, and <span class="refAuthor">D. Waite</span>, <span class="refTitle">"OAuth 2.0 Demonstrating Proof of Possession (DPoP)"</span>, <span class="seriesInfo">RFC 9449</span>, <span class="seriesInfo">DOI 10.17487/RFC9449</span>, <time datetime="2023-09" class="refDate">September 2023</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc9449">https://www.rfc-editor.org/rfc/rfc9449</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="use-cases">
|
||
<section id="appendix-A">
|
||
<h2 id="name-use-cases">
|
||
<a href="#name-use-cases" class="section-name selfRef">Use Cases</a>
|
||
</h2>
|
||
<p id="appendix-A-1">This section describes a representative use case demonstrating how
|
||
ECTs provide structured execution records.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
|
||
<p id="appendix-A-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 3.2.2</a>.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
|
||
<div id="cross-organization-financial-trading">
|
||
<section id="appendix-A.1">
|
||
<h3 id="name-cross-organization-financia">
|
||
<a href="#name-cross-organization-financia" class="section-name selfRef">Cross-Organization Financial Trading</a>
|
||
</h3>
|
||
<p id="appendix-A.1-1">In a cross-organization trading workflow, an investment bank's
|
||
agents coordinate with an external credit rating agency. The
|
||
agents operate in separate trust domains with a federation
|
||
relationship. The DAG records that independent assessments from
|
||
both organizations were completed before trade execution.<a href="#appendix-A.1-1" class="pilcrow">¶</a></p>
|
||
<span id="name-cross-organization-trading-"></span><div id="fig-finance">
|
||
<figure id="figure-4">
|
||
<div class="alignLeft art-text artwork" id="appendix-A.1-2.1">
|
||
<pre>
|
||
Trust Domain: bank.example
|
||
Agent A1 (Portfolio Risk):
|
||
jti: task-001 par: []
|
||
iss: spiffe://bank.example/agent/risk
|
||
exec_act: analyze_portfolio_risk
|
||
|
||
Trust Domain: ratings.example (external)
|
||
Agent B1 (Credit Rating):
|
||
jti: task-002 par: []
|
||
iss: spiffe://ratings.example/agent/credit
|
||
exec_act: assess_credit_rating
|
||
|
||
Trust Domain: bank.example
|
||
Agent A2 (Compliance):
|
||
jti: task-003 par: [task-001, task-002]
|
||
iss: spiffe://bank.example/agent/compliance
|
||
exec_act: verify_trade_compliance
|
||
|
||
Agent A3 (Execution):
|
||
jti: task-004 par: [task-003]
|
||
iss: spiffe://bank.example/agent/execution
|
||
exec_act: execute_trade
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
|
||
<a href="#name-cross-organization-trading-" class="selfRef">Cross-Organization Trading Workflow</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
<p id="appendix-A.1-3">The resulting DAG:<a href="#appendix-A.1-3" class="pilcrow">¶</a></p>
|
||
<span id="name-cross-organization-dag"></span><div id="fig-finance-dag">
|
||
<figure id="figure-5">
|
||
<div class="alignLeft art-text artwork" id="appendix-A.1-4.1">
|
||
<pre>
|
||
task-001 (analyze_portfolio_risk) task-002 (assess_credit_rating)
|
||
[bank.example] [ratings.example]
|
||
\ /
|
||
v v
|
||
task-003 (verify_trade_compliance)
|
||
[bank.example]
|
||
|
|
||
v
|
||
task-004 (execute_trade)
|
||
[bank.example]
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
|
||
<a href="#name-cross-organization-dag" class="selfRef">Cross-Organization DAG</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
<p id="appendix-A.1-5">Task 003 has two parents from different trust domains,
|
||
demonstrating cross-organizational fan-in. The compliance agent
|
||
verifies both parent ECTs — one signed by a local key and one by
|
||
a federated key from the rating agency's trust domain.<a href="#appendix-A.1-5" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="related-work">
|
||
<section id="appendix-B">
|
||
<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-B.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-B.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?" Together they form an
|
||
identity-plus-accountability framework for regulated agentic
|
||
systems.<a href="#appendix-B.1-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="oauth-20-token-exchange-and-the-act-claim">
|
||
<section id="appendix-B.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-B.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 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-B.2-1" class="pilcrow">¶</a></p>
|
||
<p id="appendix-B.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."<a href="#appendix-B.2-2" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="transaction-tokens">
|
||
<section id="appendix-B.3">
|
||
<h3 id="name-transaction-tokens">
|
||
<a href="#name-transaction-tokens" class="section-name selfRef">Transaction Tokens</a>
|
||
</h3>
|
||
<p id="appendix-B.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-B.3-1" class="pilcrow">¶</a></p>
|
||
<p id="appendix-B.3-2">However, "req_wl" cannot form a DAG because:<a href="#appendix-B.3-2" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="appendix-B.3-3.1">
|
||
<p id="appendix-B.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-B.3-3.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="appendix-B.3-3.2">
|
||
<p id="appendix-B.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-B.3-3.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="appendix-B.3-3.3">
|
||
<p id="appendix-B.3-3.3.1">It carries no task-level granularity, no parent references,
|
||
and no execution content.<a href="#appendix-B.3-3.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="appendix-B.3-3.4">
|
||
<p id="appendix-B.3-3.4.1">It cannot represent convergence (fan-in): when two independent
|
||
paths must both complete before a dependent task proceeds, a
|
||
linear "req_wl" string cannot express that relationship.<a href="#appendix-B.3-3.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="appendix-B.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-B.3-4" class="pilcrow">¶</a></p>
|
||
<p id="appendix-B.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"). 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-B.3-5" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="distributed-tracing-opentelemetry">
|
||
<section id="appendix-B.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-B.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-B.4-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="w3c-provenance-data-model-prov">
|
||
<section id="appendix-B.5">
|
||
<h3 id="name-w3c-provenance-data-model-p">
|
||
<a href="#name-w3c-provenance-data-model-p" class="section-name selfRef">W3C Provenance Data Model (PROV)</a>
|
||
</h3>
|
||
<p id="appendix-B.5-1">The W3C PROV Data Model defines an Entity-Activity-Agent ontology
|
||
for representing provenance information. PROV's concepts map
|
||
closely to ECT structures: PROV Activities correspond to ECT
|
||
tasks, PROV Agents correspond to WIMSE workloads, and PROV's
|
||
"wasInformedBy" relation corresponds to ECT "par" references.
|
||
However, PROV uses RDF/OWL ontologies designed for post-hoc
|
||
documentation, while ECTs are runtime-embeddable JWT tokens with
|
||
cryptographic signatures. ECT audit data could be exported to
|
||
PROV format for interoperability with provenance-aware systems.<a href="#appendix-B.5-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="scitt-supply-chain-integrity-transparency-and-trust">
|
||
<section id="appendix-B.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-B.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 transparent and auditable supply chain records.
|
||
ECTs and SCITT are complementary: the ECT "wid" claim can serve
|
||
as a correlation identifier in SCITT Signed Statements, linking
|
||
an ECT audit trail to a supply chain transparency record.<a href="#appendix-B.6-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="acknowledgments">
|
||
<section id="appendix-C">
|
||
<h2 id="name-acknowledgments">
|
||
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
|
||
</h2>
|
||
<p id="appendix-C-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-C-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="authors-addresses">
|
||
<section id="appendix-D">
|
||
<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>
|