Christian Nennemann
1385ec8af1
Remove all companion draft (ect-pol) references, regulatory compliance mappings, pre-defined extension keys, witness concept, pseudocode blocks, implementation guidance appendix, and redundant examples. Keep only the core token format, DAG validation, verification procedure, and one cross-organization use case. Draft reduced from ~40 pages to 27 pages. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
3248 lines
152 KiB
HTML
3248 lines
152 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en" class="Internet-Draft">
|
||
<head>
|
||
<meta charset="utf-8">
|
||
<meta content="Common,Latin" name="scripts">
|
||
<meta content="initial-scale=1.0" name="viewport">
|
||
<title>Execution Context Tokens for Distributed Agentic Workflows</title>
|
||
<meta content="Christian Nennemann" name="author">
|
||
<meta content="
|
||
This document defines Execution Context Tokens (ECTs), an extension
|
||
to the Workload Identity in Multi System Environments (WIMSE)
|
||
architecture for distributed agentic workflows. ECTs provide
|
||
signed, structured records of task execution order across
|
||
agent-to-agent communication. By extending WIMSE Workload Identity
|
||
Tokens with execution context claims in JSON Web Token (JWT)
|
||
format, this specification enables systems to maintain structured
|
||
audit trails of agent execution. ECTs use a directed acyclic
|
||
graph (DAG) structure to represent task dependencies and integrate
|
||
with WIMSE Workload Identity Tokens (WIT) using the same signing
|
||
model and cryptographic primitives. A new HTTP header field,
|
||
Execution-Context, is defined for transporting ECTs alongside
|
||
existing WIMSE headers.
|
||
" 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), an extension
|
||
to the Workload Identity in Multi System Environments (WIMSE)
|
||
architecture for distributed agentic workflows. ECTs provide
|
||
signed, structured records of task execution order across
|
||
agent-to-agent communication. By extending WIMSE Workload Identity
|
||
Tokens with execution context claims in JSON Web Token (JWT)
|
||
format, this specification enables systems to maintain structured
|
||
audit trails of agent execution. ECTs use a directed acyclic
|
||
graph (DAG) structure to represent task dependencies and integrate
|
||
with WIMSE Workload Identity Tokens (WIT) using the same signing
|
||
model and cryptographic primitives. A new HTTP header field,
|
||
Execution-Context, is defined for transporting ECTs alongside
|
||
existing WIMSE headers.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
<div id="status-of-memo">
|
||
<section id="section-boilerplate.1">
|
||
<h2 id="name-status-of-this-memo">
|
||
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
|
||
</h2>
|
||
<p id="section-boilerplate.1-1">
|
||
This Internet-Draft is submitted in full conformance with the
|
||
provisions of BCP 78 and BCP 79.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
|
||
<p id="section-boilerplate.1-2">
|
||
Internet-Drafts are working documents of the Internet Engineering Task
|
||
Force (IETF). Note that other groups may also distribute working
|
||
documents as Internet-Drafts. The list of current Internet-Drafts is
|
||
at <span><a href="https://datatracker.ietf.org/drafts/current/">https://datatracker.ietf.org/drafts/current/</a></span>.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
|
||
<p id="section-boilerplate.1-3">
|
||
Internet-Drafts are draft documents valid for a maximum of six months
|
||
and may be updated, replaced, or obsoleted by other documents at any
|
||
time. It is inappropriate to use Internet-Drafts as reference
|
||
material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
|
||
<p id="section-boilerplate.1-4">
|
||
This Internet-Draft will expire on 29 August 2026.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="copyright">
|
||
<section id="section-boilerplate.2">
|
||
<h2 id="name-copyright-notice">
|
||
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
|
||
</h2>
|
||
<p id="section-boilerplate.2-1">
|
||
Copyright (c) 2026 IETF Trust and the persons identified as the
|
||
document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
|
||
<p id="section-boilerplate.2-2">
|
||
This document is subject to BCP 78 and the IETF Trust's Legal
|
||
Provisions Relating to IETF Documents
|
||
(<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
|
||
publication of this document. Please review these documents
|
||
carefully, as they describe your rights and restrictions with
|
||
respect to this document. Code Components extracted from this
|
||
document must include Revised BSD License text as described in
|
||
Section 4.e of the Trust Legal Provisions and are provided without
|
||
warranty as described in the Revised BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="toc">
|
||
<section id="section-toc.1">
|
||
<a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
|
||
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
|
||
</h2>
|
||
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
|
||
<p id="section-toc.1-1.1.1"><a href="#section-1" class="auto internal xref">1</a>. <a href="#name-introduction" class="internal xref">Introduction</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1">
|
||
<p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="auto internal xref">1.1</a>. <a href="#name-motivation" class="internal xref">Motivation</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.2">
|
||
<p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="auto internal xref">1.2</a>. <a href="#name-problem-statement" class="internal xref">Problem Statement</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.3">
|
||
<p id="section-toc.1-1.1.2.3.1" class="keepWithNext"><a href="#section-1.3" class="auto internal xref">1.3</a>. <a href="#name-scope-and-applicability" class="internal xref">Scope and Applicability</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
|
||
<p id="section-toc.1-1.2.1"><a href="#section-2" class="auto internal xref">2</a>. <a href="#name-conventions-and-definitions" class="internal xref">Conventions and Definitions</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
|
||
<p id="section-toc.1-1.3.1"><a href="#section-3" class="auto internal xref">3</a>. <a href="#name-wimse-architecture-integrat" class="internal xref">WIMSE Architecture Integration</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
|
||
<p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="auto internal xref">3.1</a>. <a href="#name-wimse-foundation" class="internal xref">WIMSE Foundation</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
|
||
<p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="auto internal xref">3.2</a>. <a href="#name-extension-model" class="internal xref">Extension Model</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
|
||
<p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="auto internal xref">3.3</a>. <a href="#name-integration-points" class="internal xref">Integration Points</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
|
||
<p id="section-toc.1-1.4.1"><a href="#section-4" class="auto internal xref">4</a>. <a href="#name-execution-context-token-for" class="internal xref">Execution Context Token Format</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1">
|
||
<p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="auto internal xref">4.1</a>. <a href="#name-jose-header" class="internal xref">JOSE Header</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2">
|
||
<p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="auto internal xref">4.2</a>. <a href="#name-jwt-claims" class="internal xref">JWT Claims</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.1">
|
||
<p id="section-toc.1-1.4.2.2.2.1.1"><a href="#section-4.2.1" class="auto internal xref">4.2.1</a>. <a href="#name-standard-jwt-claims" class="internal xref">Standard JWT Claims</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.2">
|
||
<p id="section-toc.1-1.4.2.2.2.2.1"><a href="#section-4.2.2" class="auto internal xref">4.2.2</a>. <a href="#name-execution-context" class="internal xref">Execution Context</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.3">
|
||
<p id="section-toc.1-1.4.2.2.2.3.1"><a href="#section-4.2.3" class="auto internal xref">4.2.3</a>. <a href="#name-data-integrity" class="internal xref">Data Integrity</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.4">
|
||
<p id="section-toc.1-1.4.2.2.2.4.1"><a href="#section-4.2.4" class="auto internal xref">4.2.4</a>. <a href="#name-extensions" class="internal xref">Extensions</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3">
|
||
<p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="auto internal xref">4.3</a>. <a href="#name-complete-ect-example" class="internal xref">Complete ECT Example</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
|
||
<p id="section-toc.1-1.5.1"><a href="#section-5" class="auto internal xref">5</a>. <a href="#name-http-header-transport" class="internal xref">HTTP Header Transport</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.1">
|
||
<p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="auto internal xref">5.1</a>. <a href="#name-execution-context-header-fi" class="internal xref">Execution-Context Header Field</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
|
||
<p id="section-toc.1-1.6.1"><a href="#section-6" class="auto internal xref">6</a>. <a href="#name-dag-validation" class="internal xref">DAG Validation</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
|
||
<p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="auto internal xref">6.1</a>. <a href="#name-overview" class="internal xref">Overview</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
|
||
<p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="auto internal xref">6.2</a>. <a href="#name-validation-rules" class="internal xref">Validation Rules</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
|
||
<p id="section-toc.1-1.7.1"><a href="#section-7" class="auto internal xref">7</a>. <a href="#name-signature-and-token-verific" class="internal xref">Signature and Token Verification</a></p>
|
||
<ul class="compact toc ulBare ulEmpty">
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
|
||
<p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="auto internal xref">7.1</a>. <a href="#name-verification-procedure" class="internal xref">Verification Procedure</a></p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
|
||
<p id="section-toc.1-1.8.1"><a href="#section-8" class="auto internal xref">8</a>. <a href="#name-audit-ledger-interface" class="internal xref">Audit Ledger Interface</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
|
||
<p id="section-toc.1-1.9.1"><a href="#section-9" class="auto internal xref">9</a>. <a href="#name-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.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-threat-model" class="internal xref">Threat Model</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-self-assertion-limitation" class="internal xref">Self-Assertion Limitation</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-organizational-prerequisite" class="internal xref">Organizational Prerequisites</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.4">
|
||
<p id="section-toc.1-1.9.2.4.1"><a href="#section-9.4" class="auto internal xref">9.4</a>. <a href="#name-signature-verification" class="internal xref">Signature Verification</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.5">
|
||
<p id="section-toc.1-1.9.2.5.1"><a href="#section-9.5" class="auto internal xref">9.5</a>. <a href="#name-replay-attack-prevention" class="internal xref">Replay Attack Prevention</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.6">
|
||
<p id="section-toc.1-1.9.2.6.1"><a href="#section-9.6" class="auto internal xref">9.6</a>. <a href="#name-man-in-the-middle-protectio" class="internal xref">Man-in-the-Middle Protection</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.7">
|
||
<p id="section-toc.1-1.9.2.7.1"><a href="#section-9.7" class="auto internal xref">9.7</a>. <a href="#name-key-compromise" class="internal xref">Key Compromise</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.8">
|
||
<p id="section-toc.1-1.9.2.8.1"><a href="#section-9.8" class="auto internal xref">9.8</a>. <a href="#name-collusion-and-false-claims" class="internal xref">Collusion and False Claims</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.9">
|
||
<p id="section-toc.1-1.9.2.9.1"><a href="#section-9.9" class="auto internal xref">9.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.9.2.10">
|
||
<p id="section-toc.1-1.9.2.10.1"><a href="#section-9.10" class="auto internal xref">9.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.9.2.11">
|
||
<p id="section-toc.1-1.9.2.11.1"><a href="#section-9.11" class="auto internal xref">9.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.10">
|
||
<p id="section-toc.1-1.10.1"><a href="#section-10" class="auto internal xref">10</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.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-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.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-data-minimization" class="internal xref">Data Minimization</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-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.11">
|
||
<p id="section-toc.1-1.11.1"><a href="#section-11" class="auto internal xref">11</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.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-media-type-registration" class="internal xref">Media Type Registration</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-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.11.2.3">
|
||
<p id="section-toc.1-1.11.2.3.1"><a href="#section-11.3" class="auto internal xref">11.3</a>. <a href="#name-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.12">
|
||
<p id="section-toc.1-1.12.1"><a href="#section-12" class="auto internal xref">12</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.12.2.1">
|
||
<p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="auto internal xref">12.1</a>. <a href="#name-normative-references" class="internal xref">Normative References</a></p>
|
||
</li>
|
||
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.2">
|
||
<p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="auto internal xref">12.2</a>. <a href="#name-informative-references" class="internal xref">Informative References</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-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.13.2.1">
|
||
<p id="section-toc.1-1.13.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.14">
|
||
<p id="section-toc.1-1.14.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.14.2.1">
|
||
<p id="section-toc.1-1.14.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.14.2.2">
|
||
<p id="section-toc.1-1.14.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.14.2.3">
|
||
<p id="section-toc.1-1.14.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.14.2.4">
|
||
<p id="section-toc.1-1.14.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.14.2.5">
|
||
<p id="section-toc.1-1.14.2.5.1"><a href="#appendix-B.5" 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.15">
|
||
<p id="section-toc.1-1.15.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.16">
|
||
<p id="section-toc.1-1.16.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>
|
||
<div id="motivation">
|
||
<section id="section-1.1">
|
||
<h3 id="name-motivation">
|
||
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-motivation" class="section-name selfRef">Motivation</a>
|
||
</h3>
|
||
<p id="section-1.1-1">The Workload Identity in Multi System Environments (WIMSE)
|
||
framework <span>[<a href="#I-D.ietf-wimse-arch" class="cite xref">I-D.ietf-wimse-arch</a>]</span> provides robust workload
|
||
authentication through Workload Identity Tokens (WIT) and Workload
|
||
Proof Tokens (WPT). The WIMSE service-to-service protocol
|
||
<span>[<a href="#I-D.ietf-wimse-s2s-protocol" class="cite xref">I-D.ietf-wimse-s2s-protocol</a>]</span> defines how workloads authenticate
|
||
each other across call chains using the Workload-Identity and
|
||
Workload-Proof-Token HTTP headers.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
|
||
<p id="section-1.1-2">However, workload identity alone does not address execution
|
||
accountability. Knowing who performed an action does not record
|
||
what was done or in what order.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
|
||
<p id="section-1.1-3">Regulated environments increasingly deploy autonomous agents that
|
||
coordinate across organizational boundaries. Domains such as
|
||
healthcare, finance, and logistics require structured, auditable
|
||
records of automated decision-making and execution.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
|
||
<p id="section-1.1-4">This document defines an extension to the WIMSE architecture that
|
||
addresses the gap between workload identity and execution
|
||
accountability. WIMSE authenticates agents; this extension records
|
||
what they did and in what order.<a href="#section-1.1-4" class="pilcrow">¶</a></p>
|
||
<p id="section-1.1-5">As identified in <span>[<a href="#I-D.ni-wimse-ai-agent-identity" class="cite xref">I-D.ni-wimse-ai-agent-identity</a>]</span>, call context
|
||
in agentic workflows needs to be visible and preserved. ECTs
|
||
provide a mechanism to address this requirement with cryptographic
|
||
assurances.<a href="#section-1.1-5" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="problem-statement">
|
||
<section id="section-1.2">
|
||
<h3 id="name-problem-statement">
|
||
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-problem-statement" class="section-name selfRef">Problem Statement</a>
|
||
</h3>
|
||
<p id="section-1.2-1">Three core gaps exist in current approaches to regulated agentic
|
||
systems:<a href="#section-1.2-1" class="pilcrow">¶</a></p>
|
||
<ol start="1" type="1" class="normal type-1" id="section-1.2-2">
|
||
<li id="section-1.2-2.1">
|
||
<p id="section-1.2-2.1.1">WIMSE authenticates agents but does not record what they
|
||
actually did. A WIT proves "Agent A is authorized" but not
|
||
"Agent A executed Task X, producing Output Z."<a href="#section-1.2-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-1.2-2.2">
|
||
<p id="section-1.2-2.2.1">No standard mechanism exists to cryptographically order and
|
||
link task execution across a multi-agent workflow.<a href="#section-1.2-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-1.2-2.3">
|
||
<p id="section-1.2-2.3.1">No mechanism exists to reconstruct the complete execution
|
||
history of a distributed workflow for audit purposes.<a href="#section-1.2-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ol>
|
||
<p id="section-1.2-3">Existing observability tools such as distributed tracing
|
||
<span>[<a href="#OPENTELEMETRY" class="cite xref">OPENTELEMETRY</a>]</span> provide visibility for debugging and monitoring
|
||
but do not provide cryptographic assurances. Tracing data is not
|
||
cryptographically signed, not tamper-evident, and not designed for
|
||
regulatory audit scenarios.<a href="#section-1.2-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="scope-and-applicability">
|
||
<section id="section-1.3">
|
||
<h3 id="name-scope-and-applicability">
|
||
<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-scope-and-applicability" class="section-name selfRef">Scope and Applicability</a>
|
||
</h3>
|
||
<p id="section-1.3-1">This document defines:<a href="#section-1.3-1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-1.3-2.1">
|
||
<p id="section-1.3-2.1.1">The Execution Context Token (ECT) format (<a href="#ect-format" class="auto internal xref">Section 4</a>)<a href="#section-1.3-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.3-2.2">
|
||
<p id="section-1.3-2.2.1">DAG structure for task dependency ordering (<a href="#dag-validation" class="auto internal xref">Section 6</a>)<a href="#section-1.3-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.3-2.3">
|
||
<p id="section-1.3-2.3.1">Integration with the WIMSE identity framework
|
||
(<a href="#wimse-integration" class="auto internal xref">Section 3</a>)<a href="#section-1.3-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.3-2.4">
|
||
<p id="section-1.3-2.4.1">An HTTP header for ECT transport (<a href="#http-header" class="auto internal xref">Section 5</a>)<a href="#section-1.3-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.3-2.5">
|
||
<p id="section-1.3-2.5.1">Audit ledger interface requirements (<a href="#ledger-interface" class="auto internal xref">Section 8</a>)<a href="#section-1.3-2.5.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-1.3-3">The following are out of scope and are handled by WIMSE:<a href="#section-1.3-3" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-1.3-4.1">
|
||
<p id="section-1.3-4.1.1">Workload authentication and identity provisioning<a href="#section-1.3-4.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.3-4.2">
|
||
<p id="section-1.3-4.2.1">Key distribution and management<a href="#section-1.3-4.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.3-4.3">
|
||
<p id="section-1.3-4.3.1">Trust domain establishment and management<a href="#section-1.3-4.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-1.3-4.4">
|
||
<p id="section-1.3-4.4.1">Credential lifecycle management<a href="#section-1.3-4.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
</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="wimse-integration">
|
||
<section id="section-3">
|
||
<h2 id="name-wimse-architecture-integrat">
|
||
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-wimse-architecture-integrat" class="section-name selfRef">WIMSE Architecture Integration</a>
|
||
</h2>
|
||
<div id="wimse-foundation">
|
||
<section id="section-3.1">
|
||
<h3 id="name-wimse-foundation">
|
||
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-wimse-foundation" class="section-name selfRef">WIMSE Foundation</a>
|
||
</h3>
|
||
<p id="section-3.1-1">The WIMSE architecture <span>[<a href="#I-D.ietf-wimse-arch" class="cite xref">I-D.ietf-wimse-arch</a>]</span> defines:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-3.1-2.1">
|
||
<p id="section-3.1-2.1.1">Workload Identity Tokens (WIT) that prove a workload's identity
|
||
within a trust domain ("I am Agent X in trust domain Y")<a href="#section-3.1-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-3.1-2.2">
|
||
<p id="section-3.1-2.2.1">Workload Proof Tokens (WPT) that prove possession of the private
|
||
key associated with a WIT ("I control the key for Agent X")<a href="#section-3.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-3.1-2.3">
|
||
<p id="section-3.1-2.3.1">Multi-hop authentication via the service-to-service protocol
|
||
<span>[<a href="#I-D.ietf-wimse-s2s-protocol" class="cite xref">I-D.ietf-wimse-s2s-protocol</a>]</span><a href="#section-3.1-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-3.1-3">The following execution accountability needs are complementary to
|
||
the WIMSE scope and are not addressed by workload identity alone:<a href="#section-3.1-3" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-3.1-4.1">
|
||
<p id="section-3.1-4.1.1">Recording what agents actually do with their authenticated
|
||
identity<a href="#section-3.1-4.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-3.1-4.2">
|
||
<p id="section-3.1-4.2.1">Maintaining structured execution records<a href="#section-3.1-4.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-3.1-4.3">
|
||
<p id="section-3.1-4.3.1">Linking actions to their predecessors with cryptographic assurance<a href="#section-3.1-4.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="extension-model">
|
||
<section id="section-3.2">
|
||
<h3 id="name-extension-model">
|
||
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-extension-model" class="section-name selfRef">Extension Model</a>
|
||
</h3>
|
||
<p id="section-3.2-1">ECTs extend WIMSE by adding an execution accountability layer
|
||
between the identity layer and the application layer:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
|
||
<span id="name-wimse-extension-architectur"></span><div id="fig-layers">
|
||
<figure id="figure-1">
|
||
<div class="alignLeft art-ascii-art art-text artwork" id="section-3.2-2.1">
|
||
<pre>
|
||
+--------------------------------------------------+
|
||
| WIMSE Layer (Identity) |
|
||
| WIT: "I am Agent X (spiffe://td/agent/x)" |
|
||
| WPT: "I prove I control the key for Agent X" |
|
||
+--------------------------------------------------+
|
||
|
|
||
v
|
||
+--------------------------------------------------+
|
||
| ECT Layer (Execution Accountability) [This Spec]|
|
||
| ECT: "Task executed, dependencies met, |
|
||
| inputs/outputs hashed" |
|
||
+--------------------------------------------------+
|
||
|
|
||
v
|
||
+--------------------------------------------------+
|
||
| Optional: Audit Ledger (Immutable Record) |
|
||
| "ECTs MAY be appended to an audit ledger" |
|
||
+--------------------------------------------------+
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
|
||
<a href="#name-wimse-extension-architectur" class="selfRef">WIMSE Extension Architecture Layers</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
<p id="section-3.2-3">This extension reuses the WIMSE signing model, extends JWT claims
|
||
using standard JWT extensibility <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>, and maintains WIMSE
|
||
concepts including trust domains and workload identifiers.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="integration-points">
|
||
<section id="section-3.3">
|
||
<h3 id="name-integration-points">
|
||
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-integration-points" class="section-name selfRef">Integration Points</a>
|
||
</h3>
|
||
<p id="section-3.3-1">An ECT integrates with the WIMSE identity framework through the
|
||
following mechanisms:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-3.3-2.1">
|
||
<p id="section-3.3-2.1.1">The ECT JOSE header "kid" parameter <span class="bcp14">MUST</span> reference the public
|
||
key identifier from the agent's WIT.<a href="#section-3.3-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-3.3-2.2">
|
||
<p id="section-3.3-2.2.1">In WIMSE deployments, the ECT "iss" claim <span class="bcp14">SHOULD</span> use the WIMSE
|
||
workload identifier format (a SPIFFE ID <span>[<a href="#SPIFFE" class="cite xref">SPIFFE</a>]</span>).<a href="#section-3.3-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-3.3-2.3">
|
||
<p id="section-3.3-2.3.1">The ECT <span class="bcp14">MUST</span> be signed with the same private key associated
|
||
with the agent's WIT.<a href="#section-3.3-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-3.3-2.4">
|
||
<p id="section-3.3-2.4.1">The ECT signing algorithm (JOSE header "alg" parameter) <span class="bcp14">MUST</span>
|
||
match the algorithm used in the corresponding WIT.<a href="#section-3.3-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-3.3-3">When an agent makes an HTTP request to another agent, the
|
||
Execution-Context header is carried alongside WIMSE identity
|
||
headers:<a href="#section-3.3-3" class="pilcrow">¶</a></p>
|
||
<span id="name-http-header-stacking"></span><div id="fig-http-headers">
|
||
<figure id="figure-2">
|
||
<div class="alignLeft art-ascii-art art-text artwork" id="section-3.3-4.1">
|
||
<pre>
|
||
HTTP Request from Agent A to Agent B:
|
||
Workload-Identity: <WIT for Agent A>
|
||
Execution-Context: <ECT recording what A did>
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
|
||
<a href="#name-http-header-stacking" class="selfRef">HTTP Header Stacking</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
<p id="section-3.3-5">When a Workload Proof Token (WPT) is available per
|
||
<span>[<a href="#I-D.ietf-wimse-s2s-protocol" class="cite xref">I-D.ietf-wimse-s2s-protocol</a>]</span>, agents <span class="bcp14">SHOULD</span> include it
|
||
alongside the WIT and ECT. ECT verification does not depend
|
||
on the presence of a WPT; the ECT is independently verifiable
|
||
via the WIT public key.<a href="#section-3.3-5" class="pilcrow">¶</a></p>
|
||
<p id="section-3.3-6">The receiving agent (Agent B) verifies in order:<a href="#section-3.3-6" class="pilcrow">¶</a></p>
|
||
<ol start="1" type="1" class="normal type-1" id="section-3.3-7">
|
||
<li id="section-3.3-7.1">
|
||
<p id="section-3.3-7.1.1">WIT (WIMSE layer): Verifies Agent A's identity within the
|
||
trust domain. WPT verification, if present, per
|
||
<span>[<a href="#I-D.ietf-wimse-s2s-protocol" class="cite xref">I-D.ietf-wimse-s2s-protocol</a>]</span>.<a href="#section-3.3-7.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-3.3-7.2">
|
||
<p id="section-3.3-7.2.1">ECT (this extension): Records what Agent A did and what
|
||
precedent tasks exist.<a href="#section-3.3-7.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-3.3-7.3">
|
||
<p id="section-3.3-7.3.1">Ledger (if deployed): Appends the verified ECT to the audit
|
||
ledger.<a href="#section-3.3-7.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ol>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="ect-format">
|
||
<section id="section-4">
|
||
<h2 id="name-execution-context-token-for">
|
||
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-execution-context-token-for" class="section-name selfRef">Execution Context Token Format</a>
|
||
</h2>
|
||
<p id="section-4-1">An Execution Context Token is a JSON Web Token (JWT) <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>
|
||
signed as a JSON Web Signature (JWS) <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>. 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-4-1" class="pilcrow">¶</a></p>
|
||
<div id="jose-header">
|
||
<section id="section-4.1">
|
||
<h3 id="name-jose-header">
|
||
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-jose-header" class="section-name selfRef">JOSE Header</a>
|
||
</h3>
|
||
<p id="section-4.1-1">The ECT JOSE header <span class="bcp14">MUST</span> contain the following parameters:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
|
||
<span id="name-ect-jose-header-example"></span><div id="fig-header">
|
||
<figure id="figure-3">
|
||
<div class="lang-json sourcecode" id="section-4.1-2.1">
|
||
<pre>
|
||
{
|
||
"alg": "ES256",
|
||
"typ": "wimse-exec+jwt",
|
||
"kid": "agent-a-key-id-123"
|
||
}
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
|
||
<a href="#name-ect-jose-header-example" class="selfRef">ECT JOSE Header Example</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
<span class="break"></span><dl class="dlParallel" id="section-4.1-3">
|
||
<dt id="section-4.1-3.1">alg:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.1-3.2">
|
||
<p id="section-4.1-3.2.1"><span class="bcp14">REQUIRED</span>. The digital signature algorithm used to sign the ECT.
|
||
<span class="bcp14">MUST</span> match the algorithm in the corresponding WIT.
|
||
Implementations <span class="bcp14">MUST</span> support ES256 <span>[<a href="#RFC7518" class="cite xref">RFC7518</a>]</span>. The "alg"
|
||
value <span class="bcp14">MUST NOT</span> be "none". Symmetric algorithms (e.g., HS256,
|
||
HS384, HS512) <span class="bcp14">MUST NOT</span> be used, as ECTs require asymmetric
|
||
signatures for non-repudiation.<a href="#section-4.1-3.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.1-3.3">typ:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.1-3.4">
|
||
<p id="section-4.1-3.4.1"><span class="bcp14">REQUIRED</span>. <span class="bcp14">MUST</span> be set to "wimse-exec+jwt" to distinguish ECTs
|
||
from other JWT types, consistent with the WIMSE convention for
|
||
type parameter values.<a href="#section-4.1-3.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.1-3.5">kid:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.1-3.6">
|
||
<p id="section-4.1-3.6.1"><span class="bcp14">REQUIRED</span>. The key identifier referencing the public key from
|
||
the agent's WIT <span>[<a href="#RFC7517" class="cite xref">RFC7517</a>]</span>. Used by verifiers to look up the
|
||
correct public key for signature verification.<a href="#section-4.1-3.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="jwt-claims">
|
||
<section id="section-4.2">
|
||
<h3 id="name-jwt-claims">
|
||
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-jwt-claims" class="section-name selfRef">JWT Claims</a>
|
||
</h3>
|
||
<p id="section-4.2-1">The ECT payload contains both WIMSE-compatible standard JWT claims
|
||
and execution context claims defined by this specification.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
|
||
<div id="standard-jwt-claims">
|
||
<section id="section-4.2.1">
|
||
<h4 id="name-standard-jwt-claims">
|
||
<a href="#section-4.2.1" class="section-number selfRef">4.2.1. </a><a href="#name-standard-jwt-claims" class="section-name selfRef">Standard JWT Claims</a>
|
||
</h4>
|
||
<p id="section-4.2.1-1">The following standard JWT claims <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span> <span class="bcp14">MUST</span> be present in
|
||
every ECT:<a href="#section-4.2.1-1" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-4.2.1-2">
|
||
<dt id="section-4.2.1-2.1">iss:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.1-2.2">
|
||
<p id="section-4.2.1-2.2.1"><span class="bcp14">REQUIRED</span>. StringOrURI. A URI identifying the issuer of the
|
||
ECT. In WIMSE deployments, this <span class="bcp14">SHOULD</span> be the workload's
|
||
SPIFFE ID in the format <code>spiffe://<trust-domain>/<path></code>,
|
||
matching the "sub" claim of the agent's WIT. Non-WIMSE
|
||
deployments <span class="bcp14">MAY</span> use other URI schemes (e.g., HTTPS URLs or
|
||
URN:UUID identifiers).<a href="#section-4.2.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.2.1-2.3">aud:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.1-2.4">
|
||
<p id="section-4.2.1-2.4.1"><span class="bcp14">REQUIRED</span>. StringOrURI or array of StringOrURI. The intended
|
||
recipient(s) of the ECT. Because ECTs serve as both inter-agent
|
||
messages and audit records, the "aud" claim <span class="bcp14">SHOULD</span> contain the
|
||
identifiers of all entities that will verify the ECT. In
|
||
practice this means:<a href="#section-4.2.1-2.4.1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-4.2.1-2.4.2.1">
|
||
<p id="section-4.2.1-2.4.2.1.1"><strong>Point-to-point delivery</strong>: when an ECT is sent from one
|
||
agent to a single next agent, "aud" contains that agent's
|
||
workload identity. The receiving agent verifies the ECT and
|
||
forwards it to the ledger on behalf of the issuer.<a href="#section-4.2.1-2.4.2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-4.2.1-2.4.2.2">
|
||
<p id="section-4.2.1-2.4.2.2.1"><strong>Direct-to-ledger submission</strong>: when an ECT is submitted
|
||
directly to the audit ledger (e.g., after a join or at
|
||
workflow completion), "aud" contains the ledger's identity.<a href="#section-4.2.1-2.4.2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-4.2.1-2.4.2.3">
|
||
<p id="section-4.2.1-2.4.2.3.1"><strong>Multi-audience</strong>: when an ECT must be verified by both the
|
||
next agent and the ledger independently, "aud" <span class="bcp14">MUST</span> be an
|
||
array containing both identifiers (e.g.,
|
||
["spiffe://example.com/agent/next",
|
||
"spiffe://example.com/system/ledger"]). Each verifier checks
|
||
that its own identity appears in the array.<a href="#section-4.2.1-2.4.2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-4.2.1-2.4.3">In multi-parent (join) scenarios where a task depends on ECTs
|
||
from multiple parent agents, the joining agent creates a new ECT
|
||
with the parent task IDs in "par". The "aud" of this new ECT
|
||
is set according to the rules above based on where the ECT will
|
||
be delivered — it is independent of the "aud" values in the
|
||
parent ECTs.<a href="#section-4.2.1-2.4.3" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.2.1-2.5">iat:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.1-2.6">
|
||
<p id="section-4.2.1-2.6.1"><span class="bcp14">REQUIRED</span>. NumericDate. The time at which the ECT was issued.
|
||
The ECT records a completed action, so the "iat" value reflects
|
||
when the record was created, not when task execution began.<a href="#section-4.2.1-2.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.2.1-2.7">exp:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.1-2.8">
|
||
<p id="section-4.2.1-2.8.1"><span class="bcp14">REQUIRED</span>. NumericDate. The expiration time of the ECT.
|
||
Implementations <span class="bcp14">SHOULD</span> set this to 5 to 15 minutes after "iat"
|
||
to limit the replay window while allowing for reasonable clock
|
||
skew and processing time.<a href="#section-4.2.1-2.8.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
<p id="section-4.2.1-3">The standard JWT "nbf" (Not Before) claim is not used in ECTs
|
||
because ECTs record completed actions and are valid immediately
|
||
upon issuance.<a href="#section-4.2.1-3" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-4.2.1-4">
|
||
<dt id="section-4.2.1-4.1">jti:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.1-4.2">
|
||
<p id="section-4.2.1-4.2.1"><span class="bcp14">REQUIRED</span>. String. A globally unique identifier for both the
|
||
ECT and the task it records, in UUID format <span>[<a href="#RFC9562" class="cite xref">RFC9562</a>]</span>. Since
|
||
each ECT represents exactly one task, "jti" serves as both the
|
||
token identifier (for replay detection) and the task identifier
|
||
(for DAG parent references in "par"). Receivers <span class="bcp14">MUST</span> reject
|
||
ECTs whose "jti" has already been seen within the expiration
|
||
window. When "wid" is present, uniqueness is scoped to the
|
||
workflow; when "wid" is absent, uniqueness <span class="bcp14">MUST</span> be enforced
|
||
globally across the ECT store.<a href="#section-4.2.1-4.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="exec-claims">
|
||
<section id="section-4.2.2">
|
||
<h4 id="name-execution-context">
|
||
<a href="#section-4.2.2" class="section-number selfRef">4.2.2. </a><a href="#name-execution-context" class="section-name selfRef">Execution Context</a>
|
||
</h4>
|
||
<p id="section-4.2.2-1">The following claims are defined by this specification:<a href="#section-4.2.2-1" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-4.2.2-2">
|
||
<dt id="section-4.2.2-2.1">wid:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.2-2.2">
|
||
<p id="section-4.2.2-2.2.1"><span class="bcp14">OPTIONAL</span>. String. A workflow identifier that groups related
|
||
ECTs into a single workflow. When present, <span class="bcp14">MUST</span> be a UUID
|
||
<span>[<a href="#RFC9562" class="cite xref">RFC9562</a>]</span>.<a href="#section-4.2.2-2.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.2.2-2.3">exec_act:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.2-2.4">
|
||
<p id="section-4.2.2-2.4.1"><span class="bcp14">REQUIRED</span>. String. The action or task type identifier describing
|
||
what the agent performed (e.g., "process_payment",
|
||
"validate_safety", "calculate_dosage"). Note: this claim is
|
||
intentionally named "exec_act" rather than "act" to avoid
|
||
collision with the "act" (Actor) claim registered by
|
||
<span>[<a href="#RFC8693" class="cite xref">RFC8693</a>]</span>.<a href="#section-4.2.2-2.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.2.2-2.5">par:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.2-2.6">
|
||
<p id="section-4.2.2-2.6.1"><span class="bcp14">REQUIRED</span>. Array of strings. Parent task identifiers
|
||
representing DAG dependencies. Each element <span class="bcp14">MUST</span> be the "jti"
|
||
value of a previously verified ECT. An empty array indicates
|
||
a root task with no dependencies. A workflow <span class="bcp14">MAY</span> contain
|
||
multiple root tasks. Parent ECTs may have passed their own
|
||
"exp" time; ECT expiration applies to the verification window
|
||
of the ECT itself, not to its validity as a parent reference
|
||
in the ECT store.<a href="#section-4.2.2-2.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="data-integrity-claims">
|
||
<section id="section-4.2.3">
|
||
<h4 id="name-data-integrity">
|
||
<a href="#section-4.2.3" class="section-number selfRef">4.2.3. </a><a href="#name-data-integrity" class="section-name selfRef">Data Integrity</a>
|
||
</h4>
|
||
<p id="section-4.2.3-1">The following claims provide integrity verification for task
|
||
inputs and outputs without revealing the data itself:<a href="#section-4.2.3-1" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-4.2.3-2">
|
||
<dt id="section-4.2.3-2.1">inp_hash:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.3-2.2">
|
||
<p id="section-4.2.3-2.2.1"><span class="bcp14">OPTIONAL</span>. String. A cryptographic hash of the input data,
|
||
formatted as "hash-algorithm:base64url-encoded-hash" (e.g.,
|
||
"sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The
|
||
hash algorithm identifier <span class="bcp14">MUST</span> be a lowercase value from the
|
||
IANA Named Information Hash Algorithm Registry (e.g., "sha-256",
|
||
"sha-384", "sha-512"). Implementations <span class="bcp14">MUST</span> support "sha-256"
|
||
and <span class="bcp14">SHOULD</span> use "sha-256" unless a stronger algorithm is
|
||
required. Implementations <span class="bcp14">MUST NOT</span> accept hash algorithms
|
||
weaker than SHA-256 (e.g., MD5, SHA-1). The hash <span class="bcp14">MUST</span> be
|
||
computed over the raw octets of the input data.<a href="#section-4.2.3-2.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-4.2.3-2.3">out_hash:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.3-2.4">
|
||
<p id="section-4.2.3-2.4.1"><span class="bcp14">OPTIONAL</span>. String. A cryptographic hash of the output data,
|
||
using the same format and algorithm requirements as "inp_hash".<a href="#section-4.2.3-2.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="extension-claims">
|
||
<section id="section-4.2.4">
|
||
<h4 id="name-extensions">
|
||
<a href="#section-4.2.4" class="section-number selfRef">4.2.4. </a><a href="#name-extensions" class="section-name selfRef">Extensions</a>
|
||
</h4>
|
||
<span class="break"></span><dl class="dlParallel" id="section-4.2.4-1">
|
||
<dt id="section-4.2.4-1.1">ext:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-4.2.4-1.2">
|
||
<p id="section-4.2.4-1.2.1"><span class="bcp14">OPTIONAL</span>. Object. An extension object for domain-specific
|
||
claims not defined by this specification. Implementations
|
||
that do not understand extension claims <span class="bcp14">MUST</span> ignore them.<a href="#section-4.2.4-1.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
<p id="section-4.2.4-2">To avoid key collisions between different domains, extension
|
||
key names <span class="bcp14">SHOULD</span> use reverse domain notation (e.g.,
|
||
"com.example.custom_field") to avoid collisions between
|
||
independently developed extensions. To prevent abuse and
|
||
excessive token size, the serialized JSON representation of
|
||
the "ext" object <span class="bcp14">SHOULD NOT</span> exceed 4096 bytes, and the JSON
|
||
nesting depth within the "ext" object <span class="bcp14">SHOULD NOT</span> exceed 5
|
||
levels. Implementations <span class="bcp14">SHOULD</span> reject ECTs whose "ext" claim
|
||
exceeds these limits.<a href="#section-4.2.4-2" class="pilcrow">¶</a></p>
|
||
<p id="section-4.2.4-3">Extension keys for domain-specific use cases <span class="bcp14">MAY</span> be defined in
|
||
future documents.<a href="#section-4.2.4-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="complete-ect-example">
|
||
<section id="section-4.3">
|
||
<h3 id="name-complete-ect-example">
|
||
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-complete-ect-example" class="section-name selfRef">Complete ECT Example</a>
|
||
</h3>
|
||
<p id="section-4.3-1">The following is a complete ECT payload example:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
|
||
<span id="name-complete-ect-payload-exampl"></span><div id="fig-full-ect">
|
||
<figure id="figure-4">
|
||
<div class="lang-json sourcecode" id="section-4.3-2.1">
|
||
<pre>
|
||
{
|
||
"iss": "spiffe://example.com/agent/clinical",
|
||
"aud": "spiffe://example.com/agent/safety",
|
||
"iat": 1772064150,
|
||
"exp": 1772064750,
|
||
"jti": "550e8400-e29b-41d4-a716-446655440001",
|
||
|
||
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
|
||
"exec_act": "recommend_treatment",
|
||
"par": [],
|
||
|
||
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
|
||
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
|
||
}
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
|
||
<a href="#name-complete-ect-payload-exampl" class="selfRef">Complete ECT Payload Example</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="http-header">
|
||
<section id="section-5">
|
||
<h2 id="name-http-header-transport">
|
||
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-http-header-transport" class="section-name selfRef">HTTP Header Transport</a>
|
||
</h2>
|
||
<div id="execution-context-header-field">
|
||
<section id="section-5.1">
|
||
<h3 id="name-execution-context-header-fi">
|
||
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-execution-context-header-fi" class="section-name selfRef">Execution-Context Header Field</a>
|
||
</h3>
|
||
<p id="section-5.1-1">This specification defines the Execution-Context HTTP header field
|
||
<span>[<a href="#RFC9110" class="cite xref">RFC9110</a>]</span> for transporting ECTs between agents.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
|
||
<p id="section-5.1-2">The header field value is the ECT in JWS Compact Serialization
|
||
format <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>. The value consists of three Base64url-encoded
|
||
parts separated by period (".") characters.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
|
||
<p id="section-5.1-3">An agent sending a request to another agent includes the
|
||
Execution-Context header alongside the WIMSE Workload-Identity
|
||
header:<a href="#section-5.1-3" class="pilcrow">¶</a></p>
|
||
<span id="name-http-request-with-ect-heade"></span><div id="fig-http-example">
|
||
<figure id="figure-5">
|
||
<div class="alignLeft art-text artwork" id="section-5.1-4.1">
|
||
<pre>
|
||
GET /api/safety-check HTTP/1.1
|
||
Host: safety-agent.example.com
|
||
Workload-Identity: eyJhbGci...WIT...
|
||
Execution-Context: eyJhbGci...ECT...
|
||
</pre>
|
||
</div>
|
||
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
|
||
<a href="#name-http-request-with-ect-heade" class="selfRef">HTTP Request with ECT Header</a>
|
||
</figcaption></figure>
|
||
</div>
|
||
<p id="section-5.1-5">When multiple parent tasks contribute context to a single request,
|
||
multiple Execution-Context header field lines <span class="bcp14">MAY</span> be included, each
|
||
carrying a separate ECT in JWS Compact Serialization format.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
|
||
<p id="section-5.1-6">When a receiver processes multiple Execution-Context headers, it
|
||
<span class="bcp14">MUST</span> individually verify each ECT per the procedure in
|
||
<a href="#verification" class="auto internal xref">Section 7</a>. If any single ECT fails verification, the
|
||
receiver <span class="bcp14">MUST</span> reject the entire request. The set of verified
|
||
parent task IDs across all received ECTs represents the complete
|
||
set of parent dependencies available for the receiving agent's
|
||
subsequent ECT.<a href="#section-5.1-6" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="dag-validation">
|
||
<section id="section-6">
|
||
<h2 id="name-dag-validation">
|
||
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-dag-validation" class="section-name selfRef">DAG Validation</a>
|
||
</h2>
|
||
<div id="overview">
|
||
<section id="section-6.1">
|
||
<h3 id="name-overview">
|
||
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-overview" class="section-name selfRef">Overview</a>
|
||
</h3>
|
||
<p id="section-6.1-1">ECTs form a Directed Acyclic Graph (DAG) where each task
|
||
references its parent tasks via the "par" claim. This structure
|
||
provides a cryptographically signed record of execution ordering,
|
||
enabling auditors to reconstruct the complete workflow and verify
|
||
that required predecessor tasks were recorded before dependent
|
||
tasks.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
|
||
<p id="section-6.1-2">DAG validation is performed against the ECT store — either an
|
||
audit ledger or the set of parent ECTs received inline.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="validation-rules">
|
||
<section id="section-6.2">
|
||
<h3 id="name-validation-rules">
|
||
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-validation-rules" class="section-name selfRef">Validation Rules</a>
|
||
</h3>
|
||
<p id="section-6.2-1">When receiving and verifying an ECT, implementations <span class="bcp14">MUST</span> perform
|
||
the following DAG validation steps:<a href="#section-6.2-1" class="pilcrow">¶</a></p>
|
||
<ol start="1" type="1" class="normal type-1" id="section-6.2-2">
|
||
<li id="section-6.2-2.1">
|
||
<p id="section-6.2-2.1.1">Task ID Uniqueness: The "jti" claim <span class="bcp14">MUST</span> be unique within the
|
||
applicable scope (the workflow identified by "wid", or the
|
||
entire ECT store if "wid" is absent). If an ECT with the same
|
||
"jti" already exists, the ECT <span class="bcp14">MUST</span> be rejected.<a href="#section-6.2-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.2-2.2">
|
||
<p id="section-6.2-2.2.1">Parent Existence: Every task identifier listed in the "par"
|
||
array <span class="bcp14">MUST</span> correspond to a task that is available in the ECT
|
||
store (either previously recorded in the ledger or received
|
||
inline as a verified parent ECT). If any parent task is not
|
||
found, the ECT <span class="bcp14">MUST</span> be rejected.<a href="#section-6.2-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.2-2.3">
|
||
<p id="section-6.2-2.3.1">Temporal Ordering: The "iat" value of every parent task <span class="bcp14">MUST NOT</span> be greater than the "iat" value of the current task plus a
|
||
configurable clock skew tolerance (<span class="bcp14">RECOMMENDED</span>: 30 seconds).
|
||
That is, for each parent: <code>parent.iat < child.iat +
|
||
clock_skew_tolerance</code>. The tolerance accounts for clock skew
|
||
between agents; it does not guarantee strict causal ordering
|
||
from timestamps alone. Causal ordering is primarily enforced
|
||
by the DAG structure (parent existence in the ECT store), not by
|
||
timestamps. If any parent task violates this constraint, the
|
||
ECT <span class="bcp14">MUST</span> be rejected.<a href="#section-6.2-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.2-2.4">
|
||
<p id="section-6.2-2.4.1">Acyclicity: Following the chain of parent references <span class="bcp14">MUST NOT</span>
|
||
lead back to the current ECT's "jti". If a cycle is detected,
|
||
the ECT <span class="bcp14">MUST</span> be rejected.<a href="#section-6.2-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-6.2-2.5">
|
||
<p id="section-6.2-2.5.1">Trust Domain Consistency: Parent tasks <span class="bcp14">SHOULD</span> belong to the
|
||
same trust domain or to a trust domain with which a federation
|
||
relationship has been established.<a href="#section-6.2-2.5.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ol>
|
||
<p id="section-6.2-3">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-6.2-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="verification">
|
||
<section id="section-7">
|
||
<h2 id="name-signature-and-token-verific">
|
||
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-signature-and-token-verific" class="section-name selfRef">Signature and Token Verification</a>
|
||
</h2>
|
||
<div id="verification-procedure">
|
||
<section id="section-7.1">
|
||
<h3 id="name-verification-procedure">
|
||
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-verification-procedure" class="section-name selfRef">Verification Procedure</a>
|
||
</h3>
|
||
<p id="section-7.1-1">When an agent receives an ECT, it <span class="bcp14">MUST</span> perform the following
|
||
verification steps in order:<a href="#section-7.1-1" class="pilcrow">¶</a></p>
|
||
<ol start="1" type="1" class="normal type-1" id="section-7.1-2">
|
||
<li id="section-7.1-2.1">
|
||
<p id="section-7.1-2.1.1">Parse the JWS Compact Serialization to extract the JOSE header,
|
||
payload, and signature components per <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>.<a href="#section-7.1-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.2">
|
||
<p id="section-7.1-2.2.1">Verify that the "typ" header parameter is "wimse-exec+jwt".<a href="#section-7.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.3">
|
||
<p id="section-7.1-2.3.1">Verify that the "alg" header parameter is not "none" and is
|
||
not a symmetric algorithm.<a href="#section-7.1-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.4">
|
||
<p id="section-7.1-2.4.1">Verify the "kid" header parameter references a known, valid
|
||
public key from a WIT within the trust domain.<a href="#section-7.1-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.5">
|
||
<p id="section-7.1-2.5.1">Retrieve the public key identified by "kid" and verify the JWS
|
||
signature per <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span> Section 5.2.<a href="#section-7.1-2.5.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.6">
|
||
<p id="section-7.1-2.6.1">Verify that the signing key identified by "kid" has not been
|
||
revoked within the trust domain. Implementations <span class="bcp14">MUST</span> check
|
||
the key's revocation status using the trust domain's key
|
||
lifecycle mechanism (e.g., certificate revocation list, OCSP,
|
||
or SPIFFE trust bundle updates).<a href="#section-7.1-2.6.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.7">
|
||
<p id="section-7.1-2.7.1">Verify the "alg" header parameter matches the algorithm in the
|
||
corresponding WIT.<a href="#section-7.1-2.7.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.8">
|
||
<p id="section-7.1-2.8.1">Verify the "iss" claim matches the "sub" claim of the WIT
|
||
associated with the "kid" public key.<a href="#section-7.1-2.8.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.9">
|
||
<p id="section-7.1-2.9.1">Verify the "aud" claim contains the verifier's own workload
|
||
identity. When "aud" is an array, it is sufficient that the
|
||
verifier's identity appears as one element; the presence of
|
||
other audience values does not cause verification failure.
|
||
When the verifier is the audit ledger, the ledger's own
|
||
identity <span class="bcp14">MUST</span> appear in "aud".<a href="#section-7.1-2.9.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.10">
|
||
<p id="section-7.1-2.10.1">Verify the "exp" claim indicates the ECT has not expired.<a href="#section-7.1-2.10.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.11">
|
||
<p id="section-7.1-2.11.1">Verify the "iat" claim is not unreasonably far in the past
|
||
(implementation-specific threshold, <span class="bcp14">RECOMMENDED</span> maximum of
|
||
15 minutes) and is not unreasonably far in the future
|
||
(<span class="bcp14">RECOMMENDED</span>: no more than 30 seconds ahead of the
|
||
verifier's current time, to account for clock skew).<a href="#section-7.1-2.11.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.12">
|
||
<p id="section-7.1-2.12.1">Verify all required claims ("jti", "exec_act", "par") are
|
||
present and well-formed.<a href="#section-7.1-2.12.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.13">
|
||
<p id="section-7.1-2.13.1">Perform DAG validation per <a href="#dag-validation" class="auto internal xref">Section 6</a>.<a href="#section-7.1-2.13.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-7.1-2.14">
|
||
<p id="section-7.1-2.14.1">If all checks pass and an audit ledger is deployed, the ECT
|
||
<span class="bcp14">SHOULD</span> be appended to the ledger.<a href="#section-7.1-2.14.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ol>
|
||
<p id="section-7.1-3">If any verification step fails, the ECT <span class="bcp14">MUST</span> be rejected and the
|
||
failure <span class="bcp14">MUST</span> be logged for audit purposes. Error messages
|
||
<span class="bcp14">SHOULD NOT</span> reveal whether specific parent task IDs exist in the
|
||
ECT store, to prevent information disclosure.<a href="#section-7.1-3" class="pilcrow">¶</a></p>
|
||
<p id="section-7.1-4">When ECT verification fails during HTTP request processing, the
|
||
receiving agent <span class="bcp14">SHOULD</span> respond with HTTP 403 (Forbidden) if the
|
||
WIT is valid but the ECT is invalid, and HTTP 401
|
||
(Unauthorized) if the ECT signature verification fails. The
|
||
response body <span class="bcp14">SHOULD</span> include a generic error indicator without
|
||
revealing which specific verification step failed. The receiving
|
||
agent <span class="bcp14">MUST NOT</span> process the requested action when ECT verification
|
||
fails.<a href="#section-7.1-4" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="ledger-interface">
|
||
<section id="section-8">
|
||
<h2 id="name-audit-ledger-interface">
|
||
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-audit-ledger-interface" class="section-name selfRef">Audit Ledger Interface</a>
|
||
</h2>
|
||
<p id="section-8-1">ECTs <span class="bcp14">MAY</span> be recorded in an immutable audit ledger for compliance
|
||
verification and post-hoc analysis. A ledger is <span class="bcp14">RECOMMENDED</span> for
|
||
regulated environments but is not required for point-to-point
|
||
operation. This specification does not mandate a specific storage
|
||
technology. Implementations <span class="bcp14">MAY</span> use append-only logs, databases
|
||
with cryptographic commitment schemes, distributed ledgers, or
|
||
any storage mechanism that provides the required properties.<a href="#section-8-1" class="pilcrow">¶</a></p>
|
||
<p id="section-8-2">When an audit ledger is deployed, the implementation <span class="bcp14">MUST</span> provide:<a href="#section-8-2" class="pilcrow">¶</a></p>
|
||
<ol start="1" type="1" class="normal type-1" id="section-8-3">
|
||
<li id="section-8-3.1">
|
||
<p id="section-8-3.1.1">Append-only semantics: Once an ECT is recorded, it <span class="bcp14">MUST NOT</span> be
|
||
modified or deleted.<a href="#section-8-3.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-8-3.2">
|
||
<p id="section-8-3.2.1">Ordering: The ledger <span class="bcp14">MUST</span> maintain a total ordering of ECT
|
||
entries via a monotonically increasing sequence number.<a href="#section-8-3.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-8-3.3">
|
||
<p id="section-8-3.3.1">Lookup by ECT ID: The ledger <span class="bcp14">MUST</span> support efficient retrieval
|
||
of ECT entries by "jti" value.<a href="#section-8-3.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li id="section-8-3.4">
|
||
<p id="section-8-3.4.1">Integrity verification: The ledger <span class="bcp14">SHOULD</span> provide a mechanism
|
||
to verify that no entries have been tampered with (e.g.,
|
||
hash chains or Merkle trees).<a href="#section-8-3.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ol>
|
||
<p id="section-8-4">The ledger <span class="bcp14">SHOULD</span> be maintained by an entity independent of the
|
||
workflow agents to reduce the risk of collusion.<a href="#section-8-4" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="security-considerations">
|
||
<section id="section-9">
|
||
<h2 id="name-security-considerations">
|
||
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
|
||
</h2>
|
||
<p id="section-9-1">This section addresses security considerations following the
|
||
guidance in <span>[<a href="#RFC3552" class="cite xref">RFC3552</a>]</span>.<a href="#section-9-1" class="pilcrow">¶</a></p>
|
||
<div id="threat-model">
|
||
<section id="section-9.1">
|
||
<h3 id="name-threat-model">
|
||
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-threat-model" class="section-name selfRef">Threat Model</a>
|
||
</h3>
|
||
<p id="section-9.1-1">The following threat actors are considered:<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">Malicious agent (insider threat): An agent within the trust
|
||
domain that intentionally creates false ECT claims.<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">Compromised agent (external attacker): An agent whose private
|
||
key has been obtained by an external attacker.<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">Ledger tamperer: An entity attempting to modify or delete ledger
|
||
entries after they have been recorded.<a href="#section-9.1-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.1-2.4">
|
||
<p id="section-9.1-2.4.1">Time manipulator: An entity attempting to manipulate timestamps
|
||
to alter perceived execution ordering.<a href="#section-9.1-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="self-assertion-limitation">
|
||
<section id="section-9.2">
|
||
<h3 id="name-self-assertion-limitation">
|
||
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-self-assertion-limitation" class="section-name selfRef">Self-Assertion Limitation</a>
|
||
</h3>
|
||
<p id="section-9.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-9.2-1" class="pilcrow">¶</a></p>
|
||
<p id="section-9.2-2">ECTs do not independently verify that:<a href="#section-9.2-2" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-9.2-3.1">
|
||
<p id="section-9.2-3.1.1">The claimed execution actually occurred as described<a href="#section-9.2-3.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.2-3.2">
|
||
<p id="section-9.2-3.2.1">The input/output hashes correspond to the actual data processed<a href="#section-9.2-3.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.2-3.3">
|
||
<p id="section-9.2-3.3.1">The agent faithfully performed the stated action<a href="#section-9.2-3.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-9.2-4">The trustworthiness of ECT claims depends on the trustworthiness
|
||
of the signing agent and the integrity of the broader deployment
|
||
environment.<a href="#section-9.2-4" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="organizational-prerequisites">
|
||
<section id="section-9.3">
|
||
<h3 id="name-organizational-prerequisite">
|
||
<a href="#section-9.3" class="section-number selfRef">9.3. </a><a href="#name-organizational-prerequisite" class="section-name selfRef">Organizational Prerequisites</a>
|
||
</h3>
|
||
<p id="section-9.3-1">ECTs operate within a broader trust framework. The guarantees
|
||
provided by ECTs are only meaningful when the following
|
||
organizational controls are in place:<a href="#section-9.3-1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-9.3-2.1">
|
||
<p id="section-9.3-2.1.1">Key management governance: Controls over who provisions agent
|
||
keys and how keys are protected.<a href="#section-9.3-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.3-2.2">
|
||
<p id="section-9.3-2.2.1">Ledger integrity governance: The ledger is maintained by an
|
||
entity independent of the workflow agents.<a href="#section-9.3-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.3-2.3">
|
||
<p id="section-9.3-2.3.1">Agent deployment governance: Agents are deployed and maintained
|
||
in a manner that preserves their integrity.<a href="#section-9.3-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="signature-verification">
|
||
<section id="section-9.4">
|
||
<h3 id="name-signature-verification">
|
||
<a href="#section-9.4" class="section-number selfRef">9.4. </a><a href="#name-signature-verification" class="section-name selfRef">Signature Verification</a>
|
||
</h3>
|
||
<p id="section-9.4-1">ECTs <span class="bcp14">MUST</span> be signed with the agent's private key using JWS
|
||
<span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>. The signature algorithm <span class="bcp14">MUST</span> match the algorithm
|
||
specified in the agent's WIT. Receivers <span class="bcp14">MUST</span> verify the ECT
|
||
signature against the WIT public key before processing any
|
||
claims. Receivers <span class="bcp14">MUST</span> verify that the signing key has not been
|
||
revoked within the trust domain (see step 6 in
|
||
<a href="#verification" class="auto internal xref">Section 7</a>).<a href="#section-9.4-1" class="pilcrow">¶</a></p>
|
||
<p id="section-9.4-2">If signature verification fails or if the signing key has been
|
||
revoked, the ECT <span class="bcp14">MUST</span> be rejected entirely and the failure <span class="bcp14">MUST</span>
|
||
be logged.<a href="#section-9.4-2" class="pilcrow">¶</a></p>
|
||
<p id="section-9.4-3">Implementations <span class="bcp14">MUST</span> use established JWS libraries and <span class="bcp14">MUST NOT</span>
|
||
implement custom signature verification.<a href="#section-9.4-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="replay-attack-prevention">
|
||
<section id="section-9.5">
|
||
<h3 id="name-replay-attack-prevention">
|
||
<a href="#section-9.5" class="section-number selfRef">9.5. </a><a href="#name-replay-attack-prevention" class="section-name selfRef">Replay Attack Prevention</a>
|
||
</h3>
|
||
<p id="section-9.5-1">ECTs include short expiration times (<span class="bcp14">RECOMMENDED</span>: 5-15 minutes) to
|
||
limit the window for replay attacks. The "aud" claim restricts
|
||
replay to unintended recipients: an ECT intended for Agent B
|
||
will be rejected by Agent C. The "iat" claim enables receivers to
|
||
reject ECTs that are too old, even if not yet expired.<a href="#section-9.5-1" class="pilcrow">¶</a></p>
|
||
<p id="section-9.5-2">The DAG structure provides additional replay protection: an ECT
|
||
referencing parent tasks that already have a recorded child task
|
||
with the same action can be flagged as a potential replay.<a href="#section-9.5-2" class="pilcrow">¶</a></p>
|
||
<p id="section-9.5-3">Implementations <span class="bcp14">MUST</span> maintain a cache of recently-seen "jti"
|
||
values to detect replayed ECTs within the expiration window.
|
||
An ECT with a duplicate "jti" value <span class="bcp14">MUST</span> be rejected.<a href="#section-9.5-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="man-in-the-middle-protection">
|
||
<section id="section-9.6">
|
||
<h3 id="name-man-in-the-middle-protectio">
|
||
<a href="#section-9.6" class="section-number selfRef">9.6. </a><a href="#name-man-in-the-middle-protectio" class="section-name selfRef">Man-in-the-Middle Protection</a>
|
||
</h3>
|
||
<p id="section-9.6-1">ECTs do not replace transport-layer security. ECTs <span class="bcp14">MUST</span> be
|
||
transmitted over TLS or mTLS connections. When used with the WIMSE
|
||
service-to-service protocol <span>[<a href="#I-D.ietf-wimse-s2s-protocol" class="cite xref">I-D.ietf-wimse-s2s-protocol</a>]</span>,
|
||
transport security is already established. HTTP Message Signatures
|
||
<span>[<a href="#RFC9421" class="cite xref">RFC9421</a>]</span> provide an alternative channel binding mechanism.<a href="#section-9.6-1" class="pilcrow">¶</a></p>
|
||
<p id="section-9.6-2">The defense-in-depth model provides:<a href="#section-9.6-2" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-9.6-3.1">
|
||
<p id="section-9.6-3.1.1">TLS/mTLS (transport layer): Prevents network-level tampering.<a href="#section-9.6-3.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.6-3.2">
|
||
<p id="section-9.6-3.2.1">WIT/WPT (WIMSE identity layer): Proves agent identity and
|
||
request authorization.<a href="#section-9.6-3.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.6-3.3">
|
||
<p id="section-9.6-3.3.1">ECT (execution accountability layer): Records what the agent did.<a href="#section-9.6-3.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="key-compromise">
|
||
<section id="section-9.7">
|
||
<h3 id="name-key-compromise">
|
||
<a href="#section-9.7" class="section-number selfRef">9.7. </a><a href="#name-key-compromise" class="section-name selfRef">Key Compromise</a>
|
||
</h3>
|
||
<p id="section-9.7-1">If an agent's private key is compromised, an attacker can forge
|
||
ECTs that appear to originate from that agent. To mitigate this
|
||
risk:<a href="#section-9.7-1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-9.7-2.1">
|
||
<p id="section-9.7-2.1.1">Implementations <span class="bcp14">SHOULD</span> use short-lived keys and rotate them
|
||
frequently (hours to days, not months).<a href="#section-9.7-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.7-2.2">
|
||
<p id="section-9.7-2.2.1">Private keys <span class="bcp14">SHOULD</span> be stored in Hardware Security Modules (HSMs)
|
||
or equivalent secure key storage.<a href="#section-9.7-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.7-2.3">
|
||
<p id="section-9.7-2.3.1">Trust domains <span class="bcp14">MUST</span> support rapid key revocation.<a href="#section-9.7-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.7-2.4">
|
||
<p id="section-9.7-2.4.1">Upon suspected compromise, the trust domain <span class="bcp14">MUST</span> revoke the
|
||
compromised key and issue a new WIT with a fresh key pair.<a href="#section-9.7-2.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-9.7-3">ECTs signed with a compromised key that were recorded in the
|
||
ledger before revocation remain valid historical records but <span class="bcp14">SHOULD</span>
|
||
be flagged in the ledger as "signed with subsequently revoked key"
|
||
for audit purposes.<a href="#section-9.7-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="collusion-and-false-claims">
|
||
<section id="section-9.8">
|
||
<h3 id="name-collusion-and-false-claims">
|
||
<a href="#section-9.8" class="section-number selfRef">9.8. </a><a href="#name-collusion-and-false-claims" class="section-name selfRef">Collusion and False Claims</a>
|
||
</h3>
|
||
<p id="section-9.8-1">A single malicious agent cannot forge parent task references
|
||
because DAG validation requires parent tasks to exist in the
|
||
ledger. However, multiple colluding agents could potentially
|
||
create a false execution history if they control the ledger.<a href="#section-9.8-1" class="pilcrow">¶</a></p>
|
||
<p id="section-9.8-2">Mitigations include:<a href="#section-9.8-2" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-9.8-3.1">
|
||
<p id="section-9.8-3.1.1">Independent ledger maintenance: The ledger <span class="bcp14">SHOULD</span> be maintained
|
||
by an entity independent of the workflow agents.<a href="#section-9.8-3.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.8-3.2">
|
||
<p id="section-9.8-3.2.1">Cross-verification: Multiple independent ledger replicas can be
|
||
compared for consistency.<a href="#section-9.8-3.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-9.8-3.3">
|
||
<p id="section-9.8-3.3.1">Out-of-band audit: External auditors periodically verify ledger
|
||
contents against expected workflow patterns.<a href="#section-9.8-3.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="denial-of-service">
|
||
<section id="section-9.9">
|
||
<h3 id="name-denial-of-service">
|
||
<a href="#section-9.9" class="section-number selfRef">9.9. </a><a href="#name-denial-of-service" class="section-name selfRef">Denial of Service</a>
|
||
</h3>
|
||
<p id="section-9.9-1">ECT signature verification is computationally inexpensive
|
||
(approximately 1ms per ECT on modern hardware for ES256). DAG
|
||
validation complexity is O(V) where V is the number of ancestor
|
||
nodes reachable from the parent references; for typical shallow
|
||
DAGs this is efficient.<a href="#section-9.9-1" class="pilcrow">¶</a></p>
|
||
<p id="section-9.9-2">Implementations <span class="bcp14">SHOULD</span> apply rate limiting at the API layer to
|
||
prevent excessive ECT submissions. DAG validation <span class="bcp14">SHOULD</span> be
|
||
performed after signature verification to avoid wasting resources
|
||
on unsigned or incorrectly signed tokens.<a href="#section-9.9-2" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="timestamp-accuracy">
|
||
<section id="section-9.10">
|
||
<h3 id="name-timestamp-accuracy">
|
||
<a href="#section-9.10" class="section-number selfRef">9.10. </a><a href="#name-timestamp-accuracy" class="section-name selfRef">Timestamp Accuracy</a>
|
||
</h3>
|
||
<p id="section-9.10-1">ECTs rely on timestamps ("iat", "exp") for temporal ordering.
|
||
Clock skew between agents can lead to incorrect ordering
|
||
judgments. Implementations <span class="bcp14">SHOULD</span> use synchronized time sources
|
||
(e.g., NTP) and <span class="bcp14">SHOULD</span> allow a configurable clock skew tolerance
|
||
(<span class="bcp14">RECOMMENDED</span>: 30 seconds).<a href="#section-9.10-1" class="pilcrow">¶</a></p>
|
||
<p id="section-9.10-2">Cross-organizational deployments where agents span multiple trust
|
||
domains with independent time sources <span class="bcp14">MAY</span> require a higher clock
|
||
skew tolerance. Deployments using trust domain federation <span class="bcp14">SHOULD</span>
|
||
document their configured clock skew tolerance value and <span class="bcp14">SHOULD</span>
|
||
ensure all participating trust domains agree on a common tolerance.<a href="#section-9.10-2" class="pilcrow">¶</a></p>
|
||
<p id="section-9.10-3">The temporal ordering check in DAG validation incorporates the
|
||
clock skew tolerance to account for minor clock differences
|
||
between agents.<a href="#section-9.10-3" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="ect-size-constraints">
|
||
<section id="section-9.11">
|
||
<h3 id="name-ect-size-constraints">
|
||
<a href="#section-9.11" class="section-number selfRef">9.11. </a><a href="#name-ect-size-constraints" class="section-name selfRef">ECT Size Constraints</a>
|
||
</h3>
|
||
<p id="section-9.11-1">ECTs with many parent tasks or large extension objects can
|
||
increase HTTP header size. Implementations <span class="bcp14">SHOULD</span> limit the "par"
|
||
array to a maximum of 256 entries. Workflows requiring more
|
||
parent references <span class="bcp14">SHOULD</span> introduce intermediate aggregation
|
||
tasks. The "ext" object <span class="bcp14">SHOULD NOT</span> exceed 4096 bytes when
|
||
serialized as JSON and <span class="bcp14">SHOULD NOT</span> exceed a nesting depth of
|
||
5 levels (see also <a href="#extension-claims" class="auto internal xref">Section 4.2.4</a>).<a href="#section-9.11-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="privacy-considerations">
|
||
<section id="section-10">
|
||
<h2 id="name-privacy-considerations">
|
||
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
|
||
</h2>
|
||
<div id="data-exposure-in-ects">
|
||
<section id="section-10.1">
|
||
<h3 id="name-data-exposure-in-ects">
|
||
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-data-exposure-in-ects" class="section-name selfRef">Data Exposure in ECTs</a>
|
||
</h3>
|
||
<p id="section-10.1-1">ECTs necessarily reveal:<a href="#section-10.1-1" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-10.1-2.1">
|
||
<p id="section-10.1-2.1.1">Agent identities ("iss", "aud") for accountability purposes<a href="#section-10.1-2.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.1-2.2">
|
||
<p id="section-10.1-2.2.1">Action descriptions ("exec_act") for audit trail completeness<a href="#section-10.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.1-2.3">
|
||
<p id="section-10.1-2.3.1">Timestamps ("iat", "exp") for temporal ordering<a href="#section-10.1-2.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
<p id="section-10.1-3">ECTs are designed to NOT reveal:<a href="#section-10.1-3" class="pilcrow">¶</a></p>
|
||
<ul class="normal">
|
||
<li class="normal" id="section-10.1-4.1">
|
||
<p id="section-10.1-4.1.1">Actual input or output data values (replaced with cryptographic
|
||
hashes via "inp_hash" and "out_hash")<a href="#section-10.1-4.1.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.1-4.2">
|
||
<p id="section-10.1-4.2.1">Internal computation details or intermediate steps<a href="#section-10.1-4.2.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.1-4.3">
|
||
<p id="section-10.1-4.3.1">Proprietary algorithms or intellectual property<a href="#section-10.1-4.3.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
<li class="normal" id="section-10.1-4.4">
|
||
<p id="section-10.1-4.4.1">Personally identifiable information (PII)<a href="#section-10.1-4.4.1" class="pilcrow">¶</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
<div id="data-minimization">
|
||
<section id="section-10.2">
|
||
<h3 id="name-data-minimization">
|
||
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-data-minimization" class="section-name selfRef">Data Minimization</a>
|
||
</h3>
|
||
<p id="section-10.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 4.2.4</a>) deserve particular
|
||
attention: human-readable values risk exposing sensitive operational
|
||
details. See <a href="#extension-claims" class="auto internal xref">Section 4.2.4</a> for guidance on using
|
||
structured identifiers.<a href="#section-10.2-1" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
<div id="storage-and-access-control">
|
||
<section id="section-10.3">
|
||
<h3 id="name-storage-and-access-control">
|
||
<a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-storage-and-access-control" class="section-name selfRef">Storage and Access Control</a>
|
||
</h3>
|
||
<p id="section-10.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-10.3-1" class="pilcrow">¶</a></p>
|
||
<p id="section-10.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-10.3-2" class="pilcrow">¶</a></p>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="iana-considerations">
|
||
<section id="section-11">
|
||
<h2 id="name-iana-considerations">
|
||
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
|
||
</h2>
|
||
<div id="media-type-registration">
|
||
<section id="section-11.1">
|
||
<h3 id="name-media-type-registration">
|
||
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-media-type-registration" class="section-name selfRef">Media Type Registration</a>
|
||
</h3>
|
||
<p id="section-11.1-1">This document requests registration of the following media type
|
||
in the "Media Types" registry maintained by IANA:<a href="#section-11.1-1" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-11.1-2">
|
||
<dt id="section-11.1-2.1">Type name:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.1-2.2">
|
||
<p id="section-11.1-2.2.1">application<a href="#section-11.1-2.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-11.1-2.3">Subtype name:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.1-2.4">
|
||
<p id="section-11.1-2.4.1">wimse-exec+jwt<a href="#section-11.1-2.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-11.1-2.5">Required parameters:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.1-2.6">
|
||
<p id="section-11.1-2.6.1">none<a href="#section-11.1-2.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-11.1-2.7">Optional parameters:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.1-2.8">
|
||
<p id="section-11.1-2.8.1">none<a href="#section-11.1-2.8.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-11.1-2.9">Encoding considerations:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.1-2.10">
|
||
<p id="section-11.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-11.1-2.10.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-11.1-2.11">Security considerations:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.1-2.12">
|
||
<p id="section-11.1-2.12.1">See the Security Considerations section of this document.<a href="#section-11.1-2.12.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-11.1-2.13">Interoperability considerations:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.1-2.14">
|
||
<p id="section-11.1-2.14.1">none<a href="#section-11.1-2.14.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-11.1-2.15">Published specification:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.1-2.16">
|
||
<p id="section-11.1-2.16.1">This document<a href="#section-11.1-2.16.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-11.1-2.17">Applications that use this media type:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.1-2.18">
|
||
<p id="section-11.1-2.18.1">Applications that implement agentic workflows requiring execution
|
||
context tracing and audit trails.<a href="#section-11.1-2.18.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-11.1-2.19">Additional information:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.1-2.20">
|
||
<p id="section-11.1-2.20.1">Magic number(s): none
|
||
File extension(s): none
|
||
Macintosh file type code(s): none<a href="#section-11.1-2.20.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-11.1-2.21">Person and email address to contact for further information:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.1-2.22">
|
||
<p id="section-11.1-2.22.1">Christian Nennemann, ietf@nennemann.de<a href="#section-11.1-2.22.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-11.1-2.23">Intended usage:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.1-2.24">
|
||
<p id="section-11.1-2.24.1">COMMON<a href="#section-11.1-2.24.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-11.1-2.25">Restrictions on usage:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.1-2.26">
|
||
<p id="section-11.1-2.26.1">none<a href="#section-11.1-2.26.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-11.1-2.27">Author:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.1-2.28">
|
||
<p id="section-11.1-2.28.1">Christian Nennemann<a href="#section-11.1-2.28.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-11.1-2.29">Change controller:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.1-2.30">
|
||
<p id="section-11.1-2.30.1">IETF<a href="#section-11.1-2.30.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="header-registration">
|
||
<section id="section-11.2">
|
||
<h3 id="name-http-header-field-registrat">
|
||
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-http-header-field-registrat" class="section-name selfRef">HTTP Header Field Registration</a>
|
||
</h3>
|
||
<p id="section-11.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-11.2-1" class="pilcrow">¶</a></p>
|
||
<span class="break"></span><dl class="dlParallel" id="section-11.2-2">
|
||
<dt id="section-11.2-2.1">Field name:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.2-2.2">
|
||
<p id="section-11.2-2.2.1">Execution-Context<a href="#section-11.2-2.2.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-11.2-2.3">Status:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.2-2.4">
|
||
<p id="section-11.2-2.4.1">permanent<a href="#section-11.2-2.4.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
<dt id="section-11.2-2.5">Specification document:</dt>
|
||
<dd style="margin-left: 1.5em" id="section-11.2-2.6">
|
||
<p id="section-11.2-2.6.1">This document, <a href="#http-header" class="auto internal xref">Section 5</a><a href="#section-11.2-2.6.1" class="pilcrow">¶</a></p>
|
||
</dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
<div id="claims-registration">
|
||
<section id="section-11.3">
|
||
<h3 id="name-jwt-claims-registration">
|
||
<a href="#section-11.3" class="section-number selfRef">11.3. </a><a href="#name-jwt-claims-registration" class="section-name selfRef">JWT Claims Registration</a>
|
||
</h3>
|
||
<p id="section-11.3-1">This document requests registration of the following claims in
|
||
the "JSON Web Token Claims" registry maintained by IANA:<a href="#section-11.3-1" class="pilcrow">¶</a></p>
|
||
<span id="name-jwt-claims-registrations"></span><div id="_table-claims">
|
||
<table class="center" id="table-1">
|
||
<caption>
|
||
<a href="#table-1" class="selfRef">Table 1</a>:
|
||
<a href="#name-jwt-claims-registrations" class="selfRef">JWT Claims Registrations</a>
|
||
</caption>
|
||
<thead>
|
||
<tr>
|
||
<th class="text-center" rowspan="1" colspan="1">Claim Name</th>
|
||
<th class="text-left" rowspan="1" colspan="1">Claim Description</th>
|
||
<th class="text-center" rowspan="1" colspan="1">Change Controller</th>
|
||
<th class="text-center" rowspan="1" colspan="1">Reference</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="text-center" rowspan="1" colspan="1">wid</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Workflow Identifier</td>
|
||
<td class="text-center" rowspan="1" colspan="1">IETF</td>
|
||
<td class="text-center" rowspan="1" colspan="1">
|
||
<a href="#exec-claims" class="auto internal xref">Section 4.2.2</a>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="text-center" rowspan="1" colspan="1">exec_act</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Action/Task Type</td>
|
||
<td class="text-center" rowspan="1" colspan="1">IETF</td>
|
||
<td class="text-center" rowspan="1" colspan="1">
|
||
<a href="#exec-claims" class="auto internal xref">Section 4.2.2</a>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="text-center" rowspan="1" colspan="1">par</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Parent Task Identifiers</td>
|
||
<td class="text-center" rowspan="1" colspan="1">IETF</td>
|
||
<td class="text-center" rowspan="1" colspan="1">
|
||
<a href="#exec-claims" class="auto internal xref">Section 4.2.2</a>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="text-center" rowspan="1" colspan="1">inp_hash</td>
|
||
<td class="text-left" rowspan="1" colspan="1">Input Data Hash</td>
|
||
<td class="text-center" rowspan="1" colspan="1">IETF</td>
|
||
<td class="text-center" rowspan="1" colspan="1">
|
||
<a href="#data-integrity-claims" class="auto internal xref">Section 4.2.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 4.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 4.2.4</a>
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="sec-combined-references">
|
||
<section id="section-12">
|
||
<h2 id="name-references">
|
||
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-references" class="section-name selfRef">References</a>
|
||
</h2>
|
||
<div id="sec-normative-references">
|
||
<section id="section-12.1">
|
||
<h3 id="name-normative-references">
|
||
<a href="#section-12.1" class="section-number selfRef">12.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-12.2">
|
||
<h3 id="name-informative-references">
|
||
<a href="#section-12.2" class="section-number selfRef">12.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.ni-wimse-ai-agent-identity">[I-D.ni-wimse-ai-agent-identity]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Yuan, N.</span> and <span class="refAuthor">P. C. Liu</span>, <span class="refTitle">"WIMSE Applicability for AI Agents"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ni-wimse-ai-agent-identity-01</span>, <time datetime="2025-10-20" class="refDate">20 October 2025</time>, <span><<a href="https://datatracker.ietf.org/doc/html/draft-ni-wimse-ai-agent-identity-01">https://datatracker.ietf.org/doc/html/draft-ni-wimse-ai-agent-identity-01</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="I-D.oauth-transaction-tokens-for-agents">[I-D.oauth-transaction-tokens-for-agents]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Raut, A.</span>, <span class="refTitle">"Transaction Tokens For Agents"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-oauth-transaction-tokens-for-agents-04</span>, <time datetime="2026-02-10" class="refDate">10 February 2026</time>, <span><<a href="https://datatracker.ietf.org/doc/html/draft-oauth-transaction-tokens-for-agents-04">https://datatracker.ietf.org/doc/html/draft-oauth-transaction-tokens-for-agents-04</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="OPENTELEMETRY">[OPENTELEMETRY]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Cloud Native Computing Foundation</span>, <span class="refTitle">"OpenTelemetry Specification"</span>, <span><<a href="https://opentelemetry.io/docs/specs/otel/">https://opentelemetry.io/docs/specs/otel/</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="RFC3552">[RFC3552]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Rescorla, E.</span> and <span class="refAuthor">B. Korver</span>, <span class="refTitle">"Guidelines for Writing RFC Text on Security Considerations"</span>, <span class="seriesInfo">BCP 72</span>, <span class="seriesInfo">RFC 3552</span>, <span class="seriesInfo">DOI 10.17487/RFC3552</span>, <time datetime="2003-07" class="refDate">July 2003</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc3552">https://www.rfc-editor.org/rfc/rfc3552</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="RFC8693">[RFC8693]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Nadalin, A.</span>, <span class="refAuthor">Campbell, B., Ed.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">C. Mortimore</span>, <span class="refTitle">"OAuth 2.0 Token Exchange"</span>, <span class="seriesInfo">RFC 8693</span>, <span class="seriesInfo">DOI 10.17487/RFC8693</span>, <time datetime="2020-01" class="refDate">January 2020</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc8693">https://www.rfc-editor.org/rfc/rfc8693</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="RFC9421">[RFC9421]</dt>
|
||
<dd>
|
||
<span class="refAuthor">Backman, A., Ed.</span>, <span class="refAuthor">Richer, J., Ed.</span>, and <span class="refAuthor">M. Sporny</span>, <span class="refTitle">"HTTP Message Signatures"</span>, <span class="seriesInfo">RFC 9421</span>, <span class="seriesInfo">DOI 10.17487/RFC9421</span>, <time datetime="2024-02" class="refDate">February 2024</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc9421">https://www.rfc-editor.org/rfc/rfc9421</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
<dt id="SPIFFE">[SPIFFE]</dt>
|
||
<dd>
|
||
<span class="refTitle">"Secure Production Identity Framework for Everyone (SPIFFE)"</span>, <span><<a href="https://spiffe.io/docs/latest/spiffe-about/overview/">https://spiffe.io/docs/latest/spiffe-about/overview/</a>></span>. </dd>
|
||
<dd class="break"></dd>
|
||
</dl>
|
||
</section>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<div id="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 4.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-6">
|
||
<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-6" class="selfRef">Figure 6</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-7">
|
||
<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-7" class="selfRef">Figure 7</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>
|
||
</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="scitt-supply-chain-integrity-transparency-and-trust">
|
||
<section id="appendix-B.5">
|
||
<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.5-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.5-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>
|