From bf0f94ab3044dc492774179bbc320edfac8a9497 Mon Sep 17 00:00:00 2001 From: Christian Nennemann Date: Wed, 25 Feb 2026 12:38:14 +0100 Subject: [PATCH] Simplify spec: remove sub, move compensation and policy to ext - Remove sub claim (always equals iss, added no information) - Move compensation_required and compensation_reason to ext keys - Move pol, pol_decision, pol_enforcer to ext keys - IANA JWT Claims table reduced from 11 to 6 registered claims - Trim witness attestation section to concise guidance - Fix remaining ledger-mandatory language in verification step 15 and minimal implementation guidance Co-Authored-By: Claude Opus 4.6 --- ...-nennemann-wimse-execution-context-00.html | 521 +++--- draft-nennemann-wimse-execution-context-00.md | 342 ++-- ...t-nennemann-wimse-execution-context-00.txt | 1166 +++++++------- ...t-nennemann-wimse-execution-context-00.xml | 1423 ++++++++--------- 4 files changed, 1679 insertions(+), 1773 deletions(-) diff --git a/draft-nennemann-wimse-execution-context-00.html b/draft-nennemann-wimse-execution-context-00.html index 2f1d326..dc05a10 100644 --- a/draft-nennemann-wimse-execution-context-00.html +++ b/draft-nennemann-wimse-execution-context-00.html @@ -1242,7 +1242,7 @@ li > p:last-of-type:only-child { Nennemann -Expires 28 August 2026 +Expires 29 August 2026 [Page] @@ -1255,12 +1255,12 @@ li > p:last-of-type:only-child {
draft-nennemann-wimse-execution-context-00
Published:
- +
Intended Status:
Standards Track
Expires:
-
+
Author:
@@ -1312,7 +1312,7 @@ regulatory frameworks.

time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

- This Internet-Draft will expire on 28 August 2026.

+ This Internet-Draft will expire on 29 August 2026.

-
sub:
+
aud:
-

OPTIONAL. StringOrURI. The subject of the ECT. When present, -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 +

REQUIRED. StringOrURI or array of StringOrURI. The intended 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:

+practice this means:

    -
  • -

    Point-to-point delivery: when an ECT is sent from one +

  • +

    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.

    +forwards it to the ledger on behalf of the issuer.

    • -
  • -

    Direct-to-ledger submission: when an ECT is submitted +

  • +

    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.

    +workflow completion), "aud" contains the ledger's identity.

    • -
  • -

    Multi-audience: when an ECT must be verified by both the +

  • +

    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.

    +that its own identity appears in the array.

-

In multi-parent (join) scenarios where a task depends on ECTs +

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.

+parent ECTs.

-
iat:
-
-

REQUIRED. NumericDate. The time at which the ECT was issued. +

iat:
+
+

REQUIRED. NumericDate. The time at which the ECT was issued. The ECT records a completed action, so the "iat" value reflects -when the record was created, not when task execution began.

+when the record was created, not when task execution began.

-
exp:
-
-

REQUIRED. NumericDate. The expiration time of the ECT. +

exp:
+
+

REQUIRED. NumericDate. The expiration time of the ECT. 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.

+skew and processing time.

@@ -2186,70 +2173,73 @@ multiple root tasks.

-

-4.2.3. Policy Evaluation +

+4.2.3. Policy Evaluation Extension Keys

-

The following claims record policy evaluation outcomes:

-
-
pol:
-
-

OPTIONAL. String. The identifier of the policy rule that was -evaluated for this task (e.g., -"clinical_data_access_policy_v1"). MUST be present when -"pol_decision" is present.

+

Policy evaluation outcomes are recorded as extension keys within +the "ext" object (Section 4.2.6). This keeps the core +registered claims focused on DAG structure and execution context, +while allowing deployments to add policy recording as needed.

+

The following extension keys are defined for policy evaluation:

+
+
"pol":
+
+

String. The identifier of the policy rule that was evaluated +for this task (e.g., "clinical_data_access_policy_v1"). MUST +be present when "pol_decision" is present.

-
pol_decision:
-
-

OPTIONAL. String. The result of the policy evaluation. When -present, MUST be one of the values registered in the ECT Policy -Decision Values registry (Section 12.4). MUST be -present when "pol" is present. Initial values are:

+
"pol_decision":
+
+

String. The result of the policy evaluation. When present, +MUST be one of the values registered in the ECT Policy Decision +Values registry (Section 12.4). MUST be present +when "pol" is present. Initial values are:

    -
  • -

    "approved": The policy evaluation succeeded and the task -was authorized to proceed.

    +
  • +

    "approved": The policy evaluation succeeded and the task +was authorized to proceed.

    • -
  • -

    "rejected": The policy evaluation failed. A "rejected" ECT +

  • +

    "rejected": The policy evaluation failed. A "rejected" ECT MUST still be recorded 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".

    +"pol_decision" is "rejected".

    • -
  • -

    "pending_human_review": The policy evaluation requires human +

  • +

    "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.

    +parent.

-

When "pol" and "pol_decision" are absent, the ECT records task -execution without a policy checkpoint. Regulated deployments -SHOULD include policy claims on all ECTs to maintain complete -audit trails.

+

When "pol" and "pol_decision" are absent from "ext", the ECT +records task execution without a policy checkpoint. Regulated +deployments SHOULD include policy keys on all ECTs to maintain +complete audit trails.

-
pol_enforcer:
-
-

OPTIONAL. StringOrURI. The identity of the entity (system or -person) that evaluated the policy decision. When present, -SHOULD use SPIFFE ID format.

+
"pol_enforcer":
+
+

StringOrURI. The identity of the entity (system or person) +that evaluated the policy decision. When present, SHOULD use +SPIFFE ID format.

-

This specification intentionally defines only the recording of +

This specification intentionally defines only the recording of policy evaluation outcomes. The mechanisms by which policies are defined, distributed to agents, and evaluated are out of scope. -The "pol" claim is an opaque identifier referencing an external +The "pol" key is an opaque identifier referencing an external policy; the semantics and enforcement of that policy are determined by the deployment environment. Implementations may use any policy engine or framework (e.g., OPA/Rego, Cedar, XACML, or custom solutions) provided that the evaluation outcome is -faithfully recorded in the ECT claims defined above.

+faithfully recorded in the "ext" keys defined above.

@@ -2288,31 +2278,12 @@ using the same format and algorithm requirements as "inp_hash". 4.2.5. Compensation and Rollback -
-
compensation_required:
-
-

OPTIONAL. Boolean. Indicates whether this task is a -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. -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 -"exp" time; ECT expiration applies to the verification window of -the ECT itself, not to its validity as a parent reference in the -ledger.

+

Compensation and rollback actions are recorded using the "par" +claim to reference the original task and the "exec_act" claim to +describe the remediation action. The referenced parent ECTs may +have passed their own "exp" time; ECT expiration applies to the +verification window of the ECT itself, not to its validity as a +parent reference in the ECT store.

@@ -2340,31 +2311,57 @@ levels. Implementations SHOULD reject ECTs whose "ex exceeds these limits.

The following extension keys are defined by this specification for common use cases. Because these keys are documented here, -they use short names without reverse domain prefixes:

+they use short names without reverse domain prefixes.

+

Policy evaluation keys (see Section 4.2.3 for full +definitions and decision value semantics):

    -
  • -

    "exec_time_ms": Integer. Execution duration in milliseconds.

    +
  • +

    "pol": String. Policy rule identifier.

    • -
  • -

    "regulated_domain": String. Regulatory domain (e.g., -"medtech", "finance", "military").

    +
  • +

    "pol_decision": String. Policy evaluation outcome +("approved", "rejected", or "pending_human_review").

    • -
  • -

    "model_version": String. AI/ML model version.

    +
  • +

    "pol_enforcer": StringOrURI. Identity of the policy +evaluator.

    • -
  • -

    "witnessed_by": Array of StringOrURI. Identifiers of +

  • +

    "pol_timestamp": NumericDate. Time at which the policy +decision was made, if distinct from "iat".

    +
    • +
+

Operational metadata keys:

+
    +
  • +

    "exec_time_ms": Integer. Execution duration in milliseconds.

    +
    • +
  • +

    "regulated_domain": String. Regulatory domain (e.g., +"medtech", "finance", "military").

    +
    • +
  • +

    "model_version": String. AI/ML model version.

    +
    • +
  • +

    "witnessed_by": Array of StringOrURI. Identifiers of third-party entities that the issuer claims observed the task. Note: this is self-asserted; for verifiable witness -attestation, witnesses should submit independent signed ECTs.

    +attestation, witnesses should submit independent signed ECTs.

    • -
  • -

    "inp_classification": String. Data sensitivity classification -(e.g., "public", "confidential", "restricted").

    +
  • +

    "inp_classification": String. Data sensitivity classification +(e.g., "public", "confidential", "restricted").

    • -
  • -

    "pol_timestamp": NumericDate. Time at which the policy -decision was made, if distinct from "iat".

    +
  • +

    "compensation_required": Boolean. Indicates whether this task +is a compensation or rollback action.

    +
    • +
  • +

    "compensation_reason": String. Structured reason code for the +compensation action (e.g., "policy_violation_in_parent_trade"). +SHOULD use structured identifiers rather than free-form text +to minimize information leakage (see Section 11.2).

@@ -2383,7 +2380,6 @@ decision was made, if distinct from "iat".MUST be rejected.

  • -

    Parent Policy Decision: If any parent ECT contains a -"pol_decision" of "rejected" or "pending_human_review", the -current ECT'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. This rule only applies when the parent ECT -contains policy claims.

    +

    Parent Policy Decision: If any parent ECT's "ext" object +contains a "pol_decision" of "rejected" or +"pending_human_review", the current ECT'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". This rule only applies +when the parent ECT's "ext" contains policy keys.

  • Trust Domain Consistency: Parent tasks SHOULD belong to the @@ -2678,22 +2672,22 @@ verifier's current time, to account for clock skew).

  • -

    If "pol" or "pol_decision" is present, verify that both are -present and that "pol_decision" is one of "approved", -"rejected", or "pending_human_review".

    +

    If "ext" is present and contains "pol" or "pol_decision", +verify that both are present and that "pol_decision" is one +of "approved", "rejected", or "pending_human_review".

  • Perform DAG validation per Section 6.

  • -

    If all checks pass, the ECT MUST be appended to the audit -ledger.

    +

    If all checks pass and an audit ledger is deployed, the ECT +SHOULD be appended to the ledger.

    • If any verification step fails, the ECT MUST be rejected and the 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.

    +ECT store, to prevent information disclosure.

    When ECT verification fails during HTTP request processing, the receiving agent SHOULD respond with HTTP 403 (Forbidden) if the WIT is valid but the ECT is invalid, and HTTP 401 @@ -2767,11 +2761,12 @@ function verify_ect(ect_jws, verifier_id, if claim not in payload: return reject("Missing required claim: " + claim) - // Validate policy claims (optional, but must be paired) - if "pol" in payload or "pol_decision" in payload: - if "pol" not in payload or "pol_decision" not in payload: + // Validate policy extension keys (optional, but must be paired) + ext = payload.ext or {} + if "pol" in ext or "pol_decision" in ext: + if "pol" not in ext or "pol_decision" not in ext: return reject("pol and pol_decision must both be present") - if payload.pol_decision not in + if ext.pol_decision not in ["approved", "rejected", "pending_human_review"]: return reject("Invalid pol_decision value") @@ -2862,29 +2857,34 @@ software used in medical devices. Agent A (Spec Reviewer): jti: task-001 par: [] exec_act: review_requirements_spec - pol: spec_review_policy_v2 pol_decision: approved + ext.pol: spec_review_policy_v2 + ext.pol_decision: approved Agent B (Code Generator): jti: task-002 par: [task-001] exec_act: implement_module - pol: coding_standards_v3 pol_decision: approved + ext.pol: coding_standards_v3 + ext.pol_decision: approved Agent C (Test Agent): jti: task-003 par: [task-002] exec_act: execute_test_suite - pol: test_coverage_policy_v1 pol_decision: approved + ext.pol: test_coverage_policy_v1 + ext.pol_decision: approved Agent D (Build Agent): jti: task-004 par: [task-003] exec_act: build_release_artifact - pol: build_validation_v2 pol_decision: approved + ext.pol: build_validation_v2 + ext.pol_decision: approved Human Release Manager: jti: task-005 par: [task-004] exec_act: approve_release - pol: release_approval_policy pol_decision: approved - pol_enforcer: spiffe://meddev.example/human/release-mgr-42 - ext: {witnessed_by: [...]} (extension metadata) + ext.pol: release_approval_policy + ext.pol_decision: approved + ext.pol_enforcer: spiffe://meddev.example/human/release-mgr-42 + ext.witnessed_by: [...]

    Figure 8: @@ -2987,17 +2987,20 @@ execution.

    Agent A (Risk Assessment): jti: task-001 par: [] exec_act: calculate_risk_exposure - pol: risk_limits_policy_v2 pol_decision: approved + ext.pol: risk_limits_policy_v2 + ext.pol_decision: approved Agent B (Compliance): jti: task-002 par: [task-001] exec_act: verify_compliance - pol: compliance_check_v1 pol_decision: approved + ext.pol: compliance_check_v1 + ext.pol_decision: approved Agent C (Execution): jti: task-003 par: [task-002] exec_act: execute_trade - pol: execution_policy_v3 pol_decision: approved + ext.pol: execution_policy_v3 + ext.pol_decision: approved
    Figure 10: @@ -3034,7 +3037,6 @@ a cryptographic link to the original task: @@ -3074,27 +3078,32 @@ required checks were completed:
    Figure 12: @@ -3149,8 +3158,8 @@ to alter perceived execution ordering.ECTs are self-asserted by the executing agent. The agent claims what it did, and this claim is signed with its private key. A compromised or malicious agent could create ECTs with false claims -(e.g., setting "pol_decision" to "approved" without actually -evaluating the policy).

    +(e.g., setting "pol_decision" in "ext" to "approved" without +actually evaluating the policy).

    ECTs do not independently verify that:

    • @@ -3176,44 +3185,11 @@ witnesses do not co-sign the ECT and there is no cryptographic evidence 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" extension, 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 "jti" 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" extension 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 extension value 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.

      -
      -
      +

      To strengthen witness attestation beyond self-assertion, witnesses +SHOULD submit their own independent signed ECTs referencing the +observed task's "jti" in the "par" array. Auditors can then +cross-check the "witnessed_by" extension against independent +witness ECTs in the ECT store.

      @@ -3439,8 +3415,8 @@ serialized as JSON and SHOULD NOT exceed a nesting de

      Action descriptions ("exec_act") for audit trail completeness

    • -

      Policy evaluation outcomes ("pol", "pol_decision") for -compliance verification

      +

      Policy evaluation outcomes (via "ext" keys "pol", +"pol_decision") when present, for compliance verification

    • Timestamps ("iat", "exp") for temporal ordering

      @@ -3472,17 +3448,13 @@ hashes via "inp_hash" and "out_hash")Implementations SHOULD minimize the information included in ECTs. The "exec_act" claim SHOULD use structured identifiers (e.g., "process_payment") rather than natural language descriptions. -The "pol" claim SHOULD reference policy identifiers rather than -embedding policy content.

      -

      The "compensation_reason" claim (Section 4.2.5) -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.

      +The "pol" extension key SHOULD reference policy identifiers +rather than embedding policy content.

      +

      The "compensation_reason" extension key in "ext" +(Section 4.2.5) deserves particular attention: because +it is human-readable, it risks exposing sensitive operational +details. See Section 4.2.6 for guidance on using +structured identifiers.

      @@ -3680,30 +3652,6 @@ the "JSON Web Token Claims" registry maintained by IANA:IETF Section 4.2.2 - - - - pol - Policy Rule Identifier - IETF - - Section 4.2.3 - - - - pol_decision - Policy Decision Result - IETF - - Section 4.2.3 - - - - pol_enforcer - Policy Enforcer Identity - IETF - - Section 4.2.3 @@ -3720,22 +3668,6 @@ the "JSON Web Token Claims" registry maintained by IANA:IETF Section 4.2.4 - - - - compensation_required - Compensation Flag - IETF - - Section 4.2.5 - - - - compensation_reason - Compensation Reason - IETF - - Section 4.2.5 @@ -3749,6 +3681,10 @@ the "JSON Web Token Claims" registry maintained by IANA:Note: Policy evaluation keys ("pol", "pol_decision", +"pol_enforcer") are carried within the "ext" object as +spec-defined extension keys (Section 4.2.3) and do not +require separate JWT Claims registration.

      @@ -4101,8 +4037,9 @@ use cases are distinct.

      1. Create JWTs with all required claims ("iss", "aud", "iat", -"exp", "jti", "exec_act", "par") and policy claims ("pol", -"pol_decision") when policy evaluation was performed.

        +"exp", "jti", "exec_act", "par") and policy extension keys +("ext.pol", "ext.pol_decision") when policy evaluation was +performed.

      2. Sign ECTs with the agent's private key using an algorithm @@ -4116,7 +4053,7 @@ matching the WIT (ES256 recommended).

      3. -

        Append verified ECTs to the audit ledger.

        +

        If an audit ledger is deployed, append verified ECTs to it.

      @@ -4269,7 +4206,6 @@ Agent B:

       {
   "iss": "spiffe://example.com/agent/data-retrieval",
-  "sub": "spiffe://example.com/agent/data-retrieval",
   "aud": "spiffe://example.com/agent/validator",
   "iat": 1772064150,
   "exp": 1772064750,
@@ -4277,10 +4213,12 @@ Agent B:
      
   "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
   "exec_act": "fetch_patient_data",
   "par": [],
-  "pol": "clinical_data_access_policy_v1",
-  "pol_decision": "approved",
   "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
+  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
+  "ext": {
+    "pol": "clinical_data_access_policy_v1",
+    "pol_decision": "approved"
+  }
 }
      @@ -4290,7 +4228,6 @@ task, and creates its own ECT: { "iss": "spiffe://example.com/agent/validator", - "sub": "spiffe://example.com/agent/validator", "aud": "spiffe://example.com/system/ledger", "iat": 1772064160, "exp": 1772064760, @@ -4298,8 +4235,10 @@ task, and creates its own ECT: @@ -4326,7 +4265,6 @@ autonomous agents and human release approval: @@ -4346,7 +4286,6 @@ autonomous agents and human release approval: @@ -4364,7 +4305,6 @@ autonomous agents and human release approval: @@ -4382,7 +4324,6 @@ autonomous agents and human release approval: @@ -4401,7 +4344,6 @@ autonomous agents and human release approval: { "iss": "spiffe://bank.example/agent/execution", - "sub": "spiffe://bank.example/agent/execution", "aud": "spiffe://bank.example/system/ledger", "iat": 1772064250, "exp": 1772064850, @@ -4485,8 +4426,10 @@ task-...-0004 (execute_trade) "f1e2d3c4-0002-0000-0000-000000000002", "f1e2d3c4-0003-0000-0000-000000000003" ], - "pol": "trade_execution_policy_v3", - "pol_decision": "approved" + "ext": { + "pol": "trade_execution_policy_v3", + "pol_decision": "approved" + } } diff --git a/draft-nennemann-wimse-execution-context-00.md b/draft-nennemann-wimse-execution-context-00.md index afecb3b..92f290d 100644 --- a/draft-nennemann-wimse-execution-context-00.md +++ b/draft-nennemann-wimse-execution-context-00.md @@ -167,7 +167,7 @@ This document defines: - The Execution Context Token (ECT) format ({{ect-format}}) - DAG structure for task dependency ordering ({{dag-validation}}) -- Policy checkpoint recording ({{policy-claims}}) +- Policy checkpoint recording via extension keys ({{policy-claims}}) - Integration with the WIMSE identity framework ({{wimse-integration}}) - An HTTP header for ECT transport ({{http-header}}) @@ -403,12 +403,6 @@ iss: deployments MAY use other URI schemes (e.g., HTTPS URLs or URN:UUID identifiers). -sub: -: OPTIONAL. StringOrURI. The subject of the ECT. When present, - MUST equal the "iss" claim. This claim is included for - 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. Because ECTs serve as both inter-agent @@ -489,21 +483,25 @@ par: a root task with no dependencies. A workflow MAY contain multiple root tasks. -### Policy Evaluation {#policy-claims} +### Policy Evaluation Extension Keys {#policy-claims} -The following claims record policy evaluation outcomes: +Policy evaluation outcomes are recorded as extension keys within +the "ext" object ({{extension-claims}}). This keeps the core +registered claims focused on DAG structure and execution context, +while allowing deployments to add policy recording as needed. -pol: -: OPTIONAL. String. The identifier of the policy rule that was - evaluated for this task (e.g., - "clinical_data_access_policy_v1"). MUST be present when - "pol_decision" is present. +The following extension keys are defined for policy evaluation: -pol_decision: -: OPTIONAL. String. The result of the policy evaluation. When - present, MUST be one of the values registered in the ECT Policy - Decision Values registry ({{pol-decision-registry}}). MUST be - present when "pol" is present. Initial values are: +"pol": +: String. The identifier of the policy rule that was evaluated + for this task (e.g., "clinical_data_access_policy_v1"). MUST + be present when "pol_decision" is present. + +"pol_decision": +: String. The result of the policy evaluation. When present, + MUST be one of the values registered in the ECT Policy Decision + Values registry ({{pol-decision-registry}}). MUST be present + when "pol" is present. Initial values are: * "approved": The policy evaluation succeeded and the task was authorized to proceed. @@ -522,25 +520,25 @@ pol_decision: records an "approved" decision referencing this task as a parent. - When "pol" and "pol_decision" are absent, the ECT records task - execution without a policy checkpoint. Regulated deployments - SHOULD include policy claims on all ECTs to maintain complete - audit trails. + When "pol" and "pol_decision" are absent from "ext", the ECT + records task execution without a policy checkpoint. Regulated + deployments SHOULD include policy keys on all ECTs to maintain + complete audit trails. -pol_enforcer: -: OPTIONAL. StringOrURI. The identity of the entity (system or - person) that evaluated the policy decision. When present, - SHOULD use SPIFFE ID format. +"pol_enforcer": +: StringOrURI. The identity of the entity (system or person) + that evaluated the policy decision. When present, SHOULD use + SPIFFE ID format. This specification intentionally defines only the recording of policy evaluation outcomes. The mechanisms by which policies are defined, distributed to agents, and evaluated are out of scope. -The "pol" claim is an opaque identifier referencing an external +The "pol" key is an opaque identifier referencing an external policy; the semantics and enforcement of that policy are determined by the deployment environment. Implementations may use any policy engine or framework (e.g., OPA/Rego, Cedar, XACML, or custom solutions) provided that the evaluation outcome is -faithfully recorded in the ECT claims defined above. +faithfully recorded in the "ext" keys defined above. ### Data Integrity {#data-integrity-claims} @@ -565,25 +563,12 @@ out_hash: ### Compensation and Rollback {#compensation-claims} -compensation_required: -: OPTIONAL. Boolean. Indicates whether this task is a - 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. - 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 -"exp" time; ECT expiration applies to the verification window of -the ECT itself, not to its validity as a parent reference in the -ledger. +Compensation and rollback actions are recorded using the "par" +claim to reference the original task and the "exec_act" claim to +describe the remediation action. The referenced parent ECTs may +have passed their own "exp" time; ECT expiration applies to the +verification window of the ECT itself, not to its validity as a +parent reference in the ECT store. ### Extensions {#extension-claims} @@ -604,7 +589,20 @@ exceeds these limits. The following extension keys are defined by this specification for common use cases. Because these keys are documented here, -they use short names without reverse domain prefixes: +they use short names without reverse domain prefixes. + +Policy evaluation keys (see {{policy-claims}} for full +definitions and decision value semantics): + +- "pol": String. Policy rule identifier. +- "pol\_decision": String. Policy evaluation outcome + ("approved", "rejected", or "pending\_human\_review"). +- "pol\_enforcer": StringOrURI. Identity of the policy + evaluator. +- "pol\_timestamp": NumericDate. Time at which the policy + decision was made, if distinct from "iat". + +Operational metadata keys: - "exec\_time\_ms": Integer. Execution duration in milliseconds. - "regulated\_domain": String. Regulatory domain (e.g., @@ -616,8 +614,12 @@ they use short names without reverse domain prefixes: attestation, witnesses should submit independent signed ECTs. - "inp\_classification": String. Data sensitivity classification (e.g., "public", "confidential", "restricted"). -- "pol\_timestamp": NumericDate. Time at which the policy - decision was made, if distinct from "iat". +- "compensation\_required": Boolean. Indicates whether this task + is a compensation or rollback action. +- "compensation\_reason": String. Structured reason code for the + compensation action (e.g., "policy\_violation\_in\_parent\_trade"). + SHOULD use structured identifiers rather than free-form text + to minimize information leakage (see {{data-minimization}}). ## Complete ECT Example @@ -626,7 +628,6 @@ The following is a complete ECT payload example: ~~~json { "iss": "spiffe://example.com/agent/clinical", - "sub": "spiffe://example.com/agent/clinical", "aud": "spiffe://example.com/agent/safety", "iat": 1772064150, "exp": 1772064750, @@ -636,14 +637,13 @@ The following is a complete ECT payload example: "exec_act": "recommend_treatment", "par": [], - "pol": "clinical_reasoning_policy_v2", - "pol_decision": "approved", - "pol_enforcer": "spiffe://example.com/policy/clinical-engine", - "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", "ext": { + "pol": "clinical_reasoning_policy_v2", + "pol_decision": "approved", + "pol_enforcer": "spiffe://example.com/policy/clinical-engine", "pol_timestamp": 1772064145, "exec_time_ms": 245, "regulated_domain": "medtech", @@ -733,15 +733,14 @@ the following DAG validation steps: lead back to the current ECT's "jti". If a cycle is detected, the ECT MUST be rejected. -5. Parent Policy Decision: If any parent ECT contains a - "pol_decision" of "rejected" or "pending_human_review", the - current ECT'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. This rule only applies when the parent ECT - contains policy claims. +5. Parent Policy Decision: If any parent ECT's "ext" object + contains a "pol_decision" of "rejected" or + "pending_human_review", the current ECT'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". This rule only applies + when the parent ECT's "ext" contains policy keys. 6. Trust Domain Consistency: Parent tasks SHOULD belong to the same trust domain or to a trust domain with which a federation @@ -856,19 +855,19 @@ verification steps in order: 12. Verify all required claims ("jti", "exec_act", "par") are present and well-formed. -13. If "pol" or "pol_decision" is present, verify that both are - present and that "pol_decision" is one of "approved", - "rejected", or "pending_human_review". +13. If "ext" is present and contains "pol" or "pol_decision", + verify that both are present and that "pol_decision" is one + of "approved", "rejected", or "pending_human_review". 14. Perform DAG validation per {{dag-validation}}. -15. If all checks pass, the ECT MUST be appended to the audit - ledger. +15. If all checks pass and an audit ledger is deployed, the ECT + SHOULD be appended to the ledger. If any verification step fails, the ECT MUST be rejected and the 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. +ECT store, to prevent information disclosure. When ECT verification fails during HTTP request processing, the receiving agent SHOULD respond with HTTP 403 (Forbidden) if the @@ -936,11 +935,12 @@ function verify_ect(ect_jws, verifier_id, if claim not in payload: return reject("Missing required claim: " + claim) - // Validate policy claims (optional, but must be paired) - if "pol" in payload or "pol_decision" in payload: - if "pol" not in payload or "pol_decision" not in payload: + // Validate policy extension keys (optional, but must be paired) + ext = payload.ext or {} + if "pol" in ext or "pol_decision" in ext: + if "pol" not in ext or "pol_decision" not in ext: return reject("pol and pol_decision must both be present") - if payload.pol_decision not in + if ext.pol_decision not in ["approved", "rejected", "pending_human_review"]: return reject("Invalid pol_decision value") @@ -1010,29 +1010,34 @@ software used in medical devices. Agent A (Spec Reviewer): jti: task-001 par: [] exec_act: review_requirements_spec - pol: spec_review_policy_v2 pol_decision: approved + ext.pol: spec_review_policy_v2 + ext.pol_decision: approved Agent B (Code Generator): jti: task-002 par: [task-001] exec_act: implement_module - pol: coding_standards_v3 pol_decision: approved + ext.pol: coding_standards_v3 + ext.pol_decision: approved Agent C (Test Agent): jti: task-003 par: [task-002] exec_act: execute_test_suite - pol: test_coverage_policy_v1 pol_decision: approved + ext.pol: test_coverage_policy_v1 + ext.pol_decision: approved Agent D (Build Agent): jti: task-004 par: [task-003] exec_act: build_release_artifact - pol: build_validation_v2 pol_decision: approved + ext.pol: build_validation_v2 + ext.pol_decision: approved Human Release Manager: jti: task-005 par: [task-004] exec_act: approve_release - pol: release_approval_policy pol_decision: approved - pol_enforcer: spiffe://meddev.example/human/release-mgr-42 - ext: {witnessed_by: [...]} (extension metadata) + ext.pol: release_approval_policy + ext.pol_decision: approved + ext.pol_enforcer: spiffe://meddev.example/human/release-mgr-42 + ext.witnessed_by: [...] ~~~ {: #fig-medtech-sdlc title="Medical Device SDLC Workflow"} @@ -1098,17 +1103,20 @@ execution. Agent A (Risk Assessment): jti: task-001 par: [] exec_act: calculate_risk_exposure - pol: risk_limits_policy_v2 pol_decision: approved + ext.pol: risk_limits_policy_v2 + ext.pol_decision: approved Agent B (Compliance): jti: task-002 par: [task-001] exec_act: verify_compliance - pol: compliance_check_v1 pol_decision: approved + ext.pol: compliance_check_v1 + ext.pol_decision: approved Agent C (Execution): jti: task-003 par: [task-002] exec_act: execute_trade - pol: execution_policy_v3 pol_decision: approved + ext.pol: execution_policy_v3 + ext.pol_decision: approved ~~~ {: #fig-finance title="Financial Trading Workflow"} @@ -1129,7 +1137,6 @@ a cryptographic link to the original task: ~~~json { "iss": "spiffe://bank.example/agent/operations", - "sub": "spiffe://bank.example/agent/operations", "aud": "spiffe://bank.example/system/ledger", "iat": 1772150550, "exp": 1772151150, @@ -1137,11 +1144,13 @@ a cryptographic link to the original task: "wid": "d3e4f5a6-b7c8-9012-def0-123456789012", "exec_act": "initiate_trade_rollback", "par": ["550e8400-e29b-41d4-a716-446655440003"], - "pol": "compensation_policy_v1", - "pol_decision": "approved", - "pol_enforcer": "spiffe://bank.example/human/compliance-officer", - "compensation_required": true, - "compensation_reason": "policy_violation_in_parent_trade" + "ext": { + "pol": "compensation_policy_v1", + "pol_decision": "approved", + "pol_enforcer": "spiffe://bank.example/human/compliance-officer", + "compensation_required": true, + "compensation_reason": "policy_violation_in_parent_trade" + } } ~~~ {: #fig-compensation title="Compensation ECT Example"} @@ -1160,27 +1169,32 @@ required checks were completed: Agent A (Route Planning): jti: task-001 par: [] exec_act: plan_route - pol: route_policy_v1 pol_decision: approved + ext.pol: route_policy_v1 + ext.pol_decision: approved Agent B (Customs): jti: task-002 par: [task-001] exec_act: validate_customs - pol: customs_policy_v2 pol_decision: approved + ext.pol: customs_policy_v2 + ext.pol_decision: approved Agent C (Safety): jti: task-003 par: [task-001] exec_act: verify_cargo_safety - pol: safety_policy_v1 pol_decision: approved + ext.pol: safety_policy_v1 + ext.pol_decision: approved Agent D (Payment): jti: task-004 par: [task-002, task-003] exec_act: authorize_payment - pol: payment_policy_v3 pol_decision: approved + ext.pol: payment_policy_v3 + ext.pol_decision: approved System (Commitment): jti: task-005 par: [task-004] exec_act: commit_shipment - pol: commitment_policy_v1 pol_decision: approved + ext.pol: commitment_policy_v1 + ext.pol_decision: approved ~~~ {: #fig-logistics title="Logistics Workflow with Parallel Tasks"} @@ -1211,8 +1225,8 @@ The following threat actors are considered: ECTs are self-asserted by the executing agent. The agent claims what it did, and this claim is signed with its private key. A compromised or malicious agent could create ECTs with false claims -(e.g., setting "pol_decision" to "approved" without actually -evaluating the policy). +(e.g., setting "pol_decision" in "ext" to "approved" without +actually evaluating the policy). ECTs do not independently verify that: @@ -1232,32 +1246,11 @@ evidence 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" extension, 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 "jti" 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" extension 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 extension value 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. +To strengthen witness attestation beyond self-assertion, witnesses +SHOULD submit their own independent signed ECTs referencing the +observed task's "jti" in the "par" array. Auditors can then +cross-check the "witnessed_by" extension against independent +witness ECTs in the ECT store. ## Organizational Prerequisites @@ -1409,8 +1402,8 @@ ECTs necessarily reveal: - Agent identities ("iss", "aud") for accountability purposes - Action descriptions ("exec_act") for audit trail completeness -- Policy evaluation outcomes ("pol", "pol_decision") for - compliance verification +- Policy evaluation outcomes (via "ext" keys "pol", + "pol_decision") when present, for compliance verification - Timestamps ("iat", "exp") for temporal ordering ECTs are designed to NOT reveal: @@ -1426,18 +1419,14 @@ ECTs are designed to NOT reveal: Implementations SHOULD minimize the information included in ECTs. The "exec_act" claim SHOULD use structured identifiers (e.g., "process_payment") rather than natural language descriptions. -The "pol" claim SHOULD reference policy identifiers rather than -embedding policy content. +The "pol" extension key 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. +The "compensation_reason" extension key in "ext" +({{compensation-claims}}) deserves particular attention: because +it is human-readable, it risks exposing sensitive operational +details. See {{extension-claims}} for guidance on using +structured identifiers. ## Storage and Access Control @@ -1540,16 +1529,16 @@ the "JSON Web Token Claims" registry maintained by IANA: | wid | Workflow Identifier | IETF | {{exec-claims}} | | exec_act | Action/Task Type | IETF | {{exec-claims}} | | par | Parent Task Identifiers | IETF | {{exec-claims}} | -| pol | Policy Rule Identifier | IETF | {{policy-claims}} | -| pol_decision | Policy Decision Result | IETF | {{policy-claims}} | -| pol_enforcer | Policy Enforcer Identity | IETF | {{policy-claims}} | | inp_hash | Input Data Hash | IETF | {{data-integrity-claims}} | | out_hash | Output Data Hash | IETF | {{data-integrity-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"} +Note: Policy evaluation keys ("pol", "pol_decision", +"pol_enforcer") are carried within the "ext" object as +spec-defined extension keys ({{policy-claims}}) and do not +require separate JWT Claims registration. + ## ECT Policy Decision Values Registry {#pol-decision-registry} This document establishes the "ECT Policy Decision Values" @@ -1704,14 +1693,15 @@ use cases are distinct. A minimal conforming implementation needs to: 1. Create JWTs with all required claims ("iss", "aud", "iat", - "exp", "jti", "exec_act", "par") and policy claims ("pol", - "pol_decision") when policy evaluation was performed. + "exp", "jti", "exec_act", "par") and policy extension keys + ("ext.pol", "ext.pol_decision") when policy evaluation was + performed. 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. 4. Perform DAG validation (parent existence, temporal ordering, cycle detection). -5. Append verified ECTs to the audit ledger. +5. If an audit ledger is deployed, append verified ECTs to it. ## Storage Recommendations {:numbered="false"} @@ -1787,7 +1777,6 @@ ECT Payload: ~~~json { "iss": "spiffe://example.com/agent/data-retrieval", - "sub": "spiffe://example.com/agent/data-retrieval", "aud": "spiffe://example.com/agent/validator", "iat": 1772064150, "exp": 1772064750, @@ -1795,10 +1784,12 @@ ECT Payload: "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", "exec_act": "fetch_patient_data", "par": [], - "pol": "clinical_data_access_policy_v1", - "pol_decision": "approved", "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", - "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" + "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", + "ext": { + "pol": "clinical_data_access_policy_v1", + "pol_decision": "approved" + } } ~~~ @@ -1808,7 +1799,6 @@ task, and creates its own ECT: ~~~json { "iss": "spiffe://example.com/agent/validator", - "sub": "spiffe://example.com/agent/validator", "aud": "spiffe://example.com/system/ledger", "iat": 1772064160, "exp": 1772064760, @@ -1816,8 +1806,10 @@ task, and creates its own ECT: "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", "exec_act": "validate_safety", "par": ["550e8400-e29b-41d4-a716-446655440001"], - "pol": "safety_validation_policy_v2", - "pol_decision": "approved" + "ext": { + "pol": "safety_validation_policy_v2", + "pol_decision": "approved" + } } ~~~ @@ -1841,7 +1833,6 @@ Task 1 (Spec Review Agent): ~~~json { "iss": "spiffe://meddev.example/agent/spec-reviewer", - "sub": "spiffe://meddev.example/agent/spec-reviewer", "aud": "spiffe://meddev.example/agent/code-gen", "iat": 1772064150, "exp": 1772064750, @@ -1849,10 +1840,12 @@ Task 1 (Spec Review Agent): "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "review_requirements_spec", "par": [], - "pol": "spec_review_policy_v2", - "pol_decision": "approved", "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", - "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" + "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", + "ext": { + "pol": "spec_review_policy_v2", + "pol_decision": "approved" + } } ~~~ @@ -1861,7 +1854,6 @@ Task 2 (Code Generation Agent): ~~~json { "iss": "spiffe://meddev.example/agent/code-gen", - "sub": "spiffe://meddev.example/agent/code-gen", "aud": "spiffe://meddev.example/agent/test-runner", "iat": 1772064200, "exp": 1772064800, @@ -1869,8 +1861,10 @@ Task 2 (Code Generation Agent): "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "implement_module", "par": ["a1b2c3d4-0001-0000-0000-000000000001"], - "pol": "coding_standards_v3", - "pol_decision": "approved" + "ext": { + "pol": "coding_standards_v3", + "pol_decision": "approved" + } } ~~~ @@ -1879,7 +1873,6 @@ Task 3 (Autonomous Test Agent): ~~~json { "iss": "spiffe://meddev.example/agent/test-runner", - "sub": "spiffe://meddev.example/agent/test-runner", "aud": "spiffe://meddev.example/agent/build", "iat": 1772064260, "exp": 1772064860, @@ -1887,8 +1880,10 @@ Task 3 (Autonomous Test Agent): "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "execute_test_suite", "par": ["a1b2c3d4-0001-0000-0000-000000000002"], - "pol": "test_coverage_policy_v1", - "pol_decision": "approved" + "ext": { + "pol": "test_coverage_policy_v1", + "pol_decision": "approved" + } } ~~~ @@ -1897,7 +1892,6 @@ Task 4 (Build Agent): ~~~json { "iss": "spiffe://meddev.example/agent/build", - "sub": "spiffe://meddev.example/agent/build", "aud": "spiffe://meddev.example/human/release-mgr-42", "iat": 1772064310, "exp": 1772064910, @@ -1905,9 +1899,11 @@ Task 4 (Build Agent): "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "build_release_artifact", "par": ["a1b2c3d4-0001-0000-0000-000000000003"], - "pol": "build_validation_v2", - "pol_decision": "approved", - "out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc" + "out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc", + "ext": { + "pol": "build_validation_v2", + "pol_decision": "approved" + } } ~~~ @@ -1916,7 +1912,6 @@ Task 5 (Human Release Manager Approval): ~~~json { "iss": "spiffe://meddev.example/human/release-mgr-42", - "sub": "spiffe://meddev.example/human/release-mgr-42", "aud": "spiffe://meddev.example/system/ledger", "iat": 1772064510, "exp": 1772065110, @@ -1924,10 +1919,10 @@ Task 5 (Human Release Manager Approval): "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "approve_release", "par": ["a1b2c3d4-0001-0000-0000-000000000004"], - "pol": "release_approval_policy", - "pol_decision": "approved", - "pol_enforcer": "spiffe://meddev.example/human/release-mgr-42", "ext": { + "pol": "release_approval_policy", + "pol_decision": "approved", + "pol_enforcer": "spiffe://meddev.example/human/release-mgr-42", "witnessed_by": [ "spiffe://meddev.example/audit/qa-observer-1" ] @@ -1986,7 +1981,6 @@ Task 004 ECT payload: ~~~json { "iss": "spiffe://bank.example/agent/execution", - "sub": "spiffe://bank.example/agent/execution", "aud": "spiffe://bank.example/system/ledger", "iat": 1772064250, "exp": 1772064850, @@ -1997,8 +1991,10 @@ Task 004 ECT payload: "f1e2d3c4-0002-0000-0000-000000000002", "f1e2d3c4-0003-0000-0000-000000000003" ], - "pol": "trade_execution_policy_v3", - "pol_decision": "approved" + "ext": { + "pol": "trade_execution_policy_v3", + "pol_decision": "approved" + } } ~~~ diff --git a/draft-nennemann-wimse-execution-context-00.txt b/draft-nennemann-wimse-execution-context-00.txt index 6416811..04dd1d5 100644 --- a/draft-nennemann-wimse-execution-context-00.txt +++ b/draft-nennemann-wimse-execution-context-00.txt @@ -4,8 +4,8 @@ WIMSE C. Nennemann Internet-Draft Independent Researcher -Intended status: Standards Track 24 February 2026 -Expires: 28 August 2026 +Intended status: Standards Track 25 February 2026 +Expires: 29 August 2026 Execution Context Tokens for Distributed Agentic Workflows @@ -46,14 +46,14 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 28 August 2026. + This Internet-Draft will expire on 29 August 2026. -Nennemann Expires 28 August 2026 [Page 1] +Nennemann Expires 29 August 2026 [Page 1] Internet-Draft WIMSE Execution Context February 2026 @@ -89,11 +89,11 @@ Table of Contents 4.2. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Standard JWT Claims . . . . . . . . . . . . . . . . . 10 4.2.2. Execution Context . . . . . . . . . . . . . . . . . . 11 - 4.2.3. Policy Evaluation . . . . . . . . . . . . . . . . . . 12 + 4.2.3. Policy Evaluation Extension Keys . . . . . . . . . . 12 4.2.4. Data Integrity . . . . . . . . . . . . . . . . . . . 13 4.2.5. Compensation and Rollback . . . . . . . . . . . . . . 13 4.2.6. Extensions . . . . . . . . . . . . . . . . . . . . . 13 - 4.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 14 + 4.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 15 5. HTTP Header Transport . . . . . . . . . . . . . . . . . . . . 15 5.1. Execution-Context Header Field . . . . . . . . . . . . . 15 6. DAG Validation . . . . . . . . . . . . . . . . . . . . . . . 16 @@ -109,69 +109,68 @@ Table of Contents -Nennemann Expires 28 August 2026 [Page 2] +Nennemann Expires 29 August 2026 [Page 2] Internet-Draft WIMSE Execution Context February 2026 9.1.1. FDA Audit with DAG Reconstruction . . . . . . . . . . 24 9.2. Financial Trading Workflow . . . . . . . . . . . . . . . 25 - 9.3. Compensation and Rollback . . . . . . . . . . . . . . . . 25 + 9.3. Compensation and Rollback . . . . . . . . . . . . . . . . 26 9.4. Autonomous Logistics Coordination . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 27 10.2. Self-Assertion Limitation . . . . . . . . . . . . . . . 28 - 10.2.1. Witness Attestation Model . . . . . . . . . . . . . 28 - 10.3. Organizational Prerequisites . . . . . . . . . . . . . . 29 + 10.3. Organizational Prerequisites . . . . . . . . . . . . . . 28 10.4. Signature Verification . . . . . . . . . . . . . . . . . 29 - 10.5. Replay Attack Prevention . . . . . . . . . . . . . . . . 30 + 10.5. Replay Attack Prevention . . . . . . . . . . . . . . . . 29 10.6. Man-in-the-Middle Protection . . . . . . . . . . . . . . 30 10.7. Key Compromise . . . . . . . . . . . . . . . . . . . . . 30 - 10.8. Collusion and False Claims . . . . . . . . . . . . . . . 31 + 10.8. Collusion and False Claims . . . . . . . . . . . . . . . 30 10.9. Denial of Service . . . . . . . . . . . . . . . . . . . 31 - 10.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 32 + 10.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 31 10.11. ECT Size Constraints . . . . . . . . . . . . . . . . . . 32 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32 11.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . 32 - 11.2. Data Minimization . . . . . . . . . . . . . . . . . . . 33 + 11.2. Data Minimization . . . . . . . . . . . . . . . . . . . 32 11.3. Storage and Access Control . . . . . . . . . . . . . . . 33 11.4. Regulatory Access . . . . . . . . . . . . . . . . . . . 33 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 12.1. Media Type Registration . . . . . . . . . . . . . . . . 33 12.2. HTTP Header Field Registration . . . . . . . . . . . . . 34 - 12.3. JWT Claims Registration . . . . . . . . . . . . . . . . 35 - 12.4. ECT Policy Decision Values Registry . . . . . . . . . . 36 + 12.3. JWT Claims Registration . . . . . . . . . . . . . . . . 34 + 12.4. ECT Policy Decision Values Registry . . . . . . . . . . 35 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 13.1. Normative References . . . . . . . . . . . . . . . . . . 36 13.2. Informative References . . . . . . . . . . . . . . . . . 37 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 39 WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 39 - OAuth 2.0 Token Exchange and the "act" Claim . . . . . . . . . 40 + OAuth 2.0 Token Exchange and the "act" Claim . . . . . . . . . 39 Transaction Tokens . . . . . . . . . . . . . . . . . . . . . . 40 - Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 41 + Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 40 Blockchain and Distributed Ledgers . . . . . . . . . . . . . . 41 SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 41 - W3C Verifiable Credentials . . . . . . . . . . . . . . . . . . 42 - Implementation Guidance . . . . . . . . . . . . . . . . . . . . . 42 - Minimal Implementation . . . . . . . . . . . . . . . . . . . . 42 + W3C Verifiable Credentials . . . . . . . . . . . . . . . . . . 41 + Implementation Guidance . . . . . . . . . . . . . . . . . . . . . 41 + Minimal Implementation . . . . . . . . . . . . . . . . . . . . 41 Storage Recommendations . . . . . . . . . . . . . . . . . . . . 42 Performance Considerations . . . . . . . . . . . . . . . . . . 42 - Interoperability . . . . . . . . . . . . . . . . . . . . . . . 43 + Interoperability . . . . . . . . . . . . . . . . . . . . . . . 42 Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . . 43 - Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 - Example 1: Simple Two-Agent Workflow . . . . . . . . . . . . . 44 + Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 + Example 1: Simple Two-Agent Workflow . . . . . . . . . . . . . 43 Example 2: Medical Device SDLC with Release Approval . . . . . 45 Example 3: Parallel Execution with Join . . . . . . . . . . . . 48 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 48 -Nennemann Expires 28 August 2026 [Page 3] +Nennemann Expires 29 August 2026 [Page 3] Internet-Draft WIMSE Execution Context February 2026 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 1. Introduction @@ -221,7 +220,8 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 4] + +Nennemann Expires 29 August 2026 [Page 4] Internet-Draft WIMSE Execution Context February 2026 @@ -240,7 +240,7 @@ Internet-Draft WIMSE Execution Context February 2026 * DAG structure for task dependency ordering (Section 6) - * Policy checkpoint recording (Section 4.2.3) + * Policy checkpoint recording via extension keys (Section 4.2.3) * Integration with the WIMSE identity framework (Section 3) @@ -277,7 +277,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 5] +Nennemann Expires 29 August 2026 [Page 5] Internet-Draft WIMSE Execution Context February 2026 @@ -333,7 +333,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 6] +Nennemann Expires 29 August 2026 [Page 6] Internet-Draft WIMSE Execution Context February 2026 @@ -389,7 +389,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 7] +Nennemann Expires 29 August 2026 [Page 7] Internet-Draft WIMSE Execution Context February 2026 @@ -445,7 +445,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 8] +Nennemann Expires 29 August 2026 [Page 8] Internet-Draft WIMSE Execution Context February 2026 @@ -501,7 +501,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 9] +Nennemann Expires 29 August 2026 [Page 9] Internet-Draft WIMSE Execution Context February 2026 @@ -526,11 +526,6 @@ Internet-Draft WIMSE Execution Context February 2026 "sub" claim of the agent's WIT. Non-WIMSE deployments MAY use other URI schemes (e.g., HTTPS URLs or URN:UUID identifiers). - sub: OPTIONAL. StringOrURI. The subject of the ECT. When present, - MUST equal the "iss" claim. This claim is included for - 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. Because ECTs serve as both inter-agent messages and audit records, the "aud" claim SHOULD contain the @@ -553,15 +548,6 @@ Internet-Draft WIMSE Execution Context February 2026 "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 @@ -569,6 +555,13 @@ Internet-Draft WIMSE Execution Context February 2026 delivered — it is independent of the "aud" values in the parent ECTs. + + +Nennemann Expires 29 August 2026 [Page 10] + +Internet-Draft WIMSE Execution Context February 2026 + + iat: REQUIRED. NumericDate. The time at which the ECT was issued. The ECT records a completed action, so the "iat" value reflects when the record was created, not when task execution began. @@ -607,34 +600,41 @@ 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 the "jti" value of a previously verified ECT. An empty array indicates a root task with no dependencies. A workflow MAY contain multiple root tasks. -4.2.3. Policy Evaluation - The following claims record policy evaluation outcomes: - pol: OPTIONAL. String. The identifier of the policy rule that was - evaluated for this task (e.g., "clinical_data_access_policy_v1"). - MUST be present when "pol_decision" is present. - pol_decision: OPTIONAL. String. The result of the policy - evaluation. When present, MUST be one of the values registered in - the ECT Policy Decision Values registry (Section 12.4). MUST be - present when "pol" is present. Initial values are: + + + + + +Nennemann Expires 29 August 2026 [Page 11] + +Internet-Draft WIMSE Execution Context February 2026 + + +4.2.3. Policy Evaluation Extension Keys + + Policy evaluation outcomes are recorded as extension keys within the + "ext" object (Section 4.2.6). This keeps the core registered claims + focused on DAG structure and execution context, while allowing + deployments to add policy recording as needed. + + The following extension keys are defined for policy evaluation: + + "pol": String. The identifier of the policy rule that was evaluated + for this task (e.g., "clinical_data_access_policy_v1"). MUST be + present when "pol_decision" is present. + + "pol_decision": String. The result of the policy evaluation. When + present, MUST be one of the values registered in the ECT Policy + Decision Values registry (Section 12.4). MUST be present when + "pol" is present. Initial values are: * "approved": The policy evaluation succeeded and the task was authorized to proceed. @@ -653,32 +653,32 @@ Internet-Draft WIMSE Execution Context February 2026 records an "approved" decision referencing this task as a parent. - When "pol" and "pol_decision" are absent, the ECT records task - execution without a policy checkpoint. Regulated deployments - SHOULD include policy claims on all ECTs to maintain complete - audit trails. + When "pol" and "pol_decision" are absent from "ext", the ECT + records task execution without a policy checkpoint. Regulated + deployments SHOULD include policy keys on all ECTs to maintain + complete audit trails. - pol_enforcer: OPTIONAL. StringOrURI. The identity of the entity - (system or person) that evaluated the policy decision. When - present, SHOULD use SPIFFE ID format. + "pol_enforcer": StringOrURI. The identity of the entity (system or + person) that evaluated the policy decision. When present, SHOULD + use SPIFFE ID format. This specification intentionally defines only the recording of policy evaluation outcomes. The mechanisms by which policies are defined, - distributed to agents, and evaluated are out of scope. The "pol" - claim is an opaque identifier referencing an external policy; the + distributed to agents, and evaluated are out of scope. The "pol" key + is an opaque identifier referencing an external policy; the semantics -Nennemann Expires 28 August 2026 [Page 12] +Nennemann Expires 29 August 2026 [Page 12] Internet-Draft WIMSE Execution Context February 2026 - semantics and enforcement of that policy are determined by the - deployment environment. Implementations may use any policy engine or - framework (e.g., OPA/Rego, Cedar, XACML, or custom solutions) - provided that the evaluation outcome is faithfully recorded in the - ECT claims defined above. + and enforcement of that policy are determined by the deployment + environment. Implementations may use any policy engine or framework + (e.g., OPA/Rego, Cedar, XACML, or custom solutions) provided that the + evaluation outcome is faithfully recorded in the "ext" keys defined + above. 4.2.4. Data Integrity @@ -702,37 +702,34 @@ Internet-Draft WIMSE Execution Context February 2026 4.2.5. Compensation and Rollback - compensation_required: OPTIONAL. Boolean. Indicates whether this - task is a 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. 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 - "exp" time; ECT expiration applies to the verification window of the - ECT itself, not to its validity as a parent reference in the ledger. + Compensation and rollback actions are recorded using the "par" claim + to reference the original task and the "exec_act" claim to describe + the remediation action. The referenced parent ECTs may have passed + their own "exp" time; ECT expiration applies to the verification + window of the ECT itself, not to its validity as a parent reference + in the ECT store. 4.2.6. Extensions ext: OPTIONAL. Object. An extension object for domain-specific + claims not defined by this specification. Implementations that do + not understand extension claims MUST ignore them. -Nennemann Expires 28 August 2026 [Page 13] + + + + + + + + +Nennemann Expires 29 August 2026 [Page 13] Internet-Draft WIMSE Execution Context February 2026 - claims not defined by this specification. Implementations that do - not understand extension claims MUST ignore them. - To avoid key collisions between different domains, extension key names SHOULD use reverse domain notation (e.g., "com.example.custom_field") to avoid collisions between independently @@ -744,7 +741,22 @@ Internet-Draft WIMSE Execution Context February 2026 The following extension keys are defined by this specification for common use cases. Because these keys are documented here, they use - short names without reverse domain prefixes: + short names without reverse domain prefixes. + + Policy evaluation keys (see Section 4.2.3 for full definitions and + decision value semantics): + + * "pol": String. Policy rule identifier. + + * "pol_decision": String. Policy evaluation outcome ("approved", + "rejected", or "pending_human_review"). + + * "pol_enforcer": StringOrURI. Identity of the policy evaluator. + + * "pol_timestamp": NumericDate. Time at which the policy decision + was made, if distinct from "iat". + + Operational metadata keys: * "exec_time_ms": Integer. Execution duration in milliseconds. @@ -761,34 +773,30 @@ Internet-Draft WIMSE Execution Context February 2026 * "inp_classification": String. Data sensitivity classification (e.g., "public", "confidential", "restricted"). - * "pol_timestamp": NumericDate. Time at which the policy decision - was made, if distinct from "iat". + * "compensation_required": Boolean. Indicates whether this task is + a compensation or rollback action. + + + + + + +Nennemann Expires 29 August 2026 [Page 14] + +Internet-Draft WIMSE Execution Context February 2026 + + + * "compensation_reason": String. Structured reason code for the + compensation action (e.g., "policy_violation_in_parent_trade"). + SHOULD use structured identifiers rather than free-form text to + minimize information leakage (see Section 11.2). 4.3. Complete ECT Example The following is a complete ECT payload example: - - - - - - - - - - - - - -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, @@ -798,14 +806,13 @@ Internet-Draft WIMSE Execution Context February 2026 "exec_act": "recommend_treatment", "par": [], - "pol": "clinical_reasoning_policy_v2", - "pol_decision": "approved", - "pol_enforcer": "spiffe://example.com/policy/clinical-engine", - "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", "ext": { + "pol": "clinical_reasoning_policy_v2", + "pol_decision": "approved", + "pol_enforcer": "spiffe://example.com/policy/clinical-engine", "pol_timestamp": 1772064145, "exec_time_ms": 245, "regulated_domain": "medtech", @@ -826,6 +833,15 @@ Internet-Draft WIMSE Execution Context February 2026 [RFC7515]. The value consists of three Base64url-encoded parts separated by period (".") characters. + + + + +Nennemann Expires 29 August 2026 [Page 15] + +Internet-Draft WIMSE Execution Context February 2026 + + An agent sending a request to another agent includes the Execution- Context header alongside the WIMSE Workload-Identity header: @@ -834,14 +850,6 @@ Internet-Draft WIMSE Execution Context February 2026 Workload-Identity: eyJhbGci...WIT... Execution-Context: eyJhbGci...ECT... - - - -Nennemann Expires 28 August 2026 [Page 15] - -Internet-Draft WIMSE Execution Context February 2026 - - Figure 5: HTTP Request with ECT Header When multiple parent tasks contribute context to a single request, @@ -878,6 +886,18 @@ Internet-Draft WIMSE Execution Context February 2026 ECT store if "wid" is absent). If an ECT with the same "jti" already exists, the ECT MUST be rejected. + + + + + + + +Nennemann Expires 29 August 2026 [Page 16] + +Internet-Draft WIMSE Execution Context February 2026 + + 2. Parent Existence: Every task identifier listed in the "par" array MUST correspond to a task that is available in the ECT store (either previously recorded in the ledger or received inline as a @@ -890,14 +910,6 @@ Internet-Draft WIMSE Execution Context February 2026 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 - - - -Nennemann Expires 28 August 2026 [Page 16] - -Internet-Draft WIMSE Execution Context February 2026 - - timestamps alone. Causal ordering is primarily enforced by the DAG structure (parent existence in the ECT store), not by timestamps. If any parent task violates this constraint, the ECT @@ -907,14 +919,13 @@ Internet-Draft WIMSE Execution Context February 2026 lead back to the current ECT's "jti". If a cycle is detected, the ECT MUST be rejected. - 5. Parent Policy Decision: If any parent ECT contains a - "pol_decision" of "rejected" or "pending_human_review", the + 5. Parent Policy Decision: If any parent ECT's "ext" object contains + a "pol_decision" of "rejected" or "pending_human_review", the current ECT'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. This rule only applies - when the parent ECT contains policy claims. + parent's "pol_decision" is not "approved". This rule only + applies when the parent ECT's "ext" contains policy keys. 6. Trust Domain Consistency: Parent tasks SHOULD belong to the same trust domain or to a trust domain with which a federation @@ -938,18 +949,7 @@ Internet-Draft WIMSE Execution Context February 2026 - - - - - - - - - - - -Nennemann Expires 28 August 2026 [Page 17] +Nennemann Expires 29 August 2026 [Page 17] Internet-Draft WIMSE Execution Context February 2026 @@ -1005,7 +1005,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 18] +Nennemann Expires 29 August 2026 [Page 18] Internet-Draft WIMSE Execution Context February 2026 @@ -1061,7 +1061,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 19] +Nennemann Expires 29 August 2026 [Page 19] Internet-Draft WIMSE Execution Context February 2026 @@ -1075,18 +1075,18 @@ Internet-Draft WIMSE Execution Context February 2026 12. Verify all required claims ("jti", "exec_act", "par") are present and well-formed. - 13. If "pol" or "pol_decision" is present, verify that both are - present and that "pol_decision" is one of "approved", - "rejected", or "pending_human_review". + 13. If "ext" is present and contains "pol" or "pol_decision", verify + that both are present and that "pol_decision" is one of + "approved", "rejected", or "pending_human_review". 14. Perform DAG validation per Section 6. - 15. If all checks pass, the ECT MUST be appended to the audit - ledger. + 15. If all checks pass and an audit ledger is deployed, the ECT + SHOULD be appended to the ledger. If any verification step fails, the ECT MUST be rejected and the failure MUST be logged for audit purposes. Error messages SHOULD NOT - reveal whether specific parent task IDs exist in the ledger, to + reveal whether specific parent task IDs exist in the ECT store, to prevent information disclosure. When ECT verification fails during HTTP request processing, the @@ -1117,7 +1117,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 20] +Nennemann Expires 29 August 2026 [Page 20] Internet-Draft WIMSE Execution Context February 2026 @@ -1161,23 +1161,24 @@ Internet-Draft WIMSE Execution Context February 2026 if claim not in payload: return reject("Missing required claim: " + claim) - // Validate policy claims (optional, but must be paired) - if "pol" in payload or "pol_decision" in payload: - if "pol" not in payload or "pol_decision" not in payload: + // Validate policy extension keys (optional, but must be paired) + ext = payload.ext or {} + if "pol" in ext or "pol_decision" in ext: + if "pol" not in ext or "pol_decision" not in ext: return reject("pol and pol_decision must both be present") - if payload.pol_decision not in + if ext.pol_decision not in ["approved", "rejected", "pending_human_review"]: return reject("Invalid pol_decision value") - // Validate DAG (against ECT store or inline parent ECTs) -Nennemann Expires 28 August 2026 [Page 21] +Nennemann Expires 29 August 2026 [Page 21] Internet-Draft WIMSE Execution Context February 2026 + // Validate DAG (against ECT store or inline parent ECTs) result = validate_dag(payload, ect_store, clock_skew_tolerance) if result is error: @@ -1228,8 +1229,7 @@ Internet-Draft WIMSE Execution Context February 2026 - -Nennemann Expires 28 August 2026 [Page 22] +Nennemann Expires 29 August 2026 [Page 22] Internet-Draft WIMSE Execution Context February 2026 @@ -1249,47 +1249,53 @@ Internet-Draft WIMSE Execution Context February 2026 Agent A (Spec Reviewer): jti: task-001 par: [] exec_act: review_requirements_spec - pol: spec_review_policy_v2 pol_decision: approved + ext.pol: spec_review_policy_v2 + ext.pol_decision: approved Agent B (Code Generator): jti: task-002 par: [task-001] exec_act: implement_module - pol: coding_standards_v3 pol_decision: approved + ext.pol: coding_standards_v3 + ext.pol_decision: approved Agent C (Test Agent): jti: task-003 par: [task-002] exec_act: execute_test_suite - pol: test_coverage_policy_v1 pol_decision: approved + ext.pol: test_coverage_policy_v1 + ext.pol_decision: approved Agent D (Build Agent): jti: task-004 par: [task-003] exec_act: build_release_artifact - pol: build_validation_v2 pol_decision: approved + ext.pol: build_validation_v2 + ext.pol_decision: approved Human Release Manager: jti: task-005 par: [task-004] exec_act: approve_release - pol: release_approval_policy pol_decision: approved - pol_enforcer: spiffe://meddev.example/human/release-mgr-42 - ext: {witnessed_by: [...]} (extension metadata) + ext.pol: release_approval_policy + ext.pol_decision: approved + ext.pol_enforcer: spiffe://meddev.example/human/release-mgr-42 + ext.witnessed_by: [...] Figure 8: Medical Device SDLC Workflow + + + + + +Nennemann Expires 29 August 2026 [Page 23] + +Internet-Draft WIMSE Execution Context February 2026 + + ECTs record that requirements were reviewed before implementation began, that tests were executed against the implemented code, that the build artifact was validated, and that a human release manager explicitly approved the release. The DAG structure ensures no phase was skipped or reordered. - - - - -Nennemann Expires 28 August 2026 [Page 23] - -Internet-Draft WIMSE Execution Context February 2026 - - 9.1.1. FDA Audit with DAG Reconstruction During a regulatory audit, an FDA reviewer requests evidence of the @@ -1331,21 +1337,21 @@ Internet-Draft WIMSE Execution Context February 2026 * [FDA-21CFR11] Section 11.10(e): Computer-generated audit trails that record the date, time, and identity of the operator. + + + + +Nennemann Expires 29 August 2026 [Page 24] + +Internet-Draft WIMSE Execution Context February 2026 + + * [EU-MDR] Annex II: Technical documentation traceability for the software development lifecycle. * [EU-AI-ACT] Article 12: Automatic logging capabilities for high- risk AI systems involved in the development process. - - - - -Nennemann Expires 28 August 2026 [Page 24] - -Internet-Draft WIMSE Execution Context February 2026 - - * [EU-AI-ACT] Article 14: ECTs can record evidence that human oversight events occurred during the release process. @@ -1358,17 +1364,20 @@ Internet-Draft WIMSE Execution Context February 2026 Agent A (Risk Assessment): jti: task-001 par: [] exec_act: calculate_risk_exposure - pol: risk_limits_policy_v2 pol_decision: approved + ext.pol: risk_limits_policy_v2 + ext.pol_decision: approved Agent B (Compliance): jti: task-002 par: [task-001] exec_act: verify_compliance - pol: compliance_check_v1 pol_decision: approved + ext.pol: compliance_check_v1 + ext.pol_decision: approved Agent C (Execution): jti: task-003 par: [task-002] exec_act: execute_trade - pol: execution_policy_v3 pol_decision: approved + ext.pol: execution_policy_v3 + ext.pol_decision: approved Figure 10: Financial Trading Workflow @@ -1382,29 +1391,25 @@ Internet-Draft WIMSE Execution Context February 2026 * [EU-AI-ACT] Article 12: Logging of decisions made by AI-driven systems. + + + + + + +Nennemann Expires 29 August 2026 [Page 25] + +Internet-Draft WIMSE Execution Context February 2026 + + 9.3. Compensation and Rollback When a compliance violation is discovered after execution, ECTs provide a mechanism to record authorized compensation actions with a cryptographic link to the original task: - - - - - - - - - -Nennemann Expires 28 August 2026 [Page 25] - -Internet-Draft WIMSE Execution Context February 2026 - - { "iss": "spiffe://bank.example/agent/operations", - "sub": "spiffe://bank.example/agent/operations", "aud": "spiffe://bank.example/system/ledger", "iat": 1772150550, "exp": 1772151150, @@ -1412,11 +1417,13 @@ Internet-Draft WIMSE Execution Context February 2026 "wid": "d3e4f5a6-b7c8-9012-def0-123456789012", "exec_act": "initiate_trade_rollback", "par": ["550e8400-e29b-41d4-a716-446655440003"], - "pol": "compensation_policy_v1", - "pol_decision": "approved", - "pol_enforcer": "spiffe://bank.example/human/compliance-officer", - "compensation_required": true, - "compensation_reason": "policy_violation_in_parent_trade" + "ext": { + "pol": "compensation_policy_v1", + "pol_decision": "approved", + "pol_enforcer": "spiffe://bank.example/human/compliance-officer", + "compensation_required": true, + "compensation_reason": "policy_violation_in_parent_trade" + } } Figure 11: Compensation ECT Example @@ -1446,14 +1453,7 @@ Internet-Draft WIMSE Execution Context February 2026 - - - - - - - -Nennemann Expires 28 August 2026 [Page 26] +Nennemann Expires 29 August 2026 [Page 26] Internet-Draft WIMSE Execution Context February 2026 @@ -1461,27 +1461,32 @@ Internet-Draft WIMSE Execution Context February 2026 Agent A (Route Planning): jti: task-001 par: [] exec_act: plan_route - pol: route_policy_v1 pol_decision: approved + ext.pol: route_policy_v1 + ext.pol_decision: approved Agent B (Customs): jti: task-002 par: [task-001] exec_act: validate_customs - pol: customs_policy_v2 pol_decision: approved + ext.pol: customs_policy_v2 + ext.pol_decision: approved Agent C (Safety): jti: task-003 par: [task-001] exec_act: verify_cargo_safety - pol: safety_policy_v1 pol_decision: approved + ext.pol: safety_policy_v1 + ext.pol_decision: approved Agent D (Payment): jti: task-004 par: [task-002, task-003] exec_act: authorize_payment - pol: payment_policy_v3 pol_decision: approved + ext.pol: payment_policy_v3 + ext.pol_decision: approved System (Commitment): jti: task-005 par: [task-004] exec_act: commit_shipment - pol: commitment_policy_v1 pol_decision: approved + ext.pol: commitment_policy_v1 + ext.pol_decision: approved Figure 12: Logistics Workflow with Parallel Tasks @@ -1501,19 +1506,20 @@ Internet-Draft WIMSE Execution Context February 2026 * Malicious agent (insider threat): An agent within the trust domain that intentionally creates false ECT claims. + + + +Nennemann Expires 29 August 2026 [Page 27] + +Internet-Draft WIMSE Execution Context February 2026 + + * Compromised agent (external attacker): An agent whose private key has been obtained by an external attacker. * Ledger tamperer: An entity attempting to modify or delete ledger entries after they have been recorded. - - -Nennemann Expires 28 August 2026 [Page 27] - -Internet-Draft WIMSE Execution Context February 2026 - - * Time manipulator: An entity attempting to manipulate timestamps to alter perceived execution ordering. @@ -1522,7 +1528,8 @@ Internet-Draft WIMSE Execution Context February 2026 ECTs are self-asserted by the executing agent. The agent claims what it did, and this claim is signed with its private key. A compromised or malicious agent could create ECTs with false claims (e.g., setting - "pol_decision" to "approved" without actually evaluating the policy). + "pol_decision" in "ext" to "approved" without actually evaluating the + policy). ECTs do not independently verify that: @@ -1544,42 +1551,11 @@ Internet-Draft WIMSE Execution Context February 2026 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" - extension, 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 "jti" 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 28] - -Internet-Draft WIMSE Execution Context February 2026 - - - When a task's "witnessed_by" extension 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 - extension value 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. + To strengthen witness attestation beyond self-assertion, witnesses + SHOULD submit their own independent signed ECTs referencing the + observed task's "jti" in the "par" array. Auditors can then cross- + check the "witnessed_by" extension against independent witness ECTs + in the ECT store. 10.3. Organizational Prerequisites @@ -1587,6 +1563,13 @@ Internet-Draft WIMSE Execution Context February 2026 provided by ECTs are only meaningful when the following organizational controls are in place: + + +Nennemann Expires 29 August 2026 [Page 28] + +Internet-Draft WIMSE Execution Context February 2026 + + * Key management governance: Controls over who provisions agent keys and how keys are protected. @@ -1615,17 +1598,6 @@ Internet-Draft WIMSE Execution Context February 2026 Implementations MUST use established JWS libraries and MUST NOT implement custom signature verification. - - - - - - -Nennemann Expires 28 August 2026 [Page 29] - -Internet-Draft WIMSE Execution Context February 2026 - - 10.5. Replay Attack Prevention ECTs include short expiration times (RECOMMENDED: 5-15 minutes) to @@ -1642,6 +1614,18 @@ Internet-Draft WIMSE Execution Context February 2026 to detect replayed ECTs within the expiration window. An ECT with a duplicate "jti" value MUST be rejected. + + + + + + + +Nennemann Expires 29 August 2026 [Page 29] + +Internet-Draft WIMSE Execution Context February 2026 + + 10.6. Man-in-the-Middle Protection ECTs do not replace transport-layer security. ECTs MUST be @@ -1673,15 +1657,6 @@ Internet-Draft WIMSE Execution Context February 2026 * Trust domains MUST support rapid key revocation. - - - - -Nennemann Expires 28 August 2026 [Page 30] - -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. @@ -1699,6 +1674,14 @@ Internet-Draft WIMSE Execution Context February 2026 Mitigations include: + + + +Nennemann Expires 29 August 2026 [Page 30] + +Internet-Draft WIMSE Execution Context February 2026 + + * Independent ledger maintenance: The ledger SHOULD be maintained by an entity independent of the workflow agents. @@ -1724,20 +1707,6 @@ 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 31] - -Internet-Draft WIMSE Execution Context February 2026 - - 10.10. Timestamp Accuracy ECTs rely on timestamps ("iat", "exp") for temporal ordering. Clock @@ -1755,6 +1724,20 @@ Internet-Draft WIMSE Execution Context February 2026 The temporal ordering check in DAG validation incorporates the clock skew tolerance to account for minor clock differences between agents. + + + + + + + + + +Nennemann Expires 29 August 2026 [Page 31] + +Internet-Draft WIMSE Execution Context February 2026 + + 10.11. ECT Size Constraints ECTs with many parent tasks or large extension objects can increase @@ -1774,8 +1757,8 @@ Internet-Draft WIMSE Execution Context February 2026 * Action descriptions ("exec_act") for audit trail completeness - * Policy evaluation outcomes ("pol", "pol_decision") for compliance - verification + * Policy evaluation outcomes (via "ext" keys "pol", "pol_decision") + when present, for compliance verification * Timestamps ("iat", "exp") for temporal ordering @@ -1786,14 +1769,6 @@ Internet-Draft WIMSE Execution Context February 2026 * Internal computation details or intermediate steps - - - -Nennemann Expires 28 August 2026 [Page 32] - -Internet-Draft WIMSE Execution Context February 2026 - - * Proprietary algorithms or intellectual property * Personally identifiable information (PII) @@ -1803,17 +1778,21 @@ Internet-Draft WIMSE Execution Context February 2026 Implementations SHOULD minimize the information included in ECTs. The "exec_act" claim SHOULD use structured identifiers (e.g., "process_payment") rather than natural language descriptions. The - "pol" claim SHOULD reference policy identifiers rather than embedding - policy content. + "pol" extension key SHOULD reference policy identifiers rather than + embedding policy content. + + The "compensation_reason" extension key in "ext" (Section 4.2.5) + deserves particular attention: because it is human-readable, it risks + exposing sensitive operational details. See Section 4.2.6 for + guidance on using structured identifiers. + + + + +Nennemann Expires 29 August 2026 [Page 32] + +Internet-Draft WIMSE Execution Context February 2026 - The "compensation_reason" claim (Section 4.2.5) 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 @@ -1842,14 +1821,6 @@ Internet-Draft WIMSE Execution Context February 2026 Type name: application - - - -Nennemann Expires 28 August 2026 [Page 33] - -Internet-Draft WIMSE Execution Context February 2026 - - Subtype name: wimse-exec+jwt Required parameters: none @@ -1871,6 +1842,14 @@ Internet-Draft WIMSE Execution Context February 2026 regulated agentic workflows requiring execution context tracing and audit trails. + + + +Nennemann Expires 29 August 2026 [Page 33] + +Internet-Draft WIMSE Execution Context February 2026 + + Additional information: Magic number(s): none File extension(s): none Macintosh file type code(s): none @@ -1897,59 +1876,11 @@ Internet-Draft WIMSE Execution Context February 2026 Specification document: This document, Section 5 - - - - -Nennemann Expires 28 August 2026 [Page 34] - -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: - +=======================+=================+============+===========+ - | Claim Name | Claim | Change | Reference | - | | Description | Controller | | - +=======================+=================+============+===========+ - | wid | Workflow | IETF | Section | - | | Identifier | | 4.2.2 | - +-----------------------+-----------------+------------+-----------+ - | exec_act | Action/Task | IETF | Section | - | | Type | | 4.2.2 | - +-----------------------+-----------------+------------+-----------+ - | par | Parent Task | IETF | Section | - | | Identifiers | | 4.2.2 | - +-----------------------+-----------------+------------+-----------+ - | pol | Policy Rule | IETF | Section | - | | Identifier | | 4.2.3 | - +-----------------------+-----------------+------------+-----------+ - | pol_decision | Policy Decision | IETF | Section | - | | Result | | 4.2.3 | - +-----------------------+-----------------+------------+-----------+ - | pol_enforcer | Policy Enforcer | IETF | Section | - | | Identity | | 4.2.3 | - +-----------------------+-----------------+------------+-----------+ - | inp_hash | Input Data Hash | IETF | Section | - | | | | 4.2.4 | - +-----------------------+-----------------+------------+-----------+ - | out_hash | Output Data | IETF | Section | - | | Hash | | 4.2.4 | - +-----------------------+-----------------+------------+-----------+ - | compensation_required | Compensation | IETF | Section | - | | Flag | | 4.2.5 | - +-----------------------+-----------------+------------+-----------+ - | compensation_reason | Compensation | IETF | Section | - | | Reason | | 4.2.5 | - +-----------------------+-----------------+------------+-----------+ - | ext | Extension | IETF | Section | - | | Object | | 4.2.6 | - +-----------------------+-----------------+------------+-----------+ - - Table 1: JWT Claims Registrations @@ -1957,11 +1888,52 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 28 August 2026 [Page 35] + + + + + + + + + + + + + +Nennemann Expires 29 August 2026 [Page 34] Internet-Draft WIMSE Execution Context February 2026 + +============+=====================+===================+===========+ + | Claim Name | Claim Description | Change Controller | Reference | + +============+=====================+===================+===========+ + | wid | Workflow Identifier | IETF | Section | + | | | | 4.2.2 | + +------------+---------------------+-------------------+-----------+ + | exec_act | Action/Task Type | IETF | Section | + | | | | 4.2.2 | + +------------+---------------------+-------------------+-----------+ + | par | Parent Task | IETF | Section | + | | Identifiers | | 4.2.2 | + +------------+---------------------+-------------------+-----------+ + | inp_hash | Input Data Hash | IETF | Section | + | | | | 4.2.4 | + +------------+---------------------+-------------------+-----------+ + | out_hash | Output Data Hash | IETF | Section | + | | | | 4.2.4 | + +------------+---------------------+-------------------+-----------+ + | ext | Extension Object | IETF | Section | + | | | | 4.2.6 | + +------------+---------------------+-------------------+-----------+ + + Table 1: JWT Claims Registrations + + Note: Policy evaluation keys ("pol", "pol_decision", "pol_enforcer") + are carried within the "ext" object as spec-defined extension keys + (Section 4.2.3) and do not require separate JWT Claims registration. + 12.4. ECT Policy Decision Values Registry This document establishes the "ECT Policy Decision Values" registry @@ -1970,6 +1942,26 @@ Internet-Draft WIMSE Execution Context February 2026 The initial contents of the registry are: + + + + + + + + + + + + + + + +Nennemann Expires 29 August 2026 [Page 35] + +Internet-Draft WIMSE Execution Context February 2026 + + +======================+===================+============+===========+ | Value | Description | Change | Reference | | | | Controller | | @@ -2009,15 +2001,6 @@ Internet-Draft WIMSE Execution Context February 2026 . - - - - -Nennemann Expires 28 August 2026 [Page 36] - -Internet-Draft WIMSE Execution Context February 2026 - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, @@ -2027,6 +2010,14 @@ Internet-Draft WIMSE Execution Context February 2026 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . + + + +Nennemann Expires 29 August 2026 [Page 36] + +Internet-Draft WIMSE Execution Context February 2026 + + [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . @@ -2064,16 +2055,6 @@ Internet-Draft WIMSE Execution Context February 2026 resilience for the financial sector (DORA)", 14 December 2022, . - - - - - -Nennemann Expires 28 August 2026 [Page 37] - -Internet-Draft WIMSE Execution Context February 2026 - - [EU-AI-ACT] European Parliament and Council of the European Union, "Regulation (EU) 2024/1689 of the European Parliament and @@ -2085,6 +2066,14 @@ Internet-Draft WIMSE Execution Context February 2026 "Regulation (EU) 2017/745 on medical devices (MDR)", 5 April 2017, . + + + +Nennemann Expires 29 August 2026 [Page 37] + +Internet-Draft WIMSE Execution Context February 2026 + + [FDA-21CFR11] U.S. Food and Drug Administration, "Title 21, Code of Federal Regulations, Part 11: Electronic Records; @@ -2120,16 +2109,6 @@ Internet-Draft WIMSE Execution Context February 2026 . - - - - - -Nennemann Expires 28 August 2026 [Page 38] - -Internet-Draft WIMSE Execution Context February 2026 - - [MIFID-II] European Parliament and Council of the European Union, "Directive 2014/65/EU of the European Parliament and of the Council on markets in financial instruments (MiFID @@ -2141,6 +2120,16 @@ Internet-Draft WIMSE Execution Context February 2026 Specification", . + + + + + +Nennemann Expires 29 August 2026 [Page 38] + +Internet-Draft WIMSE Execution Context February 2026 + + [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, @@ -2171,21 +2160,6 @@ WIMSE Workload Identity they form an identity-plus-accountability framework for regulated agentic systems. - - - - - - - - - - -Nennemann Expires 28 August 2026 [Page 39] - -Internet-Draft WIMSE Execution Context February 2026 - - OAuth 2.0 Token Exchange and the "act" Claim [RFC8693] defines the OAuth 2.0 Token Exchange protocol and registers @@ -2204,6 +2178,14 @@ OAuth 2.0 Token Exchange and the "act" Claim concepts are orthogonal: "act" records "who authorized whom," ECTs record "what was done, in what order, with what policy outcomes." + + + +Nennemann Expires 29 August 2026 [Page 39] + +Internet-Draft WIMSE Execution Context February 2026 + + Transaction Tokens OAuth Transaction Tokens [I-D.ietf-oauth-transaction-tokens] @@ -2234,14 +2216,6 @@ Transaction Tokens ECTs and Transaction Tokens are complementary: a Txn-Token propagates authorization context ("this request is authorized for scope X on behalf of user Y"), while an ECT records execution accountability - - - -Nennemann Expires 28 August 2026 [Page 40] - -Internet-Draft WIMSE Execution Context February 2026 - - ("task T was performed, depending on tasks P1 and P2, with policy Z evaluated and approved"). An agent request could carry both a Txn- Token for authorization and an ECT for execution recording. The WPT @@ -2260,6 +2234,14 @@ Distributed Tracing (OpenTelemetry) OpenTelemetry data is typically controlled by the platform operator and can be modified or deleted without detection. ECTs and distributed traces are complementary: traces provide observability + + + +Nennemann Expires 29 August 2026 [Page 40] + +Internet-Draft WIMSE Execution Context February 2026 + + while ECTs provide signed execution records. ECTs may reference OpenTelemetry trace identifiers in the "ext" claim for correlation. @@ -2290,14 +2272,6 @@ SCITT (Supply Chain Integrity, Transparency, and Trust) "wid" as the shared correlation point. The "ext" claim in ECTs (Section 4.2.2) can carry SCITT-specific metadata such as Transparency Service identifiers or Receipt references for tighter - - - -Nennemann Expires 28 August 2026 [Page 41] - -Internet-Draft WIMSE Execution Context February 2026 - - integration. W3C Verifiable Credentials @@ -2314,9 +2288,19 @@ Minimal Implementation A minimal conforming implementation needs to: + + + + + +Nennemann Expires 29 August 2026 [Page 41] + +Internet-Draft WIMSE Execution Context February 2026 + + 1. Create JWTs with all required claims ("iss", "aud", "iat", "exp", - "jti", "exec_act", "par") and policy claims ("pol", - "pol_decision") when policy evaluation was performed. + "jti", "exec_act", "par") and policy extension keys ("ext.pol", + "ext.pol_decision") when policy evaluation was performed. 2. Sign ECTs with the agent's private key using an algorithm matching the WIT (ES256 recommended). @@ -2326,7 +2310,7 @@ Minimal Implementation 4. Perform DAG validation (parent existence, temporal ordering, cycle detection). - 5. Append verified ECTs to the audit ledger. + 5. If an audit ledger is deployed, append verified ECTs to it. Storage Recommendations @@ -2346,14 +2330,6 @@ Performance Considerations * ES256 signature verification: approximately 1ms per ECT on modern hardware. - - - -Nennemann Expires 28 August 2026 [Page 42] - -Internet-Draft WIMSE Execution Context February 2026 - - * DAG validation: O(V) where V is the number of reachable ancestor nodes (typically small for shallow workflows). @@ -2370,6 +2346,14 @@ Interoperability expected to be tested against multiple JWT libraries to ensure interoperability. + + + +Nennemann Expires 29 August 2026 [Page 42] + +Internet-Draft WIMSE Execution Context February 2026 + + Regulatory Compliance Mapping The following table summarizes how ECTs can contribute to compliance @@ -2377,39 +2361,6 @@ Regulatory Compliance Mapping block; achieving compliance requires additional organizational measures beyond this specification. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Nennemann Expires 28 August 2026 [Page 43] - -Internet-Draft WIMSE Execution Context February 2026 - - +============+========================+==========================+ | Regulation | Requirement | ECT Contribution | +============+========================+==========================+ @@ -2450,6 +2401,15 @@ Example 1: Simple Two-Agent Workflow ECT JOSE Header: + + + + +Nennemann Expires 29 August 2026 [Page 43] + +Internet-Draft WIMSE Execution Context February 2026 + + { "alg": "ES256", "typ": "wimse-exec+jwt", @@ -2458,17 +2418,8 @@ Example 1: Simple Two-Agent Workflow ECT Payload: - - - -Nennemann Expires 28 August 2026 [Page 44] - -Internet-Draft WIMSE Execution Context February 2026 - - { "iss": "spiffe://example.com/agent/data-retrieval", - "sub": "spiffe://example.com/agent/data-retrieval", "aud": "spiffe://example.com/agent/validator", "iat": 1772064150, "exp": 1772064750, @@ -2476,10 +2427,12 @@ Internet-Draft WIMSE Execution Context February 2026 "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", "exec_act": "fetch_patient_data", "par": [], - "pol": "clinical_data_access_policy_v1", - "pol_decision": "approved", "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", - "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" + "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", + "ext": { + "pol": "clinical_data_access_policy_v1", + "pol_decision": "approved" + } } Agent B receives the ECT, verifies it, executes a validation task, @@ -2487,7 +2440,6 @@ Internet-Draft WIMSE Execution Context February 2026 { "iss": "spiffe://example.com/agent/validator", - "sub": "spiffe://example.com/agent/validator", "aud": "spiffe://example.com/system/ledger", "iat": 1772064160, "exp": 1772064760, @@ -2495,12 +2447,25 @@ Internet-Draft WIMSE Execution Context February 2026 "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", "exec_act": "validate_safety", "par": ["550e8400-e29b-41d4-a716-446655440001"], - "pol": "safety_validation_policy_v2", - "pol_decision": "approved" + "ext": { + "pol": "safety_validation_policy_v2", + "pol_decision": "approved" + } } The resulting DAG: + + + + + + +Nennemann Expires 29 August 2026 [Page 44] + +Internet-Draft WIMSE Execution Context February 2026 + + task-...-0001 (fetch_patient_data) | v @@ -2513,18 +2478,8 @@ Example 2: Medical Device SDLC with Release Approval Task 1 (Spec Review Agent): - - - - -Nennemann Expires 28 August 2026 [Page 45] - -Internet-Draft WIMSE Execution Context February 2026 - - { "iss": "spiffe://meddev.example/agent/spec-reviewer", - "sub": "spiffe://meddev.example/agent/spec-reviewer", "aud": "spiffe://meddev.example/agent/code-gen", "iat": 1772064150, "exp": 1772064750, @@ -2532,17 +2487,18 @@ Internet-Draft WIMSE Execution Context February 2026 "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "review_requirements_spec", "par": [], - "pol": "spec_review_policy_v2", - "pol_decision": "approved", "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", - "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" + "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", + "ext": { + "pol": "spec_review_policy_v2", + "pol_decision": "approved" + } } Task 2 (Code Generation Agent): { "iss": "spiffe://meddev.example/agent/code-gen", - "sub": "spiffe://meddev.example/agent/code-gen", "aud": "spiffe://meddev.example/agent/test-runner", "iat": 1772064200, "exp": 1772064800, @@ -2550,15 +2506,24 @@ Internet-Draft WIMSE Execution Context February 2026 "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "implement_module", "par": ["a1b2c3d4-0001-0000-0000-000000000001"], - "pol": "coding_standards_v3", - "pol_decision": "approved" + "ext": { + "pol": "coding_standards_v3", + "pol_decision": "approved" + } } Task 3 (Autonomous Test Agent): + + + +Nennemann Expires 29 August 2026 [Page 45] + +Internet-Draft WIMSE Execution Context February 2026 + + { "iss": "spiffe://meddev.example/agent/test-runner", - "sub": "spiffe://meddev.example/agent/test-runner", "aud": "spiffe://meddev.example/agent/build", "iat": 1772064260, "exp": 1772064860, @@ -2566,23 +2531,16 @@ Internet-Draft WIMSE Execution Context February 2026 "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "execute_test_suite", "par": ["a1b2c3d4-0001-0000-0000-000000000002"], - "pol": "test_coverage_policy_v1", - "pol_decision": "approved" + "ext": { + "pol": "test_coverage_policy_v1", + "pol_decision": "approved" + } } - - - -Nennemann Expires 28 August 2026 [Page 46] - -Internet-Draft WIMSE Execution Context February 2026 - - Task 4 (Build Agent): { "iss": "spiffe://meddev.example/agent/build", - "sub": "spiffe://meddev.example/agent/build", "aud": "spiffe://meddev.example/human/release-mgr-42", "iat": 1772064310, "exp": 1772064910, @@ -2590,16 +2548,38 @@ Internet-Draft WIMSE Execution Context February 2026 "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "build_release_artifact", "par": ["a1b2c3d4-0001-0000-0000-000000000003"], - "pol": "build_validation_v2", - "pol_decision": "approved", - "out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc" + "out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc", + "ext": { + "pol": "build_validation_v2", + "pol_decision": "approved" + } } Task 5 (Human Release Manager Approval): + + + + + + + + + + + + + + + + +Nennemann Expires 29 August 2026 [Page 46] + +Internet-Draft WIMSE Execution Context February 2026 + + { "iss": "spiffe://meddev.example/human/release-mgr-42", - "sub": "spiffe://meddev.example/human/release-mgr-42", "aud": "spiffe://meddev.example/system/ledger", "iat": 1772064510, "exp": 1772065110, @@ -2607,10 +2587,10 @@ Internet-Draft WIMSE Execution Context February 2026 "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "approve_release", "par": ["a1b2c3d4-0001-0000-0000-000000000004"], - "pol": "release_approval_policy", - "pol_decision": "approved", - "pol_enforcer": "spiffe://meddev.example/human/release-mgr-42", "ext": { + "pol": "release_approval_policy", + "pol_decision": "approved", + "pol_enforcer": "spiffe://meddev.example/human/release-mgr-42", "witnessed_by": [ "spiffe://meddev.example/audit/qa-observer-1" ] @@ -2623,17 +2603,6 @@ Internet-Draft WIMSE Execution Context February 2026 "ext" object in task 5 carries witness metadata via the "witnessed_by" extension key. - - - - - - -Nennemann Expires 28 August 2026 [Page 47] - -Internet-Draft WIMSE Execution Context February 2026 - - task-...-0001 (review_requirements_spec) | v @@ -2654,6 +2623,17 @@ Internet-Draft WIMSE Execution Context February 2026 that the SDLC followed the prescribed process with human oversight at the release gate. + + + + + + +Nennemann Expires 29 August 2026 [Page 47] + +Internet-Draft WIMSE Execution Context February 2026 + + Example 3: Parallel Execution with Join A workflow where two tasks execute in parallel and a third task @@ -2671,28 +2651,8 @@ Example 3: Parallel Execution with Join Task 004 ECT payload: - - - - - - - - - - - - - - -Nennemann Expires 28 August 2026 [Page 48] - -Internet-Draft WIMSE Execution Context February 2026 - - { "iss": "spiffe://bank.example/agent/execution", - "sub": "spiffe://bank.example/agent/execution", "aud": "spiffe://bank.example/system/ledger", "iat": 1772064250, "exp": 1772064850, @@ -2703,8 +2663,10 @@ Internet-Draft WIMSE Execution Context February 2026 "f1e2d3c4-0002-0000-0000-000000000002", "f1e2d3c4-0003-0000-0000-000000000003" ], - "pol": "trade_execution_policy_v3", - "pol_decision": "approved" + "ext": { + "pol": "trade_execution_policy_v3", + "pol_decision": "approved" + } } The "par" array with two entries records that both compliance @@ -2720,6 +2682,14 @@ Acknowledgments Author's Address + + + +Nennemann Expires 29 August 2026 [Page 48] + +Internet-Draft WIMSE Execution Context February 2026 + + Christian Nennemann Independent Researcher Email: ietf@nennemann.de @@ -2741,4 +2711,34 @@ Author's Address -Nennemann Expires 28 August 2026 [Page 49] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Nennemann Expires 29 August 2026 [Page 49] diff --git a/draft-nennemann-wimse-execution-context-00.xml b/draft-nennemann-wimse-execution-context-00.xml index d03090c..e7f3bdd 100644 --- a/draft-nennemann-wimse-execution-context-00.xml +++ b/draft-nennemann-wimse-execution-context-00.xml @@ -23,7 +23,7 @@ - + Security WIMSE @@ -131,7 +131,7 @@ regulatory audit scenarios. The Execution Context Token (ECT) format () DAG structure for task dependency ordering () - Policy checkpoint recording () + Policy checkpoint recording via extension keys () Integration with the WIMSE identity framework () An HTTP header for ECT transport () @@ -405,13 +405,6 @@ SPIFFE ID in the format spiffe://<trust-domain>/<pa matching the "sub" claim of the agent's WIT. Non-WIMSE deployments MAY use other URI schemes (e.g., HTTPS URLs or URN:UUID identifiers). - -
      sub:
      -
      - OPTIONAL. StringOrURI. The subject of the ECT. When present, -MUST equal the "iss" claim. This claim is included for -compatibility with JWT libraries and frameworks that expect a -"sub" claim to be present.
      aud:
      @@ -511,24 +504,28 @@ multiple root tasks. -
      Policy Evaluation +
      Policy Evaluation Extension Keys -The following claims record policy evaluation outcomes: +Policy evaluation outcomes are recorded as extension keys within +the "ext" object (). This keeps the core +registered claims focused on DAG structure and execution context, +while allowing deployments to add policy recording as needed. + +The following extension keys are defined for policy evaluation:
      -
      pol:
      +
      "pol":
      - OPTIONAL. String. The identifier of the policy rule that was -evaluated for this task (e.g., -"clinical_data_access_policy_v1"). MUST be present when -"pol_decision" is present. + String. The identifier of the policy rule that was evaluated +for this task (e.g., "clinical_data_access_policy_v1"). MUST +be present when "pol_decision" is present.
      -
      pol_decision:
      +
      "pol_decision":
      - OPTIONAL. String. The result of the policy evaluation. When -present, MUST be one of the values registered in the ECT Policy -Decision Values registry (). MUST be -present when "pol" is present. Initial values are: + String. The result of the policy evaluation. When present, +MUST be one of the values registered in the ECT Policy Decision +Values registry (). MUST be present +when "pol" is present. Initial values are: @@ -548,28 +545,28 @@ records an "approved" decision referencing this task as a parent. - When "pol" and "pol_decision" are absent, the ECT records task -execution without a policy checkpoint. Regulated deployments -SHOULD include policy claims on all ECTs to maintain complete -audit trails. + When "pol" and "pol_decision" are absent from "ext", the ECT +records task execution without a policy checkpoint. Regulated +deployments SHOULD include policy keys on all ECTs to maintain +complete audit trails.
      -
      pol_enforcer:
      +
      "pol_enforcer":
      - OPTIONAL. StringOrURI. The identity of the entity (system or -person) that evaluated the policy decision. When present, -SHOULD use SPIFFE ID format. + StringOrURI. The identity of the entity (system or person) +that evaluated the policy decision. When present, SHOULD use +SPIFFE ID format.
      This specification intentionally defines only the recording of policy evaluation outcomes. The mechanisms by which policies are defined, distributed to agents, and evaluated are out of scope. -The "pol" claim is an opaque identifier referencing an external +The "pol" key is an opaque identifier referencing an external policy; the semantics and enforcement of that policy are determined by the deployment environment. Implementations may use any policy engine or framework (e.g., OPA/Rego, Cedar, XACML, or custom solutions) provided that the evaluation outcome is -faithfully recorded in the ECT claims defined above. +faithfully recorded in the "ext" keys defined above.
      Data Integrity @@ -601,30 +598,12 @@ using the same format and algorithm requirements as "inp_hash".
      Compensation and Rollback -
      -
      compensation_required:
      -
      - OPTIONAL. Boolean. Indicates whether this task is a -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. -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. -
      -
      - -Note: compensation ECTs reference historical parent tasks via the -"par" claim. The referenced parent ECTs may have passed their own -"exp" time; ECT expiration applies to the verification window of -the ECT itself, not to its validity as a parent reference in the -ledger. +Compensation and rollback actions are recorded using the "par" +claim to reference the original task and the "exec_act" claim to +describe the remediation action. The referenced parent ECTs may +have passed their own "exp" time; ECT expiration applies to the +verification window of the ECT itself, not to its validity as a +parent reference in the ECT store.
      Extensions @@ -650,7 +629,22 @@ exceeds these limits. The following extension keys are defined by this specification for common use cases. Because these keys are documented here, -they use short names without reverse domain prefixes: +they use short names without reverse domain prefixes. + +Policy evaluation keys (see for full +definitions and decision value semantics): + + + "pol": String. Policy rule identifier. + "pol_decision": String. Policy evaluation outcome +("approved", "rejected", or "pending_human_review"). + "pol_enforcer": StringOrURI. Identity of the policy +evaluator. + "pol_timestamp": NumericDate. Time at which the policy +decision was made, if distinct from "iat". + + +Operational metadata keys: "exec_time_ms": Integer. Execution duration in milliseconds. @@ -663,8 +657,12 @@ task. Note: this is self-asserted; for verifiable witness attestation, witnesses should submit independent signed ECTs. "inp_classification": String. Data sensitivity classification (e.g., "public", "confidential", "restricted"). - "pol_timestamp": NumericDate. Time at which the policy -decision was made, if distinct from "iat". + "compensation_required": Boolean. Indicates whether this task +is a compensation or rollback action. + "compensation_reason": String. Structured reason code for the +compensation action (e.g., "policy_violation_in_parent_trade"). +SHOULD use structured identifiers rather than free-form text +to minimize information leakage (see ).
      @@ -676,7 +674,6 @@ decision was made, if distinct from "iat".
      "exec_act": "recommend_treatment", "par": [], - "pol": "clinical_reasoning_policy_v2", - "pol_decision": "approved", - "pol_enforcer": "spiffe://example.com/policy/clinical-engine", - "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", "ext": { + "pol": "clinical_reasoning_policy_v2", + "pol_decision": "approved", + "pol_enforcer": "spiffe://example.com/policy/clinical-engine", "pol_timestamp": 1772064145, "exec_time_ms": 245, "regulated_domain": "medtech", @@ -783,15 +779,14 @@ ECT MUST be rejected. Acyclicity: Following the chain of parent references MUST NOT lead back to the current ECT's "jti". If a cycle is detected, the ECT MUST be rejected. - Parent Policy Decision: If any parent ECT contains a -"pol_decision" of "rejected" or "pending_human_review", the -current ECT'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. This rule only applies when the parent ECT -contains policy claims. + Parent Policy Decision: If any parent ECT's "ext" object +contains a "pol_decision" of "rejected" or +"pending_human_review", the current ECT'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". This rule only applies +when the parent ECT's "ext" contains policy keys. 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. @@ -897,18 +892,18 @@ identity MUST appear in "aud". verifier's current time, to account for clock skew). Verify all required claims ("jti", "exec_act", "par") are present and well-formed. - If "pol" or "pol_decision" is present, verify that both are -present and that "pol_decision" is one of "approved", -"rejected", or "pending_human_review". + If "ext" is present and contains "pol" or "pol_decision", +verify that both are present and that "pol_decision" is one +of "approved", "rejected", or "pending_human_review". Perform DAG validation per . - If all checks pass, the ECT MUST be appended to the audit -ledger. + If all checks pass and an audit ledger is deployed, the ECT +SHOULD be appended to the ledger. If any verification step fails, the ECT MUST be rejected and the 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. +ECT store, to prevent information disclosure. When ECT verification fails during HTTP request processing, the receiving agent SHOULD respond with HTTP 403 (Forbidden) if the @@ -977,11 +972,12 @@ function verify_ect(ect_jws, verifier_id, if claim not in payload: return reject("Missing required claim: " + claim) - // Validate policy claims (optional, but must be paired) - if "pol" in payload or "pol_decision" in payload: - if "pol" not in payload or "pol_decision" not in payload: + // Validate policy extension keys (optional, but must be paired) + ext = payload.ext or {} + if "pol" in ext or "pol_decision" in ext: + if "pol" not in ext or "pol_decision" not in ext: return reject("pol and pol_decision must both be present") - if payload.pol_decision not in + if ext.pol_decision not in ["approved", "rejected", "pending_human_review"]: return reject("Invalid pol_decision value") @@ -1052,29 +1048,34 @@ software used in medical devices. Agent A (Spec Reviewer): jti: task-001 par: [] exec_act: review_requirements_spec - pol: spec_review_policy_v2 pol_decision: approved + ext.pol: spec_review_policy_v2 + ext.pol_decision: approved Agent B (Code Generator): jti: task-002 par: [task-001] exec_act: implement_module - pol: coding_standards_v3 pol_decision: approved + ext.pol: coding_standards_v3 + ext.pol_decision: approved Agent C (Test Agent): jti: task-003 par: [task-002] exec_act: execute_test_suite - pol: test_coverage_policy_v1 pol_decision: approved + ext.pol: test_coverage_policy_v1 + ext.pol_decision: approved Agent D (Build Agent): jti: task-004 par: [task-003] exec_act: build_release_artifact - pol: build_validation_v2 pol_decision: approved + ext.pol: build_validation_v2 + ext.pol_decision: approved Human Release Manager: jti: task-005 par: [task-004] exec_act: approve_release - pol: release_approval_policy pol_decision: approved - pol_enforcer: spiffe://meddev.example/human/release-mgr-42 - ext: {witnessed_by: [...]} (extension metadata) + ext.pol: release_approval_policy + ext.pol_decision: approved + ext.pol_enforcer: spiffe://meddev.example/human/release-mgr-42 + ext.witnessed_by: [...] ]]>
      ECTs record that requirements were reviewed before implementation @@ -1144,17 +1145,20 @@ execution. Agent A (Risk Assessment): jti: task-001 par: [] exec_act: calculate_risk_exposure - pol: risk_limits_policy_v2 pol_decision: approved + ext.pol: risk_limits_policy_v2 + ext.pol_decision: approved Agent B (Compliance): jti: task-002 par: [task-001] exec_act: verify_compliance - pol: compliance_check_v1 pol_decision: approved + ext.pol: compliance_check_v1 + ext.pol_decision: approved Agent C (Execution): jti: task-003 par: [task-002] exec_act: execute_trade - pol: execution_policy_v3 pol_decision: approved + ext.pol: execution_policy_v3 + ext.pol_decision: approved ]]> This can contribute to compliance with: @@ -1177,7 +1181,6 @@ a cryptographic link to the original task:
      "wid": "d3e4f5a6-b7c8-9012-def0-123456789012", "exec_act": "initiate_trade_rollback", "par": ["550e8400-e29b-41d4-a716-446655440003"], - "pol": "compensation_policy_v1", - "pol_decision": "approved", - "pol_enforcer": "spiffe://bank.example/human/compliance-officer", - "compensation_required": true, - "compensation_reason": "policy_violation_in_parent_trade" + "ext": { + "pol": "compensation_policy_v1", + "pol_decision": "approved", + "pol_enforcer": "spiffe://bank.example/human/compliance-officer", + "compensation_required": true, + "compensation_reason": "policy_violation_in_parent_trade" + } } ]]>
      @@ -1208,27 +1213,32 @@ required checks were completed: Agent A (Route Planning): jti: task-001 par: [] exec_act: plan_route - pol: route_policy_v1 pol_decision: approved + ext.pol: route_policy_v1 + ext.pol_decision: approved Agent B (Customs): jti: task-002 par: [task-001] exec_act: validate_customs - pol: customs_policy_v2 pol_decision: approved + ext.pol: customs_policy_v2 + ext.pol_decision: approved Agent C (Safety): jti: task-003 par: [task-001] exec_act: verify_cargo_safety - pol: safety_policy_v1 pol_decision: approved + ext.pol: safety_policy_v1 + ext.pol_decision: approved Agent D (Payment): jti: task-004 par: [task-002, task-003] exec_act: authorize_payment - pol: payment_policy_v3 pol_decision: approved + ext.pol: payment_policy_v3 + ext.pol_decision: approved System (Commitment): jti: task-005 par: [task-004] exec_act: commit_shipment - pol: commitment_policy_v1 pol_decision: approved + ext.pol: commitment_policy_v1 + ext.pol_decision: approved ]]> Note that tasks 002 and 003 both depend only on task-001 and can @@ -1263,8 +1273,8 @@ to alter perceived execution ordering. ECTs are self-asserted by the executing agent. The agent claims what it did, and this claim is signed with its private key. A compromised or malicious agent could create ECTs with false claims -(e.g., setting "pol_decision" to "approved" without actually -evaluating the policy). +(e.g., setting "pol_decision" in "ext" to "approved" without +actually evaluating the policy). ECTs do not independently verify that: @@ -1286,36 +1296,12 @@ evidence 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 strengthen witness attestation beyond self-assertion, witnesses +SHOULD submit their own independent signed ECTs referencing the +observed task's "jti" in the "par" array. Auditors can then +cross-check the "witnessed_by" extension against independent +witness ECTs in the ECT store. -To address the self-assertion limitation of the -"witnessed_by" extension, 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 "jti" 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" extension 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 extension value 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 @@ -1486,8 +1472,8 @@ serialized as JSON and SHOULD NOT exceed a nesting depth of Agent identities ("iss", "aud") for accountability purposes Action descriptions ("exec_act") for audit trail completeness - Policy evaluation outcomes ("pol", "pol_decision") for -compliance verification + Policy evaluation outcomes (via "ext" keys "pol", +"pol_decision") when present, for compliance verification Timestamps ("iat", "exp") for temporal ordering @@ -1507,18 +1493,14 @@ hashes via "inp_hash" and "out_hash") Implementations SHOULD minimize the information included in ECTs. The "exec_act" claim SHOULD use structured identifiers (e.g., "process_payment") rather than natural language descriptions. -The "pol" claim SHOULD reference policy identifiers rather than -embedding policy content. +The "pol" extension key 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. +The "compensation_reason" extension key in "ext" +() deserves particular attention: because +it is human-readable, it risks exposing sensitive operational +details. See for guidance on using +structured identifiers.
      Storage and Access Control @@ -1663,18 +1645,6 @@ the "JSON Web Token Claims" registry maintained by IANA: Parent Task Identifiers IETF - pol - Policy Rule Identifier - IETF - - pol_decision - Policy Decision Result - IETF - - pol_enforcer - Policy Enforcer Identity - IETF - inp_hash Input Data Hash IETF @@ -1683,20 +1653,17 @@ the "JSON Web Token Claims" registry maintained by IANA: Output Data Hash IETF - compensation_required - Compensation Flag - IETF - - compensation_reason - Compensation Reason - IETF - ext Extension Object IETF +Note: Policy evaluation keys ("pol", "pol_decision", +"pol_enforcer") are carried within the "ext" object as +spec-defined extension keys () and do not +require separate JWT Claims registration. +
      ECT Policy Decision Values Registry @@ -2184,7 +2151,7 @@ been incorporated into this document. This document obsoletes RFC - +
      Related Work @@ -2324,14 +2291,15 @@ use cases are distinct. Create JWTs with all required claims ("iss", "aud", "iat", -"exp", "jti", "exec_act", "par") and policy claims ("pol", -"pol_decision") when policy evaluation was performed. +"exp", "jti", "exec_act", "par") and policy extension keys +("ext.pol", "ext.pol_decision") when policy evaluation was +performed. Sign ECTs with the agent's private key using an algorithm matching the WIT (ES256 recommended). Verify ECT signatures against WIT public keys. Perform DAG validation (parent existence, temporal ordering, cycle detection). - Append verified ECTs to the audit ledger. + If an audit ledger is deployed, append verified ECTs to it.
      @@ -2426,7 +2394,6 @@ Agent B:
      "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", "exec_act": "fetch_patient_data", "par": [], - "pol": "clinical_data_access_policy_v1", - "pol_decision": "approved", "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", - "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" + "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", + "ext": { + "pol": "clinical_data_access_policy_v1", + "pol_decision": "approved" + } } ]]>
      @@ -2447,7 +2416,6 @@ task, and creates its own ECT:
      "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", "exec_act": "validate_safety", "par": ["550e8400-e29b-41d4-a716-446655440001"], - "pol": "safety_validation_policy_v2", - "pol_decision": "approved" + "ext": { + "pol": "safety_validation_policy_v2", + "pol_decision": "approved" + } } ]]>
      @@ -2480,7 +2450,6 @@ autonomous agents and human release approval:
      "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "review_requirements_spec", "par": [], - "pol": "spec_review_policy_v2", - "pol_decision": "approved", "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg", - "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" + "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564", + "ext": { + "pol": "spec_review_policy_v2", + "pol_decision": "approved" + } } ]]>
      @@ -2500,7 +2471,6 @@ autonomous agents and human release approval:
      "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "implement_module", "par": ["a1b2c3d4-0001-0000-0000-000000000001"], - "pol": "coding_standards_v3", - "pol_decision": "approved" + "ext": { + "pol": "coding_standards_v3", + "pol_decision": "approved" + } } ]]>
      @@ -2518,7 +2490,6 @@ autonomous agents and human release approval:
      "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "execute_test_suite", "par": ["a1b2c3d4-0001-0000-0000-000000000002"], - "pol": "test_coverage_policy_v1", - "pol_decision": "approved" + "ext": { + "pol": "test_coverage_policy_v1", + "pol_decision": "approved" + } } ]]>
      @@ -2536,7 +2509,6 @@ autonomous agents and human release approval:
      "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "build_release_artifact", "par": ["a1b2c3d4-0001-0000-0000-000000000003"], - "pol": "build_validation_v2", - "pol_decision": "approved", - "out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc" + "out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc", + "ext": { + "pol": "build_validation_v2", + "pol_decision": "approved" + } } ]]>
      @@ -2555,7 +2529,6 @@ autonomous agents and human release approval:
      "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "approve_release", "par": ["a1b2c3d4-0001-0000-0000-000000000004"], - "pol": "release_approval_policy", - "pol_decision": "approved", - "pol_enforcer": "spiffe://meddev.example/human/release-mgr-42", "ext": { + "pol": "release_approval_policy", + "pol_decision": "approved", + "pol_enforcer": "spiffe://meddev.example/human/release-mgr-42", "witnessed_by": [ "spiffe://meddev.example/audit/qa-observer-1" ] @@ -2625,7 +2598,6 @@ task-...-0004 (execute_trade)
      @@ -2661,535 +2635,528 @@ tracing is built.