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

Make SPIFFE ID format recommended, not required for iss claim

Browse Source 
Allow any URI scheme for the iss claim (SPIFFE, HTTPS, URN:UUID)
to support non-WIMSE deployments that want DAG tracing without
SPIFFE infrastructure. SPIFFE format remains SHOULD for WIMSE
deployments.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Christian Nennemann
2026-02-24 23:27:34 +01:00
parent a6d2a955ee
commit d8d1524dac
4 changed files with 570 additions and 563 deletions
Download Patch File Download Diff File Expand all files Collapse all files

60
draft-nennemann-wimse-execution-context-00.txt
View File

@@ -427,8 +427,8 @@ Internet-Draft WIMSE Execution Context February 2026
* The ECT JOSE header "kid" parameter MUST reference the public key
identifier from the agent's WIT.
* The ECT "iss" claim MUST use the WIMSE workload identifier format
(a SPIFFE ID [SPIFFE]).
* In WIMSE deployments, the ECT "iss" claim SHOULD use the WIMSE
workload identifier format (a SPIFFE ID [SPIFFE]).
* The ECT MUST be signed with the same private key associated with
the agent's WIT.
@@ -519,10 +519,11 @@ Internet-Draft WIMSE Execution Context February 2026
The following standard JWT claims [RFC7519] MUST be present in every
ECT:
iss: REQUIRED. StringOrURI. The issuer of the ECT, which MUST be
the workload's SPIFFE ID in the format spiffe://<trust-
domain>/<path>. This MUST match the "sub" claim of the agent's
WIT.
iss: REQUIRED. StringOrURI. A URI identifying the issuer of the
ECT. In WIMSE deployments, this SHOULD be the workload's SPIFFE
ID in the format spiffe://<trust-domain>/<path>, matching the
"sub" claim of the agent's WIT. Non-WIMSE deployments MAY use
other URI schemes (e.g., HTTPS URLs or URN:UUID identifiers).
sub: OPTIONAL. StringOrURI. The subject of the ECT. When present,
MUST equal the "iss" claim. This claim is included for
@@ -551,9 +552,8 @@ Internet-Draft WIMSE Execution Context February 2026
"spiffe://example.com/system/ledger"]). Each verifier checks
that its own identity appears in the array.
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
@@ -562,6 +562,9 @@ Nennemann Expires 28 August 2026 [Page 10]
Internet-Draft WIMSE Execution Context February 2026
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.
@@ -604,10 +607,7 @@ Internet-Draft WIMSE Execution Context February 2026
collision with the "act" (Actor) claim registered by [RFC8693].
par: REQUIRED. Array of strings. Parent task identifiers
representing DAG dependencies. Each element MUST be the "jti"
value of a previously verified ECT. An empty array indicates a
root task with no dependencies. A workflow MAY contain multiple
root tasks.
@@ -618,6 +618,11 @@ Nennemann Expires 28 August 2026 [Page 11]
Internet-Draft WIMSE Execution Context February 2026
representing DAG dependencies. Each element MUST be the "jti"
value of a previously verified ECT. An empty array indicates a
root task with no dependencies. A workflow MAY contain multiple
root tasks.
4.2.3. Policy Evaluation
The following claims record policy evaluation outcomes:
@@ -661,11 +666,6 @@ Internet-Draft WIMSE Execution Context February 2026
evaluation outcomes. The mechanisms by which policies are defined,
distributed to agents, and evaluated are out of scope. The "pol"
claim is an opaque identifier referencing an external policy; the
semantics and enforcement of that policy are determined by the
deployment environment. Implementations may use any policy engine or
framework (e.g., OPA/Rego, Cedar, XACML, or custom solutions)
provided that the evaluation outcome is faithfully recorded in the
ECT claims defined above.
@@ -674,6 +674,12 @@ Nennemann Expires 28 August 2026 [Page 12]
Internet-Draft WIMSE Execution Context February 2026
semantics and enforcement of that policy are determined by the
deployment environment. Implementations may use any policy engine or
framework (e.g., OPA/Rego, Cedar, XACML, or custom solutions)
provided that the evaluation outcome is faithfully recorded in the
ECT claims defined above.
4.2.4. Data Integrity
The following claims provide integrity verification for task inputs
@@ -716,12 +722,6 @@ 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.
To avoid key collisions between different domains, extension key
names MUST use reverse domain notation (e.g.,
"com.example.custom_field"). Implementations MUST NOT use
@@ -730,6 +730,12 @@ Nennemann Expires 28 August 2026 [Page 13]
Internet-Draft WIMSE Execution Context February 2026
claims not defined by this specification. Implementations that do
not understand extension claims MUST ignore them.
To avoid key collisions between different domains, extension key
names MUST use reverse domain notation (e.g.,
"com.example.custom_field"). Implementations MUST NOT use
unqualified key names within the "ext" object. 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
@@ -775,12 +781,6 @@ Internet-Draft WIMSE Execution Context February 2026
Nennemann Expires 28 August 2026 [Page 14]
Internet-Draft WIMSE Execution Context February 2026