c/ietf-wimse-ect
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Implement peer review feedback for draft-nennemann-wimse-ect-00

Browse Source 
Address 11 items from peer review:
- Fix area designation from Security to ART (WIMSE is in ART area)
- Switch inp_hash/out_hash to fixed SHA-256 without algorithm prefix,
  matching DPoP (RFC 9449) and WIMSE WPT tth claim patterns
- Add partial DAG verification guidance for unavailable parents
- Add DAG integrity attacks subsection (false parents, pruning, shadow DAGs)
- Add privilege escalation subsection (ECTs are not authorization)
- Add revocation propagation semantics through the DAG
- Add W3C PROV Data Model to Related Work
- Strengthen Txn-Token differentiation with fan-in/convergence bullet
- Add explicit token binding paragraph to replay prevention
- Switch verification step 3 to algorithm allowlist model
- Add par/ext claim naming justification notes

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Christian Nennemann
2026-02-25 21:59:16 +01:00
parent 1385ec8af1
commit ff795c72e6
4 changed files with 1194 additions and 661 deletions
Download Patch File Download Diff File Expand all files Collapse all files

238
draft-nennemann-wimse-ect-00.html
View File

@@ -1402,6 +1402,9 @@ existing WIMSE headers.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
<p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="auto internal xref">6.2</a>.  <a href="#name-validation-rules" class="internal xref">Validation Rules</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3">
<p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="auto internal xref">6.3</a>.  <a href="#name-handling-unavailable-parent" class="internal xref">Handling Unavailable Parent ECTs</a></p>
</li>
</ul>
</li>
@@ -1444,13 +1447,19 @@ existing WIMSE headers.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-toc.1-1.9.2.8.1"><a href="#section-9.8" class="auto internal xref">9.8</a>.  <a href="#name-collusion-and-false-claims" class="internal xref">Collusion and False Claims</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.9">
<p id="section-toc.1-1.9.2.9.1"><a href="#section-9.9" class="auto internal xref">9.9</a>.  <a href="#name-denial-of-service" class="internal xref">Denial of Service</a></p>
<p id="section-toc.1-1.9.2.9.1"><a href="#section-9.9" class="auto internal xref">9.9</a>.  <a href="#name-dag-integrity-attacks" class="internal xref">DAG Integrity Attacks</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.10">
<p id="section-toc.1-1.9.2.10.1"><a href="#section-9.10" class="auto internal xref">9.10</a>. <a href="#name-timestamp-accuracy" class="internal xref">Timestamp Accuracy</a></p>
<p id="section-toc.1-1.9.2.10.1"><a href="#section-9.10" class="auto internal xref">9.10</a>. <a href="#name-privilege-escalation-via-ec" class="internal xref">Privilege Escalation via ECTs</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.11">
<p id="section-toc.1-1.9.2.11.1"><a href="#section-9.11" class="auto internal xref">9.11</a>. <a href="#name-ect-size-constraints" class="internal xref">ECT Size Constraints</a></p>
<p id="section-toc.1-1.9.2.11.1"><a href="#section-9.11" class="auto internal xref">9.11</a>. <a href="#name-denial-of-service" class="internal xref">Denial of Service</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.12">
<p id="section-toc.1-1.9.2.12.1"><a href="#section-9.12" class="auto internal xref">9.12</a>. <a href="#name-timestamp-accuracy" class="internal xref">Timestamp Accuracy</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.13">
<p id="section-toc.1-1.9.2.13.1"><a href="#section-9.13" class="auto internal xref">9.13</a>. <a href="#name-ect-size-constraints" class="internal xref">ECT Size Constraints</a></p>
</li>
</ul>
</li>
@@ -1517,7 +1526,10 @@ existing WIMSE headers.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-toc.1-1.14.2.4.1"><a href="#appendix-B.4" class="auto internal xref"></a><a href="#name-distributed-tracing-opentel" class="internal xref">Distributed Tracing (OpenTelemetry)</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14.2.5">
<p id="section-toc.1-1.14.2.5.1"><a href="#appendix-B.5" class="auto internal xref"></a><a href="#name-scitt-supply-chain-integrit" class="internal xref">SCITT (Supply Chain Integrity, Transparency, and Trust)</a></p>
<p id="section-toc.1-1.14.2.5.1"><a href="#appendix-B.5" class="auto internal xref"></a><a href="#name-w3c-provenance-data-model-p" class="internal xref">W3C Provenance Data Model (PROV)</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14.2.6">
<p id="section-toc.1-1.14.2.6.1"><a href="#appendix-B.6" class="auto internal xref"></a><a href="#name-scitt-supply-chain-integrit" class="internal xref">SCITT (Supply Chain Integrity, Transparency, and Trust)</a></p>
</li>
</ul>
</li>
@@ -2036,7 +2048,9 @@ a root task with no dependencies. A workflow <span class="bcp14">MAY</span> con
multiple root tasks. Parent ECTs may have passed their own
"exp" time; ECT expiration applies to the verification window
of the ECT itself, not to its validity as a parent reference
in the ECT store.<a href="#section-4.2.2-2.6.1" class="pilcrow"></a></p>
in the ECT store. Note: "par" is not a registered JWT claim
and does not conflict with OAuth Pushed Authorization Requests
(RFC 9126), which defines an endpoint, not a token claim.<a href="#section-4.2.2-2.6.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
</dl>
@@ -2052,22 +2066,19 @@ inputs and outputs without revealing the data itself:<a href="#section-4.2.3-1"
<span class="break"></span><dl class="dlParallel" id="section-4.2.3-2">
<dt id="section-4.2.3-2.1">inp_hash:</dt>
<dd style="margin-left: 1.5em" id="section-4.2.3-2.2">
<p id="section-4.2.3-2.2.1"><span class="bcp14">OPTIONAL</span>. String. A cryptographic hash of the input data,
formatted as "hash-algorithm:base64url-encoded-hash" (e.g.,
"sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The
hash algorithm identifier <span class="bcp14">MUST</span> be a lowercase value from the
IANA Named Information Hash Algorithm Registry (e.g., "sha-256",
"sha-384", "sha-512"). Implementations <span class="bcp14">MUST</span> support "sha-256"
and <span class="bcp14">SHOULD</span> use "sha-256" unless a stronger algorithm is
required. Implementations <span class="bcp14">MUST NOT</span> accept hash algorithms
weaker than SHA-256 (e.g., MD5, SHA-1). The hash <span class="bcp14">MUST</span> be
computed over the raw octets of the input data.<a href="#section-4.2.3-2.2.1" class="pilcrow"></a></p>
<p id="section-4.2.3-2.2.1"><span class="bcp14">OPTIONAL</span>. String. The base64url encoding (without padding) of
the SHA-256 hash of the input data, computed over the raw octets
of the input. This follows the same fixed-algorithm pattern
used by the DPoP "ath" claim <span>[<a href="#RFC9449" class="cite xref">RFC9449</a>]</span> and the WIMSE WPT
"tth" claim <span>[<a href="#I-D.ietf-wimse-s2s-protocol" class="cite xref">I-D.ietf-wimse-s2s-protocol</a>]</span>: SHA-256 is the
mandatory algorithm with no algorithm prefix in the value.<a href="#section-4.2.3-2.2.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
<dt id="section-4.2.3-2.3">out_hash:</dt>
<dd style="margin-left: 1.5em" id="section-4.2.3-2.4">
<p id="section-4.2.3-2.4.1"><span class="bcp14">OPTIONAL</span>. String. A cryptographic hash of the output data,
using the same format and algorithm requirements as "inp_hash".<a href="#section-4.2.3-2.4.1" class="pilcrow"></a></p>
<p id="section-4.2.3-2.4.1"><span class="bcp14">OPTIONAL</span>. String. The base64url encoding (without padding) of
the SHA-256 hash of the output data, using the same format as
"inp_hash".<a href="#section-4.2.3-2.4.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
</dl>
@@ -2081,9 +2092,12 @@ using the same format and algorithm requirements as "inp_hash".<a href="#section
<span class="break"></span><dl class="dlParallel" id="section-4.2.4-1">
<dt id="section-4.2.4-1.1">ext:</dt>
<dd style="margin-left: 1.5em" id="section-4.2.4-1.2">
<p id="section-4.2.4-1.2.1"><span class="bcp14">OPTIONAL</span>. Object. An extension object for domain-specific
claims not defined by this specification. Implementations
that do not understand extension claims <span class="bcp14">MUST</span> ignore them.<a href="#section-4.2.4-1.2.1" class="pilcrow"></a></p>
<p id="section-4.2.4-1.2.1"><span class="bcp14">OPTIONAL</span>. Object. A general-purpose extension object for
domain-specific claims not defined by this specification. The
short name "ext" follows the JWT convention of concise claim
names and is chosen over alternatives like "extensions" for
compactness. Implementations that do not understand extension
claims <span class="bcp14">MUST</span> ignore them.<a href="#section-4.2.4-1.2.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
</dl>
@@ -2123,8 +2137,12 @@ future documents.<a href="#section-4.2.4-3" class="pilcrow">¶</a></p>
"exec_act": "recommend_treatment",
"par": [],
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
"inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"ext": {
"com.example.trace_id": "abc123"
}
}
</pre>
</div>
@@ -2251,6 +2269,35 @@ implementations <span class="bcp14">SHOULD</span> enforce a maximum ancestor tra
detection completes, the ECT <span class="bcp14">SHOULD</span> be rejected.<a href="#section-6.2-3" class="pilcrow"></a></p>
</section>
</div>
<div id="handling-unavailable-parent-ects">
<section id="section-6.3">
<h3 id="name-handling-unavailable-parent">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-handling-unavailable-parent" class="section-name selfRef">Handling Unavailable Parent ECTs</a>
</h3>
<p id="section-6.3-1">In distributed deployments, a parent ECT referenced in the "par"
array may not yet be available in the local ECT store at the time
of validation — for example, due to replication lag in a
distributed ledger or out-of-order message delivery.<a href="#section-6.3-1" class="pilcrow"></a></p>
<p id="section-6.3-2">Implementations <span class="bcp14">MUST</span> distinguish between two cases:<a href="#section-6.3-2" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="section-6.3-3">
<li id="section-6.3-3.1">
<p id="section-6.3-3.1.1">Parent not found and definitively absent: The parent "jti"
does not exist in any accessible ECT store. The ECT <span class="bcp14">MUST</span> be
rejected.<a href="#section-6.3-3.1.1" class="pilcrow"></a></p>
</li>
<li id="section-6.3-3.2">
<p id="section-6.3-3.2.1">Parent not yet available: The parent "jti" is not present
locally but may arrive due to known replication delays.
Implementations <span class="bcp14">MAY</span> defer validation for a bounded period
(<span class="bcp14">RECOMMENDED</span>: no more than 60 seconds).<a href="#section-6.3-3.2.1" class="pilcrow"></a></p>
</li>
</ol>
<p id="section-6.3-4">Deferred ECTs <span class="bcp14">MUST NOT</span> be treated as verified until all parent
references are resolved. If any parent reference remains
unresolved after the deferral period or after the ECT's own "exp"
time (whichever comes first), the ECT <span class="bcp14">MUST</span> be rejected.<a href="#section-6.3-4" class="pilcrow"></a></p>
</section>
</div>
</section>
</div>
<div id="verification">
@@ -2274,8 +2321,12 @@ payload, and signature components per <span>[<a href="#RFC7515" class="cite xref
<p id="section-7.1-2.2.1">Verify that the "typ" header parameter is "wimse-exec+jwt".<a href="#section-7.1-2.2.1" class="pilcrow"></a></p>
</li>
<li id="section-7.1-2.3">
<p id="section-7.1-2.3.1">Verify that the "alg" header parameter is not "none" and is
not a symmetric algorithm.<a href="#section-7.1-2.3.1" class="pilcrow"></a></p>
<p id="section-7.1-2.3.1">Verify that the "alg" header parameter appears in the
verifier's configured allowlist of accepted signing algorithms.
The allowlist <span class="bcp14">MUST NOT</span> include "none" or any symmetric
algorithm (e.g., HS256, HS384, HS512). Implementations <span class="bcp14">MUST</span>
include ES256 in the allowlist; additional asymmetric algorithms
<span class="bcp14">MAY</span> be included per deployment policy.<a href="#section-7.1-2.3.1" class="pilcrow"></a></p>
</li>
<li id="section-7.1-2.4">
<p id="section-7.1-2.4.1">Verify the "kid" header parameter references a known, valid
@@ -2500,6 +2551,11 @@ with the same action can be flagged as a potential replay.<a href="#section-9.5-
<p id="section-9.5-3">Implementations <span class="bcp14">MUST</span> maintain a cache of recently-seen "jti"
values to detect replayed ECTs within the expiration window.
An ECT with a duplicate "jti" value <span class="bcp14">MUST</span> be rejected.<a href="#section-9.5-3" class="pilcrow"></a></p>
<p id="section-9.5-4">Additionally, each ECT is cryptographically bound to the issuing
agent via the JOSE "kid" parameter, which references the agent's
WIT public key. Verifiers <span class="bcp14">MUST</span> confirm that the "kid" resolves
to the "iss" agent's key (step 8 in <a href="#verification" class="auto internal xref">Section 7</a>), preventing
one agent from replaying another agent's ECT as its own.<a href="#section-9.5-4" class="pilcrow"></a></p>
</section>
</div>
<div id="man-in-the-middle-protection">
@@ -2556,6 +2612,15 @@ compromised key and issue a new WIT with a fresh key pair.<a href="#section-9.7-
ledger before revocation remain valid historical records but <span class="bcp14">SHOULD</span>
be flagged in the ledger as "signed with subsequently revoked key"
for audit purposes.<a href="#section-9.7-3" class="pilcrow"></a></p>
<p id="section-9.7-4">ECT revocation does not propagate through the DAG. If a parent
ECT's signing key is later revoked, child ECTs that were verified
and recorded before that revocation remain valid — they captured
a legitimate execution record at the time of issuance. However,
auditors reviewing a workflow <span class="bcp14">SHOULD</span> flag any ECT in the DAG
whose signing key was subsequently revoked, so that the scope of
a potential compromise can be assessed. New ECTs <span class="bcp14">MUST NOT</span> be
created with a "par" reference to an ECT whose signing key is
known to be revoked at creation time.<a href="#section-9.7-4" class="pilcrow"></a></p>
</section>
</div>
<div id="collusion-and-false-claims">
@@ -2584,54 +2649,110 @@ contents against expected workflow patterns.<a href="#section-9.8-3.3.1" class="
</ul>
</section>
</div>
<div id="denial-of-service">
<div id="dag-integrity-attacks">
<section id="section-9.9">
<h3 id="name-denial-of-service">
<a href="#section-9.9" class="section-number selfRef">9.9. </a><a href="#name-denial-of-service" class="section-name selfRef">Denial of Service</a>
<h3 id="name-dag-integrity-attacks">
<a href="#section-9.9" class="section-number selfRef">9.9. </a><a href="#name-dag-integrity-attacks" class="section-name selfRef">DAG Integrity Attacks</a>
</h3>
<p id="section-9.9-1">ECT signature verification is computationally inexpensive
<p id="section-9.9-1">Because the DAG structure is the primary mechanism for establishing
execution ordering, attackers may attempt to manipulate it:<a href="#section-9.9-1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-9.9-2.1">
<p id="section-9.9-2.1.1">False parent references: A malicious agent creates an ECT that
references parent tasks from an unrelated workflow, inserting
itself into a legitimate execution history. DAG validation
(<a href="#dag-validation" class="auto internal xref">Section 6</a>) mitigates this by requiring parent existence
in the ECT store, and the "wid" claim scopes parent references
to a single workflow when present.<a href="#section-9.9-2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-9.9-2.2">
<p id="section-9.9-2.2.1">Parent omission (pruning): An agent deliberately omits one or
more actual parent dependencies from the "par" array to hide
that certain tasks influenced its output. Because ECTs are
self-asserted (<a href="#self-assertion-limitation" class="auto internal xref">Section 9.2</a>), no mechanism can
force an agent to declare all dependencies. External auditors
can detect omission by comparing the declared DAG against
expected workflow patterns.<a href="#section-9.9-2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-9.9-2.3">
<p id="section-9.9-2.3.1">Shadow DAGs: Multiple colluding agents fabricate an entire
execution history by creating a sequence of ECTs with mutual
parent references. Independent ledger maintenance and
cross-verification (see <a href="#collusion-and-false-claims" class="auto internal xref">Section 9.8</a> above)
are the primary mitigations.<a href="#section-9.9-2.3.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="section-9.9-3">Verifiers <span class="bcp14">SHOULD</span> validate that the declared "wid" of parent ECTs
matches the "wid" of the child ECT, rejecting cross-workflow
parent references unless explicitly permitted by deployment
policy.<a href="#section-9.9-3" class="pilcrow"></a></p>
</section>
</div>
<div id="privilege-escalation-via-ects">
<section id="section-9.10">
<h3 id="name-privilege-escalation-via-ec">
<a href="#section-9.10" class="section-number selfRef">9.10. </a><a href="#name-privilege-escalation-via-ec" class="section-name selfRef">Privilege Escalation via ECTs</a>
</h3>
<p id="section-9.10-1">ECTs record execution history; they do not convey authorization.
Verifiers <span class="bcp14">MUST NOT</span> interpret the presence of an ECT, or a
particular set of parent references in "par", as an authorization
grant. The "par" claim demonstrates that predecessor tasks were
recorded, not that the current agent is authorized to act on
their outputs. Authorization decisions <span class="bcp14">MUST</span> remain with the
identity and authorization layer (WIT, WPT, and deployment
policy). As noted in <span>[<a href="#I-D.ni-wimse-ai-agent-identity" class="cite xref">I-D.ni-wimse-ai-agent-identity</a>]</span>,
AI intermediaries introduce novel escalation vectors; ECTs
<span class="bcp14">MUST NOT</span> be used to circumvent authorization boundaries.<a href="#section-9.10-1" class="pilcrow"></a></p>
</section>
</div>
<div id="denial-of-service">
<section id="section-9.11">
<h3 id="name-denial-of-service">
<a href="#section-9.11" class="section-number selfRef">9.11. </a><a href="#name-denial-of-service" class="section-name selfRef">Denial of Service</a>
</h3>
<p id="section-9.11-1">ECT signature verification is computationally inexpensive
(approximately 1ms per ECT on modern hardware for ES256). DAG
validation complexity is O(V) where V is the number of ancestor
nodes reachable from the parent references; for typical shallow
DAGs this is efficient.<a href="#section-9.9-1" class="pilcrow"></a></p>
<p id="section-9.9-2">Implementations <span class="bcp14">SHOULD</span> apply rate limiting at the API layer to
DAGs this is efficient.<a href="#section-9.11-1" class="pilcrow"></a></p>
<p id="section-9.11-2">Implementations <span class="bcp14">SHOULD</span> apply rate limiting at the API layer to
prevent excessive ECT submissions. DAG validation <span class="bcp14">SHOULD</span> be
performed after signature verification to avoid wasting resources
on unsigned or incorrectly signed tokens.<a href="#section-9.9-2" class="pilcrow"></a></p>
on unsigned or incorrectly signed tokens.<a href="#section-9.11-2" class="pilcrow"></a></p>
</section>
</div>
<div id="timestamp-accuracy">
<section id="section-9.10">
<section id="section-9.12">
<h3 id="name-timestamp-accuracy">
<a href="#section-9.10" class="section-number selfRef">9.10. </a><a href="#name-timestamp-accuracy" class="section-name selfRef">Timestamp Accuracy</a>
<a href="#section-9.12" class="section-number selfRef">9.12. </a><a href="#name-timestamp-accuracy" class="section-name selfRef">Timestamp Accuracy</a>
</h3>
<p id="section-9.10-1">ECTs rely on timestamps ("iat", "exp") for temporal ordering.
<p id="section-9.12-1">ECTs rely on timestamps ("iat", "exp") for temporal ordering.
Clock skew between agents can lead to incorrect ordering
judgments. Implementations <span class="bcp14">SHOULD</span> use synchronized time sources
(e.g., NTP) and <span class="bcp14">SHOULD</span> allow a configurable clock skew tolerance
(<span class="bcp14">RECOMMENDED</span>: 30 seconds).<a href="#section-9.10-1" class="pilcrow"></a></p>
<p id="section-9.10-2">Cross-organizational deployments where agents span multiple trust
(<span class="bcp14">RECOMMENDED</span>: 30 seconds).<a href="#section-9.12-1" class="pilcrow"></a></p>
<p id="section-9.12-2">Cross-organizational deployments where agents span multiple trust
domains with independent time sources <span class="bcp14">MAY</span> require a higher clock
skew tolerance. Deployments using trust domain federation <span class="bcp14">SHOULD</span>
document their configured clock skew tolerance value and <span class="bcp14">SHOULD</span>
ensure all participating trust domains agree on a common tolerance.<a href="#section-9.10-2" class="pilcrow"></a></p>
<p id="section-9.10-3">The temporal ordering check in DAG validation incorporates the
ensure all participating trust domains agree on a common tolerance.<a href="#section-9.12-2" class="pilcrow"></a></p>
<p id="section-9.12-3">The temporal ordering check in DAG validation incorporates the
clock skew tolerance to account for minor clock differences
between agents.<a href="#section-9.10-3" class="pilcrow"></a></p>
between agents.<a href="#section-9.12-3" class="pilcrow"></a></p>
</section>
</div>
<div id="ect-size-constraints">
<section id="section-9.11">
<section id="section-9.13">
<h3 id="name-ect-size-constraints">
<a href="#section-9.11" class="section-number selfRef">9.11. </a><a href="#name-ect-size-constraints" class="section-name selfRef">ECT Size Constraints</a>
<a href="#section-9.13" class="section-number selfRef">9.13. </a><a href="#name-ect-size-constraints" class="section-name selfRef">ECT Size Constraints</a>
</h3>
<p id="section-9.11-1">ECTs with many parent tasks or large extension objects can
<p id="section-9.13-1">ECTs with many parent tasks or large extension objects can
increase HTTP header size. Implementations <span class="bcp14">SHOULD</span> limit the "par"
array to a maximum of 256 entries. Workflows requiring more
parent references <span class="bcp14">SHOULD</span> introduce intermediate aggregation
tasks. The "ext" object <span class="bcp14">SHOULD NOT</span> exceed 4096 bytes when
serialized as JSON and <span class="bcp14">SHOULD NOT</span> exceed a nesting depth of
5 levels (see also <a href="#extension-claims" class="auto internal xref">Section 4.2.4</a>).<a href="#section-9.11-1" class="pilcrow"></a></p>
5 levels (see also <a href="#extension-claims" class="auto internal xref">Section 4.2.4</a>).<a href="#section-9.13-1" class="pilcrow"></a></p>
</section>
</div>
</section>
@@ -3000,6 +3121,10 @@ the "JSON Web Token Claims" registry maintained by IANA:<a href="#section-11.3-1
<dd>
<span class="refAuthor">Backman, A., Ed.</span>, <span class="refAuthor">Richer, J., Ed.</span>, and <span class="refAuthor">M. Sporny</span>, <span class="refTitle">"HTTP Message Signatures"</span>, <span class="seriesInfo">RFC 9421</span>, <span class="seriesInfo">DOI 10.17487/RFC9421</span>, <time datetime="2024-02" class="refDate">February 2024</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9421">https://www.rfc-editor.org/rfc/rfc9421</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9449">[RFC9449]</dt>
<dd>
<span class="refAuthor">Fett, D.</span>, <span class="refAuthor">Campbell, B.</span>, <span class="refAuthor">Bradley, J.</span>, <span class="refAuthor">Lodderstedt, T.</span>, <span class="refAuthor">Jones, M.</span>, and <span class="refAuthor">D. Waite</span>, <span class="refTitle">"OAuth 2.0 Demonstrating Proof of Possession (DPoP)"</span>, <span class="seriesInfo">RFC 9449</span>, <span class="seriesInfo">DOI 10.17487/RFC9449</span>, <time datetime="2023-09" class="refDate">September 2023</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9449">https://www.rfc-editor.org/rfc/rfc9449</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SPIFFE">[SPIFFE]</dt>
<dd>
<span class="refTitle">"Secure Production Identity Framework for Everyone (SPIFFE)"</span>, <span>&lt;<a href="https://spiffe.io/docs/latest/spiffe-about/overview/">https://spiffe.io/docs/latest/spiffe-about/overview/</a>&gt;</span>. </dd>
@@ -3157,6 +3282,11 @@ workloads that forward the token unchanged are not recorded.<a href="#appendix-B
<li class="normal" id="appendix-B.3-3.3">
<p id="appendix-B.3-3.3.1">It carries no task-level granularity, no parent references,
and no execution content.<a href="#appendix-B.3-3.3.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="appendix-B.3-3.4">
<p id="appendix-B.3-3.4.1">It cannot represent convergence (fan-in): when two independent
paths must both complete before a dependent task proceeds, a
linear "req_wl" string cannot express that relationship.<a href="#appendix-B.3-3.4.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="appendix-B.3-4">Extensions for agentic use cases
@@ -3194,16 +3324,32 @@ ECTs may reference OpenTelemetry trace identifiers in the "ext"
claim for correlation.<a href="#appendix-B.4-1" class="pilcrow"></a></p>
</section>
</div>
<div id="scitt-supply-chain-integrity-transparency-and-trust">
<div id="w3c-provenance-data-model-prov">
<section id="appendix-B.5">
<h3 id="name-w3c-provenance-data-model-p">
<a href="#name-w3c-provenance-data-model-p" class="section-name selfRef">W3C Provenance Data Model (PROV)</a>
</h3>
<p id="appendix-B.5-1">The W3C PROV Data Model defines an Entity-Activity-Agent ontology
for representing provenance information. PROV's concepts map
closely to ECT structures: PROV Activities correspond to ECT
tasks, PROV Agents correspond to WIMSE workloads, and PROV's
"wasInformedBy" relation corresponds to ECT "par" references.
However, PROV uses RDF/OWL ontologies designed for post-hoc
documentation, while ECTs are runtime-embeddable JWT tokens with
cryptographic signatures. ECT audit data could be exported to
PROV format for interoperability with provenance-aware systems.<a href="#appendix-B.5-1" class="pilcrow"></a></p>
</section>
</div>
<div id="scitt-supply-chain-integrity-transparency-and-trust">
<section id="appendix-B.6">
<h3 id="name-scitt-supply-chain-integrit">
<a href="#name-scitt-supply-chain-integrit" class="section-name selfRef">SCITT (Supply Chain Integrity, Transparency, and Trust)</a>
</h3>
<p id="appendix-B.5-1">The SCITT architecture <span>[<a href="#I-D.ietf-scitt-architecture" class="cite xref">I-D.ietf-scitt-architecture</a>]</span> defines a
<p id="appendix-B.6-1">The SCITT architecture <span>[<a href="#I-D.ietf-scitt-architecture" class="cite xref">I-D.ietf-scitt-architecture</a>]</span> defines a
framework for transparent and auditable supply chain records.
ECTs and SCITT are complementary: the ECT "wid" claim can serve
as a correlation identifier in SCITT Signed Statements, linking
an ECT audit trail to a supply chain transparency record.<a href="#appendix-B.5-1" class="pilcrow"></a></p>
an ECT audit trail to a supply chain transparency record.<a href="#appendix-B.6-1" class="pilcrow"></a></p>
</section>
</div>
</section>