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>
This commit is contained in:
@@ -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
|
||||
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.6-1.2.1" class="pilcrow">¶</a></p>
|
||||
<p id="section-4.2.6-1.2.1"><span class="bcp14">OPTIONAL</span>. Object. An extension object for claims beyond the
|
||||
core registered claims. This specification defines several
|
||||
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>
|
||||
|
||||
@@ -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
|
||||
claims not defined by this specification. Implementations
|
||||
that do not understand extension claims MUST ignore them.
|
||||
: OPTIONAL. Object. An extension object for claims beyond the
|
||||
core registered claims. This specification defines several
|
||||
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.
|
||||
|
||||
|
||||
@@ -711,17 +711,17 @@ Internet-Draft WIMSE Execution Context February 2026
|
||||
|
||||
4.2.6. Extensions
|
||||
|
||||
ext: OPTIONAL. Object. An extension object for domain-specific
|
||||
claims not defined by this specification. Implementations that do
|
||||
not understand extension claims MUST ignore them.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
ext: OPTIONAL. Object. An extension object for claims beyond the
|
||||
core registered claims. This specification defines several
|
||||
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.
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user