@@ -1683,7 +1689,7 @@ addresses the gap between workload identity and execution
accountability. WIMSE authenticates agents; this extension records
what they did, in what order, and what policy was evaluated.¶
As identified in [I-D.ni-wimse-ai-agent-identity], call context
-in agentic workflows must always be visible and preserved. ECTs
+in agentic workflows needs to be visible and preserved. ECTs
provide a mechanism to address this requirement with cryptographic
assurances.¶
@@ -2088,14 +2094,45 @@ claim of the agent's WIT.¶sub:
OPTIONAL. StringOrURI. The subject of the ECT. When present,
-MUST equal the "iss" claim.¶
+MUST equal the "iss" claim. This claim is included for
+compatibility with JWT libraries and frameworks that expect a
+"sub" claim to be present.¶
aud:
REQUIRED. StringOrURI or array of StringOrURI. The intended
-recipient(s) of the ECT. Typically the next agent in the
-workflow or the ledger endpoint.¶
+recipient(s) of the ECT. Because ECTs serve as both inter-agent
+messages and audit records, the "aud" claim SHOULD contain the
+identifiers of all entities that will verify the ECT. In
+practice this means:¶
+
+
+
Point-to-point delivery: when an ECT is sent from one
+agent to a single next agent, "aud" contains that agent's
+workload identity. The receiving agent verifies the ECT and
+forwards it to the ledger on behalf of the issuer.¶
+
+
+
Direct-to-ledger submission: when an ECT is submitted
+directly to the audit ledger (e.g., after a join or at
+workflow completion), "aud" contains the ledger's identity.¶
+
+
+
Multi-audience: when an ECT must be verified by both the
+next agent and the ledger independently, "aud" MUST be an
+array containing both identifiers (e.g.,
+["spiffe://example.com/agent/next",
+"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 according to the rules above based on where the ECT will
+be delivered — it is independent of the "aud" values in the
+parent ECTs.¶
iat:
@@ -2112,11 +2149,19 @@ Implementations SHOULD set this to 5 to 15 minutes af
to limit the replay window while allowing for reasonable clock
skew and processing time.¶
-
-
jti:
-
-
OPTIONAL. String. A unique identifier for the ECT, useful for
-additional replay detection.¶
+
+
+
The standard JWT "nbf" (Not Before) claim is not used in ECTs
+because ECTs record completed actions and are valid immediately
+upon issuance.¶
+
+
jti:
+
+
REQUIRED. String. A unique identifier for the ECT in UUID
+format [RFC9562]. Used for replay detection: receivers MUST
+reject ECTs whose "jti" has already been seen within the
+expiration window. The "jti" value MUST be unique across all
+ECTs issued by the same agent.¶
@@ -2185,7 +2230,30 @@ evaluated for this task (e.g.,
pol_decision:
REQUIRED. String. The result of the policy evaluation. MUST
-be one of: "approved", "rejected", or "pending_human_review".¶
+be one of the values registered in the ECT Policy Decision
+Values registry (Section 12.4). Initial values
+are:¶
+
+
+
"approved": The policy evaluation succeeded and the task
+was authorized to proceed.¶
+
+
+
"rejected": The policy evaluation failed. A "rejected" ECT
+MUST still be appended to the audit ledger for accountability.
+An ECT with "pol_decision" of "rejected" MAY appear as a
+parent in the "par" array of a subsequent ECT, but only for
+compensation, rollback, or remediation tasks. Agents MUST NOT proceed with normal workflow execution based on a parent
+ECT whose "pol_decision" is "rejected".¶
+
+
+
"pending_human_review": The policy evaluation requires human
+judgment before proceeding. Agents MUST NOT proceed with
+dependent tasks until a subsequent ECT from a human reviewer
+records an "approved" decision referencing this task as a
+parent.¶
OPTIONAL. Object. An extension object for domain-specific
claims not defined by this specification. Implementations
-that do not understand extension claims SHOULD ignore them.
-To avoid key collisions between different domains, extension
-key names SHOULD use reverse domain notation (e.g.,
-"com.example.custom_field").¶
+that do not understand extension claims MUST ignore them.¶
-
The "ext" claim is a generic extension mechanism; it is not
-registered in the IANA JWT Claims registry because its semantics
-depend on the domain-specific claims within it.¶
+
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.¶
When a receiver processes multiple Execution-Context headers, it
+MUST individually verify each ECT per the procedure in
+Section 7. If any single ECT fails verification, the
+receiver MUST reject the entire request. The set of verified
+parent task IDs across all received ECTs represents the complete
+set of parent dependencies available for the receiving agent's
+subsequent ECT.¶
@@ -2462,11 +2542,15 @@ recorded in the ledger. If any parent task is not found, the
ECT MUST be rejected.¶
-
Temporal Ordering: The "iat" value of every parent task MUST be
-less than the "iat" value of the current task plus a
+
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).
-If any parent task has an "iat" that violates this constraint,
-the ECT MUST be rejected.¶
+That is, for each parent: parent.iat < child.iat +
+clock_skew_tolerance. The tolerance accounts for clock skew
+between agents; it does not guarantee strict causal ordering
+from timestamps alone. Causal ordering is primarily enforced
+by the DAG structure (parent existence in the ledger), not by
+timestamps. If any parent task violates this constraint, the
+ECT MUST be rejected.¶
Acyclicity: Following the chain of parent references MUST NOT
@@ -2474,9 +2558,18 @@ lead back to the current task's "tid". If a cycle is detected,
the ECT MUST be rejected.¶
-
Trust Domain Consistency: Parent tasks SHOULD belong to the
+
Parent Policy Decision: If any parent task has a "pol_decision"
+of "rejected" or "pending_human_review", the current task's
+"exec_act" MUST indicate a compensation, rollback, remediation,
+or human review action. Implementations MUST NOT accept an ECT
+representing normal workflow continuation when a parent's
+"pol_decision" is not "approved", unless the current ECT has
+"compensation_required" set to true.¶
+
+
+
Trust Domain Consistency: Parent tasks SHOULD belong to the
same trust domain or to a trust domain with which a federation
-relationship has been established.¶
+identity. When "aud" is an array, it is sufficient that the
+verifier's identity appears as one element; the presence of
+other audience values does not cause verification failure.
+When the verifier is the audit ledger, the ledger's own
+identity MUST appear in "aud".¶
Verify the "exp" claim indicates the ECT has not expired.¶
@@ -2592,8 +2689,8 @@ identity or an expected recipient identifier.¶
-
Verify all required claims ("tid", "exec_act", "par", "pol",
-"pol_decision") are present and well-formed.¶
+
Verify all required claims ("jti", "tid", "exec_act", "par",
+"pol", "pol_decision") are present and well-formed.¶
Verify "pol_decision" is one of "approved", "rejected", or
@@ -2611,6 +2708,14 @@ ledger.¶
failure MUST be logged for audit purposes. Error messages
SHOULD NOT reveal whether specific parent task IDs exist in the
ledger, to prevent information disclosure.¶
+
When ECT verification fails during HTTP request processing, the
+receiving agent SHOULD respond with HTTP 403 (Forbidden) if the
+WIT and WPT are valid but the ECT is invalid, and HTTP 401
+(Unauthorized) if the ECT signature verification fails. The
+response body SHOULD include a generic error indicator without
+revealing which specific verification step failed. The receiving
+agent MUST NOT process the requested action when ECT verification
+fails.¶
@@ -2666,7 +2771,7 @@ function verify_ect(ect_jws, verifier_id,
return reject("ECT issued too long ago")
// Verify required claims
- for claim in ["tid", "exec_act", "par",
+ for claim in ["jti", "tid", "exec_act", "par",
"pol", "pol_decision"]:
if claim not in payload:
return reject("Missing required claim: " + claim)
@@ -2790,8 +2895,8 @@ examples demonstrate ECT mechanics; production deployments would
include additional domain-specific requirements beyond the scope
of this specification.¶
Note: task identifiers in this section are abbreviated for
-readability. In production, all "tid" values MUST be UUIDs per
-[RFC9562].¶
+readability. In production, all "tid" values are required to be
+UUIDs per Section 4.2.2.¶
@@ -2981,9 +3086,9 @@ a cryptographic link to the original task:
In a logistics workflow, multiple compliance checks must complete
+
In a logistics workflow, multiple compliance checks complete
before shipment commitment. The DAG structure records that all
required checks were completed:¶
Implementations SHOULD maintain a cache of recently-seen "jti"
-values (when present) to detect replayed ECTs within the
-expiration window.¶
+
Implementations MUST maintain a cache of recently-seen "jti"
+values to detect replayed ECTs within the expiration window.
+An ECT with a duplicate "jti" value MUST be rejected.¶
@@ -3678,6 +3783,120 @@ the "JSON Web Token Claims" registry maintained by IANA:IETF
This document establishes the "ECT Policy Decision Values"
+registry under the "JSON Web Token (JWT)" group. Registration
+policy is Specification Required per [RFC8126].¶
This document establishes the "ECT Regulated Domain Values"
+registry under the "JSON Web Token (JWT)" group. Registration
+policy is Specification Required per [RFC8126].¶
+Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/rfc/rfc8126>.
+
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, , <https://www.rfc-editor.org/rfc/rfc8693>.
Implementations should use established JWT/JWS libraries (JOSE)
-for token creation and verification. Custom cryptographic
-implementations should not be used. Implementations should be
-tested against multiple JWT libraries to ensure interoperability.¶
+
Implementations are expected to use established JWT/JWS libraries
+(JOSE) for token creation and verification. Custom cryptographic
+implementations are strongly discouraged. Implementations are
+expected to be tested against multiple JWT libraries to ensure
+interoperability.¶
@@ -4012,9 +4233,9 @@ compliance with various regulatory frameworks. ECTs are a
technical building block; achieving compliance requires
additional organizational measures beyond this specification.¶
diff --git a/draft-nennemann-wimse-execution-context-00.md b/draft-nennemann-wimse-execution-context-00.md
index 2ce0549..5f54b70 100644
--- a/draft-nennemann-wimse-execution-context-00.md
+++ b/draft-nennemann-wimse-execution-context-00.md
@@ -8,6 +8,7 @@ number:
date:
v: 3
area: "Security"
+workgroup: "WIMSE"
keyword:
- execution context
- workload identity
@@ -23,9 +24,8 @@ author:
email: ietf@nennemann.de
normative:
- RFC2119:
- RFC8174:
RFC7515:
+ RFC7517:
RFC7519:
RFC7518:
RFC9562:
@@ -35,7 +35,6 @@ normative:
informative:
RFC3552:
- RFC7517:
RFC8693:
RFC9421:
I-D.ni-wimse-ai-agent-identity:
@@ -150,7 +149,7 @@ accountability. WIMSE authenticates agents; this extension records
what they did, in what order, and what policy was evaluated.
As identified in {{I-D.ni-wimse-ai-agent-identity}}, call context
-in agentic workflows must always be visible and preserved. ECTs
+in agentic workflows needs to be visible and preserved. ECTs
provide a mechanism to address this requirement with cryptographic
assurances.
@@ -409,12 +408,39 @@ iss:
sub:
: OPTIONAL. StringOrURI. The subject of the ECT. When present,
- MUST equal the "iss" claim.
+ MUST equal the "iss" claim. This claim is included for
+ compatibility with JWT libraries and frameworks that expect a
+ "sub" claim to be present.
aud:
: REQUIRED. StringOrURI or array of StringOrURI. The intended
- recipient(s) of the ECT. Typically the next agent in the
- workflow or the ledger endpoint.
+ recipient(s) of the ECT. Because ECTs serve as both inter-agent
+ messages and audit records, the "aud" claim SHOULD contain the
+ identifiers of all entities that will verify the ECT. In
+ practice this means:
+
+ * **Point-to-point delivery**: when an ECT is sent from one
+ agent to a single next agent, "aud" contains that agent's
+ workload identity. The receiving agent verifies the ECT and
+ forwards it to the ledger on behalf of the issuer.
+
+ * **Direct-to-ledger submission**: when an ECT is submitted
+ directly to the audit ledger (e.g., after a join or at
+ workflow completion), "aud" contains the ledger's identity.
+
+ * **Multi-audience**: when an ECT must be verified by both the
+ next agent and the ledger independently, "aud" MUST be an
+ array containing both identifiers (e.g.,
+ \["spiffe://example.com/agent/next",
+ "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 according to the rules above based on where the ECT will
+ be delivered — it is independent of the "aud" values in the
+ parent ECTs.
iat:
: REQUIRED. NumericDate. The time at which the ECT was issued.
@@ -427,9 +453,16 @@ exp:
to limit the replay window while allowing for reasonable clock
skew and processing time.
+The standard JWT "nbf" (Not Before) claim is not used in ECTs
+because ECTs record completed actions and are valid immediately
+upon issuance.
+
jti:
-: OPTIONAL. String. A unique identifier for the ECT, useful for
- additional replay detection.
+: REQUIRED. String. A unique identifier for the ECT in UUID
+ format {{RFC9562}}. Used for replay detection: receivers MUST
+ reject ECTs whose "jti" has already been seen within the
+ expiration window. The "jti" value MUST be unique across all
+ ECTs issued by the same agent.
### Execution Context Claims {#exec-claims}
@@ -474,7 +507,26 @@ pol:
pol_decision:
: REQUIRED. String. The result of the policy evaluation. MUST
- be one of: "approved", "rejected", or "pending_human_review".
+ be one of the values registered in the ECT Policy Decision
+ Values registry ({{pol-decision-registry}}). Initial values
+ are:
+
+ * "approved": The policy evaluation succeeded and the task
+ was authorized to proceed.
+
+ * "rejected": The policy evaluation failed. A "rejected" ECT
+ MUST still be appended to the audit ledger for accountability.
+ An ECT with "pol_decision" of "rejected" MAY appear as a
+ parent in the "par" array of a subsequent ECT, but only for
+ compensation, rollback, or remediation tasks. Agents MUST
+ NOT proceed with normal workflow execution based on a parent
+ ECT whose "pol_decision" is "rejected".
+
+ * "pending_human_review": The policy evaluation requires human
+ judgment before proceeding. Agents MUST NOT proceed with
+ dependent tasks until a subsequent ECT from a human reviewer
+ records an "approved" decision referencing this task as a
+ parent.
pol_enforcer:
: OPTIONAL. StringOrURI. The identity of the entity (system or
@@ -495,12 +547,17 @@ inp_hash:
: OPTIONAL. String. A cryptographic hash of the input data,
formatted as "hash-algorithm:base64url-encoded-hash" (e.g.,
"sha-256:n4bQgYhMfWWaL-qgxVrQFaO\_TxsrC4Is0V1sFbDwCgg"). The
- hash algorithm identifier SHOULD be "sha-256". The hash MUST be
+ hash algorithm identifier MUST be a lowercase value from the
+ IANA Named Information Hash Algorithm Registry (e.g., "sha-256",
+ "sha-384", "sha-512"). Implementations MUST support "sha-256"
+ and SHOULD use "sha-256" unless a stronger algorithm is
+ required. Implementations MUST NOT accept hash algorithms
+ weaker than SHA-256 (e.g., MD5, SHA-1). The hash MUST be
computed over the raw octets of the input data.
out_hash:
: OPTIONAL. String. A cryptographic hash of the output data,
- using the same format as "inp_hash".
+ using the same format and algorithm requirements as "inp_hash".
inp_classification:
: OPTIONAL. String. The data sensitivity classification of the
@@ -516,8 +573,8 @@ exec_time_ms:
regulated_domain:
: OPTIONAL. String. The regulatory domain applicable to this
- task. Values are drawn from an extensible set; initial values
- include "medtech", "finance", and "military".
+ task. Values MUST be registered in the ECT Regulated Domain
+ Values registry ({{regulated-domain-registry}}).
model_version:
: OPTIONAL. String. The version identifier of the AI or ML model
@@ -527,11 +584,17 @@ model_version:
witnessed_by:
: OPTIONAL. Array of StringOrURI. Identifiers of third-party
- entities that observed or attested to the execution of this
- task. When present, each element SHOULD use SPIFFE ID format.
- In regulated environments, implementations SHOULD use witness
- attestation for critical decision points to mitigate the risk
- of single-agent false claims.
+ entities that the issuing agent claims observed or attested to
+ the execution of this task. When present, each element SHOULD
+ use SPIFFE ID format. Note that this claim is self-asserted by
+ the ECT issuer; witnesses listed here do not co-sign this ECT.
+ For stronger assurance, witnesses SHOULD submit independent
+ signed ECTs to the ledger attesting to their observation (see
+ {{witness-attestation-model}}). In regulated environments,
+ implementations SHOULD use witness attestation for critical
+ decision points to mitigate the risk of single-agent false
+ claims. See also {{self-assertion-limitation}} for the security
+ implications of self-asserted witness claims.
### Compensation Claims {#compensation-claims}
@@ -542,6 +605,12 @@ compensation_required:
compensation_reason:
: OPTIONAL. String. A human-readable reason for the compensation
action. MUST be present if "compensation_required" is true.
+ Values SHOULD use structured identifiers (e.g.,
+ "policy_violation_in_parent_trade") rather than free-form text
+ to minimize the risk of embedding sensitive information. See
+ {{data-minimization}} for privacy guidance.
+ If "compensation_reason" is present, "compensation_required"
+ MUST be true.
Note: compensation ECTs reference historical parent tasks via the
"par" claim. The referenced parent ECTs may have passed their own
@@ -554,14 +623,17 @@ ledger.
ext:
: OPTIONAL. Object. An extension object for domain-specific
claims not defined by this specification. Implementations
- that do not understand extension claims SHOULD ignore them.
- To avoid key collisions between different domains, extension
- key names SHOULD use reverse domain notation (e.g.,
- "com.example.custom_field").
+ that do not understand extension claims MUST ignore them.
-The "ext" claim is a generic extension mechanism; it is not
-registered in the IANA JWT Claims registry because its semantics
-depend on the domain-specific claims within it.
+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 within the "ext" object
+SHOULD NOT exceed 5 levels. Implementations SHOULD reject
+ECTs whose "ext" claim exceeds these limits.
## Complete ECT Example
@@ -574,6 +646,7 @@ The following is a complete ECT payload example:
"aud": "spiffe://example.com/agent/safety",
"iat": 1772064150,
"exp": 1772064750,
+ "jti": "7f3a8b2c-d1e4-4f56-9a0b-c3d4e5f6a7b8",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"tid": "550e8400-e29b-41d4-a716-446655440001",
@@ -627,6 +700,14 @@ When multiple parent tasks contribute context to a single request,
multiple Execution-Context header field lines MAY be included, each
carrying a separate ECT in JWS Compact Serialization format.
+When a receiver processes multiple Execution-Context headers, it
+MUST individually verify each ECT per the procedure in
+{{verification}}. If any single ECT fails verification, the
+receiver MUST reject the entire request. The set of verified
+parent task IDs across all received ECTs represents the complete
+set of parent dependencies available for the receiving agent's
+subsequent ECT.
+
# DAG Validation {#dag-validation}
## Overview
@@ -653,17 +734,30 @@ the following DAG validation steps:
recorded in the ledger. If any parent task is not found, the
ECT MUST be rejected.
-3. Temporal Ordering: The "iat" value of every parent task MUST be
- less than the "iat" value of the current task plus a
+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).
- If any parent task has an "iat" that violates this constraint,
- the ECT MUST be rejected.
+ That is, for each parent: `parent.iat < child.iat +
+ clock_skew_tolerance`. The tolerance accounts for clock skew
+ between agents; it does not guarantee strict causal ordering
+ from timestamps alone. Causal ordering is primarily enforced
+ by the DAG structure (parent existence in the ledger), not by
+ timestamps. If any parent task violates this constraint, the
+ ECT MUST be rejected.
4. Acyclicity: Following the chain of parent references MUST NOT
lead back to the current task's "tid". If a cycle is detected,
the ECT MUST be rejected.
-5. Trust Domain Consistency: Parent tasks SHOULD belong to the
+5. Parent Policy Decision: If any parent task has a "pol_decision"
+ of "rejected" or "pending_human_review", the current task's
+ "exec_act" MUST indicate a compensation, rollback, remediation,
+ or human review action. Implementations MUST NOT accept an ECT
+ representing normal workflow continuation when a parent's
+ "pol_decision" is not "approved", unless the current ECT has
+ "compensation_required" set to true.
+
+6. Trust Domain Consistency: Parent tasks SHOULD belong to the
same trust domain or to a trust domain with which a federation
relationship has been established.
@@ -685,14 +779,19 @@ function validate_dag(ect, ledger, clock_skew_tolerance):
if parent.iat >= ect.iat + clock_skew_tolerance:
return error("Parent task not earlier than current")
- // Step 3: Cycle detection
+ // Step 3: Cycle detection (with traversal limit)
visited = set()
- if has_cycle(ect.tid, ect.par, ledger, visited):
- return error("Circular dependency detected")
+ result = has_cycle(ect.tid, ect.par, ledger, visited,
+ max_ancestor_limit)
+ if result is error or result is true:
+ return error("Circular dependency or depth limit exceeded")
return success
-function has_cycle(target_tid, parent_ids, ledger, visited):
+function has_cycle(target_tid, parent_ids, ledger, visited,
+ max_depth):
+ if visited.size() >= max_depth:
+ return error("Maximum ancestor traversal limit exceeded")
for parent_id in parent_ids:
if parent_id == target_tid:
return true
@@ -701,8 +800,10 @@ function has_cycle(target_tid, parent_ids, ledger, visited):
visited.add(parent_id)
parent = ledger.get(parent_id)
if parent is not null:
- if has_cycle(target_tid, parent.par, ledger, visited):
- return true
+ result = has_cycle(target_tid, parent.par, ledger,
+ visited, max_depth)
+ if result is error or result is true:
+ return result
return false
~~~
{: #fig-dag-validation title="DAG Validation Pseudocode"}
@@ -711,7 +812,11 @@ The cycle detection traverses the ancestor graph rooted at the
current task's parents. The complexity is O(V) where V is the
number of ancestor nodes reachable from the current task's parent
references. For typical workflows with shallow DAGs, this is
-efficient. Implementations SHOULD cache cycle detection results
+efficient. To prevent denial-of-service via extremely deep or
+wide DAGs, implementations SHOULD enforce a maximum ancestor
+traversal limit (RECOMMENDED: 10000 nodes). If the limit is
+reached before cycle detection completes, the ECT SHOULD be
+rejected. Implementations SHOULD cache cycle detection results
for previously verified tasks to avoid redundant traversals.
# Signature and Token Verification {#verification}
@@ -735,30 +840,42 @@ verification steps in order:
5. Retrieve the public key identified by "kid" and verify the JWS
signature per {{RFC7515}} Section 5.2.
-6. Verify the "alg" header parameter matches the algorithm in the
+6. Verify that the signing key identified by "kid" has not been
+ revoked within the trust domain. Implementations MUST check
+ the key's revocation status using the trust domain's key
+ lifecycle mechanism (e.g., certificate revocation list, OCSP,
+ or SPIFFE trust bundle updates).
+
+7. Verify the "alg" header parameter matches the algorithm in the
corresponding WIT.
-7. Verify the "iss" claim matches the "sub" claim of the WIT
+8. Verify the "iss" claim matches the "sub" claim of the WIT
associated with the "kid" public key.
-8. Verify the "aud" claim contains the verifier's own workload
- identity or an expected recipient identifier.
+9. Verify the "aud" claim contains the verifier's own workload
+ identity. When "aud" is an array, it is sufficient that the
+ verifier's identity appears as one element; the presence of
+ other audience values does not cause verification failure.
+ When the verifier is the audit ledger, the ledger's own
+ identity MUST appear in "aud".
-9. Verify the "exp" claim indicates the ECT has not expired.
+10. Verify the "exp" claim indicates the ECT has not expired.
-10. Verify the "iat" claim is not unreasonably far in the past
+11. Verify the "iat" claim is not unreasonably far in the past
(implementation-specific threshold, RECOMMENDED maximum of
- 15 minutes).
+ 15 minutes) and is not unreasonably far in the future
+ (RECOMMENDED: no more than 30 seconds ahead of the
+ verifier's current time, to account for clock skew).
-11. Verify all required claims ("tid", "exec_act", "par", "pol",
- "pol_decision") are present and well-formed.
+12. Verify all required claims ("jti", "tid", "exec_act", "par",
+ "pol", "pol_decision") are present and well-formed.
-12. Verify "pol_decision" is one of "approved", "rejected", or
+13. Verify "pol_decision" is one of "approved", "rejected", or
"pending_human_review".
-13. Perform DAG validation per {{dag-validation}}.
+14. Perform DAG validation per {{dag-validation}}.
-14. If all checks pass, the ECT MUST be appended to the audit
+15. If all checks pass, the ECT MUST be appended to the audit
ledger.
If any verification step fails, the ECT MUST be rejected and the
@@ -766,6 +883,15 @@ failure MUST be logged for audit purposes. Error messages
SHOULD NOT reveal whether specific parent task IDs exist in the
ledger, to prevent information disclosure.
+When ECT verification fails during HTTP request processing, the
+receiving agent SHOULD respond with HTTP 403 (Forbidden) if the
+WIT and WPT are valid but the ECT is invalid, and HTTP 401
+(Unauthorized) if the ECT signature verification fails. The
+response body SHOULD include a generic error indicator without
+revealing which specific verification step failed. The receiving
+agent MUST NOT process the requested action when ECT verification
+fails.
+
## Verification Pseudocode
~~~ pseudocode
@@ -791,6 +917,10 @@ function verify_ect(ect_jws, verifier_id,
signature, public_key):
return reject("Invalid signature")
+ // Verify key not revoked
+ if is_key_revoked(header.kid, trust_domain_keys):
+ return reject("Signing key has been revoked")
+
// Verify algorithm alignment
wit = get_wit_for_key(header.kid)
if header.alg != wit.alg:
@@ -808,12 +938,14 @@ function verify_ect(ect_jws, verifier_id,
if payload.exp < current_time():
return reject("ECT has expired")
- // Verify iat freshness
+ // Verify iat freshness (not too old, not in the future)
if payload.iat < current_time() - max_age_threshold:
return reject("ECT issued too long ago")
+ if payload.iat > current_time() + clock_skew_tolerance:
+ return reject("ECT issued in the future")
// Verify required claims
- for claim in ["tid", "exec_act", "par",
+ for claim in ["jti", "tid", "exec_act", "par",
"pol", "pol_decision"]:
if claim not in payload:
return reject("Missing required claim: " + claim)
@@ -890,7 +1022,10 @@ The "ect_jws" field contains the full JWS Compact Serialization
and is the authoritative record. The other fields ("agent_id",
"action", "parents") are convenience indexes derived from the
ECT payload; if they disagree with the JWS payload, the JWS
-payload takes precedence.
+payload takes precedence. Implementations SHOULD validate that
+convenience index fields match the corresponding values in the
+JWS payload at write time to prevent desynchronization between
+the authoritative JWS and the indexed fields.
# Use Cases {#use-cases}
@@ -901,8 +1036,8 @@ include additional domain-specific requirements beyond the scope
of this specification.
Note: task identifiers in this section are abbreviated for
-readability. In production, all "tid" values MUST be UUIDs per
-{{RFC9562}}.
+readability. In production, all "tid" values are required to be
+UUIDs per {{exec-claims}}.
## Medical Device SDLC Workflow
@@ -1059,7 +1194,7 @@ violation discovery to remediation.
## Autonomous Logistics Coordination
-In a logistics workflow, multiple compliance checks must complete
+In a logistics workflow, multiple compliance checks complete
before shipment commitment. The DAG structure records that all
required checks were completed:
@@ -1113,7 +1248,7 @@ The following threat actors are considered:
- Time manipulator: An entity attempting to manipulate timestamps
to alter perceived execution ordering.
-## Self-Assertion Limitation
+## Self-Assertion Limitation {#self-assertion-limitation}
ECTs are self-asserted by the executing agent. The agent claims
what it did, and this claim is signed with its private key. A
@@ -1132,7 +1267,38 @@ The trustworthiness of ECT claims depends on the trustworthiness
of the signing agent. To mitigate single-agent false claims,
regulated environments SHOULD use the "witnessed_by" mechanism
to include independent third-party observers at critical decision
-points.
+points. However, the "witnessed_by" claim is self-asserted by
+the ECT issuer: the listed witnesses do not co-sign the ECT and
+there is no cryptographic proof within a single ECT that the
+witnesses actually observed the task. An issuing agent could
+list witnesses that did not participate.
+
+### Witness Attestation Model {#witness-attestation-model}
+
+To address the self-assertion limitation of the "witnessed_by"
+claim, witnesses SHOULD submit their own independent signed ECTs
+to the audit ledger attesting to the observed task. A witness
+attestation ECT:
+
+- MUST set "iss" to the witness's own workload identity.
+- MUST set "exec_act" to "witness_attestation" (or a domain-
+ specific equivalent).
+- MUST include the observed task's "tid" in the "par" array,
+ linking the attestation to the original task.
+- MUST set "pol_decision" to "approved" to indicate the witness
+ confirms the observation.
+
+When a task's "witnessed_by" claim lists one or more witnesses,
+auditors SHOULD verify that corresponding witness attestation
+ECTs exist in the ledger for each listed witness. A mismatch
+between the "witnessed_by" list and the set of independent witness
+ECTs in the ledger SHOULD be flagged during audit review.
+
+This model converts witness attestation from a self-asserted claim
+to a cryptographically verifiable property of the ledger: the
+witness independently signs their own ECT using their own key,
+and the ledger records both the original task ECT and the witness
+attestation ECTs.
## Organizational Prerequisites
@@ -1156,10 +1322,12 @@ ECTs MUST be signed with the agent's private key using JWS
specified in the agent's WIT. Receivers MUST verify the ECT
signature against the WIT public key before processing any
claims. Receivers MUST verify that the signing key has not been
-revoked within the trust domain.
+revoked within the trust domain (see step 6 in
+{{verification}}).
-If signature verification fails, the ECT MUST be rejected entirely
-and the failure MUST be logged.
+If signature verification fails or if the signing key has been
+revoked, the ECT MUST be rejected entirely and the failure MUST
+be logged.
Implementations MUST use established JWS libraries and MUST NOT
implement custom signature verification.
@@ -1176,9 +1344,9 @@ The DAG structure provides additional replay protection: an ECT
referencing parent tasks that already have a recorded child task
with the same action can be flagged as a potential replay.
-Implementations SHOULD maintain a cache of recently-seen "jti"
-values (when present) to detect replayed ECTs within the
-expiration window.
+Implementations MUST maintain a cache of recently-seen "jti"
+values to detect replayed ECTs within the expiration window.
+An ECT with a duplicate "jti" value MUST be rejected.
## Man-in-the-Middle Protection
@@ -1254,6 +1422,12 @@ judgments. Implementations SHOULD use synchronized time sources
(e.g., NTP) and SHOULD allow a configurable clock skew tolerance
(RECOMMENDED: 30 seconds).
+Cross-organizational deployments where agents span multiple trust
+domains with independent time sources MAY require a higher clock
+skew tolerance. Deployments using trust domain federation SHOULD
+document their configured clock skew tolerance value and SHOULD
+ensure all participating trust domains agree on a common tolerance.
+
The temporal ordering check in DAG validation incorporates the
clock skew tolerance to account for minor clock differences
between agents.
@@ -1262,8 +1436,11 @@ between agents.
ECTs with many parent tasks or large extension objects can
increase HTTP header size. Implementations SHOULD limit the "par"
-array to a reasonable size and SHOULD set maximum size limits for
-the "ext" object to prevent abuse.
+array to a maximum of 256 entries. Workflows requiring more
+parent references SHOULD introduce intermediate aggregation
+tasks. The "ext" object SHOULD NOT exceed 4096 bytes when
+serialized as JSON and SHOULD NOT exceed a nesting depth of
+5 levels (see also {{extension-claims}}).
# Privacy Considerations
@@ -1285,7 +1462,7 @@ ECTs are designed to NOT reveal:
- Proprietary algorithms or intellectual property
- Personally identifiable information (PII)
-## Data Minimization
+## Data Minimization {#data-minimization}
Implementations SHOULD minimize the information included in ECTs.
The "exec_act" claim SHOULD use structured identifiers (e.g.,
@@ -1293,6 +1470,16 @@ The "exec_act" claim SHOULD use structured identifiers (e.g.,
The "pol" claim SHOULD reference policy identifiers rather than
embedding policy content.
+The "compensation_reason" claim ({{compensation-claims}})
+deserves particular attention: because it is human-readable and
+may describe the circumstances of a failure or policy violation,
+it risks exposing sensitive operational details. Implementations
+SHOULD use short, structured reason codes (e.g.,
+"policy_violation_in_parent_trade") rather than free-form
+natural language explanations. Implementers SHOULD review
+"compensation_reason" values for potential information leakage
+before deploying to production.
+
## Storage and Access Control
ECTs stored in audit ledgers SHOULD be access-controlled so that
@@ -1408,8 +1595,39 @@ the "JSON Web Token Claims" registry maintained by IANA:
| model_version | AI/ML Model Version | IETF | {{operational-claims}} |
| compensation_required | Compensation Flag | IETF | {{compensation-claims}} |
| compensation_reason | Compensation Reason | IETF | {{compensation-claims}} |
+| ext | Extension Object | IETF | {{extension-claims}} |
{: #table-claims title="JWT Claims Registrations"}
+## ECT Policy Decision Values Registry {#pol-decision-registry}
+
+This document establishes the "ECT Policy Decision Values"
+registry under the "JSON Web Token (JWT)" group. Registration
+policy is Specification Required per {{!RFC8126}}.
+
+The initial contents of the registry are:
+
+| Value | Description | Change Controller | Reference |
+|:---:|:---|:---:|:---:|
+| approved | Policy evaluation succeeded | IETF | {{policy-claims}} |
+| rejected | Policy evaluation failed | IETF | {{policy-claims}} |
+| pending_human_review | Awaiting human judgment | IETF | {{policy-claims}} |
+{: #table-pol-decision title="ECT Policy Decision Values"}
+
+## ECT Regulated Domain Values Registry {#regulated-domain-registry}
+
+This document establishes the "ECT Regulated Domain Values"
+registry under the "JSON Web Token (JWT)" group. Registration
+policy is Specification Required per {{!RFC8126}}.
+
+The initial contents of the registry are:
+
+| Value | Description | Change Controller | Reference |
+|:---:|:---|:---:|:---:|
+| medtech | Medical technology and devices | IETF | {{operational-claims}} |
+| finance | Financial services and trading | IETF | {{operational-claims}} |
+| military | Military and defense | IETF | {{operational-claims}} |
+{: #table-regulated-domain title="ECT Regulated Domain Values"}
+
--- back
# Related Work
@@ -1499,10 +1717,11 @@ use cases are distinct.
## Minimal Implementation
{:numbered="false"}
-A minimal conforming implementation should:
+A minimal conforming implementation needs to:
1. Create JWTs with all required claims ("iss", "aud", "iat",
- "exp", "tid", "exec_act", "par", "pol", "pol_decision").
+ "exp", "jti", "tid", "exec_act", "par", "pol",
+ "pol_decision").
2. Sign ECTs with the agent's private key using an algorithm
matching the WIT (ES256 recommended).
3. Verify ECT signatures against WIT public keys.
@@ -1536,10 +1755,11 @@ A minimal conforming implementation should:
## Interoperability
{:numbered="false"}
-Implementations should use established JWT/JWS libraries (JOSE)
-for token creation and verification. Custom cryptographic
-implementations should not be used. Implementations should be
-tested against multiple JWT libraries to ensure interoperability.
+Implementations are expected to use established JWT/JWS libraries
+(JOSE) for token creation and verification. Custom cryptographic
+implementations are strongly discouraged. Implementations are
+expected to be tested against multiple JWT libraries to ensure
+interoperability.
# Regulatory Compliance Mapping
{:numbered="false"}
diff --git a/draft-nennemann-wimse-execution-context-00.txt b/draft-nennemann-wimse-execution-context-00.txt
index d6d52f6..d4a5926 100644
--- a/draft-nennemann-wimse-execution-context-00.txt
+++ b/draft-nennemann-wimse-execution-context-00.txt
@@ -2,7 +2,7 @@
-Network Working Group C. Nennemann
+WIMSE C. Nennemann
Internet-Draft Independent Researcher
Intended status: Standards Track 24 February 2026
Expires: 28 August 2026
@@ -88,24 +88,24 @@ Table of Contents
4.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. WIMSE-Compatible Claims . . . . . . . . . . . . . . . 10
- 4.2.2. Execution Context Claims . . . . . . . . . . . . . . 10
- 4.2.3. Policy Claims . . . . . . . . . . . . . . . . . . . . 11
- 4.2.4. Data Integrity Claims . . . . . . . . . . . . . . . . 11
- 4.2.5. Operational Claims . . . . . . . . . . . . . . . . . 12
- 4.2.6. Witness Claims . . . . . . . . . . . . . . . . . . . 12
- 4.2.7. Compensation Claims . . . . . . . . . . . . . . . . . 12
- 4.2.8. Extension Claims . . . . . . . . . . . . . . . . . . 12
- 4.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 13
- 5. HTTP Header Transport . . . . . . . . . . . . . . . . . . . . 13
- 5.1. Execution-Context Header Field . . . . . . . . . . . . . 13
- 6. DAG Validation . . . . . . . . . . . . . . . . . . . . . . . 14
- 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14
- 6.2. Validation Rules . . . . . . . . . . . . . . . . . . . . 14
- 6.3. DAG Validation Algorithm . . . . . . . . . . . . . . . . 15
- 7. Signature and Token Verification . . . . . . . . . . . . . . 16
- 7.1. Verification Procedure . . . . . . . . . . . . . . . . . 16
- 7.2. Verification Pseudocode . . . . . . . . . . . . . . . . . 17
- 8. Audit Ledger Interface . . . . . . . . . . . . . . . . . . . 19
+ 4.2.2. Execution Context Claims . . . . . . . . . . . . . . 11
+ 4.2.3. Policy Claims . . . . . . . . . . . . . . . . . . . . 12
+ 4.2.4. Data Integrity Claims . . . . . . . . . . . . . . . . 12
+ 4.2.5. Operational Claims . . . . . . . . . . . . . . . . . 13
+ 4.2.6. Witness Claims . . . . . . . . . . . . . . . . . . . 13
+ 4.2.7. Compensation Claims . . . . . . . . . . . . . . . . . 14
+ 4.2.8. Extension Claims . . . . . . . . . . . . . . . . . . 14
+ 4.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 14
+ 5. HTTP Header Transport . . . . . . . . . . . . . . . . . . . . 15
+ 5.1. Execution-Context Header Field . . . . . . . . . . . . . 15
+ 6. DAG Validation . . . . . . . . . . . . . . . . . . . . . . . 16
+ 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 6.2. Validation Rules . . . . . . . . . . . . . . . . . . . . 16
+ 6.3. DAG Validation Algorithm . . . . . . . . . . . . . . . . 17
+ 7. Signature and Token Verification . . . . . . . . . . . . . . 19
+ 7.1. Verification Procedure . . . . . . . . . . . . . . . . . 19
+ 7.2. Verification Pseudocode . . . . . . . . . . . . . . . . . 20
+ 8. Audit Ledger Interface . . . . . . . . . . . . . . . . . . . 22
@@ -114,54 +114,54 @@ Nennemann Expires 28 August 2026 [Page 2]
Internet-Draft WIMSE Execution Context February 2026
- 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 19
- 8.2. Required Properties . . . . . . . . . . . . . . . . . . . 19
- 8.3. Ledger Entry Structure . . . . . . . . . . . . . . . . . 20
- 9. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 20
- 9.1. Medical Device SDLC Workflow . . . . . . . . . . . . . . 20
- 9.1.1. FDA Audit with DAG Reconstruction . . . . . . . . . . 21
- 9.2. Financial Trading Workflow . . . . . . . . . . . . . . . 22
- 9.3. Compensation and Rollback . . . . . . . . . . . . . . . . 23
- 9.4. Autonomous Logistics Coordination . . . . . . . . . . . . 24
- 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
- 10.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 25
- 10.2. Self-Assertion Limitation . . . . . . . . . . . . . . . 26
- 10.3. Organizational Prerequisites . . . . . . . . . . . . . . 26
- 10.4. Signature Verification . . . . . . . . . . . . . . . . . 27
- 10.5. Replay Attack Prevention . . . . . . . . . . . . . . . . 27
- 10.6. Man-in-the-Middle Protection . . . . . . . . . . . . . . 27
- 10.7. Key Compromise . . . . . . . . . . . . . . . . . . . . . 28
- 10.8. Collusion and False Claims . . . . . . . . . . . . . . . 28
- 10.9. Denial of Service . . . . . . . . . . . . . . . . . . . 29
- 10.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 29
- 10.11. ECT Size Constraints . . . . . . . . . . . . . . . . . . 29
- 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29
- 11.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . 29
- 11.2. Data Minimization . . . . . . . . . . . . . . . . . . . 30
- 11.3. Storage and Access Control . . . . . . . . . . . . . . . 30
- 11.4. Regulatory Access . . . . . . . . . . . . . . . . . . . 30
- 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
- 12.1. Media Type Registration . . . . . . . . . . . . . . . . 30
- 12.2. HTTP Header Field Registration . . . . . . . . . . . . . 31
- 12.3. JWT Claims Registration . . . . . . . . . . . . . . . . 31
- 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
- 13.1. Normative References . . . . . . . . . . . . . . . . . . 33
- 13.2. Informative References . . . . . . . . . . . . . . . . . 34
- Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 35
- WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 36
- OAuth 2.0 Token Exchange . . . . . . . . . . . . . . . . . . . 36
- Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 36
- Blockchain and Distributed Ledgers . . . . . . . . . . . . . . 36
- SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 37
- W3C Verifiable Credentials . . . . . . . . . . . . . . . . . . 37
- Implementation Guidance . . . . . . . . . . . . . . . . . . . . . 37
- Minimal Implementation . . . . . . . . . . . . . . . . . . . . 37
- Storage Recommendations . . . . . . . . . . . . . . . . . . . . 38
- Performance Considerations . . . . . . . . . . . . . . . . . . 38
- Interoperability . . . . . . . . . . . . . . . . . . . . . . . 38
- Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . . 38
- Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
- Example 1: Simple Two-Agent Workflow . . . . . . . . . . . . . 39
+ 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 8.2. Required Properties . . . . . . . . . . . . . . . . . . . 22
+ 8.3. Ledger Entry Structure . . . . . . . . . . . . . . . . . 22
+ 9. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 9.1. Medical Device SDLC Workflow . . . . . . . . . . . . . . 23
+ 9.1.1. FDA Audit with DAG Reconstruction . . . . . . . . . . 24
+ 9.2. Financial Trading Workflow . . . . . . . . . . . . . . . 25
+ 9.3. Compensation and Rollback . . . . . . . . . . . . . . . . 26
+ 9.4. Autonomous Logistics Coordination . . . . . . . . . . . . 27
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
+ 10.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 28
+ 10.2. Self-Assertion Limitation . . . . . . . . . . . . . . . 29
+ 10.2.1. Witness Attestation Model . . . . . . . . . . . . . 29
+ 10.3. Organizational Prerequisites . . . . . . . . . . . . . . 30
+ 10.4. Signature Verification . . . . . . . . . . . . . . . . . 30
+ 10.5. Replay Attack Prevention . . . . . . . . . . . . . . . . 31
+ 10.6. Man-in-the-Middle Protection . . . . . . . . . . . . . . 31
+ 10.7. Key Compromise . . . . . . . . . . . . . . . . . . . . . 31
+ 10.8. Collusion and False Claims . . . . . . . . . . . . . . . 32
+ 10.9. Denial of Service . . . . . . . . . . . . . . . . . . . 32
+ 10.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 33
+ 10.11. ECT Size Constraints . . . . . . . . . . . . . . . . . . 33
+ 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33
+ 11.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . 33
+ 11.2. Data Minimization . . . . . . . . . . . . . . . . . . . 34
+ 11.3. Storage and Access Control . . . . . . . . . . . . . . . 34
+ 11.4. Regulatory Access . . . . . . . . . . . . . . . . . . . 34
+ 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
+ 12.1. Media Type Registration . . . . . . . . . . . . . . . . 34
+ 12.2. HTTP Header Field Registration . . . . . . . . . . . . . 35
+ 12.3. JWT Claims Registration . . . . . . . . . . . . . . . . 36
+ 12.4. ECT Policy Decision Values Registry . . . . . . . . . . 37
+ 12.5. ECT Regulated Domain Values Registry . . . . . . . . . . 38
+ 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
+ 13.1. Normative References . . . . . . . . . . . . . . . . . . 38
+ 13.2. Informative References . . . . . . . . . . . . . . . . . 39
+ Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 41
+ WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 41
+ OAuth 2.0 Token Exchange . . . . . . . . . . . . . . . . . . . 41
+ Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 41
+ Blockchain and Distributed Ledgers . . . . . . . . . . . . . . 42
+ SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 42
+ W3C Verifiable Credentials . . . . . . . . . . . . . . . . . . 42
+ Implementation Guidance . . . . . . . . . . . . . . . . . . . . . 42
+ Minimal Implementation . . . . . . . . . . . . . . . . . . . . 42
+ Storage Recommendations . . . . . . . . . . . . . . . . . . . . 43
+ Performance Considerations . . . . . . . . . . . . . . . . . . 43
+ Interoperability . . . . . . . . . . . . . . . . . . . . . . . 43
@@ -170,10 +170,13 @@ Nennemann Expires 28 August 2026 [Page 3]
Internet-Draft WIMSE Execution Context February 2026
- Example 2: Medical Device SDLC with Release Approval . . . . . 40
- Example 3: Parallel Execution with Join . . . . . . . . . . . . 43
- Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44
+ Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . . 43
+ Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
+ Example 1: Simple Two-Agent Workflow . . . . . . . . . . . . . 44
+ Example 2: Medical Device SDLC with Release Approval . . . . . 45
+ Example 3: Parallel Execution with Join . . . . . . . . . . . . 48
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction
@@ -214,10 +217,7 @@ Internet-Draft WIMSE Execution Context February 2026
requires financial entities to have logging policies that record
ICT activities and anomalies.
- This document defines an extension to the WIMSE architecture that
- addresses the gap between workload identity and execution
- accountability. WIMSE authenticates agents; this extension records
- what they did, in what order, and what policy was evaluated.
+
@@ -226,10 +226,14 @@ Nennemann Expires 28 August 2026 [Page 4]
Internet-Draft WIMSE Execution Context February 2026
+ This document defines an extension to the WIMSE architecture that
+ addresses the gap between workload identity and execution
+ accountability. WIMSE authenticates agents; this extension records
+ what they did, in what order, and what policy was evaluated.
+
As identified in [I-D.ni-wimse-ai-agent-identity], call context in
- agentic workflows must always be visible and preserved. ECTs provide
- a mechanism to address this requirement with cryptographic
- assurances.
+ agentic workflows needs to be visible and preserved. ECTs provide a
+ mechanism to address this requirement with cryptographic assurances.
1.2. Problem Statement
@@ -270,10 +274,6 @@ Internet-Draft WIMSE Execution Context February 2026
The following are out of scope and are handled by WIMSE:
- * Workload authentication and identity provisioning
-
- * Key distribution and management
-
@@ -282,6 +282,10 @@ Nennemann Expires 28 August 2026 [Page 5]
Internet-Draft WIMSE Execution Context February 2026
+ * Workload authentication and identity provisioning
+
+ * Key distribution and management
+
* Trust domain establishment and management
* Credential lifecycle management
@@ -326,10 +330,6 @@ Internet-Draft WIMSE Execution Context February 2026
Directed Acyclic Graph (DAG): A graph structure representing task
dependency ordering where edges are directed and no cycles exist.
- Execution Context Token (ECT): A JSON Web Token [RFC7519] defined by
- this specification that records task execution details and policy
- evaluation outcomes.
-
@@ -338,6 +338,10 @@ Nennemann Expires 28 August 2026 [Page 6]
Internet-Draft WIMSE Execution Context February 2026
+ Execution Context Token (ECT): A JSON Web Token [RFC7519] defined by
+ this specification that records task execution details and policy
+ evaluation outcomes.
+
Audit Ledger: An append-only, immutable log of all ECTs within a
workflow or set of workflows, used for regulatory audit and
compliance verification.
@@ -383,10 +387,6 @@ Internet-Draft WIMSE Execution Context February 2026
* Maintaining structured execution records
- * Linking compensation or rollback actions to original tasks
-
-
-
Nennemann Expires 28 August 2026 [Page 7]
@@ -394,6 +394,8 @@ Nennemann Expires 28 August 2026 [Page 7]
Internet-Draft WIMSE Execution Context February 2026
+ * Linking compensation or rollback actions to original tasks
+
3.2. Extension Model
ECTs extend WIMSE by adding an execution accountability layer between
@@ -443,8 +445,6 @@ Internet-Draft WIMSE Execution Context February 2026
-
-
Nennemann Expires 28 August 2026 [Page 8]
Internet-Draft WIMSE Execution Context February 2026
@@ -526,11 +526,48 @@ Internet-Draft WIMSE Execution Context February 2026
WIT.
sub: OPTIONAL. StringOrURI. The subject of the ECT. When present,
- MUST equal the "iss" claim.
+ MUST equal the "iss" claim. This claim is included for
+ compatibility with JWT libraries and frameworks that expect a
+ "sub" claim to be present.
aud: REQUIRED. StringOrURI or array of StringOrURI. The intended
- recipient(s) of the ECT. Typically the next agent in the workflow
- or the ledger endpoint.
+ recipient(s) of the ECT. Because ECTs serve as both inter-agent
+ messages and audit records, the "aud" claim SHOULD contain the
+ identifiers of all entities that will verify the ECT. In practice
+ this means:
+
+ * *Point-to-point delivery*: when an ECT is sent from one agent
+ to a single next agent, "aud" contains that agent's workload
+ identity. The receiving agent verifies the ECT and forwards it
+ to the ledger on behalf of the issuer.
+
+ * *Direct-to-ledger submission*: when an ECT is submitted
+ directly to the audit ledger (e.g., after a join or at workflow
+ completion), "aud" contains the ledger's identity.
+
+ * *Multi-audience*: when an ECT must be verified by both the next
+ agent and the ledger independently, "aud" MUST be an array
+ containing both identifiers (e.g.,
+ ["spiffe://example.com/agent/next",
+ "spiffe://example.com/system/ledger"]). Each verifier checks
+ that its own identity appears in the array.
+
+
+
+
+
+
+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.
iat: REQUIRED. NumericDate. The time at which the ECT was issued.
The ECT records a completed action, so the "iat" value reflects
@@ -541,8 +578,15 @@ Internet-Draft WIMSE Execution Context February 2026
limit the replay window while allowing for reasonable clock skew
and processing time.
- jti: OPTIONAL. String. A unique identifier for the ECT, useful for
- additional replay detection.
+ The standard JWT "nbf" (Not Before) claim is not used in ECTs because
+ ECTs record completed actions and are valid immediately upon
+ issuance.
+
+ jti: REQUIRED. String. A unique identifier for the ECT in UUID
+ format [RFC9562]. Used for replay detection: receivers MUST
+ reject ECTs whose "jti" has already been seen within the
+ expiration window. The "jti" value MUST be unique across all ECTs
+ issued by the same agent.
4.2.2. Execution Context Claims
@@ -554,14 +598,6 @@ Internet-Draft WIMSE Execution Context February 2026
globally across the entire ledger.
tid: REQUIRED. String. A globally unique task identifier in UUID
-
-
-
-Nennemann Expires 28 August 2026 [Page 10]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
format [RFC9562]. Each task MUST have a unique "tid" value. When
"wid" is present, uniqueness is scoped to the workflow; when "wid"
is absent, uniqueness MUST be enforced globally across the ledger.
@@ -573,6 +609,15 @@ Internet-Draft WIMSE Execution Context February 2026
collision with the "act" (Actor) claim registered by [RFC8693].
par: REQUIRED. Array of strings. Parent task identifiers
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 11]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
representing DAG dependencies. Each element MUST be a valid "tid"
from a previously executed task. An empty array indicates a root
task with no dependencies. A workflow MAY contain multiple root
@@ -586,8 +631,26 @@ Internet-Draft WIMSE Execution Context February 2026
evaluated for this task (e.g., "clinical_data_access_policy_v1").
pol_decision: REQUIRED. String. The result of the policy
- evaluation. MUST be one of: "approved", "rejected", or
- "pending_human_review".
+ evaluation. MUST be one of the values registered in the ECT
+ Policy Decision Values registry (Section 12.4). Initial values
+ are:
+
+ * "approved": The policy evaluation succeeded and the task was
+ authorized to proceed.
+
+ * "rejected": The policy evaluation failed. A "rejected" ECT
+ MUST still be appended to the audit ledger for accountability.
+ An ECT with "pol_decision" of "rejected" MAY appear as a parent
+ in the "par" array of a subsequent ECT, but only for
+ compensation, rollback, or remediation tasks. Agents MUST NOT
+ proceed with normal workflow execution based on a parent ECT
+ whose "pol_decision" is "rejected".
+
+ * "pending_human_review": The policy evaluation requires human
+ judgment before proceeding. Agents MUST NOT proceed with
+ dependent tasks until a subsequent ECT from a human reviewer
+ records an "approved" decision referencing this task as a
+ parent.
pol_enforcer: OPTIONAL. StringOrURI. The identity of the entity
(system or person) that evaluated the policy decision. When
@@ -603,21 +666,28 @@ Internet-Draft WIMSE Execution Context February 2026
and outputs without revealing the data itself:
inp_hash: OPTIONAL. String. A cryptographic hash of the input
- data, formatted as "hash-algorithm:base64url-encoded-hash" (e.g.,
- "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The hash
- algorithm identifier SHOULD be "sha-256". The hash MUST be
- computed over the raw octets of the input data.
-
- out_hash: OPTIONAL. String. A cryptographic hash of the output
- data, using the same format as "inp_hash".
-Nennemann Expires 28 August 2026 [Page 11]
+Nennemann Expires 28 August 2026 [Page 12]
Internet-Draft WIMSE Execution Context February 2026
+ data, formatted as "hash-algorithm:base64url-encoded-hash" (e.g.,
+ "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The hash
+ algorithm identifier MUST be a lowercase value from the IANA Named
+ Information Hash Algorithm Registry (e.g., "sha-256", "sha-384",
+ "sha-512"). Implementations MUST support "sha-256" and SHOULD use
+ "sha-256" unless a stronger algorithm is required.
+ Implementations MUST NOT accept hash algorithms weaker than
+ SHA-256 (e.g., MD5, SHA-1). The hash MUST be computed over the
+ raw octets of the input data.
+
+ out_hash: OPTIONAL. String. A cryptographic hash of the output
+ data, using the same format and algorithm requirements as
+ "inp_hash".
+
inp_classification: OPTIONAL. String. The data sensitivity
classification of the input (e.g., "public", "confidential",
"restricted").
@@ -630,8 +700,8 @@ Internet-Draft WIMSE Execution Context February 2026
task in milliseconds. MUST be a non-negative integer.
regulated_domain: OPTIONAL. String. The regulatory domain
- applicable to this task. Values are drawn from an extensible set;
- initial values include "medtech", "finance", and "military".
+ applicable to this task. Values MUST be registered in the ECT
+ Regulated Domain Values registry (Section 12.5).
model_version: OPTIONAL. String. The version identifier of the AI
or ML model used to perform the task, if applicable.
@@ -639,11 +709,26 @@ Internet-Draft WIMSE Execution Context February 2026
4.2.6. Witness Claims
witnessed_by: OPTIONAL. Array of StringOrURI. Identifiers of
- third-party entities that observed or attested to the execution of
- this task. When present, each element SHOULD use SPIFFE ID
- format. In regulated environments, implementations SHOULD use
- witness attestation for critical decision points to mitigate the
- risk of single-agent false claims.
+ third-party entities that the issuing agent claims observed or
+ attested to the execution of this task. When present, each
+ element SHOULD use SPIFFE ID format. Note that this claim is
+ self-asserted by the ECT issuer; witnesses listed here do not co-
+ sign this ECT. For stronger assurance, witnesses SHOULD submit
+ independent signed ECTs to the ledger attesting to their
+ observation (see Section 10.2.1). In regulated environments,
+ implementations SHOULD use witness attestation for critical
+ decision points to mitigate the risk of single-agent false claims.
+ See also Section 10.2 for the security implications of self-
+ asserted witness claims.
+
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 13]
+
+Internet-Draft WIMSE Execution Context February 2026
+
4.2.7. Compensation Claims
@@ -652,7 +737,12 @@ Internet-Draft WIMSE Execution Context February 2026
compensation_reason: OPTIONAL. String. A human-readable reason for
the compensation action. MUST be present if
- "compensation_required" is true.
+ "compensation_required" is true. Values SHOULD use structured
+ identifiers (e.g., "policy_violation_in_parent_trade") rather than
+ free-form text to minimize the risk of embedding sensitive
+ information. See Section 11.2 for privacy guidance. If
+ "compensation_reason" is present, "compensation_required" MUST be
+ true.
Note: compensation ECTs reference historical parent tasks via the
"par" claim. The referenced parent ECTs may have passed their own
@@ -663,31 +753,46 @@ Internet-Draft WIMSE Execution Context February 2026
ext: OPTIONAL. Object. An extension object for domain-specific
claims not defined by this specification. Implementations that do
- not understand extension claims SHOULD ignore them. To avoid key
- collisions between different domains, extension key names SHOULD
- use reverse domain notation (e.g., "com.example.custom_field").
+ not understand extension claims MUST ignore them.
-
-
-Nennemann Expires 28 August 2026 [Page 12]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
- The "ext" claim is a generic extension mechanism; it is not
- registered in the IANA JWT Claims registry because its semantics
- depend on the domain-specific claims within it.
+ 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
+ within the "ext" object SHOULD NOT exceed 5 levels. Implementations
+ SHOULD reject ECTs whose "ext" claim exceeds these limits.
4.3. Complete ECT Example
The following is a complete ECT payload example:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 14]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
{
"iss": "spiffe://example.com/agent/clinical",
"sub": "spiffe://example.com/agent/clinical",
"aud": "spiffe://example.com/agent/safety",
"iat": 1772064150,
"exp": 1772064750,
+ "jti": "7f3a8b2c-d1e4-4f56-9a0b-c3d4e5f6a7b8",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"tid": "550e8400-e29b-41d4-a716-446655440001",
@@ -720,16 +825,6 @@ Internet-Draft WIMSE Execution Context February 2026
This specification defines the Execution-Context HTTP header field
[RFC9110] for transporting ECTs between agents.
-
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 13]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
The header field value is the ECT in JWS Compact Serialization format
[RFC7515]. The value consists of three Base64url-encoded parts
separated by period (".") characters.
@@ -738,6 +833,15 @@ Internet-Draft WIMSE Execution Context February 2026
Context header alongside the WIMSE Workload-Identity and Workload-
Proof-Token headers:
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 15]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
GET /api/safety-check HTTP/1.1
Host: safety-agent.example.com
Workload-Identity: eyJhbGci...WIT...
@@ -750,6 +854,13 @@ Internet-Draft WIMSE Execution Context February 2026
multiple Execution-Context header field lines MAY be included, each
carrying a separate ECT in JWS Compact Serialization format.
+ When a receiver processes multiple Execution-Context headers, it MUST
+ individually verify each ECT per the procedure in Section 7. If any
+ single ECT fails verification, the receiver MUST reject the entire
+ request. The set of verified parent task IDs across all received
+ ECTs represents the complete set of parent dependencies available for
+ the receiving agent's subsequent ECT.
+
6. DAG Validation
6.1. Overview
@@ -775,28 +886,38 @@ Internet-Draft WIMSE Execution Context February 2026
the ledger. 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).
+ That is, for each parent: parent.iat < child.iat +
-
-
-
-Nennemann Expires 28 August 2026 [Page 14]
+Nennemann Expires 28 August 2026 [Page 16]
Internet-Draft WIMSE Execution Context February 2026
- 3. Temporal Ordering: The "iat" value of every parent task MUST be
- less than the "iat" value of the current task plus a configurable
- clock skew tolerance (RECOMMENDED: 30 seconds). If any parent
- task has an "iat" that violates this constraint, the ECT MUST be
- rejected.
+ clock_skew_tolerance. The tolerance accounts for clock skew
+ between agents; it does not guarantee strict causal ordering from
+ timestamps alone. Causal ordering is primarily enforced by the
+ DAG structure (parent existence in the ledger), not by
+ timestamps. If any parent task violates this constraint, the ECT
+ MUST be rejected.
4. Acyclicity: Following the chain of parent references MUST NOT
lead back to the current task's "tid". If a cycle is detected,
the ECT MUST be rejected.
- 5. Trust Domain Consistency: Parent tasks SHOULD belong to the same
+ 5. Parent Policy Decision: If any parent task has a "pol_decision"
+ of "rejected" or "pending_human_review", the current task's
+ "exec_act" MUST indicate a compensation, rollback, remediation,
+ or human review action. Implementations MUST NOT accept an ECT
+ representing normal workflow continuation when a parent's
+ "pol_decision" is not "approved", unless the current ECT has
+ "compensation_required" set to true.
+
+ 6. Trust Domain Consistency: Parent tasks SHOULD belong to the same
trust domain or to a trust domain with which a federation
relationship has been established.
@@ -828,16 +949,7 @@ Internet-Draft WIMSE Execution Context February 2026
-
-
-
-
-
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 15]
+Nennemann Expires 28 August 2026 [Page 17]
Internet-Draft WIMSE Execution Context February 2026
@@ -855,14 +967,19 @@ Internet-Draft WIMSE Execution Context February 2026
if parent.iat >= ect.iat + clock_skew_tolerance:
return error("Parent task not earlier than current")
- // Step 3: Cycle detection
+ // Step 3: Cycle detection (with traversal limit)
visited = set()
- if has_cycle(ect.tid, ect.par, ledger, visited):
- return error("Circular dependency detected")
+ result = has_cycle(ect.tid, ect.par, ledger, visited,
+ max_ancestor_limit)
+ if result is error or result is true:
+ return error("Circular dependency or depth limit exceeded")
return success
- function has_cycle(target_tid, parent_ids, ledger, visited):
+ function has_cycle(target_tid, parent_ids, ledger, visited,
+ max_depth):
+ if visited.size() >= max_depth:
+ return error("Maximum ancestor traversal limit exceeded")
for parent_id in parent_ids:
if parent_id == target_tid:
return true
@@ -871,8 +988,10 @@ Internet-Draft WIMSE Execution Context February 2026
visited.add(parent_id)
parent = ledger.get(parent_id)
if parent is not null:
- if has_cycle(target_tid, parent.par, ledger, visited):
- return true
+ result = has_cycle(target_tid, parent.par, ledger,
+ visited, max_depth)
+ if result is error or result is true:
+ return result
return false
Figure 6: DAG Validation Pseudocode
@@ -881,8 +1000,20 @@ Internet-Draft WIMSE Execution Context February 2026
current task's parents. The complexity is O(V) where V is the number
of ancestor nodes reachable from the current task's parent
references. For typical workflows with shallow DAGs, this is
- efficient. Implementations SHOULD cache cycle detection results for
- previously verified tasks to avoid redundant traversals.
+ efficient. To prevent denial-of-service via extremely deep or wide
+ DAGs, implementations SHOULD enforce a maximum ancestor traversal
+
+
+
+Nennemann Expires 28 August 2026 [Page 18]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
+ limit (RECOMMENDED: 10000 nodes). If the limit is reached before
+ cycle detection completes, the ECT SHOULD be rejected.
+ Implementations SHOULD cache cycle detection results for previously
+ verified tasks to avoid redundant traversals.
7. Signature and Token Verification
@@ -891,13 +1022,6 @@ Internet-Draft WIMSE Execution Context February 2026
When an agent receives an ECT, it MUST perform the following
verification steps in order:
-
-
-Nennemann Expires 28 August 2026 [Page 16]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
1. Parse the JWS Compact Serialization to extract the JOSE header,
payload, and signature components per [RFC7515].
@@ -912,30 +1036,51 @@ Internet-Draft WIMSE Execution Context February 2026
5. Retrieve the public key identified by "kid" and verify the JWS
signature per [RFC7515] Section 5.2.
- 6. Verify the "alg" header parameter matches the algorithm in the
+ 6. Verify that the signing key identified by "kid" has not been
+ revoked within the trust domain. Implementations MUST check the
+ key's revocation status using the trust domain's key lifecycle
+ mechanism (e.g., certificate revocation list, OCSP, or SPIFFE
+ trust bundle updates).
+
+ 7. Verify the "alg" header parameter matches the algorithm in the
corresponding WIT.
- 7. Verify the "iss" claim matches the "sub" claim of the WIT
+ 8. Verify the "iss" claim matches the "sub" claim of the WIT
associated with the "kid" public key.
- 8. Verify the "aud" claim contains the verifier's own workload
- identity or an expected recipient identifier.
+ 9. Verify the "aud" claim contains the verifier's own workload
+ identity. When "aud" is an array, it is sufficient that the
+ verifier's identity appears as one element; the presence of
+ other audience values does not cause verification failure. When
+ the verifier is the audit ledger, the ledger's own identity MUST
+ appear in "aud".
- 9. Verify the "exp" claim indicates the ECT has not expired.
+ 10. Verify the "exp" claim indicates the ECT has not expired.
- 10. Verify the "iat" claim is not unreasonably far in the past
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 19]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
+ 11. Verify the "iat" claim is not unreasonably far in the past
(implementation-specific threshold, RECOMMENDED maximum of 15
- minutes).
+ minutes) and is not unreasonably far in the future (RECOMMENDED:
+ no more than 30 seconds ahead of the verifier's current time, to
+ account for clock skew).
- 11. Verify all required claims ("tid", "exec_act", "par", "pol",
- "pol_decision") are present and well-formed.
+ 12. Verify all required claims ("jti", "tid", "exec_act", "par",
+ "pol", "pol_decision") are present and well-formed.
- 12. Verify "pol_decision" is one of "approved", "rejected", or
+ 13. Verify "pol_decision" is one of "approved", "rejected", or
"pending_human_review".
- 13. Perform DAG validation per Section 6.
+ 14. Perform DAG validation per Section 6.
- 14. If all checks pass, the ECT MUST be appended to the audit
+ 15. If all checks pass, the ECT MUST be appended to the audit
ledger.
If any verification step fails, the ECT MUST be rejected and the
@@ -943,17 +1088,16 @@ Internet-Draft WIMSE Execution Context February 2026
reveal whether specific parent task IDs exist in the ledger, to
prevent information disclosure.
+ When ECT verification fails during HTTP request processing, the
+ receiving agent SHOULD respond with HTTP 403 (Forbidden) if the WIT
+ and WPT are valid but the ECT is invalid, and HTTP 401 (Unauthorized)
+ if the ECT signature verification fails. The response body SHOULD
+ include a generic error indicator without revealing which specific
+ verification step failed. The receiving agent MUST NOT process the
+ requested action when ECT verification fails.
+
7.2. Verification Pseudocode
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 17]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
function verify_ect(ect_jws, verifier_id,
trust_domain_keys, ledger):
// Parse JWS
@@ -971,11 +1115,22 @@ Internet-Draft WIMSE Execution Context February 2026
if public_key is null:
return reject("Unknown key identifier")
+
+
+Nennemann Expires 28 August 2026 [Page 20]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
// Verify signature
if not verify_jws_signature(header, payload,
signature, public_key):
return reject("Invalid signature")
+ // Verify key not revoked
+ if is_key_revoked(header.kid, trust_domain_keys):
+ return reject("Signing key has been revoked")
+
// Verify algorithm alignment
wit = get_wit_for_key(header.kid)
if header.alg != wit.alg:
@@ -993,23 +1148,18 @@ Internet-Draft WIMSE Execution Context February 2026
if payload.exp < current_time():
return reject("ECT has expired")
- // Verify iat freshness
+ // Verify iat freshness (not too old, not in the future)
if payload.iat < current_time() - max_age_threshold:
return reject("ECT issued too long ago")
+ if payload.iat > current_time() + clock_skew_tolerance:
+ return reject("ECT issued in the future")
// Verify required claims
- for claim in ["tid", "exec_act", "par",
+ for claim in ["jti", "tid", "exec_act", "par",
"pol", "pol_decision"]:
if claim not in payload:
return reject("Missing required claim: " + claim)
-
-
-Nennemann Expires 28 August 2026 [Page 18]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
// Validate pol_decision value
if payload.pol_decision not in
["approved", "rejected", "pending_human_review"]:
@@ -1021,6 +1171,13 @@ Internet-Draft WIMSE Execution Context February 2026
if result is error:
return reject("DAG validation failed")
+
+
+Nennemann Expires 28 August 2026 [Page 21]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
// All checks passed; append to ledger
ledger.append(payload)
return accept
@@ -1059,17 +1216,24 @@ Internet-Draft WIMSE Execution Context February 2026
The ledger SHOULD be maintained by an entity independent of the
workflow agents to reduce the risk of collusion.
-
-
-Nennemann Expires 28 August 2026 [Page 19]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
8.3. Ledger Entry Structure
Each ledger entry is a logical record containing:
+
+
+
+
+
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 22]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
{
"ledger_sequence": 42,
"task_id": "550e8400-e29b-41d4-a716-446655440001",
@@ -1088,6 +1252,10 @@ Internet-Draft WIMSE Execution Context February 2026
is the authoritative record. The other fields ("agent_id", "action",
"parents") are convenience indexes derived from the ECT payload; if
they disagree with the JWS payload, the JWS payload takes precedence.
+ Implementations SHOULD validate that convenience index fields match
+ the corresponding values in the JWS payload at write time to prevent
+ desynchronization between the authoritative JWS and the indexed
+ fields.
9. Use Cases
@@ -1098,8 +1266,8 @@ Internet-Draft WIMSE Execution Context February 2026
this specification.
Note: task identifiers in this section are abbreviated for
- readability. In production, all "tid" values MUST be UUIDs per
- [RFC9562].
+ readability. In production, all "tid" values are required to be
+ UUIDs per Section 4.2.2.
9.1. Medical Device SDLC Workflow
@@ -1117,7 +1285,7 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 20]
+Nennemann Expires 28 August 2026 [Page 23]
Internet-Draft WIMSE Execution Context February 2026
@@ -1173,7 +1341,7 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 21]
+Nennemann Expires 28 August 2026 [Page 24]
Internet-Draft WIMSE Execution Context February 2026
@@ -1229,7 +1397,7 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 22]
+Nennemann Expires 28 August 2026 [Page 25]
Internet-Draft WIMSE Execution Context February 2026
@@ -1285,15 +1453,15 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 23]
+Nennemann Expires 28 August 2026 [Page 26]
Internet-Draft WIMSE Execution Context February 2026
{
- "iss": "spiffe://bank.com/agent/operations",
- "sub": "spiffe://bank.com/agent/operations",
- "aud": "spiffe://bank.com/system/ledger",
+ "iss": "spiffe://bank.example/agent/operations",
+ "sub": "spiffe://bank.example/agent/operations",
+ "aud": "spiffe://bank.example/system/ledger",
"iat": 1772150550,
"exp": 1772151150,
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
@@ -1302,7 +1470,7 @@ Internet-Draft WIMSE Execution Context February 2026
"par": ["550e8400-e29b-41d4-a716-446655440003"],
"pol": "compensation_policy_v1",
"pol_decision": "approved",
- "pol_enforcer": "spiffe://bank.com/human/compliance-officer",
+ "pol_enforcer": "spiffe://bank.example/human/compliance-officer",
"compensation_required": true,
"compensation_reason": "policy_violation_in_parent_trade"
}
@@ -1315,9 +1483,9 @@ Internet-Draft WIMSE Execution Context February 2026
9.4. Autonomous Logistics Coordination
- In a logistics workflow, multiple compliance checks must complete
- before shipment commitment. The DAG structure records that all
- required checks were completed:
+ In a logistics workflow, multiple compliance checks complete before
+ shipment commitment. The DAG structure records that all required
+ checks were completed:
@@ -1341,7 +1509,7 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 24]
+Nennemann Expires 28 August 2026 [Page 27]
Internet-Draft WIMSE Execution Context February 2026
@@ -1397,7 +1565,7 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 25]
+Nennemann Expires 28 August 2026 [Page 28]
Internet-Draft WIMSE Execution Context February 2026
@@ -1426,6 +1594,48 @@ Internet-Draft WIMSE Execution Context February 2026
the signing agent. To mitigate single-agent false claims, regulated
environments SHOULD use the "witnessed_by" mechanism to include
independent third-party observers at critical decision points.
+ However, the "witnessed_by" claim is self-asserted by the ECT issuer:
+ the listed witnesses do not co-sign the ECT and there is no
+ cryptographic proof within a single ECT that the witnesses actually
+ observed the task. An issuing agent could list witnesses that did
+ not participate.
+
+10.2.1. Witness Attestation Model
+
+ To address the self-assertion limitation of the "witnessed_by" claim,
+ witnesses SHOULD submit their own independent signed ECTs to the
+ audit ledger attesting to the observed task. A witness attestation
+ ECT:
+
+ * MUST set "iss" to the witness's own workload identity.
+
+ * MUST set "exec_act" to "witness_attestation" (or a domain-
+ specific equivalent).
+
+ * MUST include the observed task's "tid" in the "par" array, linking
+ the attestation to the original task.
+
+ * MUST set "pol_decision" to "approved" to indicate the witness
+ confirms the observation.
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 29]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
+ When a task's "witnessed_by" claim lists one or more witnesses,
+ auditors SHOULD verify that corresponding witness attestation ECTs
+ exist in the ledger for each listed witness. A mismatch between the
+ "witnessed_by" list and the set of independent witness ECTs in the
+ ledger SHOULD be flagged during audit review.
+
+ This model converts witness attestation from a self-asserted claim to
+ a cryptographically verifiable property of the ledger: the witness
+ independently signs their own ECT using their own key, and the ledger
+ records both the original task ECT and the witness attestation ECTs.
10.3. Organizational Prerequisites
@@ -1445,33 +1655,33 @@ Internet-Draft WIMSE Execution Context February 2026
* Agent deployment governance: Agents are deployed and maintained in
a manner that preserves their integrity.
-
-
-
-
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 26]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
10.4. Signature Verification
ECTs MUST be signed with the agent's private key using JWS [RFC7515].
The signature algorithm MUST match the algorithm specified in the
agent's WIT. Receivers MUST verify the ECT signature against the WIT
public key before processing any claims. Receivers MUST verify that
- the signing key has not been revoked within the trust domain.
+ the signing key has not been revoked within the trust domain (see
+ step 6 in Section 7).
- If signature verification fails, the ECT MUST be rejected entirely
- and the failure MUST be logged.
+ If signature verification fails or if the signing key has been
+ revoked, the ECT MUST be rejected entirely and the failure MUST be
+ logged.
Implementations MUST use established JWS libraries and MUST NOT
implement custom signature verification.
+
+
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 30]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
10.5. Replay Attack Prevention
ECTs include short expiration times (RECOMMENDED: 5-15 minutes) to
@@ -1484,8 +1694,9 @@ Internet-Draft WIMSE Execution Context February 2026
referencing parent tasks that already have a recorded child task with
the same action can be flagged as a potential replay.
- Implementations SHOULD maintain a cache of recently-seen "jti" values
- (when present) to detect replayed ECTs within the expiration window.
+ Implementations MUST maintain a cache of recently-seen "jti" values
+ to detect replayed ECTs within the expiration window. An ECT with a
+ duplicate "jti" value MUST be rejected.
10.6. Man-in-the-Middle Protection
@@ -1505,15 +1716,6 @@ Internet-Draft WIMSE Execution Context February 2026
* ECT (execution accountability layer): Records what the agent did
and under what policy.
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 27]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
10.7. Key Compromise
If an agent's private key is compromised, an attacker can forge ECTs
@@ -1527,6 +1729,15 @@ Internet-Draft WIMSE Execution Context February 2026
* Trust domains MUST support rapid key revocation.
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 31]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
* Upon suspected compromise, the trust domain MUST revoke the
compromised key and issue a new WIT with a fresh key pair.
@@ -1556,20 +1767,6 @@ Internet-Draft WIMSE Execution Context February 2026
* Out-of-band audit: External auditors periodically verify ledger
contents against expected workflow patterns.
-
-
-
-
-
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 28]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
10.9. Denial of Service
ECT signature verification is computationally inexpensive
@@ -1583,6 +1780,20 @@ Internet-Draft WIMSE Execution Context February 2026
performed after signature verification to avoid wasting resources on
unsigned or incorrectly signed tokens.
+
+
+
+
+
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 32]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
10.10. Timestamp Accuracy
ECTs rely on timestamps ("iat", "exp") for temporal ordering. Clock
@@ -1591,6 +1802,12 @@ Internet-Draft WIMSE Execution Context February 2026
SHOULD allow a configurable clock skew tolerance (RECOMMENDED: 30
seconds).
+ Cross-organizational deployments where agents span multiple trust
+ domains with independent time sources MAY require a higher clock skew
+ tolerance. Deployments using trust domain federation SHOULD document
+ their configured clock skew tolerance value and SHOULD ensure all
+ participating trust domains agree on a common tolerance.
+
The temporal ordering check in DAG validation incorporates the clock
skew tolerance to account for minor clock differences between agents.
@@ -1598,8 +1815,10 @@ Internet-Draft WIMSE Execution Context February 2026
ECTs with many parent tasks or large extension objects can increase
HTTP header size. Implementations SHOULD limit the "par" array to a
- reasonable size and SHOULD set maximum size limits for the "ext"
- object to prevent abuse.
+ maximum of 256 entries. Workflows requiring more parent references
+ SHOULD introduce intermediate aggregation tasks. The "ext" object
+ SHOULD NOT exceed 4096 bytes when serialized as JSON and SHOULD NOT
+ exceed a nesting depth of 5 levels (see also Section 4.2.8).
11. Privacy Considerations
@@ -1618,19 +1837,19 @@ Internet-Draft WIMSE Execution Context February 2026
ECTs are designed to NOT reveal:
-
-
-
-Nennemann Expires 28 August 2026 [Page 29]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
* Actual input or output data values (replaced with cryptographic
hashes via "inp_hash" and "out_hash")
* Internal computation details or intermediate steps
+
+
+
+Nennemann Expires 28 August 2026 [Page 33]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
* Proprietary algorithms or intellectual property
* Personally identifiable information (PII)
@@ -1643,6 +1862,15 @@ Internet-Draft WIMSE Execution Context February 2026
"pol" claim SHOULD reference policy identifiers rather than embedding
policy content.
+ The "compensation_reason" claim (Section 4.2.7) deserves particular
+ attention: because it is human-readable and may describe the
+ circumstances of a failure or policy violation, it risks exposing
+ sensitive operational details. Implementations SHOULD use short,
+ structured reason codes (e.g., "policy_violation_in_parent_trade")
+ rather than free-form natural language explanations. Implementers
+ SHOULD review "compensation_reason" values for potential information
+ leakage before deploying to production.
+
11.3. Storage and Access Control
ECTs stored in audit ledgers SHOULD be access-controlled so that only
@@ -1670,18 +1898,18 @@ Internet-Draft WIMSE Execution Context February 2026
Type name: application
- Subtype name: wimse-exec+jwt
-
- Required parameters: none
-
-Nennemann Expires 28 August 2026 [Page 30]
+Nennemann Expires 28 August 2026 [Page 34]
Internet-Draft WIMSE Execution Context February 2026
+ Subtype name: wimse-exec+jwt
+
+ Required parameters: none
+
Optional parameters: none
Encoding considerations: 8bit; an ECT is a JWT that is a JWS using
@@ -1725,19 +1953,20 @@ Internet-Draft WIMSE Execution Context February 2026
Specification document: This document, Section 5
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 35]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
12.3. JWT Claims Registration
This document requests registration of the following claims in the
"JSON Web Token Claims" registry maintained by IANA:
-
-
-
-Nennemann Expires 28 August 2026 [Page 31]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
+=======================+=================+============+===========+
| Claim Name | Claim | Change | Reference |
| | Description | Controller | |
@@ -1781,29 +2010,93 @@ Internet-Draft WIMSE Execution Context February 2026
| witnessed_by | Witness | IETF | Section |
| | Identities | | 4.2.6 |
+-----------------------+-----------------+------------+-----------+
+
+
+
+Nennemann Expires 28 August 2026 [Page 36]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
| regulated_domain | Regulatory | IETF | Section |
| | Domain | | 4.2.5 |
+-----------------------+-----------------+------------+-----------+
| model_version | AI/ML Model | IETF | Section |
| | Version | | 4.2.5 |
-
-
-
-Nennemann Expires 28 August 2026 [Page 32]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
+-----------------------+-----------------+------------+-----------+
| compensation_required | Compensation | IETF | Section |
| | Flag | | 4.2.7 |
+-----------------------+-----------------+------------+-----------+
| compensation_reason | Compensation | IETF | Section |
| | Reason | | 4.2.7 |
+ +-----------------------+-----------------+------------+-----------+
+ | ext | Extension | IETF | Section |
+ | | Object | | 4.2.8 |
+-----------------------+-----------------+------------+-----------+
Table 1: JWT Claims Registrations
+12.4. ECT Policy Decision Values Registry
+
+ This document establishes the "ECT Policy Decision Values" registry
+ under the "JSON Web Token (JWT)" group. Registration policy is
+ Specification Required per [RFC8126].
+
+ The initial contents of the registry are:
+
+ +======================+===================+============+===========+
+ | Value | Description | Change | Reference |
+ | | | Controller | |
+ +======================+===================+============+===========+
+ | approved | Policy | IETF | Section |
+ | | evaluation | | 4.2.3 |
+ | | succeeded | | |
+ +----------------------+-------------------+------------+-----------+
+ | rejected | Policy | IETF | Section |
+ | | evaluation | | 4.2.3 |
+ | | failed | | |
+ +----------------------+-------------------+------------+-----------+
+ | pending_human_review | Awaiting | IETF | Section |
+ | | human | | 4.2.3 |
+ | | judgment | | |
+ +----------------------+-------------------+------------+-----------+
+
+ Table 2: ECT Policy Decision Values
+
+
+
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 37]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
+12.5. ECT Regulated Domain Values Registry
+
+ This document establishes the "ECT Regulated Domain Values" registry
+ under the "JSON Web Token (JWT)" group. Registration policy is
+ Specification Required per [RFC8126].
+
+ The initial contents of the registry are:
+
+ +==========+====================+===================+===========+
+ | Value | Description | Change Controller | Reference |
+ +==========+====================+===================+===========+
+ | medtech | Medical technology | IETF | Section |
+ | | and devices | | 4.2.5 |
+ +----------+--------------------+-------------------+-----------+
+ | finance | Financial services | IETF | Section |
+ | | and trading | | 4.2.5 |
+ +----------+--------------------+-------------------+-----------+
+ | military | Military and | IETF | Section |
+ | | defense | | 4.2.5 |
+ +----------+--------------------+-------------------+-----------+
+
+ Table 3: ECT Regulated Domain Values
+
13. References
13.1. Normative References
@@ -1829,31 +2122,35 @@ Internet-Draft WIMSE Execution Context February 2026
DOI 10.17487/RFC2119, March 1997,
.
- [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
- Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
- .
+
+
+
+Nennemann Expires 28 August 2026 [Page 38]
+
+Internet-Draft WIMSE Execution Context February 2026
+
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, .
+ [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
+ DOI 10.17487/RFC7517, May 2015,
+ .
+
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
.
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 33]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
.
+ [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in RFCs", BCP 26,
+ RFC 8126, DOI 10.17487/RFC8126, June 2017,
+ .
+
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
@@ -1881,6 +2178,14 @@ Internet-Draft WIMSE Execution Context February 2026
intelligence (Artificial Intelligence Act)", 13 June 2024,
.
+
+
+
+Nennemann Expires 28 August 2026 [Page 39]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
[EU-MDR] European Parliament and Council of the European Union,
"Regulation (EU) 2017/745 on medical devices (MDR)", 5
April 2017, .
@@ -1899,13 +2204,6 @@ Internet-Draft WIMSE Execution Context February 2026
October 2025, .
-
-
-Nennemann Expires 28 August 2026 [Page 34]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
[I-D.ni-wimse-ai-agent-identity]
Yuan, N. and P. C. Liu, "WIMSE Applicability for AI
Agents", Work in Progress, Internet-Draft, draft-ni-wimse-
@@ -1929,15 +2227,21 @@ Internet-Draft WIMSE Execution Context February 2026
DOI 10.17487/RFC3552, July 2003,
.
- [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
- DOI 10.17487/RFC7517, May 2015,
- .
-
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
.
+
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 40]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, .
@@ -1948,20 +2252,6 @@ Internet-Draft WIMSE Execution Context February 2026
Related Work
-
-
-
-
-
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 35]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
WIMSE Workload Identity
The WIMSE architecture [I-D.ietf-wimse-arch] and service-to- service
@@ -1996,6 +2286,18 @@ Distributed Tracing (OpenTelemetry)
while ECTs provide signed execution records. ECTs may reference
OpenTelemetry trace identifiers in the "ext" claim for correlation.
+
+
+
+
+
+
+
+Nennemann Expires 28 August 2026 [Page 41]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
Blockchain and Distributed Ledgers
Both ECTs and blockchain systems provide immutable records. This
@@ -2005,19 +2307,6 @@ Blockchain and Distributed Ledgers
or any storage providing the required properties defined in
Section 8.
-
-
-
-
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 36]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
SCITT (Supply Chain Integrity, Transparency, and Trust)
The SCITT architecture [I-D.ietf-scitt-architecture] defines a
@@ -2050,14 +2339,21 @@ Implementation Guidance
Minimal Implementation
- A minimal conforming implementation should:
+ A minimal conforming implementation needs to:
1. Create JWTs with all required claims ("iss", "aud", "iat", "exp",
- "tid", "exec_act", "par", "pol", "pol_decision").
+ "jti", "tid", "exec_act", "par", "pol", "pol_decision").
2. Sign ECTs with the agent's private key using an algorithm
matching the WIT (ES256 recommended).
+
+
+Nennemann Expires 28 August 2026 [Page 42]
+
+Internet-Draft WIMSE Execution Context February 2026
+
+
3. Verify ECT signatures against WIT public keys.
4. Perform DAG validation (parent existence, temporal ordering,
@@ -2065,15 +2361,6 @@ Minimal Implementation
5. Append verified ECTs to an audit ledger.
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 37]
-
-Internet-Draft WIMSE Execution Context February 2026
-
-
Storage Recommendations
* Append-only log: Simplest approach; immutability by design.
@@ -2102,10 +2389,11 @@ Performance Considerations
Interoperability
- Implementations should use established JWT/JWS libraries (JOSE) for
- token creation and verification. Custom cryptographic
- implementations should not be used. Implementations should be tested
- against multiple JWT libraries to ensure interoperability.
+ Implementations are expected to use established JWT/JWS libraries
+ (JOSE) for token creation and verification. Custom cryptographic
+ implementations are strongly discouraged. Implementations are
+ expected to be tested against multiple JWT libraries to ensure
+ interoperability.
Regulatory Compliance Mapping
@@ -2117,15 +2405,7 @@ Regulatory Compliance Mapping
-
-
-
-
-
-
-
-
-Nennemann Expires 28 August 2026 [Page 38]
+Nennemann Expires 28 August 2026 [Page 43]
Internet-Draft WIMSE Execution Context February 2026
@@ -2160,7 +2440,7 @@ Internet-Draft WIMSE Execution Context February 2026
| | | trail |
+------------+------------------------+--------------------------+
- Table 2: Regulatory Compliance Mapping
+ Table 4: Regulatory Compliance Mapping
Examples
@@ -2181,7 +2461,7 @@ Example 1: Simple Two-Agent Workflow
-Nennemann Expires 28 August 2026 [Page 39]
+Nennemann Expires 28 August 2026 [Page 44]
Internet-Draft WIMSE Execution Context February 2026
@@ -2237,7 +2517,7 @@ Example 2: Medical Device SDLC with Release Approval
-Nennemann Expires 28 August 2026 [Page 40]
+Nennemann Expires 28 August 2026 [Page 45]
Internet-Draft WIMSE Execution Context February 2026
@@ -2293,7 +2573,7 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 41]
+Nennemann Expires 28 August 2026 [Page 46]
Internet-Draft WIMSE Execution Context February 2026
@@ -2349,7 +2629,7 @@ Internet-Draft WIMSE Execution Context February 2026
-Nennemann Expires 28 August 2026 [Page 42]
+Nennemann Expires 28 August 2026 [Page 47]
Internet-Draft WIMSE Execution Context February 2026
@@ -2405,7 +2685,7 @@ Example 3: Parallel Execution with Join
-Nennemann Expires 28 August 2026 [Page 43]
+Nennemann Expires 28 August 2026 [Page 48]
Internet-Draft WIMSE Execution Context February 2026
@@ -2461,4 +2741,4 @@ Author's Address
-Nennemann Expires 28 August 2026 [Page 44]
+Nennemann Expires 28 August 2026 [Page 49]
diff --git a/draft-nennemann-wimse-execution-context-00.xml b/draft-nennemann-wimse-execution-context-00.xml
index 98edb2c..b356336 100644
--- a/draft-nennemann-wimse-execution-context-00.xml
+++ b/draft-nennemann-wimse-execution-context-00.xml
@@ -26,13 +26,13 @@
Security
-
+ WIMSEexecution contextworkload identityagentic workflowsaudit trailcomplianceregulated systems
-
+
This document defines Execution Context Tokens (ECTs), an extension
to the Workload Identity in Multi System Environments (WIMSE)
@@ -64,7 +64,7 @@ regulatory frameworks.
-
+
Introduction
@@ -111,7 +111,7 @@ accountability. WIMSE authenticates agents; this extension records
what they did, in what order, and what policy was evaluated.
As identified in , call context
-in agentic workflows must always be visible and preserved. ECTs
+in agentic workflows needs to be visible and preserved. ECTs
provide a mechanism to address this requirement with cryptographic
assurances.
@@ -413,13 +413,41 @@ claim of the agent's WIT.
sub:
OPTIONAL. StringOrURI. The subject of the ECT. When present,
-MUST equal the "iss" claim.
+MUST equal the "iss" claim. This claim is included for
+compatibility with JWT libraries and frameworks that expect a
+"sub" claim to be present.
aud:
REQUIRED. StringOrURI or array of StringOrURI. The intended
-recipient(s) of the ECT. Typically the next agent in the
-workflow or the ledger endpoint.
+recipient(s) of the ECT. Because ECTs serve as both inter-agent
+messages and audit records, the "aud" claim SHOULD contain the
+identifiers of all entities that will verify the ECT. In
+practice this means:
+
+
+
+ Point-to-point delivery: when an ECT is sent from one
+agent to a single next agent, "aud" contains that agent's
+workload identity. The receiving agent verifies the ECT and
+forwards it to the ledger on behalf of the issuer.
+ Direct-to-ledger submission: when an ECT is submitted
+directly to the audit ledger (e.g., after a join or at
+workflow completion), "aud" contains the ledger's identity.
+ Multi-audience: when an ECT must be verified by both the
+next agent and the ledger independently, "aud" MUST be an
+array containing both identifiers (e.g.,
+["spiffe://example.com/agent/next",
+"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 according to the rules above based on where the ECT will
+be delivered — it is independent of the "aud" values in the
+parent ECTs.
iat:
@@ -434,10 +462,20 @@ Implementations SHOULD set this to 5 to 15 minutes after "iat"
to limit the replay window while allowing for reasonable clock
skew and processing time.
+
+
+The standard JWT "nbf" (Not Before) claim is not used in ECTs
+because ECTs record completed actions and are valid immediately
+upon issuance.
+
+
jti:
- OPTIONAL. String. A unique identifier for the ECT, useful for
-additional replay detection.
+ REQUIRED. String. A unique identifier for the ECT in UUID
+format . Used for replay detection: receivers MUST
+reject ECTs whose "jti" has already been seen within the
+expiration window. The "jti" value MUST be unique across all
+ECTs issued by the same agent.
@@ -496,7 +534,27 @@ evaluated for this task (e.g.,
pol_decision:
REQUIRED. String. The result of the policy evaluation. MUST
-be one of: "approved", "rejected", or "pending_human_review".
+be one of the values registered in the ECT Policy Decision
+Values registry (). Initial values
+are:
+
+
+
+ "approved": The policy evaluation succeeded and the task
+was authorized to proceed.
+ "rejected": The policy evaluation failed. A "rejected" ECT
+MUST still be appended to the audit ledger for accountability.
+An ECT with "pol_decision" of "rejected" MAY appear as a
+parent in the "par" array of a subsequent ECT, but only for
+compensation, rollback, or remediation tasks. Agents MUST
+NOT proceed with normal workflow execution based on a parent
+ECT whose "pol_decision" is "rejected".
+ "pending_human_review": The policy evaluation requires human
+judgment before proceeding. Agents MUST NOT proceed with
+dependent tasks until a subsequent ECT from a human reviewer
+records an "approved" decision referencing this task as a
+parent.
+
pol_enforcer:
@@ -524,13 +582,18 @@ inputs and outputs without revealing the data itself:
OPTIONAL. String. A cryptographic hash of the input data,
formatted as "hash-algorithm:base64url-encoded-hash" (e.g.,
"sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The
-hash algorithm identifier SHOULD be "sha-256". The hash MUST be
+hash algorithm identifier MUST be a lowercase value from the
+IANA Named Information Hash Algorithm Registry (e.g., "sha-256",
+"sha-384", "sha-512"). Implementations MUST support "sha-256"
+and SHOULD use "sha-256" unless a stronger algorithm is
+required. Implementations MUST NOT accept hash algorithms
+weaker than SHA-256 (e.g., MD5, SHA-1). The hash MUST be
computed over the raw octets of the input data.
out_hash:
OPTIONAL. String. A cryptographic hash of the output data,
-using the same format as "inp_hash".
+using the same format and algorithm requirements as "inp_hash".
inp_classification:
@@ -553,8 +616,8 @@ milliseconds. MUST be a non-negative integer.
regulated_domain:
OPTIONAL. String. The regulatory domain applicable to this
-task. Values are drawn from an extensible set; initial values
-include "medtech", "finance", and "military".
+task. Values MUST be registered in the ECT Regulated Domain
+Values registry ().
model_version:
@@ -570,11 +633,17 @@ used to perform the task, if applicable.
witnessed_by:
OPTIONAL. Array of StringOrURI. Identifiers of third-party
-entities that observed or attested to the execution of this
-task. When present, each element SHOULD use SPIFFE ID format.
-In regulated environments, implementations SHOULD use witness
-attestation for critical decision points to mitigate the risk
-of single-agent false claims.
+entities that the issuing agent claims observed or attested to
+the execution of this task. When present, each element SHOULD
+use SPIFFE ID format. Note that this claim is self-asserted by
+the ECT issuer; witnesses listed here do not co-sign this ECT.
+For stronger assurance, witnesses SHOULD submit independent
+signed ECTs to the ledger attesting to their observation (see
+). In regulated environments,
+implementations SHOULD use witness attestation for critical
+decision points to mitigate the risk of single-agent false
+claims. See also for the security
+implications of self-asserted witness claims.
@@ -590,7 +659,13 @@ compensation or rollback action for a previous task.
compensation_reason:
OPTIONAL. String. A human-readable reason for the compensation
-action. MUST be present if "compensation_required" is true.
+action. MUST be present if "compensation_required" is true.
+Values SHOULD use structured identifiers (e.g.,
+"policy_violation_in_parent_trade") rather than free-form text
+to minimize the risk of embedding sensitive information. See
+ for privacy guidance.
+If "compensation_reason" is present, "compensation_required"
+MUST be true.
@@ -608,16 +683,19 @@ ledger.
OPTIONAL. Object. An extension object for domain-specific
claims not defined by this specification. Implementations
-that do not understand extension claims SHOULD ignore them.
-To avoid key collisions between different domains, extension
-key names SHOULD use reverse domain notation (e.g.,
-"com.example.custom_field").
+that do not understand extension claims MUST ignore them.
-The "ext" claim is a generic extension mechanism; it is not
-registered in the IANA JWT Claims registry because its semantics
-depend on the domain-specific claims within it.
+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 within the "ext" object
+SHOULD NOT exceed 5 levels. Implementations SHOULD reject
+ECTs whose "ext" claim exceeds these limits.
@@ -632,6 +710,7 @@ depend on the domain-specific claims within it.
"aud": "spiffe://example.com/agent/safety",
"iat": 1772064150,
"exp": 1772064750,
+ "jti": "7f3a8b2c-d1e4-4f56-9a0b-c3d4e5f6a7b8",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"tid": "550e8400-e29b-41d4-a716-446655440001",
@@ -685,6 +764,14 @@ Execution-Context: eyJhbGci...ECT...
multiple Execution-Context header field lines MAY be included, each
carrying a separate ECT in JWS Compact Serialization format.
+When a receiver processes multiple Execution-Context headers, it
+MUST individually verify each ECT per the procedure in
+. If any single ECT fails verification, the
+receiver MUST reject the entire request. The set of verified
+parent task IDs across all received ECTs represents the complete
+set of parent dependencies available for the receiving agent's
+subsequent ECT.
+
DAG Validation
@@ -713,14 +800,26 @@ entire ledger if "wid" is absent). If a task with the same
array MUST correspond to a task that has been previously
recorded in the ledger. If any parent task is not found, the
ECT MUST be rejected.
- Temporal Ordering: The "iat" value of every parent task MUST be
-less than the "iat" value of the current task plus a
+ 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).
-If any parent task has an "iat" that violates this constraint,
-the ECT MUST be rejected.
+That is, for each parent: parent.iat < child.iat +
+clock_skew_tolerance. The tolerance accounts for clock skew
+between agents; it does not guarantee strict causal ordering
+from timestamps alone. Causal ordering is primarily enforced
+by the DAG structure (parent existence in the ledger), not by
+timestamps. If any parent task violates this constraint, the
+ECT MUST be rejected.Acyclicity: Following the chain of parent references MUST NOT
lead back to the current task's "tid". If a cycle is detected,
the ECT MUST be rejected.
+ Parent Policy Decision: If any parent task has a "pol_decision"
+of "rejected" or "pending_human_review", the current task's
+"exec_act" MUST indicate a compensation, rollback, remediation,
+or human review action. Implementations MUST NOT accept an ECT
+representing normal workflow continuation when a parent's
+"pol_decision" is not "approved", unless the current ECT has
+"compensation_required" set to true.Trust Domain Consistency: Parent tasks SHOULD belong to the
same trust domain or to a trust domain with which a federation
relationship has been established.
@@ -745,14 +844,19 @@ function validate_dag(ect, ledger, clock_skew_tolerance):
if parent.iat >= ect.iat + clock_skew_tolerance:
return error("Parent task not earlier than current")
- // Step 3: Cycle detection
+ // Step 3: Cycle detection (with traversal limit)
visited = set()
- if has_cycle(ect.tid, ect.par, ledger, visited):
- return error("Circular dependency detected")
+ result = has_cycle(ect.tid, ect.par, ledger, visited,
+ max_ancestor_limit)
+ if result is error or result is true:
+ return error("Circular dependency or depth limit exceeded")
return success
-function has_cycle(target_tid, parent_ids, ledger, visited):
+function has_cycle(target_tid, parent_ids, ledger, visited,
+ max_depth):
+ if visited.size() >= max_depth:
+ return error("Maximum ancestor traversal limit exceeded")
for parent_id in parent_ids:
if parent_id == target_tid:
return true
@@ -761,8 +865,10 @@ function has_cycle(target_tid, parent_ids, ledger, visited):
visited.add(parent_id)
parent = ledger.get(parent_id)
if parent is not null:
- if has_cycle(target_tid, parent.par, ledger, visited):
- return true
+ result = has_cycle(target_tid, parent.par, ledger,
+ visited, max_depth)
+ if result is error or result is true:
+ return result
return false
]]>
@@ -770,7 +876,11 @@ function has_cycle(target_tid, parent_ids, ledger, visited):
current task's parents. The complexity is O(V) where V is the
number of ancestor nodes reachable from the current task's parent
references. For typical workflows with shallow DAGs, this is
-efficient. Implementations SHOULD cache cycle detection results
+efficient. To prevent denial-of-service via extremely deep or
+wide DAGs, implementations SHOULD enforce a maximum ancestor
+traversal limit (RECOMMENDED: 10000 nodes). If the limit is
+reached before cycle detection completes, the ECT SHOULD be
+rejected. Implementations SHOULD cache cycle detection results
for previously verified tasks to avoid redundant traversals.
@@ -792,18 +902,29 @@ not a symmetric algorithm.
public key from a WIT within the trust domain.
Retrieve the public key identified by "kid" and verify the JWS
signature per Section 5.2.
+ Verify that the signing key identified by "kid" has not been
+revoked within the trust domain. Implementations MUST check
+the key's revocation status using the trust domain's key
+lifecycle mechanism (e.g., certificate revocation list, OCSP,
+or SPIFFE trust bundle updates).Verify the "alg" header parameter matches the algorithm in the
corresponding WIT.Verify the "iss" claim matches the "sub" claim of the WIT
associated with the "kid" public key.Verify the "aud" claim contains the verifier's own workload
-identity or an expected recipient identifier.
+identity. When "aud" is an array, it is sufficient that the
+verifier's identity appears as one element; the presence of
+other audience values does not cause verification failure.
+When the verifier is the audit ledger, the ledger's own
+identity MUST appear in "aud".
Verify the "exp" claim indicates the ECT has not expired.Verify the "iat" claim is not unreasonably far in the past
(implementation-specific threshold, RECOMMENDED maximum of
-15 minutes).
- Verify all required claims ("tid", "exec_act", "par", "pol",
-"pol_decision") are present and well-formed.
+15 minutes) and is not unreasonably far in the future
+(RECOMMENDED: no more than 30 seconds ahead of the
+verifier's current time, to account for clock skew).
+ Verify all required claims ("jti", "tid", "exec_act", "par",
+"pol", "pol_decision") are present and well-formed.Verify "pol_decision" is one of "approved", "rejected", or
"pending_human_review".Perform DAG validation per .
@@ -816,6 +937,15 @@ failure MUST be logged for audit purposes. Error messages
SHOULD NOT reveal whether specific parent task IDs exist in the
ledger, to prevent information disclosure.
+When ECT verification fails during HTTP request processing, the
+receiving agent SHOULD respond with HTTP 403 (Forbidden) if the
+WIT and WPT are valid but the ECT is invalid, and HTTP 401
+(Unauthorized) if the ECT signature verification fails. The
+response body SHOULD include a generic error indicator without
+revealing which specific verification step failed. The receiving
+agent MUST NOT process the requested action when ECT verification
+fails.
+
Verification Pseudocode
@@ -842,6 +972,10 @@ function verify_ect(ect_jws, verifier_id,
signature, public_key):
return reject("Invalid signature")
+ // Verify key not revoked
+ if is_key_revoked(header.kid, trust_domain_keys):
+ return reject("Signing key has been revoked")
+
// Verify algorithm alignment
wit = get_wit_for_key(header.kid)
if header.alg != wit.alg:
@@ -859,12 +993,14 @@ function verify_ect(ect_jws, verifier_id,
if payload.exp < current_time():
return reject("ECT has expired")
- // Verify iat freshness
+ // Verify iat freshness (not too old, not in the future)
if payload.iat < current_time() - max_age_threshold:
return reject("ECT issued too long ago")
+ if payload.iat > current_time() + clock_skew_tolerance:
+ return reject("ECT issued in the future")
// Verify required claims
- for claim in ["tid", "exec_act", "par",
+ for claim in ["jti", "tid", "exec_act", "par",
"pol", "pol_decision"]:
if claim not in payload:
return reject("Missing required claim: " + claim)
@@ -942,7 +1078,10 @@ workflow agents to reduce the risk of collusion.
and is the authoritative record. The other fields ("agent_id",
"action", "parents") are convenience indexes derived from the
ECT payload; if they disagree with the JWS payload, the JWS
-payload takes precedence.
+payload takes precedence. Implementations SHOULD validate that
+convenience index fields match the corresponding values in the
+JWS payload at write time to prevent desynchronization between
+the authoritative JWS and the indexed fields.
@@ -955,8 +1094,8 @@ include additional domain-specific requirements beyond the scope
of this specification.
Note: task identifiers in this section are abbreviated for
-readability. In production, all "tid" values MUST be UUIDs per
-.
+readability. In production, all "tid" values are required to be
+UUIDs per .
Medical Device SDLC Workflow
@@ -1095,9 +1234,9 @@ a cryptographic link to the original task:
"par": ["550e8400-e29b-41d4-a716-446655440003"],
"pol": "compensation_policy_v1",
"pol_decision": "approved",
- "pol_enforcer": "spiffe://bank.com/human/compliance-officer",
+ "pol_enforcer": "spiffe://bank.example/human/compliance-officer",
"compensation_required": true,
"compensation_reason": "policy_violation_in_parent_trade"
}
@@ -1119,7 +1258,7 @@ violation discovery to remediation.
Autonomous Logistics Coordination
-In a logistics workflow, multiple compliance checks must complete
+In a logistics workflow, multiple compliance checks complete
before shipment commitment. The DAG structure records that all
required checks were completed:
@@ -1198,8 +1337,42 @@ evaluating the policy).
of the signing agent. To mitigate single-agent false claims,
regulated environments SHOULD use the "witnessed_by" mechanism
to include independent third-party observers at critical decision
-points.
+points. However, the "witnessed_by" claim is self-asserted by
+the ECT issuer: the listed witnesses do not co-sign the ECT and
+there is no cryptographic proof within a single ECT that the
+witnesses actually observed the task. An issuing agent could
+list witnesses that did not participate.
+Witness Attestation Model
+
+To address the self-assertion limitation of the "witnessed_by"
+claim, witnesses SHOULD submit their own independent signed ECTs
+to the audit ledger attesting to the observed task. A witness
+attestation ECT:
+
+
+ MUST set "iss" to the witness's own workload identity.
+ MUST set "exec_act" to "witness_attestation" (or a domain-
+specific equivalent).
+ MUST include the observed task's "tid" in the "par" array,
+linking the attestation to the original task.
+ MUST set "pol_decision" to "approved" to indicate the witness
+confirms the observation.
+
+
+When a task's "witnessed_by" claim lists one or more witnesses,
+auditors SHOULD verify that corresponding witness attestation
+ECTs exist in the ledger for each listed witness. A mismatch
+between the "witnessed_by" list and the set of independent witness
+ECTs in the ledger SHOULD be flagged during audit review.
+
+This model converts witness attestation from a self-asserted claim
+to a cryptographically verifiable property of the ledger: the
+witness independently signs their own ECT using their own key,
+and the ledger records both the original task ECT and the witness
+attestation ECTs.
+
+Organizational Prerequisites
@@ -1226,10 +1399,12 @@ in a manner that preserves their integrity.
specified in the agent's WIT. Receivers MUST verify the ECT
signature against the WIT public key before processing any
claims. Receivers MUST verify that the signing key has not been
-revoked within the trust domain.
+revoked within the trust domain (see step 6 in
+).
-If signature verification fails, the ECT MUST be rejected entirely
-and the failure MUST be logged.
+If signature verification fails or if the signing key has been
+revoked, the ECT MUST be rejected entirely and the failure MUST
+be logged.Implementations MUST use established JWS libraries and MUST NOT
implement custom signature verification.
@@ -1247,9 +1422,9 @@ reject ECTs that are too old, even if not yet expired.
referencing parent tasks that already have a recorded child task
with the same action can be flagged as a potential replay.
-Implementations SHOULD maintain a cache of recently-seen "jti"
-values (when present) to detect replayed ECTs within the
-expiration window.
+Implementations MUST maintain a cache of recently-seen "jti"
+values to detect replayed ECTs within the expiration window.
+An ECT with a duplicate "jti" value MUST be rejected.Man-in-the-Middle Protection
@@ -1336,6 +1511,12 @@ judgments. Implementations SHOULD use synchronized time sources
(e.g., NTP) and SHOULD allow a configurable clock skew tolerance
(RECOMMENDED: 30 seconds).
+Cross-organizational deployments where agents span multiple trust
+domains with independent time sources MAY require a higher clock
+skew tolerance. Deployments using trust domain federation SHOULD
+document their configured clock skew tolerance value and SHOULD
+ensure all participating trust domains agree on a common tolerance.
+
The temporal ordering check in DAG validation incorporates the
clock skew tolerance to account for minor clock differences
between agents.
@@ -1345,8 +1526,11 @@ between agents.
ECTs with many parent tasks or large extension objects can
increase HTTP header size. Implementations SHOULD limit the "par"
-array to a reasonable size and SHOULD set maximum size limits for
-the "ext" object to prevent abuse.
+array to a maximum of 256 entries. Workflows requiring more
+parent references SHOULD introduce intermediate aggregation
+tasks. The "ext" object SHOULD NOT exceed 4096 bytes when
+serialized as JSON and SHOULD NOT exceed a nesting depth of
+5 levels (see also ).
@@ -1383,6 +1567,16 @@ The "exec_act" claim SHOULD use structured identifiers (e.g.,
The "pol" claim SHOULD reference policy identifiers rather than
embedding policy content.
+The "compensation_reason" claim ()
+deserves particular attention: because it is human-readable and
+may describe the circumstances of a failure or policy violation,
+it risks exposing sensitive operational details. Implementations
+SHOULD use short, structured reason codes (e.g.,
+"policy_violation_in_parent_trade") rather than free-form
+natural language explanations. Implementers SHOULD review
+"compensation_reason" values for potential information leakage
+before deploying to production.
+
Storage and Access Control
@@ -1582,6 +1776,66 @@ the "JSON Web Token Claims" registry maintained by IANA:
Compensation ReasonIETF
+ ext
+ Extension Object
+ IETF
+
+
+
+
+ECT Policy Decision Values Registry
+
+This document establishes the "ECT Policy Decision Values"
+registry under the "JSON Web Token (JWT)" group. Registration
+policy is Specification Required per .
+
+The initial contents of the registry are:
+
+
+ Value
+ Description
+ Change Controller
+ Reference
+ approved
+ Policy evaluation succeeded
+ IETF
+
+ rejected
+ Policy evaluation failed
+ IETF
+
+ pending_human_review
+ Awaiting human judgment
+ IETF
+
+
+
+
+ECT Regulated Domain Values Registry
+
+This document establishes the "ECT Regulated Domain Values"
+registry under the "JSON Web Token (JWT)" group. Registration
+policy is Specification Required per .
+
+The initial contents of the registry are:
+
+
+ Value
+ Description
+ Change Controller
+ Reference
+ medtech
+ Medical technology and devices
+ IETF
+
+ finance
+ Financial services and trading
+ IETF
+
+ military
+ Military and defense
+ IETF
+
@@ -1599,45 +1853,6 @@ the "JSON Web Token Claims" registry maintained by IANA:
-
-
- Key words for use in RFCs to Indicate Requirement Levels
-
-
-
- In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
-
-
-
-
-
-
-
-
- Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
-
-
-
- RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
-
-
-
-
-
-
-
-
- Date and Time on the Internet: Timestamps
-
-
-
-
- This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
-
-
-
-
-JSON Web Signature (JWS)
@@ -1652,6 +1867,18 @@ the "JSON Web Token Claims" registry maintained by IANA:
+
+
+ JSON Web Key (JWK)
+
+
+
+ A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.
+
+
+
+
+JSON Web Token (JWT)
@@ -1786,6 +2013,49 @@ been incorporated into this document. This document obsoletes RFC
+
+
+ Key words for use in RFCs to Indicate Requirement Levels
+
+
+
+ In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
+
+
+
+
+
+
+
+
+ Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
+
+
+
+ RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
+
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+
@@ -1809,18 +2079,6 @@ been incorporated into this document. This document obsoletes RFC
-
-
- JSON Web Key (JWK)
-
-
-
- A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.
-
-
-
-
-OAuth 2.0 Token Exchange
@@ -1982,7 +2240,7 @@ been incorporated into this document. This document obsoletes RFC
-
+
Related Work
@@ -2069,11 +2327,12 @@ use cases are distinct.
Minimal Implementation
-A minimal conforming implementation should:
+A minimal conforming implementation needs to:Create JWTs with all required claims ("iss", "aud", "iat",
-"exp", "tid", "exec_act", "par", "pol", "pol_decision").
+"exp", "jti", "tid", "exec_act", "par", "pol",
+"pol_decision").Sign ECTs with the agent's private key using an algorithm
matching the WIT (ES256 recommended).Verify ECT signatures against WIT public keys.
@@ -2112,10 +2371,11 @@ latency.
Interoperability
-Implementations should use established JWT/JWS libraries (JOSE)
-for token creation and verification. Custom cryptographic
-implementations should not be used. Implementations should be
-tested against multiple JWT libraries to ensure interoperability.
+Implementations are expected to use established JWT/JWS libraries
+(JOSE) for token creation and verification. Custom cryptographic
+implementations are strongly discouraged. Implementations are
+expected to be tested against multiple JWT libraries to ensure
+interoperability.
@@ -2418,447 +2678,525 @@ tracing is built.