Add RFC 8126 to normative references

RFC 8126 (IANA Considerations guidelines) was used inline
but missing from the normative references list.

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

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

@@ -2294,9 +2294,12 @@ parent reference in the ECT store.<a href="#section-4.2.5-1" class="pilcrow">¶<
 <span class="break"></span><dl class="dlParallel" id="section-4.2.6-1">
             <dt id="section-4.2.6-1.1">ext:</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>.  Object.  An extension object for domain-specific
+              <p id="section-4.2.6-1.2.1"><span class="bcp14">OPTIONAL</span>.  Object.  An extension object for claims beyond the
-claims not defined by this specification.  Implementations
+core registered claims.  This specification defines several
-that do not understand extension claims <span class="bcp14">MUST</span> ignore them.<a href="#section-4.2.6-1.2.1" class="pilcrow">¶</a></p>
+extension keys for policy evaluation (<a href="#policy-claims" class="auto internal xref">Section 4.2.3</a>) and
+operational metadata; deployments <span class="bcp14">MAY</span> also include
+domain-specific keys.  Implementations <span class="bcp14">MUST</span> ignore extension
+keys they do not recognize.<a href="#section-4.2.6-1.2.1" class="pilcrow">¶</a></p>
 </dd>
           <dd class="break"></dd>
 </dl>
@@ -4004,7 +4007,7 @@ registered as a SCITT Signed Statement on a Transparency Service.
 This enables auditors to verify both the individual execution
 steps (via ECT DAG validation) and the end-to-end supply chain
 integrity (via SCITT Receipts) using the "wid" as the shared
-correlation point.  The "ext" claim in ECTs (<a href="#exec-claims" class="auto internal xref">Section 4.2.2</a>)
+correlation point.  The "ext" claim in ECTs (<a href="#extension-claims" class="auto internal xref">Section 4.2.6</a>)
 can carry SCITT-specific metadata such as Transparency Service
 identifiers or Receipt references for tighter integration.<a href="#appendix-A.6-1" class="pilcrow">¶</a></p>
 </section>

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

@@ -28,6 +28,7 @@ normative:
   RFC7517:
   RFC7519:
   RFC7518:
+  RFC8126:
   RFC9562:
   RFC9110:
   I-D.ietf-wimse-arch:
@@ -573,9 +574,12 @@ parent reference in the ECT store.
 ### Extensions {#extension-claims}
 
 ext:
-: OPTIONAL.  Object.  An extension object for domain-specific
+: OPTIONAL.  Object.  An extension object for claims beyond the
-  claims not defined by this specification.  Implementations
+  core registered claims.  This specification defines several
-  that do not understand extension claims MUST ignore them.
+  extension keys for policy evaluation ({{policy-claims}}) and
+  operational metadata; deployments MAY also include
+  domain-specific keys.  Implementations MUST ignore extension
+  keys they do not recognize.
 
 To avoid key collisions between different domains, extension
 key names SHOULD use reverse domain notation (e.g.,
@@ -1543,7 +1547,7 @@ require separate JWT Claims registration.
 
 This document establishes the "ECT Policy Decision Values"
 registry under the "JSON Web Token (JWT)" group.  Registration
-policy is Specification Required per {{!RFC8126}}.
+policy is Specification Required per {{RFC8126}}.
 
 The initial contents of the registry are:
 
@@ -1671,7 +1675,7 @@ registered as a SCITT Signed Statement on a Transparency Service.
 This enables auditors to verify both the individual execution
 steps (via ECT DAG validation) and the end-to-end supply chain
 integrity (via SCITT Receipts) using the "wid" as the shared
-correlation point.  The "ext" claim in ECTs ({{exec-claims}})
+correlation point.  The "ext" claim in ECTs ({{extension-claims}})
 can carry SCITT-specific metadata such as Transparency Service
 identifiers or Receipt references for tighter integration.
 

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

@@ -711,17 +711,17 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
 4.2.6.  Extensions
 
-   ext:  OPTIONAL.  Object.  An extension object for domain-specific
+   ext:  OPTIONAL.  Object.  An extension object for claims beyond the
-      claims not defined by this specification.  Implementations that do
+      core registered claims.  This specification defines several
-      not understand extension claims MUST ignore them.
+      extension keys for policy evaluation (Section 4.2.3) and
-
+      operational metadata; deployments MAY also include domain-specific
-
+      keys.  Implementations MUST ignore extension keys they do not
-
+      recognize.
-
-
-
-
 
+   To avoid key collisions between different domains, extension key
+   names SHOULD use reverse domain notation (e.g.,
+   "com.example.custom_field") to avoid collisions between independently
+   developed extensions.  To prevent abuse and excessive token size, the
 
 
 
@@ -730,10 +730,6 @@ Nennemann                Expires 29 August 2026                [Page 13]
 Internet-Draft           WIMSE Execution Context           February 2026
 
 
-   To avoid key collisions between different domains, extension key
-   names SHOULD use reverse domain notation (e.g.,
-   "com.example.custom_field") to avoid collisions between independently
-   developed extensions.  To prevent abuse and excessive token size, the
    serialized JSON representation of the "ext" object SHOULD NOT exceed
    4096 bytes, and the JSON nesting depth within the "ext" object SHOULD
    NOT exceed 5 levels.  Implementations SHOULD reject ECTs whose "ext"
@@ -776,6 +772,10 @@ Internet-Draft           WIMSE Execution Context           February 2026
    *  "compensation_required": Boolean.  Indicates whether this task is
       a compensation or rollback action.
 
+   *  "compensation_reason": String.  Structured reason code for the
+      compensation action (e.g., "policy_violation_in_parent_trade").
+      SHOULD use structured identifiers rather than free-form text to
+      minimize information leakage (see Section 11.2).
 
 
 
@@ -786,11 +786,6 @@ Nennemann                Expires 29 August 2026                [Page 14]
 Internet-Draft           WIMSE Execution Context           February 2026
 
 
-   *  "compensation_reason": String.  Structured reason code for the
-      compensation action (e.g., "policy_violation_in_parent_trade").
-      SHOULD use structured identifiers rather than free-form text to
-      minimize information leakage (see Section 11.2).
-
 4.3.  Complete ECT Example
 
    The following is a complete ECT payload example:
@@ -833,6 +828,11 @@ Internet-Draft           WIMSE Execution Context           February 2026
    [RFC7515].  The value consists of three Base64url-encoded parts
    separated by period (".") characters.
 
+   An agent sending a request to another agent includes the Execution-
+   Context header alongside the WIMSE Workload-Identity header:
+
+
+
 
 
 
@@ -842,9 +842,6 @@ Nennemann                Expires 29 August 2026                [Page 15]
 Internet-Draft           WIMSE Execution Context           February 2026
 
 
-   An agent sending a request to another agent includes the Execution-
-   Context header alongside the WIMSE Workload-Identity header:
-
    GET /api/safety-check HTTP/1.1
    Host: safety-agent.example.com
    Workload-Identity: eyJhbGci...WIT...
@@ -886,8 +883,11 @@ Internet-Draft           WIMSE Execution Context           February 2026
        ECT store if "wid" is absent).  If an ECT with the same "jti"
        already exists, the ECT MUST be rejected.
 
-
+   2.  Parent Existence: Every task identifier listed in the "par" array
-
+       MUST correspond to a task that is available in the ECT store
+       (either previously recorded in the ledger or received inline as a
+       verified parent ECT).  If any parent task is not found, the ECT
+       MUST be rejected.
 
 
 
@@ -898,12 +898,6 @@ Nennemann                Expires 29 August 2026                [Page 16]
 Internet-Draft           WIMSE Execution Context           February 2026
 
 
-   2.  Parent Existence: Every task identifier listed in the "par" array
-       MUST correspond to a task that is available in the ECT store
-       (either previously recorded in the ledger or received inline as a
-       verified parent ECT).  If any parent task is not found, the ECT
-       MUST be rejected.
-
    3.  Temporal Ordering: The "iat" value of every parent task MUST NOT
        be greater than the "iat" value of the current task plus a
        configurable clock skew tolerance (RECOMMENDED: 30 seconds).
@@ -948,6 +942,12 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
 
 
+
+
+
+
+
+
 
 Nennemann                Expires 29 August 2026                [Page 17]
 
@@ -2270,7 +2270,7 @@ SCITT (Supply Chain Integrity, Transparency, and Trust)
    both the individual execution steps (via ECT DAG validation) and the
    end-to-end supply chain integrity (via SCITT Receipts) using the
    "wid" as the shared correlation point.  The "ext" claim in ECTs
-   (Section 4.2.2) can carry SCITT-specific metadata such as
+   (Section 4.2.6) can carry SCITT-specific metadata such as
    Transparency Service identifiers or Receipt references for tighter
    integration.