Make SPIFFE ID format recommended, not required for iss claim

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>

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

@@ -1933,8 +1933,8 @@ following mechanisms:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
 key identifier from the agent's WIT.<a href="#section-3.3-2.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-3.3-2.2">
-            <p id="section-3.3-2.2.1">The ECT "iss" claim <span class="bcp14">MUST</span> use the WIMSE workload identifier
+            <p id="section-3.3-2.2.1">In WIMSE deployments, the ECT "iss" claim <span class="bcp14">SHOULD</span> use the WIMSE
-format (a SPIFFE ID <span>[<a href="#SPIFFE" class="cite xref">SPIFFE</a>]</span>).<a href="#section-3.3-2.2.1" class="pilcrow">¶</a></p>
+workload identifier format (a SPIFFE ID <span>[<a href="#SPIFFE" class="cite xref">SPIFFE</a>]</span>).<a href="#section-3.3-2.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-3.3-2.3">
             <p id="section-3.3-2.3.1">The ECT <span class="bcp14">MUST</span> be signed with the same private key associated
@@ -2059,10 +2059,12 @@ every ECT:<a href="#section-4.2.1-1" class="pilcrow">¶</a></p>
 <span class="break"></span><dl class="dlParallel" id="section-4.2.1-2">
             <dt id="section-4.2.1-2.1">iss:</dt>
             <dd style="margin-left: 1.5em" id="section-4.2.1-2.2">
-              <p id="section-4.2.1-2.2.1"><span class="bcp14">REQUIRED</span>.  StringOrURI.  The issuer of the ECT, which <span class="bcp14">MUST</span> be
+              <p id="section-4.2.1-2.2.1"><span class="bcp14">REQUIRED</span>.  StringOrURI.  A URI identifying the issuer of the
-the workload's SPIFFE ID in the format
+ECT.  In WIMSE deployments, this <span class="bcp14">SHOULD</span> be the workload's
-<code>spiffe://&lt;trust-domain&gt;/&lt;path&gt;</code>.  This <span class="bcp14">MUST</span> match the "sub"
+SPIFFE ID in the format <code>spiffe://&lt;trust-domain&gt;/&lt;path&gt;</code>,
-claim of the agent's WIT.<a href="#section-4.2.1-2.2.1" class="pilcrow">¶</a></p>
+matching the "sub" claim of the agent's WIT.  Non-WIMSE
+deployments <span class="bcp14">MAY</span> use other URI schemes (e.g., HTTPS URLs or
+URN:UUID identifiers).<a href="#section-4.2.1-2.2.1" class="pilcrow">¶</a></p>
 </dd>
             <dd class="break"></dd>
 <dt id="section-4.2.1-2.3">sub:</dt>

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

@@ -310,8 +310,8 @@ following mechanisms:
 - 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
+- In WIMSE deployments, the ECT "iss" claim SHOULD use the WIMSE
-  format (a SPIFFE ID {{SPIFFE}}).
+  workload identifier format (a SPIFFE ID {{SPIFFE}}).
 
 - The ECT MUST be signed with the same private key associated
   with the agent's WIT.
@@ -395,10 +395,12 @@ The following standard JWT claims {{RFC7519}} MUST be present in
 every ECT:
 
 iss:
-: REQUIRED.  StringOrURI.  The issuer of the ECT, which MUST be
+: REQUIRED.  StringOrURI.  A URI identifying the issuer of the
-  the workload's SPIFFE ID in the format
+  ECT.  In WIMSE deployments, this SHOULD be the workload's
-  `spiffe://<trust-domain>/<path>`.  This MUST match the "sub"
+  SPIFFE ID in the format `spiffe://<trust-domain>/<path>`,
-  claim of the agent's WIT.
+  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,

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

@@ -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
+   *  In WIMSE deployments, the ECT "iss" claim SHOULD use the WIMSE
-      (a SPIFFE ID [SPIFFE]).
+      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
+   iss:  REQUIRED.  StringOrURI.  A URI identifying the issuer of the
-      the workload's SPIFFE ID in the format spiffe://<trust-
+      ECT.  In WIMSE deployments, this SHOULD be the workload's SPIFFE
-      domain>/<path>.  This MUST match the "sub" claim of the agent's
+      ID in the format spiffe://<trust-domain>/<path>, matching the
-      WIT.
+      "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