From 0a38226b3297922cf4c8944e5e87e27073e06e92 Mon Sep 17 00:00:00 2001 From: Christian Nennemann Date: Wed, 25 Feb 2026 13:13:00 +0100 Subject: [PATCH] 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 --- ...-nennemann-wimse-execution-context-00.html | 11 +- draft-nennemann-wimse-execution-context-00.md | 14 +- ...t-nennemann-wimse-execution-context-00.txt | 62 +- ...t-nennemann-wimse-execution-context-00.xml | 1096 +++++++++-------- 4 files changed, 597 insertions(+), 586 deletions(-) diff --git a/draft-nennemann-wimse-execution-context-00.html b/draft-nennemann-wimse-execution-context-00.html index dc05a10..b4834d7 100644 --- a/draft-nennemann-wimse-execution-context-00.html +++ b/draft-nennemann-wimse-execution-context-00.html @@ -2294,9 +2294,12 @@ parent reference in the ECT store.¶<
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 (Section 4.2.3) and +operational metadata; deployments MAY also include +domain-specific keys. Implementations MUST ignore extension +keys they do not recognize.

@@ -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 (Section 4.2.2) +correlation point. The "ext" claim in ECTs (Section 4.2.6) can carry SCITT-specific metadata such as Transparency Service identifiers or Receipt references for tighter integration.

diff --git a/draft-nennemann-wimse-execution-context-00.md b/draft-nennemann-wimse-execution-context-00.md index 92f290d..5aba041 100644 --- a/draft-nennemann-wimse-execution-context-00.md +++ b/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 - 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. diff --git a/draft-nennemann-wimse-execution-context-00.txt b/draft-nennemann-wimse-execution-context-00.txt index 04dd1d5..9696647 100644 --- a/draft-nennemann-wimse-execution-context-00.txt +++ b/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 - 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. diff --git a/draft-nennemann-wimse-execution-context-00.xml b/draft-nennemann-wimse-execution-context-00.xml index e7f3bdd..39818bd 100644 --- a/draft-nennemann-wimse-execution-context-00.xml +++ b/draft-nennemann-wimse-execution-context-00.xml @@ -32,7 +32,7 @@ - + This document defines Execution Context Tokens (ECTs), an extension to the Workload Identity in Multi System Environments (WIMSE) @@ -65,7 +65,7 @@ regulatory frameworks. - +
Introduction @@ -611,9 +611,12 @@ parent reference in the ECT store.
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 () and +operational metadata; deployments MAY also include +domain-specific keys. Implementations MUST ignore extension +keys they do not recognize.
@@ -1759,6 +1762,23 @@ policy is Specification Required per . + + + Guidelines for Writing an IANA Considerations Section in RFCs + + + + + + Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). + To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. + This is the third edition of this document; it obsoletes RFC 5226. + + + + + + Universally Unique IDentifiers (UUIDs) @@ -1893,23 +1913,6 @@ been incorporated into this document. This document obsoletes RFC - - - Guidelines for Writing an IANA Considerations Section in RFCs - - - - - - Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). - To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. - This is the third edition of this document; it obsoletes RFC 5226. - - - - - - @@ -2151,7 +2154,7 @@ been incorporated into this document. This document obsoletes RFC - +
Related Work @@ -2268,7 +2271,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 () +correlation point. The "ext" claim in ECTs () can carry SCITT-specific metadata such as Transparency Service identifiers or Receipt references for tighter integration. @@ -2635,528 +2638,529 @@ tracing is built.