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

Remove duplicate RFC 2119/8174 refs and add compiled output

Browse Source 
Remove RFC 2119 and RFC 8174 from normative YAML block since the
BCP 14 boilerplate directive adds them automatically, causing
duplicate reference warnings. Rebuild draft with zero warnings.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Christian Nennemann
2026-02-24 18:51:45 +01:00
parent 397419d711
commit 8615105ce0
4 changed files with 2137 additions and 1078 deletions
Download Patch File Download Diff File Expand all files Collapse all files

339
draft-nennemann-wimse-execution-context-00.html
View File

@@ -1249,7 +1249,7 @@ li > p:last-of-type:only-child {
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-workgroup">Workgroup:</dt>
<dd class="workgroup">Network Working Group</dd>
<dd class="workgroup">WIMSE</dd>
<dt class="label-internet-draft">Internet-Draft:</dt>
<dd class="internet-draft">draft-nennemann-wimse-execution-context-00</dd>
<dt class="label-published">Published:</dt>
@@ -1548,6 +1548,12 @@ regulatory frameworks.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.3">
<p id="section-toc.1-1.12.2.3.1"><a href="#section-12.3" class="auto internal xref">12.3</a>.  <a href="#name-jwt-claims-registration" class="internal xref">JWT Claims Registration</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.4">
<p id="section-toc.1-1.12.2.4.1"><a href="#section-12.4" class="auto internal xref">12.4</a>.  <a href="#name-ect-policy-decision-values-" class="internal xref">ECT Policy Decision Values Registry</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.5">
<p id="section-toc.1-1.12.2.5.1"><a href="#section-12.5" class="auto internal xref">12.5</a>.  <a href="#name-ect-regulated-domain-values" class="internal xref">ECT Regulated Domain Values Registry</a></p>
</li>
</ul>
</li>
@@ -1683,7 +1689,7 @@ addresses the gap between workload identity and execution
accountability. WIMSE authenticates agents; this extension records
what they did, in what order, and what policy was evaluated.<a href="#section-1.1-5" class="pilcrow"></a></p>
<p id="section-1.1-6">As identified in <span>[<a href="#I-D.ni-wimse-ai-agent-identity" class="cite xref">I-D.ni-wimse-ai-agent-identity</a>]</span>, call context
in agentic workflows must always be visible and preserved. ECTs
in agentic workflows needs to be visible and preserved. ECTs
provide a mechanism to address this requirement with cryptographic
assurances.<a href="#section-1.1-6" class="pilcrow"></a></p>
</section>
@@ -2088,14 +2094,45 @@ claim of the agent's WIT.<a href="#section-4.2.1-2.2.1" class="pilcrow">¶</a></
<dt id="section-4.2.1-2.3">sub:</dt>
<dd style="margin-left: 1.5em" id="section-4.2.1-2.4">
<p id="section-4.2.1-2.4.1"><span class="bcp14">OPTIONAL</span>. StringOrURI. The subject of the ECT. When present,
<span class="bcp14">MUST</span> equal the "iss" claim.<a href="#section-4.2.1-2.4.1" class="pilcrow"></a></p>
<span class="bcp14">MUST</span> equal the "iss" claim. This claim is included for
compatibility with JWT libraries and frameworks that expect a
"sub" claim to be present.<a href="#section-4.2.1-2.4.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
<dt id="section-4.2.1-2.5">aud:</dt>
<dd style="margin-left: 1.5em" id="section-4.2.1-2.6">
<p id="section-4.2.1-2.6.1"><span class="bcp14">REQUIRED</span>. StringOrURI or array of StringOrURI. The intended
recipient(s) of the ECT. Typically the next agent in the
workflow or the ledger endpoint.<a href="#section-4.2.1-2.6.1" class="pilcrow"></a></p>
recipient(s) of the ECT. Because ECTs serve as both inter-agent
messages and audit records, the "aud" claim <span class="bcp14">SHOULD</span> contain the
identifiers of all entities that will verify the ECT. In
practice this means:<a href="#section-4.2.1-2.6.1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-4.2.1-2.6.2.1">
<p id="section-4.2.1-2.6.2.1.1"><strong>Point-to-point delivery</strong>: when an ECT is sent from one
agent to a single next agent, "aud" contains that agent's
workload identity. The receiving agent verifies the ECT and
forwards it to the ledger on behalf of the issuer.<a href="#section-4.2.1-2.6.2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-4.2.1-2.6.2.2">
<p id="section-4.2.1-2.6.2.2.1"><strong>Direct-to-ledger submission</strong>: when an ECT is submitted
directly to the audit ledger (e.g., after a join or at
workflow completion), "aud" contains the ledger's identity.<a href="#section-4.2.1-2.6.2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-4.2.1-2.6.2.3">
<p id="section-4.2.1-2.6.2.3.1"><strong>Multi-audience</strong>: when an ECT must be verified by both the
next agent and the ledger independently, "aud" <span class="bcp14">MUST</span> be an
array containing both identifiers (e.g.,
["spiffe://example.com/agent/next",
"spiffe://example.com/system/ledger"]). Each verifier checks
that its own identity appears in the array.<a href="#section-4.2.1-2.6.2.3.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="section-4.2.1-2.6.3">In multi-parent (join) scenarios where a task depends on ECTs
from multiple parent agents, the joining agent creates a new ECT
with the parent task IDs in "par". The "aud" of this new ECT
is set according to the rules above based on where the ECT will
be delivered — it is independent of the "aud" values in the
parent ECTs.<a href="#section-4.2.1-2.6.3" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
<dt id="section-4.2.1-2.7">iat:</dt>
@@ -2112,11 +2149,19 @@ Implementations <span class="bcp14">SHOULD</span> set this to 5 to 15 minutes af
to limit the replay window while allowing for reasonable clock
skew and processing time.<a href="#section-4.2.1-2.10.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
<dt id="section-4.2.1-2.11">jti:</dt>
<dd style="margin-left: 1.5em" id="section-4.2.1-2.12">
<p id="section-4.2.1-2.12.1"><span class="bcp14">OPTIONAL</span>. String. A unique identifier for the ECT, useful for
additional replay detection.<a href="#section-4.2.1-2.12.1" class="pilcrow"></a></p>
<dd class="break"></dd>
</dl>
<p id="section-4.2.1-3">The standard JWT "nbf" (Not Before) claim is not used in ECTs
because ECTs record completed actions and are valid immediately
upon issuance.<a href="#section-4.2.1-3" class="pilcrow"></a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.2.1-4">
<dt id="section-4.2.1-4.1">jti:</dt>
<dd style="margin-left: 1.5em" id="section-4.2.1-4.2">
<p id="section-4.2.1-4.2.1"><span class="bcp14">REQUIRED</span>. String. A unique identifier for the ECT in UUID
format <span>[<a href="#RFC9562" class="cite xref">RFC9562</a>]</span>. Used for replay detection: receivers <span class="bcp14">MUST</span>
reject ECTs whose "jti" has already been seen within the
expiration window. The "jti" value <span class="bcp14">MUST</span> be unique across all
ECTs issued by the same agent.<a href="#section-4.2.1-4.2.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
</dl>
@@ -2185,7 +2230,30 @@ evaluated for this task (e.g.,
<dt id="section-4.2.3-2.3">pol_decision:</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">REQUIRED</span>. String. The result of the policy evaluation. <span class="bcp14">MUST</span>
be one of: "approved", "rejected", or "pending_human_review".<a href="#section-4.2.3-2.4.1" class="pilcrow"></a></p>
be one of the values registered in the ECT Policy Decision
Values registry (<a href="#pol-decision-registry" class="auto internal xref">Section 12.4</a>). Initial values
are:<a href="#section-4.2.3-2.4.1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-4.2.3-2.4.2.1">
<p id="section-4.2.3-2.4.2.1.1">"approved": The policy evaluation succeeded and the task
was authorized to proceed.<a href="#section-4.2.3-2.4.2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-4.2.3-2.4.2.2">
<p id="section-4.2.3-2.4.2.2.1">"rejected": The policy evaluation failed. A "rejected" ECT
<span class="bcp14">MUST</span> still be appended to the audit ledger for accountability.
An ECT with "pol_decision" of "rejected" <span class="bcp14">MAY</span> appear as a
parent in the "par" array of a subsequent ECT, but only for
compensation, rollback, or remediation tasks. Agents <span class="bcp14">MUST NOT</span> proceed with normal workflow execution based on a parent
ECT whose "pol_decision" is "rejected".<a href="#section-4.2.3-2.4.2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-4.2.3-2.4.2.3">
<p id="section-4.2.3-2.4.2.3.1">"pending_human_review": The policy evaluation requires human
judgment before proceeding. Agents <span class="bcp14">MUST NOT</span> proceed with
dependent tasks until a subsequent ECT from a human reviewer
records an "approved" decision referencing this task as a
parent.<a href="#section-4.2.3-2.4.2.3.1" class="pilcrow"></a></p>
</li>
</ul>
</dd>
<dd class="break"></dd>
<dt id="section-4.2.3-2.5">pol_enforcer:</dt>
@@ -2218,8 +2286,12 @@ inputs and outputs without revealing the data itself:<a href="#section-4.2.4-1"
<p id="section-4.2.4-2.2.1"><span class="bcp14">OPTIONAL</span>. String. A cryptographic hash of the input data,
formatted as "hash-algorithm:base64url-encoded-hash" (e.g.,
"sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The
hash algorithm identifier <span class="bcp14">SHOULD</span> be "sha-256". The hash <span class="bcp14">MUST</span> be
computed over the raw octets of the input data.<a href="#section-4.2.4-2.2.1" class="pilcrow"></a></p>
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. The hash <span class="bcp14">MUST</span> be computed over the raw octets of the
input data.<a href="#section-4.2.4-2.2.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
<dt id="section-4.2.4-2.3">out_hash:</dt>
@@ -2253,8 +2325,8 @@ milliseconds. <span class="bcp14">MUST</span> be a non-negative integer.<a href
<dt id="section-4.2.5-2.3">regulated_domain:</dt>
<dd style="margin-left: 1.5em" id="section-4.2.5-2.4">
<p id="section-4.2.5-2.4.1"><span class="bcp14">OPTIONAL</span>. String. The regulatory domain applicable to this
task. Values are drawn from an extensible set; initial values
include "medtech", "finance", and "military".<a href="#section-4.2.5-2.4.1" class="pilcrow"></a></p>
task. Values <span class="bcp14">MUST</span> be registered in the ECT Regulated Domain
Values registry (<a href="#regulated-domain-registry" class="auto internal xref">Section 12.5</a>).<a href="#section-4.2.5-2.4.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
<dt id="section-4.2.5-2.5">model_version:</dt>
@@ -2300,7 +2372,9 @@ compensation or rollback action for a previous task.<a href="#section-4.2.7-1.2.
<dt id="section-4.2.7-1.3">compensation_reason:</dt>
<dd style="margin-left: 1.5em" id="section-4.2.7-1.4">
<p id="section-4.2.7-1.4.1"><span class="bcp14">OPTIONAL</span>. String. A human-readable reason for the compensation
action. <span class="bcp14">MUST</span> be present if "compensation_required" is true.<a href="#section-4.2.7-1.4.1" class="pilcrow"></a></p>
action. <span class="bcp14">MUST</span> be present if "compensation_required" is true.
If "compensation_reason" is present, "compensation_required"
<span class="bcp14">MUST</span> be true.<a href="#section-4.2.7-1.4.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
</dl>
@@ -2321,16 +2395,14 @@ ledger.<a href="#section-4.2.7-2" class="pilcrow">¶</a></p>
<dd style="margin-left: 1.5em" id="section-4.2.8-1.2">
<p id="section-4.2.8-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">SHOULD</span> ignore them.
To avoid key collisions between different domains, extension
key names <span class="bcp14">SHOULD</span> use reverse domain notation (e.g.,
"com.example.custom_field").<a href="#section-4.2.8-1.2.1" class="pilcrow"></a></p>
that do not understand extension claims <span class="bcp14">MUST</span> ignore them.<a href="#section-4.2.8-1.2.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
</dl>
<p id="section-4.2.8-2">The "ext" claim is a generic extension mechanism; it is not
registered in the IANA JWT Claims registry because its semantics
depend on the domain-specific claims within it.<a href="#section-4.2.8-2" class="pilcrow"></a></p>
<p id="section-4.2.8-2">To avoid key collisions between different domains, extension
key names <span class="bcp14">MUST</span> use reverse domain notation (e.g.,
"com.example.custom_field"). Implementations <span class="bcp14">MUST NOT</span> use
unqualified key names within the "ext" object.<a href="#section-4.2.8-2" class="pilcrow"></a></p>
</section>
</div>
</section>
@@ -2351,6 +2423,7 @@ depend on the domain-specific claims within it.<a href="#section-4.2.8-2" class=
"aud": "spiffe://example.com/agent/safety",
"iat": 1772064150,
"exp": 1772064750,
"jti": "7f3a8b2c-d1e4-4f56-9a0b-c3d4e5f6a7b8",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"tid": "550e8400-e29b-41d4-a716-446655440001",
@@ -2419,6 +2492,13 @@ Execution-Context: eyJhbGci...ECT...
<p id="section-5.1-5">When multiple parent tasks contribute context to a single request,
multiple Execution-Context header field lines <span class="bcp14">MAY</span> be included, each
carrying a separate ECT in JWS Compact Serialization format.<a href="#section-5.1-5" class="pilcrow"></a></p>
<p id="section-5.1-6">When a receiver processes multiple Execution-Context headers, it
<span class="bcp14">MUST</span> individually verify each ECT per the procedure in
<a href="#verification" class="auto internal xref">Section 7</a>. If any single ECT fails verification, the
receiver <span class="bcp14">MUST</span> reject the entire request. The set of verified
parent task IDs across all received ECTs represents the complete
set of parent dependencies available for the receiving agent's
subsequent ECT.<a href="#section-5.1-6" class="pilcrow"></a></p>
</section>
</div>
</section>
@@ -2462,11 +2542,15 @@ recorded in the ledger. If any parent task is not found, the
ECT <span class="bcp14">MUST</span> be rejected.<a href="#section-6.2-2.2.1" class="pilcrow"></a></p>
</li>
<li id="section-6.2-2.3">
<p id="section-6.2-2.3.1">Temporal Ordering: The "iat" value of every parent task <span class="bcp14">MUST</span> be
less than the "iat" value of the current task plus a
<p id="section-6.2-2.3.1">Temporal Ordering: The "iat" value of every parent task <span class="bcp14">MUST NOT</span> be greater than the "iat" value of the current task plus a
configurable clock skew tolerance (<span class="bcp14">RECOMMENDED</span>: 30 seconds).
If any parent task has an "iat" that violates this constraint,
the ECT <span class="bcp14">MUST</span> be rejected.<a href="#section-6.2-2.3.1" class="pilcrow"></a></p>
That is, for each parent: <code>parent.iat &lt; child.iat +
clock_skew_tolerance</code>. The tolerance accounts for clock skew
between agents; it does not guarantee strict causal ordering
from timestamps alone. Causal ordering is primarily enforced
by the DAG structure (parent existence in the ledger), not by
timestamps. If any parent task violates this constraint, the
ECT <span class="bcp14">MUST</span> be rejected.<a href="#section-6.2-2.3.1" class="pilcrow"></a></p>
</li>
<li id="section-6.2-2.4">
<p id="section-6.2-2.4.1">Acyclicity: Following the chain of parent references <span class="bcp14">MUST NOT</span>
@@ -2474,9 +2558,18 @@ lead back to the current task's "tid". If a cycle is detected,
the ECT <span class="bcp14">MUST</span> be rejected.<a href="#section-6.2-2.4.1" class="pilcrow"></a></p>
</li>
<li id="section-6.2-2.5">
<p id="section-6.2-2.5.1">Trust Domain Consistency: Parent tasks <span class="bcp14">SHOULD</span> belong to the
<p id="section-6.2-2.5.1">Parent Policy Decision: If any parent task has a "pol_decision"
of "rejected" or "pending_human_review", the current task's
"exec_act" <span class="bcp14">MUST</span> indicate a compensation, rollback, remediation,
or human review action. Implementations <span class="bcp14">MUST NOT</span> accept an ECT
representing normal workflow continuation when a parent's
"pol_decision" is not "approved", unless the current ECT has
"compensation_required" set to true.<a href="#section-6.2-2.5.1" class="pilcrow"></a></p>
</li>
<li id="section-6.2-2.6">
<p id="section-6.2-2.6.1">Trust Domain Consistency: Parent tasks <span class="bcp14">SHOULD</span> belong to the
same trust domain or to a trust domain with which a federation
relationship has been established.<a href="#section-6.2-2.5.1" class="pilcrow"></a></p>
relationship has been established.<a href="#section-6.2-2.6.1" class="pilcrow"></a></p>
</li>
</ol>
</section>
@@ -2581,7 +2674,11 @@ associated with the "kid" public key.<a href="#section-7.1-2.7.1" class="pilcrow
</li>
<li id="section-7.1-2.8">
<p id="section-7.1-2.8.1">Verify the "aud" claim contains the verifier's own workload
identity or an expected recipient identifier.<a href="#section-7.1-2.8.1" class="pilcrow"></a></p>
identity. When "aud" is an array, it is sufficient that the
verifier's identity appears as one element; the presence of
other audience values does not cause verification failure.
When the verifier is the audit ledger, the ledger's own
identity <span class="bcp14">MUST</span> appear in "aud".<a href="#section-7.1-2.8.1" class="pilcrow"></a></p>
</li>
<li id="section-7.1-2.9">
<p id="section-7.1-2.9.1">Verify the "exp" claim indicates the ECT has not expired.<a href="#section-7.1-2.9.1" class="pilcrow"></a></p>
@@ -2592,8 +2689,8 @@ identity or an expected recipient identifier.<a href="#section-7.1-2.8.1" class=
15 minutes).<a href="#section-7.1-2.10.1" class="pilcrow"></a></p>
</li>
<li id="section-7.1-2.11">
<p id="section-7.1-2.11.1">Verify all required claims ("tid", "exec_act", "par", "pol",
"pol_decision") are present and well-formed.<a href="#section-7.1-2.11.1" class="pilcrow"></a></p>
<p id="section-7.1-2.11.1">Verify all required claims ("jti", "tid", "exec_act", "par",
"pol", "pol_decision") are present and well-formed.<a href="#section-7.1-2.11.1" class="pilcrow"></a></p>
</li>
<li id="section-7.1-2.12">
<p id="section-7.1-2.12.1">Verify "pol_decision" is one of "approved", "rejected", or
@@ -2611,6 +2708,14 @@ ledger.<a href="#section-7.1-2.14.1" class="pilcrow">¶</a></p>
failure <span class="bcp14">MUST</span> be logged for audit purposes. Error messages
<span class="bcp14">SHOULD NOT</span> reveal whether specific parent task IDs exist in the
ledger, to prevent information disclosure.<a href="#section-7.1-3" class="pilcrow"></a></p>
<p id="section-7.1-4">When ECT verification fails during HTTP request processing, the
receiving agent <span class="bcp14">SHOULD</span> respond with HTTP 403 (Forbidden) if the
WIT and WPT are valid but the ECT is invalid, and HTTP 401
(Unauthorized) if the ECT signature verification fails. The
response body <span class="bcp14">SHOULD</span> include a generic error indicator without
revealing which specific verification step failed. The receiving
agent <span class="bcp14">MUST NOT</span> process the requested action when ECT verification
fails.<a href="#section-7.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="verification-pseudocode">
@@ -2666,7 +2771,7 @@ function verify_ect(ect_jws, verifier_id,
return reject("ECT issued too long ago")
// Verify required claims
for claim in ["tid", "exec_act", "par",
for claim in ["jti", "tid", "exec_act", "par",
"pol", "pol_decision"]:
if claim not in payload:
return reject("Missing required claim: " + claim)
@@ -2790,8 +2895,8 @@ examples demonstrate ECT mechanics; production deployments would
include additional domain-specific requirements beyond the scope
of this specification.<a href="#section-9-1" class="pilcrow"></a></p>
<p id="section-9-2">Note: task identifiers in this section are abbreviated for
readability. In production, all "tid" values <span class="bcp14">MUST</span> be UUIDs per
<span>[<a href="#RFC9562" class="cite xref">RFC9562</a>]</span>.<a href="#section-9-2" class="pilcrow"></a></p>
readability. In production, all "tid" values are required to be
UUIDs per <a href="#exec-claims" class="auto internal xref">Section 4.2.2</a>.<a href="#section-9-2" class="pilcrow"></a></p>
<div id="medical-device-sdlc-workflow">
<section id="section-9.1">
<h3 id="name-medical-device-sdlc-workflo">
@@ -2981,9 +3086,9 @@ a cryptographic link to the original task:<a href="#section-9.3-1" class="pilcro
<div class="lang-json sourcecode" id="section-9.3-2.1">
<pre>
{
"iss": "spiffe://bank.com/agent/operations",
"sub": "spiffe://bank.com/agent/operations",
"aud": "spiffe://bank.com/system/ledger",
"iss": "spiffe://bank.example/agent/operations",
"sub": "spiffe://bank.example/agent/operations",
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772150550,
"exp": 1772151150,
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
@@ -2992,7 +3097,7 @@ a cryptographic link to the original task:<a href="#section-9.3-1" class="pilcro
"par": ["550e8400-e29b-41d4-a716-446655440003"],
"pol": "compensation_policy_v1",
"pol_decision": "approved",
"pol_enforcer": "spiffe://bank.com/human/compliance-officer",
"pol_enforcer": "spiffe://bank.example/human/compliance-officer",
"compensation_required": true,
"compensation_reason": "policy_violation_in_parent_trade"
}
@@ -3012,7 +3117,7 @@ violation discovery to remediation.<a href="#section-9.3-3" class="pilcrow">¶</
<h3 id="name-autonomous-logistics-coordi">
<a href="#section-9.4" class="section-number selfRef">9.4. </a><a href="#name-autonomous-logistics-coordi" class="section-name selfRef">Autonomous Logistics Coordination</a>
</h3>
<p id="section-9.4-1">In a logistics workflow, multiple compliance checks must complete
<p id="section-9.4-1">In a logistics workflow, multiple compliance checks complete
before shipment commitment. The DAG structure records that all
required checks were completed:<a href="#section-9.4-1" class="pilcrow"></a></p>
<span id="name-logistics-workflow-with-par"></span><div id="fig-logistics">
@@ -3179,9 +3284,9 @@ reject ECTs that are too old, even if not yet expired.<a href="#section-10.5-1"
<p id="section-10.5-2">The DAG structure provides additional replay protection: an ECT
referencing parent tasks that already have a recorded child task
with the same action can be flagged as a potential replay.<a href="#section-10.5-2" class="pilcrow"></a></p>
<p id="section-10.5-3">Implementations <span class="bcp14">SHOULD</span> maintain a cache of recently-seen "jti"
values (when present) to detect replayed ECTs within the
expiration window.<a href="#section-10.5-3" class="pilcrow"></a></p>
<p id="section-10.5-3">Implementations <span class="bcp14">MUST</span> maintain a cache of recently-seen "jti"
values to detect replayed ECTs within the expiration window.
An ECT with a duplicate "jti" value <span class="bcp14">MUST</span> be rejected.<a href="#section-10.5-3" class="pilcrow"></a></p>
</section>
</div>
<div id="man-in-the-middle-protection">
@@ -3678,6 +3783,120 @@ the "JSON Web Token Claims" registry maintained by IANA:<a href="#section-12.3-1
<td class="text-center" rowspan="1" colspan="1">IETF</td>
<td class="text-center" rowspan="1" colspan="1">
<a href="#compensation-claims" class="auto internal xref">Section 4.2.7</a>
</td>
</tr>
<tr>
<td class="text-center" rowspan="1" colspan="1">ext</td>
<td class="text-left" rowspan="1" colspan="1">Extension Object</td>
<td class="text-center" rowspan="1" colspan="1">IETF</td>
<td class="text-center" rowspan="1" colspan="1">
<a href="#extension-claims" class="auto internal xref">Section 4.2.8</a>
</td>
</tr>
</tbody>
</table>
</div>
</section>
</div>
<div id="pol-decision-registry">
<section id="section-12.4">
<h3 id="name-ect-policy-decision-values-">
<a href="#section-12.4" class="section-number selfRef">12.4. </a><a href="#name-ect-policy-decision-values-" class="section-name selfRef">ECT Policy Decision Values Registry</a>
</h3>
<p id="section-12.4-1">This document establishes the "ECT Policy Decision Values"
registry under the "JSON Web Token (JWT)" group. Registration
policy is Specification Required per <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>.<a href="#section-12.4-1" class="pilcrow"></a></p>
<p id="section-12.4-2">The initial contents of the registry are:<a href="#section-12.4-2" class="pilcrow"></a></p>
<span id="name-ect-policy-decision-values"></span><div id="_table-pol-decision">
<table class="center" id="table-2">
<caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-ect-policy-decision-values" class="selfRef">ECT Policy Decision Values</a>
</caption>
<thead>
<tr>
<th class="text-center" rowspan="1" colspan="1">Value</th>
<th class="text-left" rowspan="1" colspan="1">Description</th>
<th class="text-center" rowspan="1" colspan="1">Change Controller</th>
<th class="text-center" rowspan="1" colspan="1">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td class="text-center" rowspan="1" colspan="1">approved</td>
<td class="text-left" rowspan="1" colspan="1">Policy evaluation succeeded</td>
<td class="text-center" rowspan="1" colspan="1">IETF</td>
<td class="text-center" rowspan="1" colspan="1">
<a href="#policy-claims" class="auto internal xref">Section 4.2.3</a>
</td>
</tr>
<tr>
<td class="text-center" rowspan="1" colspan="1">rejected</td>
<td class="text-left" rowspan="1" colspan="1">Policy evaluation failed</td>
<td class="text-center" rowspan="1" colspan="1">IETF</td>
<td class="text-center" rowspan="1" colspan="1">
<a href="#policy-claims" class="auto internal xref">Section 4.2.3</a>
</td>
</tr>
<tr>
<td class="text-center" rowspan="1" colspan="1">pending_human_review</td>
<td class="text-left" rowspan="1" colspan="1">Awaiting human judgment</td>
<td class="text-center" rowspan="1" colspan="1">IETF</td>
<td class="text-center" rowspan="1" colspan="1">
<a href="#policy-claims" class="auto internal xref">Section 4.2.3</a>
</td>
</tr>
</tbody>
</table>
</div>
</section>
</div>
<div id="regulated-domain-registry">
<section id="section-12.5">
<h3 id="name-ect-regulated-domain-values">
<a href="#section-12.5" class="section-number selfRef">12.5. </a><a href="#name-ect-regulated-domain-values" class="section-name selfRef">ECT Regulated Domain Values Registry</a>
</h3>
<p id="section-12.5-1">This document establishes the "ECT Regulated Domain Values"
registry under the "JSON Web Token (JWT)" group. Registration
policy is Specification Required per <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>.<a href="#section-12.5-1" class="pilcrow"></a></p>
<p id="section-12.5-2">The initial contents of the registry are:<a href="#section-12.5-2" class="pilcrow"></a></p>
<span id="name-ect-regulated-domain-values-2"></span><div id="_table-regulated-domain">
<table class="center" id="table-3">
<caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-ect-regulated-domain-values-2" class="selfRef">ECT Regulated Domain Values</a>
</caption>
<thead>
<tr>
<th class="text-center" rowspan="1" colspan="1">Value</th>
<th class="text-left" rowspan="1" colspan="1">Description</th>
<th class="text-center" rowspan="1" colspan="1">Change Controller</th>
<th class="text-center" rowspan="1" colspan="1">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td class="text-center" rowspan="1" colspan="1">medtech</td>
<td class="text-left" rowspan="1" colspan="1">Medical technology and devices</td>
<td class="text-center" rowspan="1" colspan="1">IETF</td>
<td class="text-center" rowspan="1" colspan="1">
<a href="#operational-claims" class="auto internal xref">Section 4.2.5</a>
</td>
</tr>
<tr>
<td class="text-center" rowspan="1" colspan="1">finance</td>
<td class="text-left" rowspan="1" colspan="1">Financial services and trading</td>
<td class="text-center" rowspan="1" colspan="1">IETF</td>
<td class="text-center" rowspan="1" colspan="1">
<a href="#operational-claims" class="auto internal xref">Section 4.2.5</a>
</td>
</tr>
<tr>
<td class="text-center" rowspan="1" colspan="1">military</td>
<td class="text-left" rowspan="1" colspan="1">Military and defense</td>
<td class="text-center" rowspan="1" colspan="1">IETF</td>
<td class="text-center" rowspan="1" colspan="1">
<a href="#operational-claims" class="auto internal xref">Section 4.2.5</a>
</td>
</tr>
</tbody>
@@ -3710,14 +3929,14 @@ the "JSON Web Token Claims" registry maintained by IANA:<a href="#section-12.3-1
<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="RFC3339">[RFC3339]</dt>
<dd>
<span class="refAuthor">Klyne, G.</span> and <span class="refAuthor">C. Newman</span>, <span class="refTitle">"Date and Time on the Internet: Timestamps"</span>, <span class="seriesInfo">RFC 3339</span>, <span class="seriesInfo">DOI 10.17487/RFC3339</span>, <time datetime="2002-07" class="refDate">July 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc3339">https://www.rfc-editor.org/rfc/rfc3339</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>
@@ -3726,6 +3945,10 @@ the "JSON Web Token Claims" registry maintained by IANA:<a href="#section-12.3-1
<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="RFC8126">[RFC8126]</dt>
<dd>
<span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc8126">https://www.rfc-editor.org/rfc/rfc8126</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>
@@ -3783,10 +4006,6 @@ the "JSON Web Token Claims" registry maintained by IANA:<a href="#section-12.3-1
<dd>
<span class="refAuthor">Rescorla, E.</span> and <span class="refAuthor">B. Korver</span>, <span class="refTitle">"Guidelines for Writing RFC Text on Security Considerations"</span>, <span class="seriesInfo">BCP 72</span>, <span class="seriesInfo">RFC 3552</span>, <span class="seriesInfo">DOI 10.17487/RFC3552</span>, <time datetime="2003-07" class="refDate">July 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc3552">https://www.rfc-editor.org/rfc/rfc3552</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="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>
@@ -3917,11 +4136,12 @@ use cases are distinct.<a href="#appendix-A.6-1" class="pilcrow">¶</a></p>
<h3 id="name-minimal-implementation">
<a href="#name-minimal-implementation" class="section-name selfRef">Minimal Implementation</a>
</h3>
<p id="appendix-B.1-1">A minimal conforming implementation should:<a href="#appendix-B.1-1" class="pilcrow"></a></p>
<p id="appendix-B.1-1">A minimal conforming implementation needs to:<a href="#appendix-B.1-1" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="appendix-B.1-2">
<li id="appendix-B.1-2.1">
<p id="appendix-B.1-2.1.1">Create JWTs with all required claims ("iss", "aud", "iat",
"exp", "tid", "exec_act", "par", "pol", "pol_decision").<a href="#appendix-B.1-2.1.1" class="pilcrow"></a></p>
"exp", "jti", "tid", "exec_act", "par", "pol",
"pol_decision").<a href="#appendix-B.1-2.1.1" class="pilcrow"></a></p>
</li>
<li id="appendix-B.1-2.2">
<p id="appendix-B.1-2.2.1">Sign ECTs with the agent's private key using an algorithm
@@ -3994,10 +4214,11 @@ latency.<a href="#appendix-B.3-1.4.1" class="pilcrow">¶</a></p>
<h3 id="name-interoperability">
<a href="#name-interoperability" class="section-name selfRef">Interoperability</a>
</h3>
<p id="appendix-B.4-1">Implementations should use established JWT/JWS libraries (JOSE)
for token creation and verification. Custom cryptographic
implementations should not be used. Implementations should be
tested against multiple JWT libraries to ensure interoperability.<a href="#appendix-B.4-1" class="pilcrow"></a></p>
<p id="appendix-B.4-1">Implementations are expected to use established JWT/JWS libraries
(JOSE) for token creation and verification. Custom cryptographic
implementations are strongly discouraged. Implementations are
expected to be tested against multiple JWT libraries to ensure
interoperability.<a href="#appendix-B.4-1" class="pilcrow"></a></p>
</section>
</div>
</section>
@@ -4012,9 +4233,9 @@ compliance with various regulatory frameworks. ECTs are a
technical building block; achieving compliance requires
additional organizational measures beyond this specification.<a href="#appendix-C-1" class="pilcrow"></a></p>
<span id="name-regulatory-compliance-mappin"></span><div id="_table-regulatory">
<table class="center" id="table-2">
<table class="center" id="table-4">
<caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#table-4" class="selfRef">Table 4</a>:
<a href="#name-regulatory-compliance-mappin" class="selfRef">Regulatory Compliance Mapping</a>
</caption>
<thead>