c/ietf-draft-analyzer
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
ietf-draft-analyzer/workspace/drafts/act/draft-nennemann-act-01.html
Christian Nennemann 56f2ce669c feat: unified drafts/ structure with PDF outputs for ACT and ECT 
Both drafts now live in workspace/drafts/ as siblings:
  drafts/
  ├── act/                       (ACT -01, native to parent repo)
  │   ├── draft-nennemann-act-01.md     kramdown-rfc source
  │   ├── draft-nennemann-act-01.{xml,txt,html,pdf}
  │   ├── .refcache/             bibxml cache
  │   └── build.sh
  ├── ietf-wimse-ect/            (ECT -02, submodule, PDF added)
  │   └── ...
  └── README-pdf.md              PDF toolchain docs

ACT kramdown-rfc conversion:
- full YAML frontmatter (title, author, refs)
- section structure matches kramdown-rfc conventions
- {{REF}} citation syntax, auto-numbered sections
- references auto-built from normative/informative blocks
- removed manual TOC (kramdown-rfc generates)
- builds cleanly: 133K XML, 89K TXT, 208K HTML, 167K PDF

PDF toolchain:
- xml2rfc --pdf via weasyprint<60 + pydyf<0.10 injected into xml2rfc pipx venv
- both build.sh scripts now produce PDF as Step 4
- README-pdf.md documents the setup for new machines

Submodule: bump ietf-wimse-ect pointer for build.sh PDF step
2026-04-12 14:01:57 +02:00

3980 lines
203 KiB
HTML
Raw Permalink Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<!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>Agent Context Token (ACT)</title>
<meta content="Christian Nennemann" name="author">
<meta content="
This document defines the Agent Context Token (ACT), a self-contained
JWT-based format that captures the full invocation context of an
autonomous AI agent — its capabilities, constraints, delegation
provenance, oversight requirements, task metadata, and DAG position —
and unifies authorization and execution accountability in a single
token lifecycle. An ACT begins as a signed authorization mandate and
transitions into a tamper-evident execution record once the agent
completes its task, appending cryptographic hashes of inputs and
outputs and linking to predecessor tasks via a directed acyclic graph
(DAG). ACT requires no Authorization Server, no workload identity
infrastructure, and no transparency service for basic operation. Trust
is bootstrapped via pre-shared keys and is upgradeable to PKI or
Decentralized Identifiers (DIDs). ACT is designed for
cross-organizational agent federation in regulated and unregulated
environments alike. ACT is the general-purpose agent context
primitive; the WIMSE Execution Context Token (ECT)
is a sibling profile specialized for
workload-identity-bound execution recording in WIMSE deployments.
" name="description">
<meta content="xml2rfc 3.31.0" name="generator">
<meta content="agent authorization" name="keyword">
<meta content="execution accountability" name="keyword">
<meta content="JWT" name="keyword">
<meta content="DAG" name="keyword">
<meta content="delegation" name="keyword">
<meta content="draft-nennemann-act-01" name="ietf.draft">
<!-- Generator version information:
xml2rfc 3.31.0
Python 3.14.3
ConfigArgParse 1.7.1
google-i18n-address 3.1.1
intervaltree 3.2.1
Jinja2 3.1.6
lxml 6.0.2
platformdirs 4.9.2
pycountry 26.2.16
PyYAML 6.0.3
requests 2.32.5
wcwidth 0.6.0
weasyprint 59.0
-->
<link href="draft-nennemann-act-01.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">ACT</td>
<td class="right">April 2026</td>
</tr></thead>
<tfoot><tr>
<td class="left">Nennemann</td>
<td class="center">Expires 14 October 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">Network Working Group</dd>
<dt class="label-internet-draft">Internet-Draft:</dt>
<dd class="internet-draft">draft-nennemann-act-01</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2026-04-12" class="published">12 April 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-10-14">14 October 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">Agent Context Token (ACT)</h1>
<section id="section-abstract">
<h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document defines the Agent Context Token (ACT), a self-contained
JWT-based format that captures the full invocation context of an
autonomous AI agent — its capabilities, constraints, delegation
provenance, oversight requirements, task metadata, and DAG position —
and unifies authorization and execution accountability in a single
token lifecycle. An ACT begins as a signed authorization mandate and
transitions into a tamper-evident execution record once the agent
completes its task, appending cryptographic hashes of inputs and
outputs and linking to predecessor tasks via a directed acyclic graph
(DAG). ACT requires no Authorization Server, no workload identity
infrastructure, and no transparency service for basic operation. Trust
is bootstrapped via pre-shared keys and is upgradeable to PKI or
Decentralized Identifiers (DIDs). ACT is designed for
cross-organizational agent federation in regulated and unregulated
environments alike. ACT is the general-purpose agent context
primitive; the WIMSE Execution Context Token (ECT)
<span>[<a href="#I-D.nennemann-wimse-ect" class="cite xref">I-D.nennemann-wimse-ect</a>]</span> is a sibling profile specialized for
workload-identity-bound execution recording in WIMSE deployments.<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 14 October 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-problem-statement" class="internal xref">Problem Statement</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-design-goals" class="internal xref">Design Goals</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-non-goals" class="internal xref">Non-Goals</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.4">
<p id="section-toc.1-1.1.2.4.1"><a href="#section-1.4" class="auto internal xref">1.4</a>.  <a href="#name-relationship-to-related-wor" class="internal xref">Relationship to Related Work</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.4.2.1">
<p id="section-toc.1-1.1.2.4.2.1.1"><a href="#section-1.4.1" class="auto internal xref">1.4.1</a>.  <a href="#name-concurrent-agent-authorizat" class="internal xref">Concurrent Agent Authorization Proposals</a></p>
</li>
</ul>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.5">
<p id="section-toc.1-1.1.2.5.1"><a href="#section-1.5" class="auto internal xref">1.5</a>.  <a href="#name-applicability" class="internal xref">Applicability</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.5.2.1">
<p id="section-toc.1-1.1.2.5.2.1.1"><a href="#section-1.5.1" class="auto internal xref">1.5.1</a>.  <a href="#name-model-context-protocol-mcp-" class="internal xref">Model Context Protocol (MCP) Tool-Use Flows</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.5.2.2">
<p id="section-toc.1-1.1.2.5.2.2.1"><a href="#section-1.5.2" class="auto internal xref">1.5.2</a>.  <a href="#name-openai-agents-sdk-and-funct" class="internal xref">OpenAI Agents SDK and Function Calling</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.5.2.3">
<p id="section-toc.1-1.1.2.5.2.3.1"><a href="#section-1.5.3" class="auto internal xref">1.5.3</a>.  <a href="#name-langgraph-and-langchain-age" class="internal xref">LangGraph and LangChain Agent Graphs</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.5.2.4">
<p id="section-toc.1-1.1.2.5.2.4.1"><a href="#section-1.5.4" class="auto internal xref">1.5.4</a>.  <a href="#name-google-agent2agent-a2a-prot" class="internal xref">Google Agent2Agent (A2A) Protocol</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.5.2.5">
<p id="section-toc.1-1.1.2.5.2.5.1"><a href="#section-1.5.5" class="auto internal xref">1.5.5</a>.  <a href="#name-enterprise-orchestration-wi" class="internal xref">Enterprise Orchestration Without WIMSE (CrewAI, AutoGen)</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.5.2.6">
<p id="section-toc.1-1.1.2.5.2.6.1"><a href="#section-1.5.6" class="auto internal xref">1.5.6</a>.  <a href="#name-relationship-to-wimse-ect" class="internal xref">Relationship to WIMSE ECT</a></p>
</li>
</ul>
</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-act-lifecycle" class="internal xref">ACT Lifecycle</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-phase-1-authorization-manda" class="internal xref">Phase 1: Authorization Mandate</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-phase-2-execution-record" class="internal xref">Phase 2: Execution Record</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-lifecycle-state-machine" class="internal xref">Lifecycle State Machine</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-act-token-format" class="internal xref">ACT 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-authorization-ph" class="internal xref">JWT Claims: Authorization Phase</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-act-authorization-claims" class="internal xref">ACT Authorization Claims</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-jwt-claims-execution-phase" class="internal xref">JWT Claims: Execution Phase</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4">
<p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="auto internal xref">4.4</a>.  <a href="#name-complete-examples" class="internal xref">Complete Examples</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4.2.1">
<p id="section-toc.1-1.4.2.4.2.1.1"><a href="#section-4.4.1" class="auto internal xref">4.4.1</a>.  <a href="#name-example-phase-1-authorizati" class="internal xref">Example: Phase 1 — Authorization Mandate</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4.2.2">
<p id="section-toc.1-1.4.2.4.2.2.1"><a href="#section-4.4.2" class="auto internal xref">4.4.2</a>.  <a href="#name-example-phase-2-execution-r" class="internal xref">Example: Phase 2 — Execution Record (same token, re-signed by target agent)</a></p>
</li>
</ul>
</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-trust-model" class="internal xref">Trust Model</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-tier-0-bootstrap-tofu-trust" class="internal xref">Tier 0: Bootstrap (TOFU — Trust On First Use)</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2">
<p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="auto internal xref">5.2</a>.  <a href="#name-tier-1-pre-shared-keys-mand" class="internal xref">Tier 1: Pre-Shared Keys (Mandatory-to-Implement)</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.3">
<p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="auto internal xref">5.3</a>.  <a href="#name-tier-2-pki-x509" class="internal xref">Tier 2: PKI / X.509</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.4">
<p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="auto internal xref">5.4</a>.  <a href="#name-tier-3-decentralized-identi" class="internal xref">Tier 3: Decentralized Identifiers (DID)</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.5">
<p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="auto internal xref">5.5</a>.  <a href="#name-cross-tier-interoperability" class="internal xref">Cross-Tier Interoperability</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-delegation-chain" class="internal xref">Delegation Chain</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-peer-to-peer-delegation" class="internal xref">Peer-to-Peer Delegation</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-privilege-reduction-require" class="internal xref">Privilege Reduction Requirements</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3">
<p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="auto internal xref">6.3</a>.  <a href="#name-delegation-verification" class="internal xref">Delegation Verification</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-dag-structure-and-causal-or" class="internal xref">DAG Structure and Causal Ordering</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-dag-validation" class="internal xref">DAG Validation</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
<p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="auto internal xref">7.2</a>.  <a href="#name-root-tasks-and-fan-in" class="internal xref">Root Tasks and Fan-in</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.3">
<p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="auto internal xref">7.3</a>.  <a href="#name-dag-vs-linear-delegation-ch" class="internal xref">DAG vs Linear Delegation Chains</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.3.2.1">
<p id="section-toc.1-1.7.2.3.2.1.1"><a href="#section-7.3.1" class="auto internal xref">7.3.1</a>.  <a href="#name-what-linear-chains-express-" class="internal xref">What Linear Chains Express Well</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.3.2.2">
<p id="section-toc.1-1.7.2.3.2.2.1"><a href="#section-7.3.2" class="auto internal xref">7.3.2</a>.  <a href="#name-limitations-of-linear-chain" class="internal xref">Limitations of Linear Chains</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.3.2.3">
<p id="section-toc.1-1.7.2.3.2.3.1"><a href="#section-7.3.3" class="auto internal xref">7.3.3</a>.  <a href="#name-acts-dag-approach" class="internal xref">ACT's DAG Approach</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.3.2.4">
<p id="section-toc.1-1.7.2.3.2.4.1"><a href="#section-7.3.4" class="auto internal xref">7.3.4</a>.  <a href="#name-verifiability-implications" class="internal xref">Verifiability Implications</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.3.2.5">
<p id="section-toc.1-1.7.2.3.2.5.1"><a href="#section-7.3.5" class="auto internal xref">7.3.5</a>.  <a href="#name-interoperability-with-linea" class="internal xref">Interoperability with Linear-Chain Designs</a></p>
</li>
</ul>
</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-verification-procedure" class="internal xref">Verification Procedure</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1">
<p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="auto internal xref">8.1</a>.  <a href="#name-authorization-phase-verific" class="internal xref">Authorization Phase Verification</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2">
<p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="auto internal xref">8.2</a>.  <a href="#name-execution-phase-verificatio" class="internal xref">Execution Phase Verification</a></p>
</li>
</ul>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
<p id="section-toc.1-1.9.1"><a href="#section-9" class="auto internal xref">9</a>.  <a href="#name-transport" class="internal xref">Transport</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-http-header-transport" class="internal xref">HTTP Header Transport</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-non-http-transports" class="internal xref">Non-HTTP Transports</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-audit-ledger-interface" class="internal xref">Audit Ledger Interface</a></p>
</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-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.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-threat-model" class="internal xref">Threat Model</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-self-assertion-limitation" class="internal xref">Self-Assertion Limitation</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-key-compromise" class="internal xref">Key Compromise</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.4">
<p id="section-toc.1-1.11.2.4.1"><a href="#section-11.4" class="auto internal xref">11.4</a>.  <a href="#name-replay-attack-prevention" class="internal xref">Replay Attack Prevention</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.5">
<p id="section-toc.1-1.11.2.5.1"><a href="#section-11.5" class="auto internal xref">11.5</a>.  <a href="#name-equivocation" class="internal xref">Equivocation</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.6">
<p id="section-toc.1-1.11.2.6.1"><a href="#section-11.6" class="auto internal xref">11.6</a>.  <a href="#name-privilege-escalation" class="internal xref">Privilege Escalation</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.7">
<p id="section-toc.1-1.11.2.7.1"><a href="#section-11.7" class="auto internal xref">11.7</a>.  <a href="#name-denial-of-service" class="internal xref">Denial of Service</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-privacy-considerations" class="internal xref">Privacy Considerations</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
<p id="section-toc.1-1.13.1"><a href="#section-13" class="auto internal xref">13</a>. <a href="#name-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.13.2.1">
<p id="section-toc.1-1.13.2.1.1"><a href="#section-13.1" class="auto internal xref">13.1</a>.  <a href="#name-media-type-registration" class="internal xref">Media Type Registration</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.2">
<p id="section-toc.1-1.13.2.2.1"><a href="#section-13.2" class="auto internal xref">13.2</a>.  <a href="#name-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.13.2.3">
<p id="section-toc.1-1.13.2.3.1"><a href="#section-13.3" class="auto internal xref">13.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.14">
<p id="section-toc.1-1.14.1"><a href="#section-14" class="auto internal xref">14</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.14.2.1">
<p id="section-toc.1-1.14.2.1.1"><a href="#section-14.1" class="auto internal xref">14.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.14.2.2">
<p id="section-toc.1-1.14.2.2.1"><a href="#section-14.2" class="auto internal xref">14.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.15">
<p id="section-toc.1-1.15.1"><a href="#appendix-A" class="auto internal xref"></a><a href="#name-appendix-a-complete-json-sc" class="internal xref">Appendix A: Complete JSON Schema</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-B" class="auto internal xref"></a><a href="#name-appendix-b-test-vectors" class="internal xref">Appendix B: Test Vectors</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16.2.1">
<p id="section-toc.1-1.16.2.1.1"><a href="#appendix-B.1" class="auto internal xref"></a><a href="#name-b1-valid-phase-1-act-root-m" class="internal xref">B.1. Valid Phase 1 ACT — Root Mandate (Tier 1, Pre-Shared Key)</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16.2.2">
<p id="section-toc.1-1.16.2.2.1"><a href="#appendix-B.2" class="auto internal xref"></a><a href="#name-b2-valid-phase-2-act-comple" class="internal xref">B.2. Valid Phase 2 ACT — Completed Execution</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16.2.3">
<p id="section-toc.1-1.16.2.3.1"><a href="#appendix-B.3" class="auto internal xref"></a><a href="#name-b3-valid-phase-2-act-fan-in" class="internal xref">B.3. Valid Phase 2 ACT — Fan-in (Multiple Parents)</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16.2.4">
<p id="section-toc.1-1.16.2.4.1"><a href="#appendix-B.4" class="auto internal xref"></a><a href="#name-b4-invalid-act-delegation-d" class="internal xref">B.4. Invalid ACT — Delegation Depth Exceeded</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16.2.5">
<p id="section-toc.1-1.16.2.5.1"><a href="#appendix-B.5" class="auto internal xref"></a><a href="#name-b5-invalid-act-capability-e" class="internal xref">B.5. Invalid ACT — Capability Escalation</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16.2.6">
<p id="section-toc.1-1.16.2.6.1"><a href="#appendix-B.6" class="auto internal xref"></a><a href="#name-b6-invalid-act-exec_act-mis" class="internal xref">B.6. Invalid ACT — exec_act Mismatch</a></p>
</li>
</ul>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17">
<p id="section-toc.1-1.17.1"><a href="#appendix-C" class="auto internal xref"></a><a href="#name-appendix-c-deployment-scena" class="internal xref">Appendix C: Deployment Scenarios</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17.2.1">
<p id="section-toc.1-1.17.2.1.1"><a href="#appendix-C.1" class="auto internal xref"></a><a href="#name-c1-minimal-deployment-zero-" class="internal xref">C.1. Minimal Deployment (Zero Infrastructure)</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17.2.2">
<p id="section-toc.1-1.17.2.2.1"><a href="#appendix-C.2" class="auto internal xref"></a><a href="#name-c2-regulated-deployment-wit" class="internal xref">C.2. Regulated Deployment with Hash-Chained Ledger</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17.2.3">
<p id="section-toc.1-1.17.2.3.1"><a href="#appendix-C.3" class="auto internal xref"></a><a href="#name-c3-high-assurance-cross-org" class="internal xref">C.3. High-Assurance Cross-Organizational Deployment</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17.2.4">
<p id="section-toc.1-1.17.2.4.1"><a href="#appendix-C.4" class="auto internal xref"></a><a href="#name-c4-wimse-environment-integr" class="internal xref">C.4. WIMSE Environment Integration</a></p>
</li>
</ul>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.18">
<p id="section-toc.1-1.18.1"><a href="#appendix-D" class="auto internal xref"></a><a href="#name-acknowledgments" class="internal xref">Acknowledgments</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.19">
<p id="section-toc.1-1.19.1"><a href="#appendix-E" class="auto internal xref"></a><a href="#name-authors-address" class="internal xref">Author's Address</a></p>
</li>
</ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
<h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
</h2>
<p id="section-1-1">Autonomous AI agents increasingly operate across organizational
boundaries, executing multi-step workflows where individual tasks are
delegated from one agent to another. These workflows create two
distinct, inseparable compliance requirements:<a href="#section-1-1" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="section-1-2">
<li id="section-1-2.1">
<p id="section-1-2.1.1"><strong>Authorization</strong>: was the agent permitted to perform the action,
under what constraints, and by whose authority?<a href="#section-1-2.1.1" class="pilcrow"></a></p>
</li>
<li id="section-1-2.2">
<p id="section-1-2.2.1"><strong>Accountability</strong>: what did the agent actually do, with what
inputs, producing what outputs, in what causal relationship to
prior tasks?<a href="#section-1-2.2.1" class="pilcrow"></a></p>
</li>
</ol>
<p id="section-1-3">Existing specifications address these requirements in isolation.
The Agent Authorization Profile (AAP) <span>[<a href="#I-D.aap-oauth-profile" class="cite xref">I-D.aap-oauth-profile</a>]</span>
provides structured authorization via OAuth 2.0 but requires a
central Authorization Server. The WIMSE Execution Context Token
<span>[<a href="#I-D.nennemann-wimse-ect" class="cite xref">I-D.nennemann-wimse-ect</a>]</span> provides execution accountability but
requires WIMSE workload identity infrastructure (SPIFFE/SPIRE).<a href="#section-1-3" class="pilcrow"></a></p>
<p id="section-1-4">This document defines the Agent Context Token (ACT), which addresses
both requirements in a single, self-contained token that requires no
shared infrastructure beyond the ability to verify asymmetric
signatures. The word "Context" in the name reflects what the token
carries: the complete invocation context of an agent — DAG references,
task metadata, capabilities, delegation chain, and oversight claims
— bound together in one cryptographically verifiable envelope. ACT
is positioned as the general agent context primitive, with the
WIMSE Execution Context Token (ECT) <span>[<a href="#I-D.nennemann-wimse-ect" class="cite xref">I-D.nennemann-wimse-ect</a>]</span> as a
sibling profile specialized for workload-identity-bound execution
contexts in WIMSE deployments.<a href="#section-1-4" class="pilcrow"></a></p>
<div id="problem-statement">
<section id="section-1.1">
<h3 id="name-problem-statement">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-problem-statement" class="section-name selfRef">Problem Statement</a>
</h3>
<p id="section-1.1-1">Cross-organizational agent federation today faces a bootstrapping
problem: deploying shared OAuth infrastructure or a common SPIFFE
trust domain requires organizational agreement before the first
message is exchanged. In practice this means either:<a href="#section-1.1-1" class="pilcrow"></a></p>
<p id="section-1.1-2">(a) agents operate without cryptographic authorization or audit
trails, relying on application-layer access control only; or<a href="#section-1.1-2" class="pilcrow"></a></p>
<p id="section-1.1-3">(b) organizations adopt one party's identity infrastructure, creating
a hub-and-spoke dependency that contradicts the decentralized
nature of agent networks.<a href="#section-1.1-3" class="pilcrow"></a></p>
<p id="section-1.1-4">ACT solves this by making pre-shared keys the mandatory-to-implement
trust baseline — two agents can begin a secure, auditable interaction
with nothing more than an out-of-band key exchange — while providing
a clean upgrade path to PKI or DID-based trust without changing the
token format.<a href="#section-1.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="design-goals">
<section id="section-1.2">
<h3 id="name-design-goals">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-design-goals" class="section-name selfRef">Design Goals</a>
</h3>
<ul class="normal">
<li class="normal" id="section-1.2-1.1">
<p id="section-1.2-1.1.1"><strong>G1 — Zero infrastructure baseline</strong>: ACT <span class="bcp14">MUST</span> be deployable with
no shared servers, no common identity provider, and no transparency
service.<a href="#section-1.2-1.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-1.2-1.2">
<p id="section-1.2-1.2.1"><strong>G2 — Single token lifecycle</strong>: Authorization and accountability
<span class="bcp14">MUST</span> be expressed in the same token format to prevent
authorization-accountability gaps.<a href="#section-1.2-1.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-1.2-1.3">
<p id="section-1.2-1.3.1"><strong>G3 — Peer-to-peer delegation</strong>: Delegation chains <span class="bcp14">MUST</span> be
verifiable without contacting an Authorization Server, using
cryptographic chaining of agent signatures.<a href="#section-1.2-1.3.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-1.2-1.4">
<p id="section-1.2-1.4.1"><strong>G4 — DAG-native causal ordering</strong>: Workflows with parallel
branches and fan-in dependencies <span class="bcp14">MUST</span> be expressible natively,
without flattening to a linear chain.<a href="#section-1.2-1.4.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-1.2-1.5">
<p id="section-1.2-1.5.1"><strong>G5 — Cross-organizational interoperability</strong>: ACTs issued by
agents in different trust domains <span class="bcp14">MUST</span> be verifiable by any
participant holding the issuing agent's public key.<a href="#section-1.2-1.5.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-1.2-1.6">
<p id="section-1.2-1.6.1"><strong>G6 — Regulatory applicability</strong>: ACT <span class="bcp14">MUST</span> provide sufficient
evidence for audit requirements in DORA <span>[<a href="#DORA" class="cite xref">DORA</a>]</span>, EU AI Act
Article 12 <span>[<a href="#EUAIA" class="cite xref">EUAIA</a>]</span>, and IEC 62304 <span>[<a href="#IEC62304" class="cite xref">IEC62304</a>]</span> without requiring
additional log formats.<a href="#section-1.2-1.6.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-1.2-1.7">
<p id="section-1.2-1.7.1"><strong>G7 — Upgrade path</strong>: The trust model <span class="bcp14">MUST</span> support migration from
pre-shared keys to PKI or DID without breaking existing ACT chains.<a href="#section-1.2-1.7.1" class="pilcrow"></a></p>
</li>
</ul>
</section>
</div>
<div id="non-goals">
<section id="section-1.3">
<h3 id="name-non-goals">
<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-non-goals" class="section-name selfRef">Non-Goals</a>
</h3>
<p id="section-1.3-1">The following are explicitly out of scope:<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">Defining internal AI model behavior or decision logic.<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">Replacing organizational security policies or procedures.<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">Defining storage formats for audit ledgers.<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">Specifying token revocation infrastructure (deployments <span class="bcp14">MAY</span> use
existing mechanisms such as <span>[<a href="#RFC7009" class="cite xref">RFC7009</a>]</span> for this purpose).<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">Providing non-equivocation guarantees in standalone mode (see
<a href="#equivocation" class="auto internal xref">Section 11.5</a> for the equivocation discussion and optional
transparency anchoring).<a href="#section-1.3-2.5.1" class="pilcrow"></a></p>
</li>
</ul>
</section>
</div>
<div id="relationship-to-related-work">
<section id="section-1.4">
<h3 id="name-relationship-to-related-wor">
<a href="#section-1.4" class="section-number selfRef">1.4. </a><a href="#name-relationship-to-related-wor" class="section-name selfRef">Relationship to Related Work</a>
</h3>
<p id="section-1.4-1"><strong>AAP <span>[<a href="#I-D.aap-oauth-profile" class="cite xref">I-D.aap-oauth-profile</a>]</span></strong>: ACT addresses the same authorization
problem as AAP but does not require an Authorization Server. ACT
delegation is peer-to-peer via cryptographic signature chaining;
AAP delegation requires OAuth Token Exchange <span>[<a href="#RFC8693" class="cite xref">RFC8693</a>]</span> against a
central AS. ACT is not a profile of AAP; it is an
infrastructure-independent alternative for the same problem class.<a href="#section-1.4-1" class="pilcrow"></a></p>
<p id="section-1.4-2"><strong>WIMSE ECT <span>[<a href="#I-D.nennemann-wimse-ect" class="cite xref">I-D.nennemann-wimse-ect</a>]</span></strong>: ACT addresses the same
execution accountability problem as the WIMSE Execution Context Token
but does not require WIMSE workload identity infrastructure. ACT is
not a profile of WIMSE; it is deployable in environments without
SPIFFE/SPIRE. In environments where WIMSE is deployed, ACT <span class="bcp14">MAY</span> be
carried alongside WIMSE tokens to augment accountability with
authorization provenance.<a href="#section-1.4-2" class="pilcrow"></a></p>
<p id="section-1.4-3"><strong>SCITT <span>[<a href="#I-D.ietf-scitt-architecture" class="cite xref">I-D.ietf-scitt-architecture</a>]</span></strong>: For deployments requiring
non-equivocation guarantees (see <a href="#equivocation" class="auto internal xref">Section 11.5</a>), ACT execution
records <span class="bcp14">MAY</span> be anchored to a SCITT Transparency Service as a Layer 2
mechanism. This is <span class="bcp14">OPTIONAL</span> and not required for basic ACT operation.
Note: The SCITT architecture draft is currently in AUTH48 (RFC
Editor queue) at version -22 and is about to become an RFC; readers
should use the RFC number once assigned.<a href="#section-1.4-3" class="pilcrow"></a></p>
<div id="concurrent-agent-authorization-proposals">
<section id="section-1.4.1">
<h4 id="name-concurrent-agent-authorizat">
<a href="#section-1.4.1" class="section-number selfRef">1.4.1. </a><a href="#name-concurrent-agent-authorizat" class="section-name selfRef">Concurrent Agent Authorization Proposals</a>
</h4>
<p id="section-1.4.1-1">Several concurrent proposals in the IETF and academic communities
address overlapping portions of the agent authorization problem
space. This subsection situates ACT relative to those proposals.
Protocol-layer comparison of linear versus DAG delegation
structure is deferred to <a href="#dag-vs-linear" class="auto internal xref">Section 7.3</a>; the summaries below focus
on scope and deployability.<a href="#section-1.4.1-1" class="pilcrow"></a></p>
<p id="section-1.4.1-2"><strong>AIP / IBCTs <span>[<a href="#AIP-IBCT" class="cite xref">AIP-IBCT</a>]</span></strong>: The Agent Interaction Protocol proposes
Interaction-Bound Capability Tokens in two modes: compact signed
JWTs for single-hop invocation and Biscuit/Datalog tokens for
multi-hop delegation, motivated by a survey of approximately 2,000
Model Context Protocol servers that found no authorization
enforcement. ACT addresses the same problem class but relies
exclusively on JWT/JOSE throughout (no Biscuit or Datalog
dependency), defines an explicit two-phase lifecycle separating
authorization (Mandate) from proof-of-execution (Record), and
supports DAG delegation structure. IBCTs are modeled as append-only
chains at the protocol layer; ACT operates at the authorization
graph layer with revocable lifecycle states.<a href="#section-1.4.1-2" class="pilcrow"></a></p>
<p id="section-1.4.1-3"><strong>SentinelAgent <span>[<a href="#SentinelAgent" class="cite xref">SentinelAgent</a>]</span></strong>: SentinelAgent defines a formal
Delegation Chain Calculus with seven verifiable properties, a TLA+
mechanization, and reports 100% true-positive and 0% false-positive
rates against the DelegationBench v4 benchmark. It addresses the
same accountability question as ACT — namely, which principal
authorized a given chain of actions. The differentiator is
deployment substrate: SentinelAgent expresses its guarantees in a
domain-specific formal calculus, whereas ACT encodes the same
invariants in IETF-standard JWT infrastructure (RFC 7519, RFC 7515,
RFC 8032) already deployable in existing OAuth- and JOSE-aware
stacks.<a href="#section-1.4.1-3" class="pilcrow"></a></p>
<p id="section-1.4.1-4"><strong>Agentic JWT <span>[<a href="#AgenticJWT" class="cite xref">AgenticJWT</a>]</span></strong>: Agentic JWT derives a per-agent
identity as a one-way hash of the agent's prompt, registered tools,
and configuration, and chains delegation assertions across
invocations. It is the closest prior-art JWT-based construction
for agentic delegation. ACT differs in that it adds an explicit
two-phase lifecycle — separating the authorization mandate from
the proof-of-execution record — and expresses delegation as a DAG
via the array-valued <code>pred</code> claim rather than a strictly linear
chain.<a href="#section-1.4.1-4" class="pilcrow"></a></p>
<p id="section-1.4.1-5"><strong>OAuth Transaction Tokens for Agents
<span>[<a href="#I-D.oauth-transaction-tokens-for-agents" class="cite xref">I-D.oauth-transaction-tokens-for-agents</a>]</span></strong>: This draft
extends OAuth Transaction Tokens with an <code>actchain</code> claim (an
ordered delegation array), an <code>agentic_ctx</code> claim conveying intent
and constraints, and flow-type markers distinguishing interactive
from autonomous invocations. It is complementary to ACT at the
OAuth layer. The primary differentiators are topology and
infrastructure dependency: Transaction Tokens for Agents presume
an OAuth Authorization Server and use a linear <code>actchain</code>, whereas
ACT operates peer-to-peer without any AS and uses a DAG-valued
<code>pred</code>. A detailed differencing document is referenced in
<a href="#security-considerations" class="auto internal xref">Section 11</a>.<a href="#section-1.4.1-5" class="pilcrow"></a></p>
<p id="section-1.4.1-6"><strong>Helixar Delegation Protocol (HDP)
<span>[<a href="#I-D.helixar-hdp-agentic-delegation" class="cite xref">I-D.helixar-hdp-agentic-delegation</a>]</span></strong>: HDP specifies
Ed25519 signatures over RFC 8785-canonicalized JSON, an
append-only linear delegation chain with session binding, and
offline verification. ACT addresses the same problem but is
encoded in JWT/JOSE (aligning with the broader IETF token
ecosystem) rather than raw canonical JSON, and its <code>pred</code> claim
admits DAG topologies rather than strictly linear chains.<a href="#section-1.4.1-6" class="pilcrow"></a></p>
<p id="section-1.4.1-7"><strong>SCITT Profile for AI Agent Execution Records
<span>[<a href="#I-D.emirdag-scitt-ai-agent-execution" class="cite xref">I-D.emirdag-scitt-ai-agent-execution</a>]</span></strong>: This draft
defines a SCITT profile in which AgentInteractionRecord (AIR)
payloads are carried as COSE_Sign1 statements anchored to a
SCITT Transparency Service. It is highly complementary to ACT:
where ACT defines the two-phase lifecycle token issued and
consumed by agents at runtime, the SCITT AI Agent Execution
draft defines the payload format suitable for long-term anchoring.
Implementations that anchor Phase 2 ACTs to SCITT
(<a href="#security-considerations" class="auto internal xref">Section 11</a>) <span class="bcp14">SHOULD</span> consider the AIR payload
structure defined in that draft as the canonical encoding for
anchored records.<a href="#section-1.4.1-7" class="pilcrow"></a></p>
</section>
</div>
</section>
</div>
<div id="applicability">
<section id="section-1.5">
<h3 id="name-applicability">
<a href="#section-1.5" class="section-number selfRef">1.5. </a><a href="#name-applicability" class="section-name selfRef">Applicability</a>
</h3>
<p id="section-1.5-1">ACT is designed as a general-purpose primitive for AI agent
authorization and execution accountability. While a sibling
specification <span>[<a href="#I-D.nennemann-wimse-ect" class="cite xref">I-D.nennemann-wimse-ect</a>]</span> profiles execution context
tokens specifically for the WIMSE working group's workload identity
infrastructure, ACT operates without any shared identity plane. This
section identifies deployment contexts where ACT applies independently
of WIMSE, and clarifies how ACT complements — rather than competes
with — ecosystem-specific agent protocols.<a href="#section-1.5-1" class="pilcrow"></a></p>
<div id="model-context-protocol-mcp-tool-use-flows">
<section id="section-1.5.1">
<h4 id="name-model-context-protocol-mcp-">
<a href="#section-1.5.1" class="section-number selfRef">1.5.1. </a><a href="#name-model-context-protocol-mcp-" class="section-name selfRef">Model Context Protocol (MCP) Tool-Use Flows</a>
</h4>
<p id="section-1.5.1-1">The Model Context Protocol <span>[<a href="#MCP-SPEC" class="cite xref">MCP-SPEC</a>]</span> defines a client-server
interface by which LLM hosts invoke external tools via structured
JSON-RPC calls. MCP 2025-11-25 mandates OAuth 2.1 for transport-layer
authentication, but provides no mechanism for carrying per-invocation
authorization constraints or for producing a tamper-evident record
of what arguments were passed and what result was returned.<a href="#section-1.5.1-1" class="pilcrow"></a></p>
<p id="section-1.5.1-2">ACT addresses this gap as follows: when an MCP host is about to
dispatch a tool call on behalf of an agent, it <span class="bcp14">SHOULD</span> issue a Phase 1
ACT Mandate encoding the permitted tool name (e.g., as a capability
constraint), the declaring scope, and any parameter-level constraints
applicable to that invocation. The MCP server, upon receiving the
request, <span class="bcp14">MAY</span> validate the ACT Mandate and, upon completing the tool
execution, <span class="bcp14">SHOULD</span> transition the token to Phase 2 by appending
SHA-256 hashes of the serialized input arguments and the JSON
response, then re-sign. The resulting Phase 2 ACT constitutes an
unforgeable record that a specific tool was called with specific
arguments and returned a specific result, independently of MCP's
OAuth layer.<a href="#section-1.5.1-2" class="pilcrow"></a></p>
<p id="section-1.5.1-3">This integration requires no modification to MCP transport; the ACT
<span class="bcp14">SHOULD</span> be carried in the <code>ACT-Mandate</code> and <code>ACT-Record</code> HTTP headers
defined in <a href="#http-header-transport" class="auto internal xref">Section 9.1</a> of this document.<a href="#section-1.5.1-3" class="pilcrow"></a></p>
</section>
</div>
<div id="openai-agents-sdk-and-function-calling">
<section id="section-1.5.2">
<h4 id="name-openai-agents-sdk-and-funct">
<a href="#section-1.5.2" class="section-number selfRef">1.5.2. </a><a href="#name-openai-agents-sdk-and-funct" class="section-name selfRef">OpenAI Agents SDK and Function Calling</a>
</h4>
<p id="section-1.5.2-1">The OpenAI Agents SDK <span>[<a href="#OPENAI-AGENTS-SDK" class="cite xref">OPENAI-AGENTS-SDK</a>]</span> enables composition of
agents via handoffs — structured transfers of control from one agent
to another, each potentially invoking registered function tools. The
SDK provides no built-in mechanism for a receiving agent to verify
that the handoff was authorized by a named principal, nor for the
invoking agent to produce a verifiable record of what functions it
called.<a href="#section-1.5.2-1" class="pilcrow"></a></p>
<p id="section-1.5.2-2">ACT is applicable at the handoff boundary: the orchestrating agent
<span class="bcp14">SHOULD</span> issue a Phase 1 ACT Mandate to the receiving agent at the
moment of handoff, encoding the permitted function set as
capability constraints and the maximum privilege the receiving agent
<span class="bcp14">MAY</span> exercise. The receiving agent <span class="bcp14">SHOULD</span> attach its Phase 2 ACT
Record to any callback or downstream response, providing the
orchestrator with cryptographic evidence of the actions taken. In
multi-turn chains involving multiple handoffs, the DAG linkage
(<a href="#dag-structure" class="auto internal xref">Section 7</a>) allows each handoff to be expressed as a
parent-child edge, preserving the full causal ordering of the agent
invocation sequence.<a href="#section-1.5.2-2" class="pilcrow"></a></p>
<p id="section-1.5.2-3">Implementations that use the OpenAI function calling API directly,
without the Agents SDK, <span class="bcp14">MAY</span> apply ACT at the application layer: the
calling process issues a Phase 1 ACT before the function call
parameter block is finalized, and the receiving function handler
returns a Phase 2 ACT alongside its JSON result.<a href="#section-1.5.2-3" class="pilcrow"></a></p>
</section>
</div>
<div id="langgraph-and-langchain-agent-graphs">
<section id="section-1.5.3">
<h4 id="name-langgraph-and-langchain-age">
<a href="#section-1.5.3" class="section-number selfRef">1.5.3. </a><a href="#name-langgraph-and-langchain-age" class="section-name selfRef">LangGraph and LangChain Agent Graphs</a>
</h4>
<p id="section-1.5.3-1">LangGraph <span>[<a href="#LANGGRAPH" class="cite xref">LANGGRAPH</a>]</span> models agent workflows as typed StateGraphs in
which nodes represent agent invocations or tool calls and edges
represent conditional transitions. The DAG structure of ACT
(<a href="#dag-structure" class="auto internal xref">Section 7</a>) is a natural fit for this model: each LangGraph
node that performs an observable action corresponds to exactly one
ACT task identifier (<code>tid</code>), and directed edges in the LangGraph
correspond to <code>pred</code> (predecessor) references in successor ACTs.<a href="#section-1.5.3-1" class="pilcrow"></a></p>
<p id="section-1.5.3-2">ACT is applicable at the node boundary: when a LangGraph node
dispatches a sub-agent or invokes a tool with side effects, it <span class="bcp14">SHOULD</span>
issue a Phase 1 ACT Mandate encoding the node's permitted actions
before any external call is made. Upon transition out of the node,
a Phase 2 ACT Record <span class="bcp14">SHOULD</span> be produced and attached to the
LangGraph state object alongside the node's output. Downstream nodes
that fan-in from multiple predecessors <span class="bcp14">MAY</span> retrieve the set of parent
ACT identifiers from the shared state to populate their <code>pred</code> array,
thereby expressing LangGraph's fan-in semantics within the ACT DAG
without any additional infrastructure.<a href="#section-1.5.3-2" class="pilcrow"></a></p>
<p id="section-1.5.3-3">In contrast to LangGraph's built-in state audit trail, which is
mutable in-process memory, Phase 2 ACTs are cryptographically signed
and portable: they can be exported from a LangGraph run and
submitted to an external audit ledger, satisfying compliance
requirements that cannot be met by in-process logging alone.<a href="#section-1.5.3-3" class="pilcrow"></a></p>
</section>
</div>
<div id="google-agent2agent-a2a-protocol">
<section id="section-1.5.4">
<h4 id="name-google-agent2agent-a2a-prot">
<a href="#section-1.5.4" class="section-number selfRef">1.5.4. </a><a href="#name-google-agent2agent-a2a-prot" class="section-name selfRef">Google Agent2Agent (A2A) Protocol</a>
</h4>
<p id="section-1.5.4-1">The Agent2Agent protocol <span>[<a href="#A2A-SPEC" class="cite xref">A2A-SPEC</a>]</span> defines a task-oriented JSON-RPC
interface for inter-agent communication, with authentication
delegated to OAuth 2.0 or API key schemes declared in each agent's
Agent Card. A2A provides no mechanism for a receiving agent to
verify the authorization provenance of a task request beyond the
transport-layer credential, and produces no token that represents
the execution of the task in a verifiable, portable form.<a href="#section-1.5.4-1" class="pilcrow"></a></p>
<p id="section-1.5.4-2">ACT is applicable as a session-layer accountability complement to
A2A: a client agent <span class="bcp14">SHOULD</span> include a Phase 1 ACT Mandate in the
<code>metadata</code> field of the A2A Task object, encoding the task type as
a capability constraint and the delegating agent's identity as the
ACT issuer. The receiving agent <span class="bcp14">SHOULD</span> validate the Mandate before
beginning task execution and <span class="bcp14">SHOULD</span> return a Phase 2 ACT Record
as an artifact in the A2A TaskResult, enabling the client agent to
retain cryptographic proof of what was executed on its behalf.<a href="#section-1.5.4-2" class="pilcrow"></a></p>
<p id="section-1.5.4-3">This integration does not require modification to A2A's transport or
authentication scheme; ACT and A2A's OAuth credentials operate at
independent layers and are not redundant. A2A's credential answers
"is this client permitted to contact this server?"; the ACT Mandate
answers "is this agent permitted to request this specific task
under these constraints?".<a href="#section-1.5.4-3" class="pilcrow"></a></p>
</section>
</div>
<div id="enterprise-orchestration-without-wimse-crewai-autogen">
<section id="section-1.5.5">
<h4 id="name-enterprise-orchestration-wi">
<a href="#section-1.5.5" class="section-number selfRef">1.5.5. </a><a href="#name-enterprise-orchestration-wi" class="section-name selfRef">Enterprise Orchestration Without WIMSE (CrewAI, AutoGen)</a>
</h4>
<p id="section-1.5.5-1">Enterprise orchestration frameworks such as CrewAI <span>[<a href="#CREWAI" class="cite xref">CREWAI</a>]</span> and
AutoGen <span>[<a href="#AUTOGEN" class="cite xref">AUTOGEN</a>]</span> deploy multi-agent systems within a single
organizational boundary, typically without SPIFFE/SPIRE workload
identity infrastructure. In these environments, OAuth Authorization
Servers are often unavailable or impractical to deploy for
intra-process agent communication.<a href="#section-1.5.5-1" class="pilcrow"></a></p>
<p id="section-1.5.5-2">ACT is applicable in this context via its Tier 1 (pre-shared key)
trust model (<a href="#tier1" class="auto internal xref">Section 5.2</a>): each agent role in a CrewAI Crew or
AutoGen ConversableAgent graph is assigned an Ed25519 keypair at
instantiation time. The orchestrating agent issues Phase 1 Mandates
to worker agents before delegating tasks, constraining each worker
to only the tools and actions relevant to its role. Worker agents
produce Phase 2 Records on task completion. The resulting ACT chain
is exportable as a structured audit trail that satisfies the
per-action logging requirements of DORA <span>[<a href="#DORA" class="cite xref">DORA</a>]</span> and EU AI Act
Article 12 <span>[<a href="#EUAIA" class="cite xref">EUAIA</a>]</span> without requiring shared infrastructure beyond
the ability to exchange public keys at deployment time.<a href="#section-1.5.5-2" class="pilcrow"></a></p>
<p id="section-1.5.5-3">Implementations <span class="bcp14">SHOULD NOT</span> use ACT's self-assertion mode (where an
agent issues and records its own mandate without external sign-off)
in regulated workflows; at minimum, the orchestrating agent <span class="bcp14">MUST</span>
sign the initial Mandate so that accountability is anchored to a
principal outside the executing agent.<a href="#section-1.5.5-3" class="pilcrow"></a></p>
</section>
</div>
<div id="relationship-to-wimse-ect">
<section id="section-1.5.6">
<h4 id="name-relationship-to-wimse-ect">
<a href="#section-1.5.6" class="section-number selfRef">1.5.6. </a><a href="#name-relationship-to-wimse-ect" class="section-name selfRef">Relationship to WIMSE ECT</a>
</h4>
<p id="section-1.5.6-1">Where WIMSE infrastructure is deployed, ACT and the WIMSE Execution
Context Token <span>[<a href="#I-D.nennemann-wimse-ect" class="cite xref">I-D.nennemann-wimse-ect</a>]</span> serve complementary and
non-overlapping functions. The ECT records workload-level execution
in WIMSE terms — which SPIFFE workload executed, in which trust
domain, against which service. ACT records the authorization
provenance — which agent was permitted to request which action,
under what capability constraints, by whose authority — and
transitions that authorization record into an execution record upon
task completion.<a href="#section-1.5.6-1" class="pilcrow"></a></p>
<p id="section-1.5.6-2">In mixed environments, both tokens <span class="bcp14">SHOULD</span> be carried simultaneously:
the <code>Workload-Identity</code> header carries the WIMSE ECT; the
<code>ACT-Record</code> header carries the ACT. Verifiers <span class="bcp14">MAY</span> correlate the
two by matching the ACT <code>tid</code> claim against application-layer
identifiers present in the ECT's task context. Neither token is a
profile or extension of the other; they operate at different
abstraction layers and their co-presence is additive.<a href="#section-1.5.6-2" class="pilcrow"></a></p>
</section>
</div>
</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"><strong>Agent</strong>: An autonomous software entity that executes tasks, issues
ACTs as mandates for sub-agents, and produces ACTs as execution
records of its own actions.<a href="#section-2-2" class="pilcrow"></a></p>
<p id="section-2-3"><strong>Authorization Mandate</strong>: An ACT in Phase 1, encoding what an agent
is permitted to do, under what constraints, and by whose authority.<a href="#section-2-3" class="pilcrow"></a></p>
<p id="section-2-4"><strong>Execution Record</strong>: An ACT in Phase 2, encoding what an agent
actually did, including cryptographic hashes of inputs and outputs
and causal links to predecessor tasks.<a href="#section-2-4" class="pilcrow"></a></p>
<p id="section-2-5"><strong>Directed Acyclic Graph (DAG)</strong>: A graph structure representing task
dependency ordering where edges are directed and no cycles exist. Used
by ACT to model causal relationships between tasks in a workflow.<a href="#section-2-5" class="pilcrow"></a></p>
<p id="section-2-6"><strong>Delegation Chain</strong>: A cryptographically verifiable sequence of ACT
issuances from a root authority through one or more agents, each
signing a new ACT that reduces privileges relative to the one it
received.<a href="#section-2-6" class="pilcrow"></a></p>
<p id="section-2-7"><strong>Trust Tier</strong>: A level of key management infrastructure used to
establish the public key of an ACT issuer. Tiers range from
pre-shared keys (Tier 1, mandatory) to PKI (Tier 2) and DIDs
(Tier 3).<a href="#section-2-7" class="pilcrow"></a></p>
<p id="section-2-8"><strong>Workflow</strong>: A set of related tasks, identified by a shared <code>wid</code>
claim, forming a single logical unit of work.<a href="#section-2-8" class="pilcrow"></a></p>
</section>
</div>
<div id="act-lifecycle">
<section id="section-3">
<h2 id="name-act-lifecycle">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-act-lifecycle" class="section-name selfRef">ACT Lifecycle</a>
</h2>
<p id="section-3-1">An ACT has a two-phase lifecycle. The same token format is used in
both phases; the presence or absence of execution claims determines
which phase a token represents.<a href="#section-3-1" class="pilcrow"></a></p>
<p id="section-3-2">A token is a <strong>Phase 2 Execution Record</strong> if and only if the claim
<code>exec_act</code> is present. A token that does not contain <code>exec_act</code> is
a <strong>Phase 1 Authorization Mandate</strong>. Verifiers <span class="bcp14">MUST</span> determine the
phase before applying verification rules, and <span class="bcp14">MUST</span> reject a token
that is presented in the wrong phase for the operation being
performed.<a href="#section-3-2" class="pilcrow"></a></p>
<div id="phase-1-authorization-mandate">
<section id="section-3.1">
<h3 id="name-phase-1-authorization-manda">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-phase-1-authorization-manda" class="section-name selfRef">Phase 1: Authorization Mandate</a>
</h3>
<p id="section-3.1-1">In Phase 1, an ACT is created by a delegating agent (or a human
operator) to authorize a target agent to perform a specific task. The
token carries:<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">The identity of the issuing agent and the target agent.<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">The capabilities granted, with associated constraints.<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">Human oversight requirements for high-impact actions.<a href="#section-3.1-2.3.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-3.1-2.4">
<p id="section-3.1-2.4.1">The delegation provenance (who authorized the issuer to delegate).<a href="#section-3.1-2.4.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-3.1-2.5">
<p id="section-3.1-2.5.1">A task identifier and declared purpose.<a href="#section-3.1-2.5.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="section-3.1-3">The Phase 1 ACT is signed by the issuing agent using its private key.
The target agent receives the ACT and uses it as a bearer mandate —
evidence that it is authorized to proceed.<a href="#section-3.1-3" class="pilcrow"></a></p>
<p id="section-3.1-4">Phase 1 ACTs are short-lived. Implementations <span class="bcp14">SHOULD</span> set expiration
(<code>exp</code>) to no more than 15 minutes after issuance (<code>iat</code>) for
automated agent-to-agent workflows. Longer lifetimes <span class="bcp14">MAY</span> be used for
human-initiated mandates where the agent may not act immediately.<a href="#section-3.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="phase-2-execution-record">
<section id="section-3.2">
<h3 id="name-phase-2-execution-record">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-phase-2-execution-record" class="section-name selfRef">Phase 2: Execution Record</a>
</h3>
<p id="section-3.2-1">Upon completing the authorized task, the executing agent <span class="bcp14">MUST</span>
transition the ACT to Phase 2 by:<a href="#section-3.2-1" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.2-2">
<li id="section-3.2-2.1">
<p id="section-3.2-2.1.1">Adding the <code>exec_act</code> claim describing the action performed.<a href="#section-3.2-2.1.1" class="pilcrow"></a></p>
</li>
<li id="section-3.2-2.2">
<p id="section-3.2-2.2.1">Optionally adding <code>inp_hash</code> and/or <code>out_hash</code> SHA-256 hashes
of task inputs and outputs (<span class="bcp14">RECOMMENDED</span> for regulated environments).<a href="#section-3.2-2.2.1" class="pilcrow"></a></p>
</li>
<li id="section-3.2-2.3">
<p id="section-3.2-2.3.1">Adding the <code>pred</code> array referencing predecessor task identifiers (DAG
dependencies).<a href="#section-3.2-2.3.1" class="pilcrow"></a></p>
</li>
<li id="section-3.2-2.4">
<p id="section-3.2-2.4.1">Adding <code>exec_ts</code> and <code>status</code> claims.<a href="#section-3.2-2.4.1" class="pilcrow"></a></p>
</li>
<li id="section-3.2-2.5">
<p id="section-3.2-2.5.1">Re-signing the complete token with its own private key.<a href="#section-3.2-2.5.1" class="pilcrow"></a></p>
</li>
</ol>
<p id="section-3.2-3">The re-signing is critical: it produces a new signature over the
combined authorization + execution claims, binding the executing
agent's cryptographic identity to both the mandate it received and
the execution it performed. This creates a single, non-repudiable
record that answers both "was this agent authorized?" and "what
did it do?"<a href="#section-3.2-3" class="pilcrow"></a></p>
<p id="section-3.2-4">Note on issuer signature preservation: re-signing replaces the
Phase 1 signature produced by the issuing agent (<code>iss</code>). The
integrity of the original mandate is preserved through the
<code>del.chain</code> mechanism: the chain entry's <code>sig</code> field is the <code>iss</code>
agent's signature over the Phase 1 ACT, and this signature remains
intact and verifiable in the Phase 2 token. For root mandates where
<code>del.chain</code> is empty, the issuer's signature is not independently
preserved in Phase 2. Deployments requiring independent
verifiability of the original mandate <span class="bcp14">SHOULD</span> retain the Phase 1
ACT separately alongside the Phase 2 record.<a href="#section-3.2-4" class="pilcrow"></a></p>
<p id="section-3.2-5">The resulting Phase 2 ACT <span class="bcp14">SHOULD</span> be submitted to an audit ledger
(<a href="#audit-ledger" class="auto internal xref">Section 10</a>) and <span class="bcp14">MAY</span> be sent to the next agent in the workflow
as evidence of completed prerequisites.<a href="#section-3.2-5" class="pilcrow"></a></p>
</section>
</div>
<div id="lifecycle-state-machine">
<section id="section-3.3">
<h3 id="name-lifecycle-state-machine">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-lifecycle-state-machine" class="section-name selfRef">Lifecycle State Machine</a>
</h3>
<div class="alignLeft art-text artwork" id="section-3.3-1">
<pre>
[Issuer creates Phase 1 ACT]
|
| sign(issuer_key)
v
+------------------+
| MANDATE | Phase 1: Authorization Mandate
| (unsigned by | Carried as bearer token by target agent
| target agent) |
+------------------+
|
| Target agent executes task
| adds exec_act, inp_hash, out_hash, pred
| re-signs with target_agent_key
v
+------------------+
| RECORD | Phase 2: Execution Record
| (signed by | Submitted to ledger, passed to next agent
| target agent) |
+------------------+
|
| (optional) anchor to SCITT Transparency Service
v
+------------------+
| ANCHORED | Phase 2 + external non-equivocation
+------------------+
</pre><a href="#section-3.3-1" class="pilcrow"></a>
</div>
</section>
</div>
</section>
</div>
<div id="act-token-format">
<section id="section-4">
<h2 id="name-act-token-format">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-act-token-format" class="section-name selfRef">ACT Token Format</a>
</h2>
<p id="section-4-1">An ACT is a JSON Web Token <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span> signed as a JSON Web Signature
<span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span> using JWS Compact Serialization. All ACTs <span class="bcp14">MUST</span> use JWS
Compact Serialization to ensure 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 ACT JOSE header <span class="bcp14">MUST</span> contain:<a href="#section-4.1-1" class="pilcrow"></a></p>
<div class="lang-json sourcecode" id="section-4.1-2">
<pre>
{
"alg": "ES256",
"typ": "act+jwt",
"kid": "agent-a-key-2026-03"
}
</pre><a href="#section-4.1-2" class="pilcrow"></a>
</div>
<p id="section-4.1-3"><strong>alg</strong> (<span class="bcp14">REQUIRED</span>): The digital signature algorithm. Implementations
<span class="bcp14">MUST</span> support ES256 <span>[<a href="#RFC7518" class="cite xref">RFC7518</a>]</span>. EdDSA (Ed25519) <span>[<a href="#RFC8037" class="cite xref">RFC8037</a>]</span> is
<span class="bcp14">RECOMMENDED</span> for new deployments due to smaller signatures and
resistance to side-channel attacks. Symmetric algorithms (HS256,
HS384, HS512) <span class="bcp14">MUST NOT</span> be used. The "alg" value <span class="bcp14">MUST NOT</span> be "none".<a href="#section-4.1-3" class="pilcrow"></a></p>
<p id="section-4.1-4"><strong>typ</strong> (<span class="bcp14">REQUIRED</span>): <span class="bcp14">MUST</span> be "act+jwt" to distinguish ACTs from other
JWT types.<a href="#section-4.1-4" class="pilcrow"></a></p>
<p id="section-4.1-5"><strong>kid</strong> (<span class="bcp14">REQUIRED</span>): An identifier for the signing key. In Tier 1
deployments (pre-shared keys), this is an opaque string agreed
out-of-band. In Tier 2 deployments (PKI), this is the X.509
certificate thumbprint. In Tier 3 deployments (DID), this is the
DID key fragment (e.g., <code>did:key:z6Mk...#key-1</code>).<a href="#section-4.1-5" class="pilcrow"></a></p>
<p id="section-4.1-6"><strong>x5c</strong> (<span class="bcp14">OPTIONAL</span>): In Tier 2 deployments, the X.509 certificate
chain <span class="bcp14">MAY</span> be included to enable verification without out-of-band
key distribution.<a href="#section-4.1-6" class="pilcrow"></a></p>
<p id="section-4.1-7"><strong>did</strong> (<span class="bcp14">OPTIONAL</span>): In Tier 3 deployments, the full DID of the
issuing agent <span class="bcp14">MAY</span> be included for resolution.<a href="#section-4.1-7" class="pilcrow"></a></p>
</section>
</div>
<div id="jwt-claims-authorization-phase">
<section id="section-4.2">
<h3 id="name-jwt-claims-authorization-ph">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-jwt-claims-authorization-ph" class="section-name selfRef">JWT Claims: Authorization Phase</a>
</h3>
<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"><strong>iss</strong> (<span class="bcp14">REQUIRED</span>): The identifier of the agent issuing the mandate.
Format depends on trust tier: an opaque string (Tier 1), an X.509
Subject DN (Tier 2), or a DID (Tier 3).<a href="#section-4.2.1-1" class="pilcrow"></a></p>
<p id="section-4.2.1-2"><strong>sub</strong> (<span class="bcp14">REQUIRED</span>): The identifier of the agent authorized to act.
<span class="bcp14">MUST</span> use the same format convention as <code>iss</code>.<a href="#section-4.2.1-2" class="pilcrow"></a></p>
<p id="section-4.2.1-3"><strong>aud</strong> (<span class="bcp14">REQUIRED</span>): The intended recipient(s). <span class="bcp14">MUST</span> include the
identifier of the target agent (<code>sub</code>). When an audit ledger is
deployed, <span class="bcp14">MUST</span> also include the ledger's identifier. When multiple
recipients are present, <span class="bcp14">MUST</span> be an array. Verifiers that are audit
ledgers <span class="bcp14">MUST</span> verify that their own identifier appears in <code>aud</code>.<a href="#section-4.2.1-3" class="pilcrow"></a></p>
<p id="section-4.2.1-4"><strong>iat</strong> (<span class="bcp14">REQUIRED</span>): Issuance time as a NumericDate <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>.<a href="#section-4.2.1-4" class="pilcrow"></a></p>
<p id="section-4.2.1-5"><strong>exp</strong> (<span class="bcp14">REQUIRED</span>): Expiration time. Implementations <span class="bcp14">SHOULD</span> set to
no more than 15 minutes after <code>iat</code> for automated workflows.<a href="#section-4.2.1-5" class="pilcrow"></a></p>
<p id="section-4.2.1-6"><strong>jti</strong> (<span class="bcp14">REQUIRED</span>): A UUID <span>[<a href="#RFC9562" class="cite xref">RFC9562</a>]</span> uniquely identifying this ACT
and, in Phase 2, the task it records. Used as the task identifier
for DAG predecessor references in <code>pred</code>.<a href="#section-4.2.1-6" class="pilcrow"></a></p>
</section>
</div>
<div id="act-authorization-claims">
<section id="section-4.2.2">
<h4 id="name-act-authorization-claims">
<a href="#section-4.2.2" class="section-number selfRef">4.2.2. </a><a href="#name-act-authorization-claims" class="section-name selfRef">ACT Authorization Claims</a>
</h4>
<p id="section-4.2.2-1"><strong>wid</strong> (<span class="bcp14">OPTIONAL</span>): A UUID identifying the workflow to which this
task belongs. When present, groups related ACTs and scopes <code>jti</code>
uniqueness to the workflow.<a href="#section-4.2.2-1" class="pilcrow"></a></p>
<p id="section-4.2.2-2"><strong>task</strong> (<span class="bcp14">REQUIRED</span>): An object describing the authorized task:<a href="#section-4.2.2-2" class="pilcrow"></a></p>
<div class="lang-json sourcecode" id="section-4.2.2-3">
<pre>
{
"task": {
"purpose": "validate_patient_dosage",
"data_sensitivity": "restricted",
"created_by": "operator:clinical-admin-01",
"expires_at": 1772064750
}
}
</pre><a href="#section-4.2.2-3" class="pilcrow"></a>
</div>
<ul class="normal">
<li class="normal" id="section-4.2.2-4.1">
<p id="section-4.2.2-4.1.1"><code>purpose</code> (<span class="bcp14">REQUIRED</span>): A string describing the intended task.
Implementations <span class="bcp14">SHOULD</span> use a controlled vocabulary or reverse-
domain notation (e.g., "com.example.validate_dosage") to enable
semantic consistency checking by the receiving agent.<a href="#section-4.2.2-4.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-4.2.2-4.2">
<p id="section-4.2.2-4.2.1"><code>data_sensitivity</code> (<span class="bcp14">OPTIONAL</span>): One of "public", "internal",
"confidential", "restricted". Receiving agents <span class="bcp14">MUST NOT</span> perform
actions that would expose data above this classification.<a href="#section-4.2.2-4.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-4.2.2-4.3">
<p id="section-4.2.2-4.3.1"><code>created_by</code> (<span class="bcp14">OPTIONAL</span>): An identifier for the human or system
that initiated the workflow. <span class="bcp14">SHOULD</span> be pseudonymous (see
<a href="#privacy-considerations" class="auto internal xref">Section 12</a>).<a href="#section-4.2.2-4.3.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-4.2.2-4.4">
<p id="section-4.2.2-4.4.1"><code>expires_at</code> (<span class="bcp14">OPTIONAL</span>): A NumericDate after which the task
mandate is no longer valid, independent of <code>exp</code>.<a href="#section-4.2.2-4.4.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="section-4.2.2-5"><strong>cap</strong> (<span class="bcp14">REQUIRED</span>): An array of capability objects, each specifying
an action the agent is authorized to perform and the constraints
under which it may do so:<a href="#section-4.2.2-5" class="pilcrow"></a></p>
<div class="lang-json sourcecode" id="section-4.2.2-6">
<pre>
{
"cap": [
{
"action": "read.patient_record",
"constraints": {
"patient_id_scope": "current_task_only",
"max_records": 1,
"data_classification_max": "restricted"
}
},
{
"action": "write.dosage_recommendation",
"constraints": {
"status": "draft_only"
}
}
]
}
</pre><a href="#section-4.2.2-6" class="pilcrow"></a>
</div>
<p id="section-4.2.2-7">Action names <span class="bcp14">MUST</span> conform to the ABNF grammar:<a href="#section-4.2.2-7" class="pilcrow"></a></p>
<div class="alignLeft art-text artwork" id="section-4.2.2-8">
<pre>
action-name = component *( "." component )
component = ALPHA *( ALPHA / DIGIT / "-" / "_" )
</pre><a href="#section-4.2.2-8" class="pilcrow"></a>
</div>
<p id="section-4.2.2-9">Receiving agents <span class="bcp14">MUST</span> perform exact string matching on action names.
Wildcard matching is NOT part of this specification.<a href="#section-4.2.2-9" class="pilcrow"></a></p>
<p id="section-4.2.2-10">When multiple capabilities match the same action, OR semantics
apply: if ANY capability grants the action, the request is
authorized subject to that capability's constraints. When multiple
constraints exist within a single capability, AND semantics apply:
ALL constraints <span class="bcp14">MUST</span> be satisfied. When the same constraint key
appears in both a capability-level and a policy-level context, the
more restrictive value applies: lower numeric limits, narrower
allow-lists (intersection), broader block-lists (union), and
narrower time windows.<a href="#section-4.2.2-10" class="pilcrow"></a></p>
<p id="section-4.2.2-11"><strong>oversight</strong> (<span class="bcp14">OPTIONAL</span>): Human oversight requirements:<a href="#section-4.2.2-11" class="pilcrow"></a></p>
<div class="lang-json sourcecode" id="section-4.2.2-12">
<pre>
{
"oversight": {
"requires_approval_for": ["write.publish", "execute.payment"],
"approval_ref": "https://approval.example.com/workflow/w-123"
}
}
</pre><a href="#section-4.2.2-12" class="pilcrow"></a>
</div>
<p id="section-4.2.2-13">When <code>requires_approval_for</code> lists an action, the receiving agent
<span class="bcp14">MUST NOT</span> execute that action autonomously. The approval mechanism
is out of scope for this specification.<a href="#section-4.2.2-13" class="pilcrow"></a></p>
<p id="section-4.2.2-14"><strong>del</strong> (<span class="bcp14">OPTIONAL</span>): Delegation provenance, establishing the chain
of authority from the root mandate to this ACT. If <code>del</code> is absent,
the ACT <span class="bcp14">MUST</span> be treated as a root mandate with <code>depth</code> = 0 and
further delegation is not permitted (i.e., the receiving agent <span class="bcp14">MUST NOT</span> issue sub-mandates based on this ACT).<a href="#section-4.2.2-14" class="pilcrow"></a></p>
<div class="lang-json sourcecode" id="section-4.2.2-15">
<pre>
{
"del": {
"depth": 1,
"max_depth": 3,
"chain": [
{
"delegator": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
"jti": "550e8400-e29b-41d4-a716-446655440000",
"sig": "base64url-encoded-signature-of-parent-act-hash"
}
]
}
}
</pre><a href="#section-4.2.2-15" class="pilcrow"></a>
</div>
<ul class="normal">
<li class="normal" id="section-4.2.2-16.1">
<p id="section-4.2.2-16.1.1"><code>depth</code>: The current delegation depth. 0 means this is a root
mandate issued by a human or root authority.<a href="#section-4.2.2-16.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-4.2.2-16.2">
<p id="section-4.2.2-16.2.1"><code>max_depth</code>: The maximum permitted delegation depth. Receiving
agents <span class="bcp14">MUST NOT</span> issue sub-mandates that would exceed this depth.<a href="#section-4.2.2-16.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-4.2.2-16.3">
<p id="section-4.2.2-16.3.1"><code>chain</code>: An array of delegation provenance records ordered from
root to immediate parent (<code>chain[0]</code> is the root authority,
<code>chain[depth-1]</code> is the direct parent of this ACT). Each entry
contains:<a href="#section-4.2.2-16.3.1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-4.2.2-16.3.2.1">
<p id="section-4.2.2-16.3.2.1.1"><code>delegator</code>: The identifier of the agent that authorized this
delegation step (i.e., the <code>iss</code> of the parent ACT at that
depth).<a href="#section-4.2.2-16.3.2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-4.2.2-16.3.2.2">
<p id="section-4.2.2-16.3.2.2.1"><code>jti</code>: The <code>jti</code> of the parent ACT that authorized this
delegation step.<a href="#section-4.2.2-16.3.2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-4.2.2-16.3.2.3">
<p id="section-4.2.2-16.3.2.3.1"><code>sig</code>: The delegating agent's signature over the SHA-256 hash
of that parent ACT, providing cryptographic linkage without
requiring the full parent ACT to be transmitted.<a href="#section-4.2.2-16.3.2.3.1" class="pilcrow"></a></p>
</li>
</ul>
</li>
</ul>
<p id="section-4.2.2-17">The <code>sig</code> field in each chain entry is the critical departure from
AAP's delegation model: rather than requiring a central AS to
validate the chain, any verifier holding the delegating agent's
public key can independently verify each step by recomputing the
hash and checking the signature.<a href="#section-4.2.2-17" class="pilcrow"></a></p>
</section>
</div>
</section>
</div>
<div id="jwt-claims-execution-phase">
<section id="section-4.3">
<h3 id="name-jwt-claims-execution-phase">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-jwt-claims-execution-phase" class="section-name selfRef">JWT Claims: Execution Phase</a>
</h3>
<p id="section-4.3-1">The following claims are added by the executing agent when
transitioning to Phase 2. Their presence distinguishes an Execution
Record from an Authorization Mandate.<a href="#section-4.3-1" class="pilcrow"></a></p>
<p id="section-4.3-2"><strong>exec_act</strong> (<span class="bcp14">REQUIRED</span> in Phase 2): A string identifying the action
actually performed. <span class="bcp14">MUST</span> conform to the same ABNF grammar as
capability action names. <span class="bcp14">MUST</span> match one of the <code>action</code> values in
the <code>cap</code> array of the Phase 1 claims.<a href="#section-4.3-2" class="pilcrow"></a></p>
<p id="section-4.3-3"><strong>pred</strong> (<span class="bcp14">REQUIRED</span> in Phase 2): An array of <code>jti</code> values of predecessor
tasks in the DAG. An empty array indicates a root task. Each value
<span class="bcp14">MUST</span> be the <code>jti</code> of a previously verified ACT (Phase 2) within
the same workflow (same <code>wid</code>) or the global ACT store if <code>wid</code> is
absent.<a href="#section-4.3-3" class="pilcrow"></a></p>
<p id="section-4.3-4"><strong>inp_hash</strong> (<span class="bcp14">OPTIONAL</span>): The base64url encoding (without padding) of
the SHA-256 hash of the task's input data, computed over the raw
octets of the serialized input. Provides cryptographic evidence of
what data the agent processed.<a href="#section-4.3-4" class="pilcrow"></a></p>
<p id="section-4.3-5"><strong>out_hash</strong> (<span class="bcp14">OPTIONAL</span>): The base64url encoding (without padding) of
the SHA-256 hash of the task's output data, using the same format
as <code>inp_hash</code>. Provides cryptographic evidence of what data the
agent produced.<a href="#section-4.3-5" class="pilcrow"></a></p>
<p id="section-4.3-6"><strong>exec_ts</strong> (<span class="bcp14">REQUIRED</span> in Phase 2): A NumericDate recording the
actual time of task execution. <span class="bcp14">MAY</span> differ from <code>iat</code> when the agent
queued the mandate before execution. <span class="bcp14">MUST</span> be greater than or equal
to <code>iat</code>. <span class="bcp14">SHOULD</span> be less than or equal to <code>exp</code>; execution after
mandate expiry is possible when tasks are long-running and <span class="bcp14">MUST NOT</span>
cause automatic rejection, but implementors <span class="bcp14">SHOULD</span> log a warning.<a href="#section-4.3-6" class="pilcrow"></a></p>
<p id="section-4.3-7"><strong>status</strong> (<span class="bcp14">REQUIRED</span> in Phase 2): One of "completed", "failed",
"partial". Allows audit systems to distinguish successful execution
from partial or failed attempts, which is essential for regulated
environments where failed attempts must be recorded.<a href="#section-4.3-7" class="pilcrow"></a></p>
<p id="section-4.3-8"><strong>err</strong> (<span class="bcp14">OPTIONAL</span>, present when <code>status</code> is "failed" or "partial"):
An object providing error context:<a href="#section-4.3-8" class="pilcrow"></a></p>
<div class="lang-json sourcecode" id="section-4.3-9">
<pre>
{
"err": {
"code": "constraint_violation",
"detail": "data_classification_max exceeded"
}
}
</pre><a href="#section-4.3-9" class="pilcrow"></a>
</div>
<p id="section-4.3-10">Error detail <span class="bcp14">SHOULD NOT</span> reveal internal system state beyond what is
necessary for audit purposes.<a href="#section-4.3-10" class="pilcrow"></a></p>
</section>
</div>
<div id="complete-examples">
<section id="section-4.4">
<h3 id="name-complete-examples">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-complete-examples" class="section-name selfRef">Complete Examples</a>
</h3>
<div id="example-phase-1-authorization-mandate">
<section id="section-4.4.1">
<h4 id="name-example-phase-1-authorizati">
<a href="#section-4.4.1" class="section-number selfRef">4.4.1. </a><a href="#name-example-phase-1-authorizati" class="section-name selfRef">Example: Phase 1 — Authorization Mandate</a>
</h4>
<div class="alignLeft art-text artwork" id="section-4.4.1-1">
<pre>
{
"alg": "ES256",
"typ": "act+jwt",
"kid": "agent-clinical-key-2026-03"
}
.
{
"iss": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
"sub": "did:key:z6MknGc3omCyas4b1GmEn4xySHgLuSHxrKrUBnrhJekxZHFz",
"aud": [
"did:key:z6MknGc3omCyas4b1GmEn4xySHgLuSHxrKrUBnrhJekxZHFz",
"https://ledger.hospital.example.com"
],
"iat": 1772064000,
"exp": 1772064900,
"jti": "550e8400-e29b-41d4-a716-446655440001",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"task": {
"purpose": "validate_treatment_recommendation",
"data_sensitivity": "restricted",
"created_by": "operator:clinical-admin-01"
},
"cap": [
{
"action": "read.patient_record",
"constraints": {
"patient_id_scope": "current_task_only",
"max_records": 1
}
},
{
"action": "write.safety_assessment",
"constraints": {
"status": "draft_only"
}
}
],
"oversight": {
"requires_approval_for": ["write.publish_assessment"]
},
"del": {
"depth": 0,
"max_depth": 2,
"chain": []
}
}
</pre><a href="#section-4.4.1-1" class="pilcrow"></a>
</div>
</section>
</div>
<div id="example-phase-2-execution-record-same-token-re-signed-by-target-agent">
<section id="section-4.4.2">
<h4 id="name-example-phase-2-execution-r">
<a href="#section-4.4.2" class="section-number selfRef">4.4.2. </a><a href="#name-example-phase-2-execution-r" class="section-name selfRef">Example: Phase 2 — Execution Record (same token, re-signed by target agent)</a>
</h4>
<div class="alignLeft art-text artwork" id="section-4.4.2-1">
<pre>
{
"alg": "EdDSA",
"typ": "act+jwt",
"kid": "agent-safety-key-2026-03"
}
.
{
"iss": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
"sub": "did:key:z6MknGc3omCyas4b1GmEn4xySHgLuSHxrKrUBnrhJekxZHFz",
"aud": [
"did:key:z6MknGc3omCyas4b1GmEn4xySHgLuSHxrKrUBnrhJekxZHFz",
"https://ledger.hospital.example.com"
],
"iat": 1772064000,
"exp": 1772064900,
"jti": "550e8400-e29b-41d4-a716-446655440001",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"task": {
"purpose": "validate_treatment_recommendation",
"data_sensitivity": "restricted",
"created_by": "operator:clinical-admin-01"
},
"cap": [
{
"action": "read.patient_record",
"constraints": {
"patient_id_scope": "current_task_only",
"max_records": 1
}
},
{
"action": "write.safety_assessment",
"constraints": {
"status": "draft_only"
}
}
],
"oversight": {
"requires_approval_for": ["write.publish_assessment"]
},
"del": {
"depth": 0,
"max_depth": 2,
"chain": []
},
"exec_act": "write.safety_assessment",
"pred": ["550e8400-e29b-41d4-a716-446655440000"],
"inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"exec_ts": 1772064300,
"status": "completed"
}
</pre><a href="#section-4.4.2-1" class="pilcrow"></a>
</div>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="trust-model">
<section id="section-5">
<h2 id="name-trust-model">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-trust-model" class="section-name selfRef">Trust Model</a>
</h2>
<p id="section-5-1">ACT defines four trust tiers. Tier 1 is mandatory-to-implement; all
others are optional upgrades. An ACT verifier <span class="bcp14">MUST</span> be able to process
ACTs from any tier it has configured. The trust tier in use is
determined by the <code>kid</code> format and the presence of <code>x5c</code> or <code>did</code>
header parameters.<a href="#section-5-1" class="pilcrow"></a></p>
<div id="tier-0-bootstrap-tofu-trust-on-first-use">
<section id="section-5.1">
<h3 id="name-tier-0-bootstrap-tofu-trust">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-tier-0-bootstrap-tofu-trust" class="section-name selfRef">Tier 0: Bootstrap (TOFU — Trust On First Use)</a>
</h3>
<p id="section-5.1-1">Tier 0 is NOT part of the normative trust model and <span class="bcp14">MUST NOT</span> be used
in regulated environments. It is defined here for documentation
purposes only, to describe the common bootstrapping scenario.<a href="#section-5.1-1" class="pilcrow"></a></p>
<p id="section-5.1-2">In Tier 0, the first ACT received from an agent establishes its
public key. This is equivalent to SSH TOFU behavior: an attacker
who intercepts the first message can substitute their own key. Tier 0
deployments <span class="bcp14">MUST</span> transition to Tier 1 or higher before exchanging
ACTs that carry sensitive capabilities.<a href="#section-5.1-2" class="pilcrow"></a></p>
</section>
</div>
<div id="tier1">
<section id="section-5.2">
<h3 id="name-tier-1-pre-shared-keys-mand">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-tier-1-pre-shared-keys-mand" class="section-name selfRef">Tier 1: Pre-Shared Keys (Mandatory-to-Implement)</a>
</h3>
<p id="section-5.2-1">In Tier 1, both parties exchange public keys out-of-band prior to
the first ACT exchange. The <code>kid</code> is an opaque string agreed during
the key exchange. Implementations <span class="bcp14">MUST</span> support Tier 1.<a href="#section-5.2-1" class="pilcrow"></a></p>
<p id="section-5.2-2">Key exchange <span class="bcp14">MAY</span> occur via any out-of-band mechanism: manual
configuration, a configuration management system, or a prior
authenticated channel. This specification does not mandate a
specific key exchange protocol.<a href="#section-5.2-2" class="pilcrow"></a></p>
<p id="section-5.2-3">Tier 1 public keys <span class="bcp14">MUST</span> be Ed25519 <span>[<a href="#RFC8037" class="cite xref">RFC8037</a>]</span> or P-256 (ES256)
<span>[<a href="#RFC7518" class="cite xref">RFC7518</a>]</span> keys. RSA keys <span class="bcp14">SHOULD NOT</span> be used in Tier 1 deployments due to
key size. Key rotation <span class="bcp14">MUST</span> be performed out-of-band using the same
mechanism as the initial exchange.<a href="#section-5.2-3" class="pilcrow"></a></p>
</section>
</div>
<div id="tier-2-pki-x509">
<section id="section-5.3">
<h3 id="name-tier-2-pki-x509">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-tier-2-pki-x509" class="section-name selfRef">Tier 2: PKI / X.509</a>
</h3>
<p id="section-5.3-1">In Tier 2, agent identity is bound to an X.509 certificate issued
by a mutually trusted Certificate Authority (CA). The <code>kid</code> is the
certificate thumbprint (SHA-256 of the DER-encoded certificate).<a href="#section-5.3-1" class="pilcrow"></a></p>
<p id="section-5.3-2">Cross-organizational ACT exchange in Tier 2 requires either:<a href="#section-5.3-2" class="pilcrow"></a></p>
<p id="section-5.3-3">(a) a mutually trusted root CA, or
(b) cross-certification between the organizations' CAs, or
(c) explicit trust anchoring (one organization's CA is added to
the other's trust store).<a href="#section-5.3-3" class="pilcrow"></a></p>
<p id="section-5.3-4">The <code>x5c</code> JOSE header parameter <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span> <span class="bcp14">MAY</span> carry the full
certificate chain to enable verification without out-of-band trust
store configuration.<a href="#section-5.3-4" class="pilcrow"></a></p>
</section>
</div>
<div id="tier-3-decentralized-identifiers-did">
<section id="section-5.4">
<h3 id="name-tier-3-decentralized-identi">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-tier-3-decentralized-identi" class="section-name selfRef">Tier 3: Decentralized Identifiers (DID)</a>
</h3>
<p id="section-5.4-1">In Tier 3, agent identity is expressed as a DID <span>[<a href="#W3C-DID" class="cite xref">W3C-DID</a>]</span>. The
<code>kid</code> is a DID key fragment. The <code>did</code> JOSE header parameter carries
the full DID for resolution.<a href="#section-5.4-1" class="pilcrow"></a></p>
<p id="section-5.4-2">Implementations <span class="bcp14">SHOULD</span> support at minimum <code>did:key</code> <span>[<a href="#DID-KEY" class="cite xref">DID-KEY</a>]</span> for
self-contained key distribution without external resolution, and
<code>did:web</code> <span>[<a href="#DID-WEB" class="cite xref">DID-WEB</a>]</span> for organizations that prefer DNS-anchored
identity.<a href="#section-5.4-2" class="pilcrow"></a></p>
<p id="section-5.4-3">DID resolution latency introduces a dependency on external
infrastructure. To preserve the zero-infrastructure baseline,
implementations using Tier 3 <span class="bcp14">MAY</span> cache DID Documents and <span class="bcp14">MUST</span>
specify a maximum cache TTL in their configuration.<a href="#section-5.4-3" class="pilcrow"></a></p>
</section>
</div>
<div id="cross-tier-interoperability">
<section id="section-5.5">
<h3 id="name-cross-tier-interoperability">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-cross-tier-interoperability" class="section-name selfRef">Cross-Tier Interoperability</a>
</h3>
<p id="section-5.5-1">A delegation chain <span class="bcp14">MAY</span> include agents operating at different trust
tiers. Each step in the chain is verified using the trust tier of
the signing agent at that step. Verifiers <span class="bcp14">MUST NOT</span> reject a chain
solely because it mixes trust tiers, but <span class="bcp14">MAY</span> apply stricter
policy for chains that include Tier 0 or Tier 1 steps when
exchanging sensitive capabilities.<a href="#section-5.5-1" class="pilcrow"></a></p>
</section>
</div>
</section>
</div>
<div id="delegation-chain">
<section id="section-6">
<h2 id="name-delegation-chain">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-delegation-chain" class="section-name selfRef">Delegation Chain</a>
</h2>
<p id="section-6-1">ACT delegation is peer-to-peer: no Authorization Server is involved.
Delegation is expressed as a cryptographically verifiable chain of
ACT issuances, where each step reduces privileges relative to the
previous step.<a href="#section-6-1" class="pilcrow"></a></p>
<div id="peer-to-peer-delegation">
<section id="section-6.1">
<h3 id="name-peer-to-peer-delegation">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-peer-to-peer-delegation" class="section-name selfRef">Peer-to-Peer Delegation</a>
</h3>
<p id="section-6.1-1">When Agent A authorizes Agent B to perform a sub-task, Agent A:<a href="#section-6.1-1" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="section-6.1-2">
<li id="section-6.1-2.1">
<p id="section-6.1-2.1.1">Creates a new ACT with <code>sub</code> set to Agent B's identifier.<a href="#section-6.1-2.1.1" class="pilcrow"></a></p>
</li>
<li id="section-6.1-2.2">
<p id="section-6.1-2.2.1">Sets <code>cap</code> to a subset of A's own authorized capabilities,
with constraints at least as restrictive as those in A's mandate.<a href="#section-6.1-2.2.1" class="pilcrow"></a></p>
</li>
<li id="section-6.1-2.3">
<p id="section-6.1-2.3.1">Sets <code>del.depth</code> to A's own <code>del.depth + 1</code>.<a href="#section-6.1-2.3.1" class="pilcrow"></a></p>
</li>
<li id="section-6.1-2.4">
<p id="section-6.1-2.4.1">Sets <code>del.max_depth</code> to no more than the <code>del.max_depth</code> value
in A's own mandate.<a href="#section-6.1-2.4.1" class="pilcrow"></a></p>
</li>
<li id="section-6.1-2.5">
<p id="section-6.1-2.5.1">Adds a chain entry containing A's identifier as <code>delegator</code>,
the <code>jti</code> of A's own mandate, and a <code>sig</code> value computed as:<a href="#section-6.1-2.5.1" class="pilcrow"></a></p>
<div class="alignLeft art-text artwork" id="section-6.1-2.5.2">
<pre>
sig = Sign(A.private_key, SHA-256(canonical_ACT_phase1_bytes))
</pre><a href="#section-6.1-2.5.2" class="pilcrow"></a>
</div>
<p id="section-6.1-2.5.3">
where <code>canonical_ACT_phase1_bytes</code> is the UTF-8 encoded bytes
of the JWS Compact Serialization of A's Phase 1 ACT.<a href="#section-6.1-2.5.3" class="pilcrow"></a></p>
</li>
<li id="section-6.1-2.6">
<p id="section-6.1-2.6.1">Signs the new ACT with A's private key.<a href="#section-6.1-2.6.1" class="pilcrow"></a></p>
</li>
</ol>
</section>
</div>
<div id="privilege-reduction-requirements">
<section id="section-6.2">
<h3 id="name-privilege-reduction-require">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-privilege-reduction-require" class="section-name selfRef">Privilege Reduction Requirements</a>
</h3>
<p id="section-6.2-1">When issuing a delegated ACT, the issuing agent <span class="bcp14">MUST</span> reduce
privileges by one or more of:<a href="#section-6.2-1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-6.2-2.1">
<p id="section-6.2-2.1.1">Removing capabilities (sub-set of parent capabilities only).<a href="#section-6.2-2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-6.2-2.2">
<p id="section-6.2-2.2.1">Adding stricter constraints (lower rate limits, narrower domains,
shorter time windows, lower data classification ceiling).<a href="#section-6.2-2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-6.2-2.3">
<p id="section-6.2-2.3.1">Reducing token lifetime (<code>exp</code> closer to <code>iat</code>).<a href="#section-6.2-2.3.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-6.2-2.4">
<p id="section-6.2-2.4.1">Reducing <code>del.max_depth</code>.<a href="#section-6.2-2.4.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="section-6.2-3">The issuing agent <span class="bcp14">MUST NOT</span> grant capabilities not present in its
own mandate. Capability escalation via delegation is prohibited and
<span class="bcp14">MUST</span> be detected and rejected by verifiers.<a href="#section-6.2-3" class="pilcrow"></a></p>
<p id="section-6.2-4">For well-known numeric constraints (e.g., <code>max_records</code>,
<code>max_requests_per_hour</code>), "more restrictive" means a numerically
lower or equal value. For well-known enumerated constraints
(e.g., <code>data_sensitivity</code>), "more restrictive" means a value that
is equal or higher in the defined ordering
("public" &lt; "internal" &lt; "confidential" &lt; "restricted").
For unknown or domain-specific constraint keys, verifiers <span class="bcp14">MUST</span>
treat the constraint as non-comparable and <span class="bcp14">MUST</span> reject the
delegation unless the delegated constraint value is byte-for-byte
identical to the parent constraint value.<a href="#section-6.2-4" class="pilcrow"></a></p>
</section>
</div>
<div id="delegation-verification">
<section id="section-6.3">
<h3 id="name-delegation-verification">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-delegation-verification" class="section-name selfRef">Delegation Verification</a>
</h3>
<p id="section-6.3-1">A verifier receiving a delegated ACT <span class="bcp14">MUST</span>:<a href="#section-6.3-1" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="section-6.3-2">
<li id="section-6.3-2.1">
<p id="section-6.3-2.1.1">Verify the ACT's own signature (<a href="#auth-verification" class="auto internal xref">Section 8.1</a>).<a href="#section-6.3-2.1.1" class="pilcrow"></a></p>
</li>
<li id="section-6.3-2.2">
<p id="section-6.3-2.2.1">For each entry in <code>del.chain</code>, in order from index 0 to
<code>del.depth - 1</code>:
a. Retrieve the public key for <code>entry.delegator</code>.
b. Verify that <code>entry.sig</code> is a valid signature over the SHA-256
hash of the referenced parent ACT (identified by <code>entry.jti</code>).
c. Verify that the capabilities in the current ACT are a subset
of the capabilities in the parent ACT, per the constraint
comparison rules in <a href="#privilege-reduction-requirements" class="auto internal xref">Section 6.2</a>.<a href="#section-6.3-2.2.1" class="pilcrow"></a></p>
</li>
<li id="section-6.3-2.3">
<p id="section-6.3-2.3.1">Verify that <code>del.depth</code> does not exceed <code>del.max_depth</code>.<a href="#section-6.3-2.3.1" class="pilcrow"></a></p>
</li>
<li id="section-6.3-2.4">
<p id="section-6.3-2.4.1">Verify that <code>del.chain</code> length equals <code>del.depth</code>.<a href="#section-6.3-2.4.1" class="pilcrow"></a></p>
</li>
</ol>
<p id="section-6.3-3">If any step fails, the ACT <span class="bcp14">MUST</span> be rejected.<a href="#section-6.3-3" class="pilcrow"></a></p>
</section>
</div>
</section>
</div>
<div id="dag-structure">
<section id="section-7">
<h2 id="name-dag-structure-and-causal-or">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-dag-structure-and-causal-or" class="section-name selfRef">DAG Structure and Causal Ordering</a>
</h2>
<p id="section-7-1">ACTs in Phase 2 form a DAG over the <code>pred</code> (predecessor) claim. The DAG
encodes causal dependencies: a task <span class="bcp14">MAY</span> NOT begin before all its
parent tasks are completed.<a href="#section-7-1" class="pilcrow"></a></p>
<div id="dag-validation">
<section id="section-7.1">
<h3 id="name-dag-validation">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-dag-validation" class="section-name selfRef">DAG Validation</a>
</h3>
<p id="section-7.1-1">When processing a Phase 2 ACT, implementations <span class="bcp14">MUST</span>:<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"><strong>Uniqueness</strong>: Verify the <code>jti</code> is unique within the workflow
(<code>wid</code>) or globally if <code>wid</code> is absent.<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"><strong>Predecessor Existence</strong>: Verify every <code>jti</code> in <code>pred</code> corresponds to
a Phase 2 ACT available in the ACT store or audit ledger.<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"><strong>Temporal Ordering</strong>: Verify that for each parent:
<code>parent.exec_ts &lt; child.exec_ts + clock_skew_tolerance</code>
(<span class="bcp14">RECOMMENDED</span> tolerance: 30 seconds). Causal ordering is
primarily enforced by DAG structure, not timestamps.<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"><strong>Acyclicity</strong>: Following parent references <span class="bcp14">MUST NOT</span> lead back
to the current ACT's <code>jti</code>. Implementations <span class="bcp14">MUST</span> enforce a
maximum ancestor traversal limit (<span class="bcp14">RECOMMENDED</span>: 10,000 nodes).<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"><strong>Capability Consistency</strong>: Verify that <code>exec_act</code> matches one
of the <code>action</code> values in the <code>cap</code> array from Phase 1.<a href="#section-7.1-2.5.1" class="pilcrow"></a></p>
</li>
</ol>
</section>
</div>
<div id="root-tasks-and-fan-in">
<section id="section-7.2">
<h3 id="name-root-tasks-and-fan-in">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-root-tasks-and-fan-in" class="section-name selfRef">Root Tasks and Fan-in</a>
</h3>
<p id="section-7.2-1">A root task has <code>pred = []</code>. A workflow <span class="bcp14">MAY</span> have multiple root tasks
representing parallel branches with no shared predecessor.<a href="#section-7.2-1" class="pilcrow"></a></p>
<p id="section-7.2-2">Fan-in — a task with multiple parents — is expressed naturally:<a href="#section-7.2-2" class="pilcrow"></a></p>
<div class="lang-json sourcecode" id="section-7.2-3">
<pre>
{
"pred": [
"550e8400-e29b-41d4-a716-446655440001",
"550e8400-e29b-41d4-a716-446655440002"
]
}
</pre><a href="#section-7.2-3" class="pilcrow"></a>
</div>
<p id="section-7.2-4">This indicates the current task depends on the completion of both
referenced parent tasks, which <span class="bcp14">MAY</span> have been executed in parallel
by different agents.<a href="#section-7.2-4" class="pilcrow"></a></p>
</section>
</div>
<div id="dag-vs-linear">
<section id="section-7.3">
<h3 id="name-dag-vs-linear-delegation-ch">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-dag-vs-linear-delegation-ch" class="section-name selfRef">DAG vs Linear Delegation Chains</a>
</h3>
<p id="section-7.3-1">Several concurrent proposals for agent authorization model delegation
as an ordered, linear chain of tokens or principals. Examples include
the <code>actchain</code> claim of
<span>[<a href="#I-D.oauth-transaction-tokens-for-agents" class="cite xref">I-D.oauth-transaction-tokens-for-agents</a>]</span>, the Agentic JWT
construction of <span>[<a href="#AgenticJWT" class="cite xref">AgenticJWT</a>]</span>, the AIP / Interaction-Bound Context Token
(IBCT) model of <span>[<a href="#AIP-IBCT" class="cite xref">AIP-IBCT</a>]</span>, and the delegation record defined in
<span>[<a href="#I-D.helixar-hdp-agentic-delegation" class="cite xref">I-D.helixar-hdp-agentic-delegation</a>]</span>. In each of these
designs, the trail from the originator to the final executor is
represented as an ordered array recording one predecessor per hop.<a href="#section-7.3-1" class="pilcrow"></a></p>
<div id="what-linear-chains-express-well">
<section id="section-7.3.1">
<h4 id="name-what-linear-chains-express-">
<a href="#section-7.3.1" class="section-number selfRef">7.3.1. </a><a href="#name-what-linear-chains-express-" class="section-name selfRef">What Linear Chains Express Well</a>
</h4>
<p id="section-7.3.1-1">Linear chains are a natural fit for simple sequential delegation:
agent A delegates to agent B, which delegates to agent C. The chain
records the history of that single hand-off in order, and verifiers
can walk from the current holder back to the originator without
branching. For interactive user-to-agent-to-service flows, where each
step has exactly one predecessor, a linear chain is both sufficient
and compact.<a href="#section-7.3.1-1" class="pilcrow"></a></p>
</section>
</div>
<div id="limitations-of-linear-chains">
<section id="section-7.3.2">
<h4 id="name-limitations-of-linear-chain">
<a href="#section-7.3.2" class="section-number selfRef">7.3.2. </a><a href="#name-limitations-of-linear-chain" class="section-name selfRef">Limitations of Linear Chains</a>
</h4>
<p id="section-7.3.2-1">Agentic workflows in practice are rarely purely linear. Planner
agents dispatch parallel sub-tasks; synthesizer agents consume
results from multiple independent branches; tool calls execute
concurrently and their outputs are merged. A linear chain cannot
faithfully represent the following common topologies:<a href="#section-7.3.2-1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-7.3.2-2.1">
<p id="section-7.3.2-2.1.1"><strong>Fork</strong>: A single task spawns multiple independent sub-tasks. A
linear chain cannot express that two concurrent sub-executions
share a common parent authorization but are otherwise
independent; each sub-task would either omit its siblings or
fabricate a false ordering between them.<a href="#section-7.3.2-2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-7.3.2-2.2">
<p id="section-7.3.2-2.2.1"><strong>Join (fan-in)</strong>: A task whose output depends on results from
several predecessors has no single prior hop. Linear chains
cannot express multiple-parent relationships without either
collapsing parallel branches into an arbitrary order or
duplicating records.<a href="#section-7.3.2-2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-7.3.2-2.3">
<p id="section-7.3.2-2.3.1"><strong>Diamond dependencies</strong>: A planner dispatches parallel work and
later synthesizes the results. The synthesis step depends on
every branch, and all branches depend on the same planner.
This diamond shape requires a DAG; a linear chain forces the
verifier to pick one branch and discard the others.<a href="#section-7.3.2-2.3.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-7.3.2-2.4">
<p id="section-7.3.2-2.4.1"><strong>Cross-chain references</strong>: When two independently authorized
chains produce outputs that are later combined (e.g., a shared
cache lookup and a fresh retrieval), linear chains force a
single history and cannot record that the combined result has
two distinct provenances.<a href="#section-7.3.2-2.4.1" class="pilcrow"></a></p>
</li>
</ul>
</section>
</div>
<div id="acts-dag-approach">
<section id="section-7.3.3">
<h4 id="name-acts-dag-approach">
<a href="#section-7.3.3" class="section-number selfRef">7.3.3. </a><a href="#name-acts-dag-approach" class="section-name selfRef">ACT's DAG Approach</a>
</h4>
<p id="section-7.3.3-1">As specified in <a href="#jwt-claims-execution-phase" class="auto internal xref">Section 4.3</a>, the <code>pred</code> claim is
an array of parent <code>jti</code> values rather than a single scalar. This
allows an ACT to record:<a href="#section-7.3.3-1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-7.3.3-2.1">
<p id="section-7.3.3-2.1.1">Zero parents (a root task, <code>pred = []</code>);<a href="#section-7.3.3-2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-7.3.3-2.2">
<p id="section-7.3.3-2.2.1">Exactly one parent (a linear chain, equivalent to the
single-predecessor designs referenced above);<a href="#section-7.3.3-2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-7.3.3-2.3">
<p id="section-7.3.3-2.3.1">Multiple parents (fan-in from parallel branches); and<a href="#section-7.3.3-2.3.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-7.3.3-2.4">
<p id="section-7.3.3-2.4.1">Any acyclic shape that matches the actual execution structure.<a href="#section-7.3.3-2.4.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="section-7.3.3-3">The following example illustrates a diamond workflow. A research
agent (A) dispatches a web-search agent (B) and a code-analysis
agent (C) in parallel; both complete, and their outputs are
combined by a writer agent (D):<a href="#section-7.3.3-3" class="pilcrow"></a></p>
<div class="alignLeft art-text artwork" id="section-7.3.3-4">
<pre>
+-----+
| A | pred = []
+-----+
/ \
v v
+---+ +---+
| B | | C | pred = [A.jti]
+---+ +---+
\ /
v v
+-----+
| D | pred = [B.jti, C.jti]
+-----+
</pre><a href="#section-7.3.3-4" class="pilcrow"></a>
</div>
<p id="section-7.3.3-5">A linear <code>actchain</code> representation cannot express that D depends on
both B and C. At best, it can record one of the two parents and lose
the other, or serialize B and C into a false sequential order.<a href="#section-7.3.3-5" class="pilcrow"></a></p>
</section>
</div>
<div id="verifiability-implications">
<section id="section-7.3.4">
<h4 id="name-verifiability-implications">
<a href="#section-7.3.4" class="section-number selfRef">7.3.4. </a><a href="#name-verifiability-implications" class="section-name selfRef">Verifiability Implications</a>
</h4>
<p id="section-7.3.4-1">With a DAG representation, an auditor holding the set of Phase 2
ACTs for a workflow can reconstruct the full execution graph, not
just one chain per final record. This matters for:<a href="#section-7.3.4-1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-7.3.4-2.1">
<p id="section-7.3.4-2.1.1"><strong>Debugging</strong>: identifying which branch contributed an erroneous
input to a downstream synthesis.<a href="#section-7.3.4-2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-7.3.4-2.2">
<p id="section-7.3.4-2.2.1"><strong>Compliance</strong>: demonstrating that every input to a regulated
decision was itself authorized, not only the most recent hop.<a href="#section-7.3.4-2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-7.3.4-2.3">
<p id="section-7.3.4-2.3.1"><strong>Tamper-evidence</strong>: detecting that a branch has been omitted,
since the surviving siblings' <code>pred</code> arrays name the missing
predecessor by <code>jti</code>.<a href="#section-7.3.4-2.3.1" class="pilcrow"></a></p>
</li>
</ul>
</section>
</div>
<div id="interoperability-with-linear-chain-designs">
<section id="section-7.3.5">
<h4 id="name-interoperability-with-linea">
<a href="#section-7.3.5" class="section-number selfRef">7.3.5. </a><a href="#name-interoperability-with-linea" class="section-name selfRef">Interoperability with Linear-Chain Designs</a>
</h4>
<p id="section-7.3.5-1">ACT's DAG reduces to a linear chain in the degenerate case where
every <code>pred</code> array has length zero or one. An implementation that
requires linear-chain semantics <span class="bcp14">MAY</span> treat such ACTs as equivalent
to <code>actchain</code>-style records and ignore the fork/join capability.
The reverse reduction is not available: a linear-chain-only design
cannot represent ACT DAG topologies without loss of information.<a href="#section-7.3.5-1" class="pilcrow"></a></p>
<p id="section-7.3.5-2">ACT therefore takes the linear chain as a strict subset of its
model rather than as a competing approach. The DAG generalization
is deliberate and is motivated by the concurrent, branching nature
of real agentic executions rather than by any deficiency in the
linear-chain designs for the sequential cases they target.<a href="#section-7.3.5-2" class="pilcrow"></a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="verification-procedure">
<section id="section-8">
<h2 id="name-verification-procedure">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-verification-procedure" class="section-name selfRef">Verification Procedure</a>
</h2>
<div id="auth-verification">
<section id="section-8.1">
<h3 id="name-authorization-phase-verific">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-authorization-phase-verific" class="section-name selfRef">Authorization Phase Verification</a>
</h3>
<p id="section-8.1-1">A receiving agent <span class="bcp14">MUST</span> verify a Phase 1 ACT as follows:<a href="#section-8.1-1" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="section-8.1-2">
<li id="section-8.1-2.1">
<p id="section-8.1-2.1.1">Parse JWS Compact Serialization per <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>.<a href="#section-8.1-2.1.1" class="pilcrow"></a></p>
</li>
<li id="section-8.1-2.2">
<p id="section-8.1-2.2.1">Verify <code>typ</code> is "act+jwt".<a href="#section-8.1-2.2.1" class="pilcrow"></a></p>
</li>
<li id="section-8.1-2.3">
<p id="section-8.1-2.3.1">Verify <code>alg</code> is in the verifier's algorithm allowlist. The
allowlist <span class="bcp14">MUST NOT</span> include "none" or any symmetric algorithm.<a href="#section-8.1-2.3.1" class="pilcrow"></a></p>
</li>
<li id="section-8.1-2.4">
<p id="section-8.1-2.4.1">Retrieve the public key for <code>kid</code> per the applicable trust tier
(<a href="#trust-model" class="auto internal xref">Section 5</a>).<a href="#section-8.1-2.4.1" class="pilcrow"></a></p>
</li>
<li id="section-8.1-2.5">
<p id="section-8.1-2.5.1">Verify the JWS signature.<a href="#section-8.1-2.5.1" class="pilcrow"></a></p>
</li>
<li id="section-8.1-2.6">
<p id="section-8.1-2.6.1">Verify <code>exp</code> has not passed (with clock skew tolerance:
<span class="bcp14">RECOMMENDED</span> maximum 5 minutes).<a href="#section-8.1-2.6.1" class="pilcrow"></a></p>
</li>
<li id="section-8.1-2.7">
<p id="section-8.1-2.7.1">Verify <code>iat</code> is not unreasonably in the future (<span class="bcp14">RECOMMENDED</span>:
no more than 30 seconds ahead).<a href="#section-8.1-2.7.1" class="pilcrow"></a></p>
</li>
<li id="section-8.1-2.8">
<p id="section-8.1-2.8.1">Verify <code>aud</code> contains the verifier's own identifier.<a href="#section-8.1-2.8.1" class="pilcrow"></a></p>
</li>
<li id="section-8.1-2.9">
<p id="section-8.1-2.9.1">Verify <code>iss</code> is a trusted agent identity per local policy.<a href="#section-8.1-2.9.1" class="pilcrow"></a></p>
</li>
<li id="section-8.1-2.10">
<p id="section-8.1-2.10.1">Verify <code>sub</code> matches the verifier's own identifier (the agent
is the intended recipient of this mandate).<a href="#section-8.1-2.10.1" class="pilcrow"></a></p>
</li>
<li id="section-8.1-2.11">
<p id="section-8.1-2.11.1">Verify all required claims are present and well-formed.<a href="#section-8.1-2.11.1" class="pilcrow"></a></p>
</li>
<li id="section-8.1-2.12">
<p id="section-8.1-2.12.1">Verify delegation chain (<a href="#delegation-verification" class="auto internal xref">Section 6.3</a>) if
<code>del.chain</code> is non-empty.<a href="#section-8.1-2.12.1" class="pilcrow"></a></p>
</li>
<li id="section-8.1-2.13">
<p id="section-8.1-2.13.1">Verify capabilities are within policy limits.<a href="#section-8.1-2.13.1" class="pilcrow"></a></p>
</li>
</ol>
</section>
</div>
<div id="execution-phase-verification">
<section id="section-8.2">
<h3 id="name-execution-phase-verificatio">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-execution-phase-verificatio" class="section-name selfRef">Execution Phase Verification</a>
</h3>
<p id="section-8.2-1">In addition to all Phase 1 verification steps, a verifier processing
a Phase 2 ACT <span class="bcp14">MUST</span>:<a href="#section-8.2-1" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="section-8.2-2">
<li id="section-8.2-2.1">
<p id="section-8.2-2.1.1">Verify <code>exec_act</code> is present and matches an <code>action</code> in <code>cap</code>.<a href="#section-8.2-2.1.1" class="pilcrow"></a></p>
</li>
<li id="section-8.2-2.2">
<p id="section-8.2-2.2.1">Verify <code>pred</code> is present and perform DAG validation
(<a href="#dag-validation" class="auto internal xref">Section 7.1</a>).<a href="#section-8.2-2.2.1" class="pilcrow"></a></p>
</li>
<li id="section-8.2-2.3">
<p id="section-8.2-2.3.1">Verify <code>exec_ts</code> is present and is greater than or equal to
<code>iat</code>. If <code>exec_ts</code> is after <code>exp</code>, implementations <span class="bcp14">SHOULD</span> log
a warning but <span class="bcp14">MUST NOT</span> reject the record solely on this basis.<a href="#section-8.2-2.3.1" class="pilcrow"></a></p>
</li>
<li id="section-8.2-2.4">
<p id="section-8.2-2.4.1">Verify <code>status</code> is present and has a valid value.<a href="#section-8.2-2.4.1" class="pilcrow"></a></p>
</li>
<li id="section-8.2-2.5">
<p id="section-8.2-2.5.1">Verify the re-signature was produced by the <code>sub</code> agent (the
executing agent), not the <code>iss</code> agent (the mandating agent).
This is verified by checking that the <code>kid</code> in the Phase 2 JOSE
header corresponds to the <code>sub</code> agent's public key.<a href="#section-8.2-2.5.1" class="pilcrow"></a></p>
</li>
<li id="section-8.2-2.6">
<p id="section-8.2-2.6.1">If <code>inp_hash</code> or <code>out_hash</code> are present, verify them against
locally available input/output data when possible.<a href="#section-8.2-2.6.1" class="pilcrow"></a></p>
</li>
</ol>
</section>
</div>
</section>
</div>
<div id="transport">
<section id="section-9">
<h2 id="name-transport">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-transport" class="section-name selfRef">Transport</a>
</h2>
<div id="http-header-transport">
<section id="section-9.1">
<h3 id="name-http-header-transport">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-http-header-transport" class="section-name selfRef">HTTP Header Transport</a>
</h3>
<p id="section-9.1-1">This specification defines two HTTP header fields for ACT transport:<a href="#section-9.1-1" class="pilcrow"></a></p>
<p id="section-9.1-2"><strong>ACT-Mandate</strong>: Carries a Phase 1 ACT issued by an upstream agent
or operator. Value is the JWS Compact Serialization of the ACT.<a href="#section-9.1-2" class="pilcrow"></a></p>
<div class="alignLeft art-text artwork" id="section-9.1-3">
<pre>
GET /api/safety-check HTTP/1.1
Host: safety-agent.example.com
ACT-Mandate: eyJhbGci...Phase1ACT...
</pre><a href="#section-9.1-3" class="pilcrow"></a>
</div>
<p id="section-9.1-4"><strong>ACT-Record</strong>: Carries a Phase 2 ACT from a predecessor agent,
serving as evidence of completed prerequisites.<a href="#section-9.1-4" class="pilcrow"></a></p>
<div class="alignLeft art-text artwork" id="section-9.1-5">
<pre>
POST /api/downstream HTTP/1.1
Host: downstream-agent.example.com
ACT-Mandate: eyJhbGci...Phase1ACT...
ACT-Record: eyJhbGci...Phase2ACT...
</pre><a href="#section-9.1-5" class="pilcrow"></a>
</div>
<p id="section-9.1-6">Multiple <code>ACT-Record</code> header lines <span class="bcp14">MAY</span> be included when a task has
multiple completed predecessors (DAG fan-in). If any single ACT-Record
fails verification, the receiver <span class="bcp14">MUST</span> reject the entire request.<a href="#section-9.1-6" class="pilcrow"></a></p>
</section>
</div>
<div id="non-http-transports">
<section id="section-9.2">
<h3 id="name-non-http-transports">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-non-http-transports" class="section-name selfRef">Non-HTTP Transports</a>
</h3>
<p id="section-9.2-1">For non-HTTP transports (MCP stdio, A2A message queues, AMQP, etc.),
ACTs <span class="bcp14">SHOULD</span> be carried as a dedicated field in the transport's
metadata envelope. The field name <span class="bcp14">SHOULD</span> be <code>act_mandate</code> for Phase 1
ACTs and <code>act_record</code> for Phase 2 ACTs. Implementations <span class="bcp14">MUST</span> use the
JWS Compact Serialization form in all transports.<a href="#section-9.2-1" class="pilcrow"></a></p>
</section>
</div>
</section>
</div>
<div id="audit-ledger">
<section id="section-10">
<h2 id="name-audit-ledger-interface">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-audit-ledger-interface" class="section-name selfRef">Audit Ledger Interface</a>
</h2>
<p id="section-10-1">Phase 2 ACTs <span class="bcp14">SHOULD</span> be submitted to an immutable audit ledger.
A ledger is <span class="bcp14">RECOMMENDED</span> for regulated environments but is not
required for basic ACT operation. This specification does not
mandate a specific storage technology.<a href="#section-10-1" class="pilcrow"></a></p>
<p id="section-10-2">When an audit ledger is deployed, the implementation <span class="bcp14">MUST</span> provide:<a href="#section-10-2" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="section-10-3">
<li id="section-10-3.1">
<p id="section-10-3.1.1"><strong>Append-only semantics</strong>: Once an ACT is recorded, it <span class="bcp14">MUST NOT</span>
be modified or deleted.<a href="#section-10-3.1.1" class="pilcrow"></a></p>
</li>
<li id="section-10-3.2">
<p id="section-10-3.2.1"><strong>Ordering</strong>: A monotonically increasing sequence number per
recorded ACT.<a href="#section-10-3.2.1" class="pilcrow"></a></p>
</li>
<li id="section-10-3.3">
<p id="section-10-3.3.1"><strong>Lookup</strong>: Efficient retrieval by <code>jti</code> value.<a href="#section-10-3.3.1" class="pilcrow"></a></p>
</li>
<li id="section-10-3.4">
<p id="section-10-3.4.1"><strong>Integrity</strong>: A cryptographic commitment scheme over recorded
ACTs (e.g., hash-chaining, Merkle tree anchoring, or SCITT
registration per <span>[<a href="#I-D.ietf-scitt-architecture" class="cite xref">I-D.ietf-scitt-architecture</a>]</span>).<a href="#section-10-3.4.1" class="pilcrow"></a></p>
</li>
</ol>
</section>
</div>
<div id="security-considerations">
<section id="section-11">
<h2 id="name-security-considerations">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
</h2>
<div id="threat-model">
<section id="section-11.1">
<h3 id="name-threat-model">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-threat-model" class="section-name selfRef">Threat Model</a>
</h3>
<p id="section-11.1-1">ACT assumes an adversarial environment where:<a href="#section-11.1-1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-11.1-2.1">
<p id="section-11.1-2.1.1">Individual agents may be compromised.<a href="#section-11.1-2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-11.1-2.2">
<p id="section-11.1-2.2.1">Network paths may be intercepted (mitigated by transport security).<a href="#section-11.1-2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-11.1-2.3">
<p id="section-11.1-2.3.1">Attackers may attempt to replay valid ACTs from prior interactions.<a href="#section-11.1-2.3.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-11.1-2.4">
<p id="section-11.1-2.4.1">Colluding agents may attempt to fabricate execution records.<a href="#section-11.1-2.4.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-11.1-2.5">
<p id="section-11.1-2.5.1">Agents may attempt privilege escalation via manipulated delegation
chains.<a href="#section-11.1-2.5.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="section-11.1-3">ACT does NOT assume:<a href="#section-11.1-3" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-11.1-4.1">
<p id="section-11.1-4.1.1">A trusted central authority (by design).<a href="#section-11.1-4.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-11.1-4.2">
<p id="section-11.1-4.2.1">Synchronized clocks beyond the stated skew tolerance.<a href="#section-11.1-4.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-11.1-4.3">
<p id="section-11.1-4.3.1">Availability of external network services during verification.<a href="#section-11.1-4.3.1" class="pilcrow"></a></p>
</li>
</ul>
</section>
</div>
<div id="self-assertion-limitation">
<section id="section-11.2">
<h3 id="name-self-assertion-limitation">
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-self-assertion-limitation" class="section-name selfRef">Self-Assertion Limitation</a>
</h3>
<p id="section-11.2-1">Phase 2 ACTs are self-asserted: an executing agent signs its own
execution record. A compromised agent with an intact private key can
produce Phase 2 ACTs claiming arbitrary inputs, outputs, and action
types, as long as the claimed <code>exec_act</code> matches an authorized
capability.<a href="#section-11.2-1" class="pilcrow"></a></p>
<p id="section-11.2-2">This is a fundamental limitation of self-sovereign attestation. It
is the same limitation affecting WIMSE ECT
<span>[<a href="#I-D.nennemann-wimse-ect" class="cite xref">I-D.nennemann-wimse-ect</a>]</span>.<a href="#section-11.2-2" class="pilcrow"></a></p>
<p id="section-11.2-3">Mitigations:<a href="#section-11.2-3" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-11.2-4.1">
<p id="section-11.2-4.1.1"><strong>Cross-agent corroboration</strong>: A receiving agent that processes
an ACT-Record as a prerequisite independently verifies that the
claimed <code>out_hash</code> matches the data it actually received.<a href="#section-11.2-4.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-11.2-4.2">
<p id="section-11.2-4.2.1"><strong>Ledger sequencing</strong>: An append-only ledger with monotonic
sequence numbers prevents retroactive insertion of fabricated
records.<a href="#section-11.2-4.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-11.2-4.3">
<p id="section-11.2-4.3.1"><strong>SCITT anchoring</strong>: For high-assurance deployments, Phase 2 ACTs
<span class="bcp14">SHOULD</span> be anchored to a SCITT Transparency Service, providing
external witness that the record was submitted at a claimed time.<a href="#section-11.2-4.3.1" class="pilcrow"></a></p>
</li>
</ul>
</section>
</div>
<div id="key-compromise">
<section id="section-11.3">
<h3 id="name-key-compromise">
<a href="#section-11.3" class="section-number selfRef">11.3. </a><a href="#name-key-compromise" class="section-name selfRef">Key Compromise</a>
</h3>
<p id="section-11.3-1">If an agent's private key is compromised, an attacker can issue
arbitrary Phase 1 mandates (impersonating the agent as an issuer)
and fabricate Phase 2 records (impersonating the agent as an
executor).<a href="#section-11.3-1" class="pilcrow"></a></p>
<p id="section-11.3-2">Key compromise response:<a href="#section-11.3-2" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="section-11.3-3">
<li id="section-11.3-3.1">
<p id="section-11.3-3.1.1">The compromised agent's identifier <span class="bcp14">MUST</span> be added to all
verifiers' deny lists.<a href="#section-11.3-3.1.1" class="pilcrow"></a></p>
</li>
<li id="section-11.3-3.2">
<p id="section-11.3-3.2.1">In Tier 2 (PKI) deployments, the certificate <span class="bcp14">MUST</span> be revoked
via CRL or OCSP.<a href="#section-11.3-3.2.1" class="pilcrow"></a></p>
</li>
<li id="section-11.3-3.3">
<p id="section-11.3-3.3.1">In Tier 3 (DID) deployments, the DID Document <span class="bcp14">MUST</span> be updated
to revoke the compromised key.<a href="#section-11.3-3.3.1" class="pilcrow"></a></p>
</li>
<li id="section-11.3-3.4">
<p id="section-11.3-3.4.1">In Tier 1 (pre-shared key) deployments, both parties <span class="bcp14">MUST</span>
perform an out-of-band key rotation.<a href="#section-11.3-3.4.1" class="pilcrow"></a></p>
</li>
</ol>
<p id="section-11.3-4">ACT chains that include records signed by a compromised key <span class="bcp14">MUST</span>
be treated as potentially tainted from the point of compromise.
Audit systems <span class="bcp14">MUST</span> flag all ACTs signed after the estimated
compromise time.<a href="#section-11.3-4" class="pilcrow"></a></p>
</section>
</div>
<div id="replay-attack-prevention">
<section id="section-11.4">
<h3 id="name-replay-attack-prevention">
<a href="#section-11.4" class="section-number selfRef">11.4. </a><a href="#name-replay-attack-prevention" class="section-name selfRef">Replay Attack Prevention</a>
</h3>
<p id="section-11.4-1"><code>jti</code> uniqueness within the applicable scope (workflow or global)
provides replay detection. Verifiers <span class="bcp14">MUST</span> reject ACTs whose <code>jti</code>
has already been seen and processed.<a href="#section-11.4-1" class="pilcrow"></a></p>
<p id="section-11.4-2"><code>exp</code> provides a time-bounded replay window. Verifiers <span class="bcp14">MUST</span> reject
expired ACTs. The combination of <code>jti</code> and <code>exp</code> means that replay
detection state only needs to be maintained for the duration of token
lifetimes.<a href="#section-11.4-2" class="pilcrow"></a></p>
</section>
</div>
<div id="equivocation">
<section id="section-11.5">
<h3 id="name-equivocation">
<a href="#section-11.5" class="section-number selfRef">11.5. </a><a href="#name-equivocation" class="section-name selfRef">Equivocation</a>
</h3>
<p id="section-11.5-1">In standalone deployment (no audit ledger, no SCITT anchoring), ACT
does NOT provide non-equivocation guarantees. A compromised agent
can maintain two valid ACT chains — presenting Phase 2 records with
different <code>out_hash</code> values to different verifiers — and both will
pass independent verification.<a href="#section-11.5-1" class="pilcrow"></a></p>
<p id="section-11.5-2"><strong>Deployments claiming DORA <span>[<a href="#DORA" class="cite xref">DORA</a>]</span> Article 10/11 compliance or EU AI
Act <span>[<a href="#EUAIA" class="cite xref">EUAIA</a>]</span> Article 12 compliance <span class="bcp14">MUST</span> use one of:</strong><a href="#section-11.5-2" class="pilcrow"></a></p>
<p id="section-11.5-3">(a) A shared append-only audit ledger visible to all relevant parties,
with cryptographic integrity (hash chaining or Merkle trees).<a href="#section-11.5-3" class="pilcrow"></a></p>
<p id="section-11.5-4">(b) SCITT anchoring <span>[<a href="#I-D.ietf-scitt-architecture" class="cite xref">I-D.ietf-scitt-architecture</a>]</span> providing external
Transparency Service receipts.<a href="#section-11.5-4" class="pilcrow"></a></p>
<p id="section-11.5-5">Standalone ACT provides tamper detection (a verifier can detect
modification of a record it has seen) but not split-view prevention
(a verifier cannot detect a different record shown to another
verifier).<a href="#section-11.5-5" class="pilcrow"></a></p>
</section>
</div>
<div id="privilege-escalation">
<section id="section-11.6">
<h3 id="name-privilege-escalation">
<a href="#section-11.6" class="section-number selfRef">11.6. </a><a href="#name-privilege-escalation" class="section-name selfRef">Privilege Escalation</a>
</h3>
<p id="section-11.6-1">Verifiers <span class="bcp14">MUST</span> check that each step in <code>del.chain</code> reduces or
maintains (never increases) the capabilities relative to the
preceding step. Implementations <span class="bcp14">MUST</span> reject ACTs where:<a href="#section-11.6-1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-11.6-2.1">
<p id="section-11.6-2.1.1"><code>del.depth</code> exceeds <code>del.max_depth</code>.<a href="#section-11.6-2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-11.6-2.2">
<p id="section-11.6-2.2.1"><code>cap</code> contains actions not present in any referenced parent ACT.<a href="#section-11.6-2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-11.6-2.3">
<p id="section-11.6-2.3.1">Constraints in <code>cap</code> are less restrictive than those in the parent.<a href="#section-11.6-2.3.1" class="pilcrow"></a></p>
</li>
</ul>
</section>
</div>
<div id="denial-of-service">
<section id="section-11.7">
<h3 id="name-denial-of-service">
<a href="#section-11.7" class="section-number selfRef">11.7. </a><a href="#name-denial-of-service" class="section-name selfRef">Denial of Service</a>
</h3>
<p id="section-11.7-1">ACT verification is more computationally expensive than standard JWT
validation due to delegation chain verification and DAG traversal.<a href="#section-11.7-1" class="pilcrow"></a></p>
<p id="section-11.7-2">Mitigations:<a href="#section-11.7-2" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-11.7-3.1">
<p id="section-11.7-3.1.1">Reject ACTs larger than 64KB before parsing.<a href="#section-11.7-3.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-11.7-3.2">
<p id="section-11.7-3.2.1">Enforce maximum <code>del.chain</code> length (<span class="bcp14">RECOMMENDED</span>: 10 entries).<a href="#section-11.7-3.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-11.7-3.3">
<p id="section-11.7-3.3.1">Enforce maximum DAG ancestor traversal depth (<span class="bcp14">RECOMMENDED</span>: 10,000
nodes, <a href="#dag-validation" class="auto internal xref">Section 7.1</a>).<a href="#section-11.7-3.3.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-11.7-3.4">
<p id="section-11.7-3.4.1">Cache verification results for recently seen <code>jti</code> values within
the token lifetime window.<a href="#section-11.7-3.4.1" class="pilcrow"></a></p>
</li>
</ul>
</section>
</div>
</section>
</div>
<div id="privacy-considerations">
<section id="section-12">
<h2 id="name-privacy-considerations">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
</h2>
<p id="section-12-1">ACT tokens and audit ledger records may contain information that
identifies agents, organizations, or individuals. Implementations
<span class="bcp14">SHOULD</span> apply data minimization principles:<a href="#section-12-1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-12-2.1">
<p id="section-12-2.1.1"><code>task.created_by</code> <span class="bcp14">SHOULD</span> use a pseudonymous identifier rather
than a personal email address or real name.<a href="#section-12-2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-12-2.2">
<p id="section-12-2.2.1"><code>task.purpose</code> <span class="bcp14">SHOULD</span> use a controlled vocabulary code rather
than free-text descriptions that may contain personal data.<a href="#section-12-2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-12-2.3">
<p id="section-12-2.3.1"><code>del.chain</code> entries reveal organizational structure. Cross-
organizational delegation chains <span class="bcp14">SHOULD</span> use Tier 3 (DID)
identifiers that do not reveal organizational affiliation.<a href="#section-12-2.3.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-12-2.4">
<p id="section-12-2.4.1"><code>inp_hash</code> and <code>out_hash</code> are hashes of data, not the data
itself, and do not constitute personal data under GDPR
Article 4(1) provided the underlying data is not trivially
reversible (e.g., hashes of very short strings).<a href="#section-12-2.4.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="section-12-3">For GDPR Article 17 (right to erasure) compliance, audit ledgers
<span class="bcp14">SHOULD</span> store only ACT tokens (which contain hashes, not raw data)
and <span class="bcp14">SHOULD</span> implement crypto-shredding for any associated encrypted
payloads.<a href="#section-12-3" class="pilcrow"></a></p>
</section>
</div>
<div id="iana-considerations">
<section id="section-13">
<h2 id="name-iana-considerations">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
</h2>
<div id="media-type-registration">
<section id="section-13.1">
<h3 id="name-media-type-registration">
<a href="#section-13.1" class="section-number selfRef">13.1. </a><a href="#name-media-type-registration" class="section-name selfRef">Media Type Registration</a>
</h3>
<p id="section-13.1-1">This document requests registration of the following media type:<a href="#section-13.1-1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-13.1-2.1">
<p id="section-13.1-2.1.1">Type name: application<a href="#section-13.1-2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-13.1-2.2">
<p id="section-13.1-2.2.1">Subtype name: act+jwt<a href="#section-13.1-2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-13.1-2.3">
<p id="section-13.1-2.3.1">Required parameters: none<a href="#section-13.1-2.3.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-13.1-2.4">
<p id="section-13.1-2.4.1">Encoding considerations: binary (base64url-encoded JWT)<a href="#section-13.1-2.4.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-13.1-2.5">
<p id="section-13.1-2.5.1">Security considerations: See <a href="#security-considerations" class="auto internal xref">Section 11</a>.<a href="#section-13.1-2.5.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-13.1-2.6">
<p id="section-13.1-2.6.1">Interoperability considerations: See <a href="#auth-verification" class="auto internal xref">Section 8.1</a>.<a href="#section-13.1-2.6.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-13.1-2.7">
<p id="section-13.1-2.7.1">Specification: This document.<a href="#section-13.1-2.7.1" class="pilcrow"></a></p>
</li>
</ul>
</section>
</div>
<div id="http-header-field-registration">
<section id="section-13.2">
<h3 id="name-http-header-field-registrat">
<a href="#section-13.2" class="section-number selfRef">13.2. </a><a href="#name-http-header-field-registrat" class="section-name selfRef">HTTP Header Field Registration</a>
</h3>
<p id="section-13.2-1">This document requests registration of the following HTTP header
fields in the "Hypertext Transfer Protocol (HTTP) Field Name
Registry":<a href="#section-13.2-1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-13.2-2.1">
<p id="section-13.2-2.1.1">Header field name: ACT-Mandate<a href="#section-13.2-2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-13.2-2.2">
<p id="section-13.2-2.2.1">Applicable protocol: HTTP<a href="#section-13.2-2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-13.2-2.3">
<p id="section-13.2-2.3.1">Status: permanent<a href="#section-13.2-2.3.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-13.2-2.4">
<p id="section-13.2-2.4.1">Specification: This document, <a href="#http-header-transport" class="auto internal xref">Section 9.1</a>.<a href="#section-13.2-2.4.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-13.2-2.5">
<p id="section-13.2-2.5.1">Header field name: ACT-Record<a href="#section-13.2-2.5.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-13.2-2.6">
<p id="section-13.2-2.6.1">Applicable protocol: HTTP<a href="#section-13.2-2.6.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-13.2-2.7">
<p id="section-13.2-2.7.1">Status: permanent<a href="#section-13.2-2.7.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-13.2-2.8">
<p id="section-13.2-2.8.1">Specification: This document, <a href="#http-header-transport" class="auto internal xref">Section 9.1</a>.<a href="#section-13.2-2.8.1" class="pilcrow"></a></p>
</li>
</ul>
</section>
</div>
<div id="jwt-claims-registration">
<section id="section-13.3">
<h3 id="name-jwt-claims-registration">
<a href="#section-13.3" class="section-number selfRef">13.3. </a><a href="#name-jwt-claims-registration" class="section-name selfRef">JWT Claims Registration</a>
</h3>
<p id="section-13.3-1">This document requests registration of the following claims in the
IANA "JSON Web Token Claims" registry:<a href="#section-13.3-1" class="pilcrow"></a></p>
<table class="center" id="table-1">
<caption><a href="#table-1" class="selfRef">Table 1</a></caption>
<thead>
<tr>
<th class="text-left" rowspan="1" colspan="1">Claim Name</th>
<th class="text-left" rowspan="1" colspan="1">Description</th>
<th class="text-left" rowspan="1" colspan="1">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td class="text-left" rowspan="1" colspan="1">wid</td>
<td class="text-left" rowspan="1" colspan="1">Workflow identifier</td>
<td class="text-left" rowspan="1" colspan="1">This document</td>
</tr>
<tr>
<td class="text-left" rowspan="1" colspan="1">task</td>
<td class="text-left" rowspan="1" colspan="1">Task authorization context</td>
<td class="text-left" rowspan="1" colspan="1">This document</td>
</tr>
<tr>
<td class="text-left" rowspan="1" colspan="1">cap</td>
<td class="text-left" rowspan="1" colspan="1">Capabilities with constraints</td>
<td class="text-left" rowspan="1" colspan="1">This document</td>
</tr>
<tr>
<td class="text-left" rowspan="1" colspan="1">oversight</td>
<td class="text-left" rowspan="1" colspan="1">Human oversight requirements</td>
<td class="text-left" rowspan="1" colspan="1">This document</td>
</tr>
<tr>
<td class="text-left" rowspan="1" colspan="1">del</td>
<td class="text-left" rowspan="1" colspan="1">Delegation provenance chain</td>
<td class="text-left" rowspan="1" colspan="1">This document</td>
</tr>
<tr>
<td class="text-left" rowspan="1" colspan="1">exec_act</td>
<td class="text-left" rowspan="1" colspan="1">Executed action identifier</td>
<td class="text-left" rowspan="1" colspan="1">This document</td>
</tr>
<tr>
<td class="text-left" rowspan="1" colspan="1">pred</td>
<td class="text-left" rowspan="1" colspan="1">Predecessor task identifiers (DAG)</td>
<td class="text-left" rowspan="1" colspan="1">This document</td>
</tr>
<tr>
<td class="text-left" rowspan="1" colspan="1">inp_hash</td>
<td class="text-left" rowspan="1" colspan="1">SHA-256 hash of task input</td>
<td class="text-left" rowspan="1" colspan="1">This document</td>
</tr>
<tr>
<td class="text-left" rowspan="1" colspan="1">out_hash</td>
<td class="text-left" rowspan="1" colspan="1">SHA-256 hash of task output</td>
<td class="text-left" rowspan="1" colspan="1">This document</td>
</tr>
<tr>
<td class="text-left" rowspan="1" colspan="1">exec_ts</td>
<td class="text-left" rowspan="1" colspan="1">Actual execution timestamp</td>
<td class="text-left" rowspan="1" colspan="1">This document</td>
</tr>
<tr>
<td class="text-left" rowspan="1" colspan="1">status</td>
<td class="text-left" rowspan="1" colspan="1">Execution status</td>
<td class="text-left" rowspan="1" colspan="1">This document</td>
</tr>
<tr>
<td class="text-left" rowspan="1" colspan="1">err</td>
<td class="text-left" rowspan="1" colspan="1">Execution error context</td>
<td class="text-left" rowspan="1" colspan="1">This document</td>
</tr>
</tbody>
</table>
</section>
</div>
</section>
</div>
<div id="sec-combined-references">
<section id="section-14">
<h2 id="name-references">
<a href="#section-14" class="section-number selfRef">14. </a><a href="#name-references" class="section-name selfRef">References</a>
</h2>
<div id="sec-normative-references">
<section id="section-14.1">
<h3 id="name-normative-references">
<a href="#section-14.1" class="section-number selfRef">14.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
</h3>
<dl class="references">
<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>&lt;<a href="https://www.rfc-editor.org/rfc/rfc2119">https://www.rfc-editor.org/rfc/rfc2119</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/rfc/rfc7515">https://www.rfc-editor.org/rfc/rfc7515</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/rfc/rfc7517">https://www.rfc-editor.org/rfc/rfc7517</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/rfc/rfc7518">https://www.rfc-editor.org/rfc/rfc7518</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/rfc/rfc7519">https://www.rfc-editor.org/rfc/rfc7519</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8037">[RFC8037]</dt>
<dd>
<span class="refAuthor">Liusvaara, I.</span>, <span class="refTitle">"CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)"</span>, <span class="seriesInfo">RFC 8037</span>, <span class="seriesInfo">DOI 10.17487/RFC8037</span>, <time datetime="2017-01" class="refDate">January 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc8037">https://www.rfc-editor.org/rfc/rfc8037</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/rfc/rfc8174">https://www.rfc-editor.org/rfc/rfc8174</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9110">https://www.rfc-editor.org/rfc/rfc9110</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9562">https://www.rfc-editor.org/rfc/rfc9562</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</div>
<div id="sec-informative-references">
<section id="section-14.2">
<h3 id="name-informative-references">
<a href="#section-14.2" class="section-number selfRef">14.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
</h3>
<dl class="references">
<dt id="A2A-SPEC">[A2A-SPEC]</dt>
<dd>
<span class="refAuthor">Google</span>, <span class="refTitle">"Agent2Agent (A2A) Protocol"</span>, <span>&lt;<a href="https://github.com/a2aproject/A2A">https://github.com/a2aproject/A2A</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="AgenticJWT">[AgenticJWT]</dt>
<dd>
<span class="refTitle">"Agentic JWT: A JSON Web Token Profile for Delegated Agent Authorization"</span>, <time datetime="2025" class="refDate">2025</time>, <span>&lt;<a href="https://arxiv.org/abs/2509.13597">https://arxiv.org/abs/2509.13597</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="AIP-IBCT">[AIP-IBCT]</dt>
<dd>
<span class="refAuthor">S., P.</span>, <span class="refTitle">"AIP: Agent Interaction Protocol with Interaction-Bound Context Tokens"</span>, <time datetime="2026-03" class="refDate">March 2026</time>, <span>&lt;<a href="https://arxiv.org/abs/2603.24775">https://arxiv.org/abs/2603.24775</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="AUTOGEN">[AUTOGEN]</dt>
<dd>
<span class="refAuthor">Microsoft</span>, <span class="refTitle">"AutoGen Documentation"</span>, <span>&lt;<a href="https://microsoft.github.io/autogen/">https://microsoft.github.io/autogen/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CREWAI">[CREWAI]</dt>
<dd>
<span class="refAuthor">CrewAI</span>, <span class="refTitle">"CrewAI Documentation"</span>, <span>&lt;<a href="https://docs.crewai.com/">https://docs.crewai.com/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="DID-KEY">[DID-KEY]</dt>
<dd>
<span class="refAuthor">D., L.</span>, <span class="refTitle">"The did:key Method v0.7"</span>, <time datetime="2021" class="refDate">2021</time>, <span>&lt;<a href="https://w3c-ccg.github.io/did-method-key/">https://w3c-ccg.github.io/did-method-key/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="DID-WEB">[DID-WEB]</dt>
<dd>
<span class="refAuthor">O., S.</span>, <span class="refTitle">"did:web Method Specification"</span>, <time datetime="2022" class="refDate">2022</time>, <span>&lt;<a href="https://w3c-ccg.github.io/did-method-web/">https://w3c-ccg.github.io/did-method-web/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="DORA">[DORA]</dt>
<dd>
<span class="refAuthor">European Parliament</span>, <span class="refTitle">"Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554"</span>, <time datetime="2022" class="refDate">2022</time>, <span>&lt;<a href="https://eur-lex.europa.eu/eli/reg/2022/2554/oj">https://eur-lex.europa.eu/eli/reg/2022/2554/oj</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="EUAIA">[EUAIA]</dt>
<dd>
<span class="refAuthor">European Parliament</span>, <span class="refTitle">"EU Artificial Intelligence Act, Regulation (EU) 2024/1689"</span>, <time datetime="2024" class="refDate">2024</time>, <span>&lt;<a href="https://eur-lex.europa.eu/eli/reg/2024/1689/oj">https://eur-lex.europa.eu/eli/reg/2024/1689/oj</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.aap-oauth-profile">[I-D.aap-oauth-profile]</dt>
<dd>
<span class="refAuthor">A., C.</span>, <span class="refTitle">"Agent Authorization Profile (AAP) for OAuth 2.0"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-aap-oauth-profile-01</span>, <time datetime="2026-02" class="refDate">February 2026</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/draft-aap-oauth-profile/">https://datatracker.ietf.org/doc/draft-aap-oauth-profile/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.emirdag-scitt-ai-agent-execution">[I-D.emirdag-scitt-ai-agent-execution]</dt>
<dd>
<span class="refAuthor">Emirdag</span>, <span class="refTitle">"A SCITT Profile for AI Agent Execution Records"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-emirdag-scitt-ai-agent-execution-00</span>, <time datetime="2026-04" class="refDate">April 2026</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/draft-emirdag-scitt-ai-agent-execution/">https://datatracker.ietf.org/doc/draft-emirdag-scitt-ai-agent-execution/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.helixar-hdp-agentic-delegation">[I-D.helixar-hdp-agentic-delegation]</dt>
<dd>
<span class="refAuthor">Helixar</span>, <span class="refTitle">"Helixar Delegation Protocol (HDP) for Agentic Delegation"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-helixar-hdp-agentic-delegation-00</span>, <time datetime="2026" class="refDate">2026</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/draft-helixar-hdp-agentic-delegation/">https://datatracker.ietf.org/doc/draft-helixar-hdp-agentic-delegation/</a>&gt;</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>&lt;<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>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.nennemann-wimse-ect">[I-D.nennemann-wimse-ect]</dt>
<dd>
<span class="refAuthor">Nennemann, C.</span>, <span class="refTitle">"Execution Context Tokens for Distributed Agentic Workflows"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-nennemann-wimse-ect-02</span>, <time datetime="2026" class="refDate">2026</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/">https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/</a>&gt;</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">G., F.</span>, <span class="refTitle">"Transaction Tokens for Agentic AI Systems"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-oauth-transaction-tokens-for-agents-06</span>, <time datetime="2026" class="refDate">2026</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/draft-oauth-transaction-tokens-for-agents/">https://datatracker.ietf.org/doc/draft-oauth-transaction-tokens-for-agents/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IEC62304">[IEC62304]</dt>
<dd>
<span class="refAuthor">IEC</span>, <span class="refTitle">"Medical device software — Software life cycle processes, IEC 62304:2006+AMD1:2015"</span>, <time datetime="2015" class="refDate">2015</time>, <span>&lt;<a href="https://www.iec.ch/">https://www.iec.ch/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="LANGGRAPH">[LANGGRAPH]</dt>
<dd>
<span class="refAuthor">LangChain</span>, <span class="refTitle">"LangGraph Documentation"</span>, <span>&lt;<a href="https://langchain-ai.github.io/langgraph/">https://langchain-ai.github.io/langgraph/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="MCP-SPEC">[MCP-SPEC]</dt>
<dd>
<span class="refTitle">"Model Context Protocol Specification"</span>, <time datetime="2025-11-25" class="refDate">25 November 2025</time>, <span>&lt;<a href="https://modelcontextprotocol.io/specification/2025-11-25">https://modelcontextprotocol.io/specification/2025-11-25</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="OPENAI-AGENTS-SDK">[OPENAI-AGENTS-SDK]</dt>
<dd>
<span class="refAuthor">OpenAI</span>, <span class="refTitle">"OpenAI Agents SDK"</span>, <span>&lt;<a href="https://openai.github.io/openai-agents-python/">https://openai.github.io/openai-agents-python/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7009">[RFC7009]</dt>
<dd>
<span class="refAuthor">Lodderstedt, T., Ed.</span>, <span class="refAuthor">Dronia, S.</span>, and <span class="refAuthor">M. Scurtescu</span>, <span class="refTitle">"OAuth 2.0 Token Revocation"</span>, <span class="seriesInfo">RFC 7009</span>, <span class="seriesInfo">DOI 10.17487/RFC7009</span>, <time datetime="2013-08" class="refDate">August 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc7009">https://www.rfc-editor.org/rfc/rfc7009</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/rfc/rfc8693">https://www.rfc-editor.org/rfc/rfc8693</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SentinelAgent">[SentinelAgent]</dt>
<dd>
<span class="refAuthor">Patil</span>, <span class="refTitle">"SentinelAgent: A Formal Delegation Chain Calculus for Verifiable Agent Authorization"</span>, <time datetime="2026-04" class="refDate">April 2026</time>, <span>&lt;<a href="https://arxiv.org/abs/2604.02767">https://arxiv.org/abs/2604.02767</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="W3C-DID">[W3C-DID]</dt>
<dd>
<span class="refAuthor">M., S.</span>, <span class="refTitle">"Decentralized Identifiers (DIDs) v1.0"</span>, <time datetime="2022-07" class="refDate">July 2022</time>, <span>&lt;<a href="https://www.w3.org/TR/did-core/">https://www.w3.org/TR/did-core/</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="appendix-a-complete-json-schema">
<section id="appendix-A">
<h2 id="name-appendix-a-complete-json-sc">
<a href="#name-appendix-a-complete-json-sc" class="section-name selfRef">Appendix A: Complete JSON Schema</a>
</h2>
<p id="appendix-A-1">The normative JSON Schema for ACT Phase 1 and Phase 2 tokens is
available at [TODO: reference implementation repository].<a href="#appendix-A-1" class="pilcrow"></a></p>
</section>
</div>
<div id="appendix-b-test-vectors">
<section id="appendix-B">
<h2 id="name-appendix-b-test-vectors">
<a href="#name-appendix-b-test-vectors" class="section-name selfRef">Appendix B: Test Vectors</a>
</h2>
<div id="b1-valid-phase-1-act-root-mandate-tier-1-pre-shared-key">
<section id="appendix-B.1">
<h3 id="name-b1-valid-phase-1-act-root-m">
<a href="#name-b1-valid-phase-1-act-root-m" class="section-name selfRef">B.1. Valid Phase 1 ACT — Root Mandate (Tier 1, Pre-Shared Key)</a>
</h3>
<div class="alignLeft art-text artwork" id="appendix-B.1-1">
<pre>
[TODO: include encoded test vector with signing key, payload,
and expected JWS Compact Serialization]
</pre><a href="#appendix-B.1-1" class="pilcrow"></a>
</div>
</section>
</div>
<div id="b2-valid-phase-2-act-completed-execution">
<section id="appendix-B.2">
<h3 id="name-b2-valid-phase-2-act-comple">
<a href="#name-b2-valid-phase-2-act-comple" class="section-name selfRef">B.2. Valid Phase 2 ACT — Completed Execution</a>
</h3>
<div class="alignLeft art-text artwork" id="appendix-B.2-1">
<pre>
[TODO: include encoded test vector demonstrating Phase 1 -&gt; Phase 2
transition with re-signature by target agent]
</pre><a href="#appendix-B.2-1" class="pilcrow"></a>
</div>
</section>
</div>
<div id="b3-valid-phase-2-act-fan-in-multiple-parents">
<section id="appendix-B.3">
<h3 id="name-b3-valid-phase-2-act-fan-in">
<a href="#name-b3-valid-phase-2-act-fan-in" class="section-name selfRef">B.3. Valid Phase 2 ACT — Fan-in (Multiple Parents)</a>
</h3>
<div class="alignLeft art-text artwork" id="appendix-B.3-1">
<pre>
[TODO: demonstrate pred with two predecessor jti values from parallel
workflow branches]
</pre><a href="#appendix-B.3-1" class="pilcrow"></a>
</div>
</section>
</div>
<div id="b4-invalid-act-delegation-depth-exceeded">
<section id="appendix-B.4">
<h3 id="name-b4-invalid-act-delegation-d">
<a href="#name-b4-invalid-act-delegation-d" class="section-name selfRef">B.4. Invalid ACT — Delegation Depth Exceeded</a>
</h3>
<div class="alignLeft art-text artwork" id="appendix-B.4-1">
<pre>
[TODO: demonstrate del.depth &gt; del.max_depth rejection]
</pre><a href="#appendix-B.4-1" class="pilcrow"></a>
</div>
</section>
</div>
<div id="b5-invalid-act-capability-escalation">
<section id="appendix-B.5">
<h3 id="name-b5-invalid-act-capability-e">
<a href="#name-b5-invalid-act-capability-e" class="section-name selfRef">B.5. Invalid ACT — Capability Escalation</a>
</h3>
<div class="alignLeft art-text artwork" id="appendix-B.5-1">
<pre>
[TODO: demonstrate rejection when delegated cap contains action
not present in parent ACT]
</pre><a href="#appendix-B.5-1" class="pilcrow"></a>
</div>
</section>
</div>
<div id="b6-invalid-act-execact-mismatch">
<section id="appendix-B.6">
<h3 id="name-b6-invalid-act-exec_act-mis">
<a href="#name-b6-invalid-act-exec_act-mis" class="section-name selfRef">B.6. Invalid ACT — exec_act Mismatch</a>
</h3>
<div class="alignLeft art-text artwork" id="appendix-B.6-1">
<pre>
[TODO: demonstrate rejection when exec_act does not match any
cap.action in the Phase 1 claims]
</pre><a href="#appendix-B.6-1" class="pilcrow"></a>
</div>
</section>
</div>
</section>
</div>
<div id="appendix-c-deployment-scenarios">
<section id="appendix-C">
<h2 id="name-appendix-c-deployment-scena">
<a href="#name-appendix-c-deployment-scena" class="section-name selfRef">Appendix C: Deployment Scenarios</a>
</h2>
<div id="c1-minimal-deployment-zero-infrastructure">
<section id="appendix-C.1">
<h3 id="name-c1-minimal-deployment-zero-">
<a href="#name-c1-minimal-deployment-zero-" class="section-name selfRef">C.1. Minimal Deployment (Zero Infrastructure)</a>
</h3>
<p id="appendix-C.1-1">Two organizations exchange pre-shared public keys via secure email.
Each agent signs Phase 1 mandates and Phase 2 records with its
Ed25519 key. No ledger, no external services. Suitable for
development and low-risk workflows.<a href="#appendix-C.1-1" class="pilcrow"></a></p>
<p id="appendix-C.1-2">Limitation: No non-equivocation (<a href="#equivocation" class="auto internal xref">Section 11.5</a>).<a href="#appendix-C.1-2" class="pilcrow"></a></p>
</section>
</div>
<div id="c2-regulated-deployment-with-hash-chained-ledger">
<section id="appendix-C.2">
<h3 id="name-c2-regulated-deployment-wit">
<a href="#name-c2-regulated-deployment-wit" class="section-name selfRef">C.2. Regulated Deployment with Hash-Chained Ledger</a>
</h3>
<p id="appendix-C.2-1">Phase 2 ACTs are submitted to a shared append-only ledger with
hash-chaining. Each recorded ACT extends a cryptographic chain,
providing tamper evidence for each ACT and the chain as a whole.
The ledger is shared between all regulated parties participating
in the workflow. Suitable for DORA compliance.<a href="#appendix-C.2-1" class="pilcrow"></a></p>
</section>
</div>
<div id="c3-high-assurance-cross-organizational-deployment">
<section id="appendix-C.3">
<h3 id="name-c3-high-assurance-cross-org">
<a href="#name-c3-high-assurance-cross-org" class="section-name selfRef">C.3. High-Assurance Cross-Organizational Deployment</a>
</h3>
<p id="appendix-C.3-1">Phase 2 ACTs are anchored to a SCITT Transparency Service. SCITT
receipts are attached to the audit record as non-equivocation proofs.
DID-based agent identities (Tier 3) enable self-sovereign key
management without shared CA infrastructure.<a href="#appendix-C.3-1" class="pilcrow"></a></p>
</section>
</div>
<div id="c4-wimse-environment-integration">
<section id="appendix-C.4">
<h3 id="name-c4-wimse-environment-integr">
<a href="#name-c4-wimse-environment-integr" class="section-name selfRef">C.4. WIMSE Environment Integration</a>
</h3>
<p id="appendix-C.4-1">In environments where WIMSE is already deployed, ACT-Mandate and
ACT-Record headers are carried alongside the WIMSE Workload-Identity
header. The ECT and ACT serve different purposes: the ECT records
workload-level execution in WIMSE terms; the ACT records the
authorization provenance and capability constraints that governed
the action.<a href="#appendix-C.4-1" class="pilcrow"></a></p>
</section>
</div>
</section>
</div>
<div id="acknowledgments">
<section id="appendix-D">
<h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
</h2>
<p id="appendix-D-1">The author thanks the IETF WIMSE, OAuth, and SCITT working groups
for foundational work on workload identity, delegated authorization,
and transparent supply chain records that informs this specification.<a href="#appendix-D-1" class="pilcrow"></a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-E">
<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>
Reference in New Issue View Git Blame Copy Permalink