Regenerate HTML rendering with local xml2rfc

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

draft-nennemann-wimse-execution-context-00.html

@@ -1490,6 +1490,11 @@ regulatory frameworks.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2">
                 <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="auto internal xref">10.2</a>.  <a href="#name-self-assertion-limitation" class="internal xref">Self-Assertion Limitation</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2.2.1">
+                    <p id="section-toc.1-1.10.2.2.2.1.1"><a href="#section-10.2.1" class="auto internal xref">10.2.1</a>.  <a href="#name-witness-attestation-model" class="internal xref">Witness Attestation Model</a></p>
+</li>
+                </ul>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.3">
                 <p id="section-toc.1-1.10.2.3.1"><a href="#section-10.3" class="auto internal xref">10.3</a>.  <a href="#name-organizational-prerequisite" class="internal xref">Organizational Prerequisites</a></p>
@@ -2290,14 +2295,15 @@ hash algorithm identifier <span class="bcp14">MUST</span> be a lowercase value f
 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
+required.  Implementations <span class="bcp14">MUST NOT</span> accept hash algorithms
-input data.<a href="#section-4.2.4-2.2.1" class="pilcrow">¶</a></p>
+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.4-2.2.1" class="pilcrow">¶</a></p>
 </dd>
             <dd class="break"></dd>
 <dt id="section-4.2.4-2.3">out_hash:</dt>
             <dd style="margin-left: 1.5em" id="section-4.2.4-2.4">
               <p id="section-4.2.4-2.4.1"><span class="bcp14">OPTIONAL</span>.  String.  A cryptographic hash of the output data,
-using the same format as "inp_hash".<a href="#section-4.2.4-2.4.1" class="pilcrow">¶</a></p>
+using the same format and algorithm requirements as "inp_hash".<a href="#section-4.2.4-2.4.1" class="pilcrow">¶</a></p>
 </dd>
             <dd class="break"></dd>
 <dt id="section-4.2.4-2.5">inp_classification:</dt>
@@ -2347,11 +2353,17 @@ used to perform the task, if applicable.<a href="#section-4.2.5-2.6.1" class="pi
             <dt id="section-4.2.6-1.1">witnessed_by:</dt>
             <dd style="margin-left: 1.5em" id="section-4.2.6-1.2">
               <p id="section-4.2.6-1.2.1"><span class="bcp14">OPTIONAL</span>.  Array of StringOrURI.  Identifiers of third-party
-entities that observed or attested to the execution of this
+entities that the issuing agent claims observed or attested to
-task.  When present, each element <span class="bcp14">SHOULD</span> use SPIFFE ID format.
+the execution of this task.  When present, each element <span class="bcp14">SHOULD</span>
-In regulated environments, implementations <span class="bcp14">SHOULD</span> use witness
+use SPIFFE ID format.  Note that this claim is self-asserted by
-attestation for critical decision points to mitigate the risk
+the ECT issuer; witnesses listed here do not co-sign this ECT.
-of single-agent false claims.<a href="#section-4.2.6-1.2.1" class="pilcrow">¶</a></p>
+For stronger assurance, witnesses <span class="bcp14">SHOULD</span> submit independent
+signed ECTs to the ledger attesting to their observation (see
+<a href="#witness-attestation-model" class="auto internal xref">Section 10.2.1</a>).  In regulated environments,
+implementations <span class="bcp14">SHOULD</span> use witness attestation for critical
+decision points to mitigate the risk of single-agent false
+claims.  See also <a href="#self-assertion-limitation" class="auto internal xref">Section 10.2</a> for the security
+implications of self-asserted witness claims.<a href="#section-4.2.6-1.2.1" class="pilcrow">¶</a></p>
 </dd>
           <dd class="break"></dd>
 </dl>
@@ -2373,6 +2385,10 @@ compensation or rollback action for a previous task.<a href="#section-4.2.7-1.2.
             <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.
+Values <span class="bcp14">SHOULD</span> use structured identifiers (e.g.,
+"policy_violation_in_parent_trade") rather than free-form text
+to minimize the risk of embedding sensitive information.  See
+<a href="#data-minimization" class="auto internal xref">Section 11.2</a> for privacy guidance.
 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>
@@ -2402,7 +2418,12 @@ that do not understand extension claims <span class="bcp14">MUST</span> ignore t
 <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>
+unqualified key names within the "ext" object.  To prevent
+abuse and excessive token size, the serialized JSON
+representation of the "ext" object <span class="bcp14">SHOULD NOT</span> exceed 4096
+bytes, and the JSON nesting depth within the "ext" object
+<span class="bcp14">SHOULD NOT</span> exceed 5 levels.  Implementations <span class="bcp14">SHOULD</span> reject
+ECTs whose "ext" claim exceeds these limits.<a href="#section-4.2.8-2" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -2597,14 +2618,19 @@ function validate_dag(ect, ledger, clock_skew_tolerance):
     if parent.iat &gt;= ect.iat + clock_skew_tolerance:
       return error("Parent task not earlier than current")
 
-  // Step 3: Cycle detection
+  // Step 3: Cycle detection (with traversal limit)
   visited = set()
-  if has_cycle(ect.tid, ect.par, ledger, visited):
+  result = has_cycle(ect.tid, ect.par, ledger, visited,
-    return error("Circular dependency detected")
+                      max_ancestor_limit)
+  if result is error or result is true:
+    return error("Circular dependency or depth limit exceeded")
 
   return success
 
-function has_cycle(target_tid, parent_ids, ledger, visited):
+function has_cycle(target_tid, parent_ids, ledger, visited,
+                   max_depth):
+  if visited.size() &gt;= max_depth:
+    return error("Maximum ancestor traversal limit exceeded")
   for parent_id in parent_ids:
     if parent_id == target_tid:
       return true
@@ -2613,8 +2639,10 @@ function has_cycle(target_tid, parent_ids, ledger, visited):
     visited.add(parent_id)
     parent = ledger.get(parent_id)
     if parent is not null:
-      if has_cycle(target_tid, parent.par, ledger, visited):
+      result = has_cycle(target_tid, parent.par, ledger,
-        return true
+                          visited, max_depth)
+      if result is error or result is true:
+        return result
   return false
 </pre>
 </div>
@@ -2626,7 +2654,11 @@ function has_cycle(target_tid, parent_ids, ledger, visited):
 current task's parents.  The complexity is O(V) where V is the
 number of ancestor nodes reachable from the current task's parent
 references.  For typical workflows with shallow DAGs, this is
-efficient.  Implementations <span class="bcp14">SHOULD</span> cache cycle detection results
+efficient.  To prevent denial-of-service via extremely deep or
+wide DAGs, implementations <span class="bcp14">SHOULD</span> enforce a maximum ancestor
+traversal limit (<span class="bcp14">RECOMMENDED</span>: 10000 nodes).  If the limit is
+reached before cycle detection completes, the ECT <span class="bcp14">SHOULD</span> be
+rejected.  Implementations <span class="bcp14">SHOULD</span> cache cycle detection results
 for previously verified tasks to avoid redundant traversals.<a href="#section-6.3-3" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -2665,43 +2697,52 @@ public key from a WIT within the trust domain.<a href="#section-7.1-2.4.1" class
 signature per <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span> Section 5.2.<a href="#section-7.1-2.5.1" class="pilcrow">¶</a></p>
 </li>
           <li id="section-7.1-2.6">
-            <p id="section-7.1-2.6.1">Verify the "alg" header parameter matches the algorithm in the
+            <p id="section-7.1-2.6.1">Verify that the signing key identified by "kid" has not been
-corresponding WIT.<a href="#section-7.1-2.6.1" class="pilcrow">¶</a></p>
+revoked within the trust domain.  Implementations <span class="bcp14">MUST</span> check
+the key's revocation status using the trust domain's key
+lifecycle mechanism (e.g., certificate revocation list, OCSP,
+or SPIFFE trust bundle updates).<a href="#section-7.1-2.6.1" class="pilcrow">¶</a></p>
 </li>
           <li id="section-7.1-2.7">
-            <p id="section-7.1-2.7.1">Verify the "iss" claim matches the "sub" claim of the WIT
+            <p id="section-7.1-2.7.1">Verify the "alg" header parameter matches the algorithm in the
-associated with the "kid" public key.<a href="#section-7.1-2.7.1" class="pilcrow">¶</a></p>
+corresponding WIT.<a href="#section-7.1-2.7.1" class="pilcrow">¶</a></p>
 </li>
           <li id="section-7.1-2.8">
-            <p id="section-7.1-2.8.1">Verify the "aud" claim contains the verifier's own workload
+            <p id="section-7.1-2.8.1">Verify the "iss" claim matches the "sub" claim of the WIT
+associated with the "kid" public key.<a href="#section-7.1-2.8.1" class="pilcrow">¶</a></p>
+</li>
+          <li id="section-7.1-2.9">
+            <p id="section-7.1-2.9.1">Verify the "aud" claim contains the verifier's own workload
 identity.  When "aud" is an array, it is sufficient that the
 verifier's identity appears as one element; the presence of
 other audience values does not cause verification failure.
 When the verifier is the audit ledger, the ledger's own
-identity <span class="bcp14">MUST</span> appear in "aud".<a href="#section-7.1-2.8.1" class="pilcrow">¶</a></p>
+identity <span class="bcp14">MUST</span> appear in "aud".<a href="#section-7.1-2.9.1" class="pilcrow">¶</a></p>
-</li>
-          <li id="section-7.1-2.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>
 </li>
           <li id="section-7.1-2.10">
-            <p id="section-7.1-2.10.1">Verify the "iat" claim is not unreasonably far in the past
+            <p id="section-7.1-2.10.1">Verify the "exp" claim indicates the ECT has not expired.<a href="#section-7.1-2.10.1" class="pilcrow">¶</a></p>
-(implementation-specific threshold, <span class="bcp14">RECOMMENDED</span> maximum of
-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 ("jti", "tid", "exec_act", "par",
+            <p id="section-7.1-2.11.1">Verify the "iat" claim is not unreasonably far in the past
-"pol", "pol_decision") are present and well-formed.<a href="#section-7.1-2.11.1" class="pilcrow">¶</a></p>
+(implementation-specific threshold, <span class="bcp14">RECOMMENDED</span> maximum of
+15 minutes) and is not unreasonably far in the future
+(<span class="bcp14">RECOMMENDED</span>: no more than 30 seconds ahead of the
+verifier's current time, to account for clock skew).<a href="#section-7.1-2.11.1" class="pilcrow">¶</a></p>
 </li>
           <li id="section-7.1-2.12">
-            <p id="section-7.1-2.12.1">Verify "pol_decision" is one of "approved", "rejected", or
+            <p id="section-7.1-2.12.1">Verify all required claims ("jti", "tid", "exec_act", "par",
-"pending_human_review".<a href="#section-7.1-2.12.1" class="pilcrow">¶</a></p>
+"pol", "pol_decision") are present and well-formed.<a href="#section-7.1-2.12.1" class="pilcrow">¶</a></p>
 </li>
           <li id="section-7.1-2.13">
-            <p id="section-7.1-2.13.1">Perform DAG validation per <a href="#dag-validation" class="auto internal xref">Section 6</a>.<a href="#section-7.1-2.13.1" class="pilcrow">¶</a></p>
+            <p id="section-7.1-2.13.1">Verify "pol_decision" is one of "approved", "rejected", or
+"pending_human_review".<a href="#section-7.1-2.13.1" class="pilcrow">¶</a></p>
 </li>
           <li id="section-7.1-2.14">
-            <p id="section-7.1-2.14.1">If all checks pass, the ECT <span class="bcp14">MUST</span> be appended to the audit
+            <p id="section-7.1-2.14.1">Perform DAG validation per <a href="#dag-validation" class="auto internal xref">Section 6</a>.<a href="#section-7.1-2.14.1" class="pilcrow">¶</a></p>
-ledger.<a href="#section-7.1-2.14.1" class="pilcrow">¶</a></p>
+</li>
+          <li id="section-7.1-2.15">
+            <p id="section-7.1-2.15.1">If all checks pass, the ECT <span class="bcp14">MUST</span> be appended to the audit
+ledger.<a href="#section-7.1-2.15.1" class="pilcrow">¶</a></p>
 </li>
         </ol>
 <p id="section-7.1-3">If any verification step fails, the ECT <span class="bcp14">MUST</span> be rejected and the
@@ -2749,6 +2790,10 @@ function verify_ect(ect_jws, verifier_id,
                                signature, public_key):
     return reject("Invalid signature")
 
+  // Verify key not revoked
+  if is_key_revoked(header.kid, trust_domain_keys):
+    return reject("Signing key has been revoked")
+
   // Verify algorithm alignment
   wit = get_wit_for_key(header.kid)
   if header.alg != wit.alg:
@@ -2766,9 +2811,11 @@ function verify_ect(ect_jws, verifier_id,
   if payload.exp &lt; current_time():
     return reject("ECT has expired")
 
-  // Verify iat freshness
+  // Verify iat freshness (not too old, not in the future)
   if payload.iat &lt; current_time() - max_age_threshold:
     return reject("ECT issued too long ago")
+  if payload.iat &gt; current_time() + clock_skew_tolerance:
+    return reject("ECT issued in the future")
 
   // Verify required claims
   for claim in ["jti", "tid", "exec_act", "par",
@@ -2879,7 +2926,10 @@ workflow agents to reduce the risk of collusion.<a href="#section-8.2-3" class="
 and is the authoritative record.  The other fields ("agent_id",
 "action", "parents") are convenience indexes derived from the
 ECT payload; if they disagree with the JWS payload, the JWS
-payload takes precedence.<a href="#section-8.3-3" class="pilcrow">¶</a></p>
+payload takes precedence.  Implementations <span class="bcp14">SHOULD</span> validate that
+convenience index fields match the corresponding values in the
+JWS payload at write time to prevent desynchronization between
+the authoritative JWS and the indexed fields.<a href="#section-8.3-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -3223,7 +3273,49 @@ evaluating the policy).<a href="#section-10.2-1" class="pilcrow">¶</a></p>
 of the signing agent.  To mitigate single-agent false claims,
 regulated environments <span class="bcp14">SHOULD</span> use the "witnessed_by" mechanism
 to include independent third-party observers at critical decision
-points.<a href="#section-10.2-4" class="pilcrow">¶</a></p>
+points.  However, the "witnessed_by" claim is self-asserted by
+the ECT issuer: the listed witnesses do not co-sign the ECT and
+there is no cryptographic proof within a single ECT that the
+witnesses actually observed the task.  An issuing agent could
+list witnesses that did not participate.<a href="#section-10.2-4" class="pilcrow">¶</a></p>
+<div id="witness-attestation-model">
+<section id="section-10.2.1">
+          <h4 id="name-witness-attestation-model">
+<a href="#section-10.2.1" class="section-number selfRef">10.2.1. </a><a href="#name-witness-attestation-model" class="section-name selfRef">Witness Attestation Model</a>
+          </h4>
+<p id="section-10.2.1-1">To address the self-assertion limitation of the "witnessed_by"
+claim, witnesses <span class="bcp14">SHOULD</span> submit their own independent signed ECTs
+to the audit ledger attesting to the observed task.  A witness
+attestation ECT:<a href="#section-10.2.1-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-10.2.1-2.1">
+              <p id="section-10.2.1-2.1.1"><span class="bcp14">MUST</span> set "iss" to the witness's own workload identity.<a href="#section-10.2.1-2.1.1" class="pilcrow">¶</a></p>
+</li>
+            <li class="normal" id="section-10.2.1-2.2">
+              <p id="section-10.2.1-2.2.1"><span class="bcp14">MUST</span> set "exec_act" to "witness_attestation" (or a domain-
+specific equivalent).<a href="#section-10.2.1-2.2.1" class="pilcrow">¶</a></p>
+</li>
+            <li class="normal" id="section-10.2.1-2.3">
+              <p id="section-10.2.1-2.3.1"><span class="bcp14">MUST</span> include the observed task's "tid" in the "par" array,
+linking the attestation to the original task.<a href="#section-10.2.1-2.3.1" class="pilcrow">¶</a></p>
+</li>
+            <li class="normal" id="section-10.2.1-2.4">
+              <p id="section-10.2.1-2.4.1"><span class="bcp14">MUST</span> set "pol_decision" to "approved" to indicate the witness
+confirms the observation.<a href="#section-10.2.1-2.4.1" class="pilcrow">¶</a></p>
+</li>
+          </ul>
+<p id="section-10.2.1-3">When a task's "witnessed_by" claim lists one or more witnesses,
+auditors <span class="bcp14">SHOULD</span> verify that corresponding witness attestation
+ECTs exist in the ledger for each listed witness.  A mismatch
+between the "witnessed_by" list and the set of independent witness
+ECTs in the ledger <span class="bcp14">SHOULD</span> be flagged during audit review.<a href="#section-10.2.1-3" class="pilcrow">¶</a></p>
+<p id="section-10.2.1-4">This model converts witness attestation from a self-asserted claim
+to a cryptographically verifiable property of the ledger: the
+witness independently signs their own ECT using their own key,
+and the ledger records both the original task ECT and the witness
+attestation ECTs.<a href="#section-10.2.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
 </section>
 </div>
 <div id="organizational-prerequisites">
@@ -3264,9 +3356,11 @@ in a manner that preserves their integrity.<a href="#section-10.3-2.4.1" class="
 specified in the agent's WIT.  Receivers <span class="bcp14">MUST</span> verify the ECT
 signature against the WIT public key before processing any
 claims.  Receivers <span class="bcp14">MUST</span> verify that the signing key has not been
-revoked within the trust domain.<a href="#section-10.4-1" class="pilcrow">¶</a></p>
+revoked within the trust domain (see step 6 in
-<p id="section-10.4-2">If signature verification fails, the ECT <span class="bcp14">MUST</span> be rejected entirely
+<a href="#verification" class="auto internal xref">Section 7</a>).<a href="#section-10.4-1" class="pilcrow">¶</a></p>
-and the failure <span class="bcp14">MUST</span> be logged.<a href="#section-10.4-2" class="pilcrow">¶</a></p>
+<p id="section-10.4-2">If signature verification fails or if the signing key has been
+revoked, the ECT <span class="bcp14">MUST</span> be rejected entirely and the failure <span class="bcp14">MUST</span>
+be logged.<a href="#section-10.4-2" class="pilcrow">¶</a></p>
 <p id="section-10.4-3">Implementations <span class="bcp14">MUST</span> use established JWS libraries and <span class="bcp14">MUST NOT</span>
 implement custom signature verification.<a href="#section-10.4-3" class="pilcrow">¶</a></p>
 </section>
@@ -3402,9 +3496,14 @@ 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-10.10-1" class="pilcrow">¶</a></p>
-<p id="section-10.10-2">The temporal ordering check in DAG validation incorporates the
+<p id="section-10.10-2">Cross-organizational deployments where agents span multiple trust
+domains with independent time sources <span class="bcp14">MAY</span> require a higher clock
+skew tolerance.  Deployments using trust domain federation <span class="bcp14">SHOULD</span>
+document their configured clock skew tolerance value and <span class="bcp14">SHOULD</span>
+ensure all participating trust domains agree on a common tolerance.<a href="#section-10.10-2" class="pilcrow">¶</a></p>
+<p id="section-10.10-3">The temporal ordering check in DAG validation incorporates the
 clock skew tolerance to account for minor clock differences
-between agents.<a href="#section-10.10-2" class="pilcrow">¶</a></p>
+between agents.<a href="#section-10.10-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="ect-size-constraints">
@@ -3414,8 +3513,11 @@ between agents.<a href="#section-10.10-2" class="pilcrow">¶</a></p>
         </h3>
 <p id="section-10.11-1">ECTs with many parent tasks or large extension objects can
 increase HTTP header size.  Implementations <span class="bcp14">SHOULD</span> limit the "par"
-array to a reasonable size and <span class="bcp14">SHOULD</span> set maximum size limits for
+array to a maximum of 256 entries.  Workflows requiring more
-the "ext" object to prevent abuse.<a href="#section-10.11-1" class="pilcrow">¶</a></p>
+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.8</a>).<a href="#section-10.11-1" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -3474,6 +3576,15 @@ The "exec_act" claim <span class="bcp14">SHOULD</span> use structured identifier
 "process_payment") rather than natural language descriptions.
 The "pol" claim <span class="bcp14">SHOULD</span> reference policy identifiers rather than
 embedding policy content.<a href="#section-11.2-1" class="pilcrow">¶</a></p>
+<p id="section-11.2-2">The "compensation_reason" claim (<a href="#compensation-claims" class="auto internal xref">Section 4.2.7</a>)
+deserves particular attention: because it is human-readable and
+may describe the circumstances of a failure or policy violation,
+it risks exposing sensitive operational details.  Implementations
+<span class="bcp14">SHOULD</span> use short, structured reason codes (e.g.,
+"policy_violation_in_parent_trade") rather than free-form
+natural language explanations.  Implementers <span class="bcp14">SHOULD</span> review
+"compensation_reason" values for potential information leakage
+before deploying to production.<a href="#section-11.2-2" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="storage-and-access-control">