From ddc1e3c6c0ec1cdeff25c4c5448939dcf3234417 Mon Sep 17 00:00:00 2001 From: Christian Nennemann Date: Wed, 25 Feb 2026 15:38:38 +0100 Subject: [PATCH] Split policy/compensation into companion spec, slim down base ECT Move all policy evaluation (pol, pol_decision, pol_enforcer) and compensation claims to I-D.nennemann-wimse-ect-policy-compensation. Base spec now focuses on execution ordering, DAG structure, and audit trail. All examples, diagrams, and prose updated accordingly. Co-Authored-By: Claude Opus 4.6 --- ...-nennemann-wimse-execution-context-00.html | 586 ++----- draft-nennemann-wimse-execution-context-00.md | 305 +--- ...t-nennemann-wimse-execution-context-00.txt | 1358 +++++++---------- ...t-nennemann-wimse-execution-context-00.xml | 1340 +++++++--------- 4 files changed, 1299 insertions(+), 2290 deletions(-) diff --git a/draft-nennemann-wimse-execution-context-00.html b/draft-nennemann-wimse-execution-context-00.html index 6b066fc..64cbb10 100644 --- a/draft-nennemann-wimse-execution-context-00.html +++ b/draft-nennemann-wimse-execution-context-00.html @@ -11,16 +11,16 @@ to the Workload Identity in Multi System Environments (WIMSE) architecture for distributed agentic workflows in regulated environments. ECTs provide signed, structured records of task -execution order, policy evaluation outcomes, and compliance state -across -agent-to-agent communication. By extending WIMSE Workload Identity +execution order and compliance state across agent-to-agent +communication. By extending WIMSE Workload Identity Tokens with execution context claims in JSON Web Token (JWT) format, this specification enables regulated systems to maintain structured audit trails that support compliance verification. ECTs use a directed acyclic graph (DAG) structure to represent task -dependencies, record policy evaluation outcomes at each decision -point, and integrate with WIMSE Workload Identity Tokens (WIT) -using the same signing model and cryptographic primitives. A new +dependencies and integrate with WIMSE Workload Identity Tokens (WIT) +using the same signing model and cryptographic primitives. +Policy evaluation and compensation extensions are defined in + . A new HTTP header field, Execution-Context, is defined for transporting ECTs alongside existing WIMSE headers. ECTs are a technical building block that @@ -1277,16 +1277,16 @@ li > p:last-of-type:only-child { to the Workload Identity in Multi System Environments (WIMSE) architecture for distributed agentic workflows in regulated environments. ECTs provide signed, structured records of task -execution order, policy evaluation outcomes, and compliance state -across -agent-to-agent communication. By extending WIMSE Workload Identity +execution order and compliance state across agent-to-agent +communication. By extending WIMSE Workload Identity Tokens with execution context claims in JSON Web Token (JWT) format, this specification enables regulated systems to maintain structured audit trails that support compliance verification. ECTs use a directed acyclic graph (DAG) structure to represent task -dependencies, record policy evaluation outcomes at each decision -point, and integrate with WIMSE Workload Identity Tokens (WIT) -using the same signing model and cryptographic primitives. A new +dependencies and integrate with WIMSE Workload Identity Tokens (WIT) +using the same signing model and cryptographic primitives. +Policy evaluation and compensation extensions are defined in +[I-D.nennemann-wimse-ect-policy-compensation]. A new HTTP header field, Execution-Context, is defined for transporting ECTs alongside existing WIMSE headers. ECTs are a technical building block that @@ -1391,16 +1391,13 @@ regulatory frameworks.

4.2.2.  Execution Context

  • -

    4.2.3.  Policy Evaluation

    +

    4.2.3.  Data Integrity

  • -

    4.2.4.  Data Integrity

    +

    4.2.4.  Compensation and Rollback

  • -

    4.2.5.  Compensation and Rollback

    -
    • -
  • -

    4.2.6.  Extensions

    +

    4.2.5.  Extensions

    • @@ -1533,9 +1530,6 @@ regulatory frameworks.

  • 12.3.  JWT Claims Registration

    -
    • -
  • -

    12.4.  ECT Policy Decision Values Registry

    • @@ -1639,18 +1633,17 @@ each other across call chains using the Workload-Identity and Workload-Proof-Token HTTP headers.

    However, workload identity alone does not address execution accountability. Knowing who performed an action does not record -what was done, what policy was applied, or whether compliance -requirements were evaluated at each decision point.

    +what was done or in what order.

    Regulated environments increasingly deploy autonomous agents that coordinate across organizational boundaries. Multiple regulatory frameworks — including [EU-AI-ACT], [FDA-21CFR11], [MIFID-II], and [DORA] — require structured, auditable records of automated -decision-making and execution (see Table 3 for a +decision-making and execution (see Table 2 for a detailed mapping).

    This document defines an extension to the WIMSE architecture that addresses the gap between workload identity and execution accountability. WIMSE authenticates agents; this extension records -what they did, in what order, and what policy was evaluated.

    +what they did and in what order.

    As identified in [I-D.ni-wimse-ai-agent-identity], call context in agentic workflows needs to be visible and preserved. ECTs provide a mechanism to address this requirement with cryptographic @@ -1668,15 +1661,15 @@ systems:

  • WIMSE authenticates agents but does not record what they actually did. A WIT proves "Agent A is authorized" but not -"Agent A executed Task X, under Policy Y, producing Output Z."

    +"Agent A executed Task X, producing Output Z."

  • -

    No standard mechanism exists to record policy evaluation -outcomes at each decision point in a multi-agent workflow.

    +

    No standard mechanism exists to cryptographically order and +link task execution across a multi-agent workflow.

  • -

    No mechanism exists to cryptographically link compensation and -rollback decisions to original actions.

    +

    No mechanism exists to reconstruct the complete execution +history of a distributed workflow for audit purposes.

    • Existing observability tools such as distributed tracing @@ -1700,17 +1693,18 @@ regulatory audit scenarios.

    DAG structure for task dependency ordering (Section 6)

  • -

    Policy checkpoint recording (Section 4.2.3)

    +

    Integration with the WIMSE identity framework +(Section 3)

  • -

    Integration with the WIMSE identity framework -(Section 3)

    +

    An HTTP header for ECT transport (Section 5)

  • -

    An HTTP header for ECT transport (Section 5)

    +

    Audit ledger interface requirements (Section 8)

  • -

    Audit ledger interface requirements (Section 8)

    +

    Policy evaluation and compensation extensions are defined +separately in [I-D.nennemann-wimse-ect-policy-compensation]

    • The following are out of scope and are handled by WIMSE:

    @@ -1744,11 +1738,10 @@ controls, policies, procedures, validation, and governance measures beyond the scope of this specification. The regulatory references in this document are intended to motivate the design requirements, not to claim that implementing ECTs satisfies these regulations.

    -

    ECTs provide evidence of claimed execution ordering and policy -evaluation. They do not independently verify that the claimed -execution actually occurred as described, that the policy -evaluation was correct, or that the agent faithfully performed the -stated action. The trustworthiness of ECT claims depends on the +

    ECTs provide evidence of claimed execution ordering. They do not +independently verify that the claimed execution actually occurred +as described or that the agent faithfully performed the stated +action. The trustworthiness of ECT claims depends on the trustworthiness of the signing agent and the integrity of the broader deployment environment.

    @@ -1787,7 +1780,7 @@ edges are directed and no cycles exist.Execution Context Token (ECT):

    A JSON Web Token [RFC7519] defined by this specification that -records task execution details and policy evaluation outcomes.

    +records task execution details.

    Audit Ledger:
    @@ -1797,35 +1790,29 @@ set of workflows, used for regulatory audit and compliance verification.

    -
    Policy Checkpoint:
    +
    Workload Identity Token (WIT):
    -

    A point in a workflow where a policy evaluation outcome is -recorded within an ECT.

    +

    A WIMSE credential proving a workload's identity within a trust +domain.

    -
    Workload Identity Token (WIT):
    +
    Workload Proof Token (WPT):
    -

    A WIMSE credential proving a workload's identity within a trust -domain.

    +

    A WIMSE proof-of-possession token used for request-level +authentication.

    -
    Workload Proof Token (WPT):
    +
    Trust Domain:
    -

    A WIMSE proof-of-possession token used for request-level -authentication.

    -
    -
    -
    Trust Domain:
    -
    -

    A WIMSE concept representing an organizational boundary with a +

    A WIMSE concept representing an organizational boundary with a shared identity issuer, corresponding to a SPIFFE [SPIFFE] -trust domain.

    +trust domain.

    -
    Witness:
    -
    -

    A third-party entity that observes and attests to the execution -of a task, providing additional accountability.

    +
    Witness:
    +
    +

    A third-party entity that observes and attests to the execution +of a task, providing additional accountability.

    @@ -1864,13 +1851,10 @@ the WIMSE scope and are not addressed by workload identity alone:

  • -

    Recording policy evaluation outcomes at each hop

    +

    Maintaining structured execution records

  • -

    Maintaining structured execution records

    -
    • -
  • -

    Linking compensation or rollback actions to original tasks

    +

    Linking actions to their predecessors with cryptographic assurance

    • @@ -1896,7 +1880,7 @@ between the identity layer and the application layer:[I-D.ietf-wimse-s2s-protocol].

  • -

    ECT (this extension): Records what Agent A did, what policy was -evaluated, and what precedent tasks exist.

    +

    ECT (this extension): Records what Agent A did and what +precedent tasks exist.

  • Ledger (if deployed): Appends the verified ECT to the audit @@ -2171,85 +2155,17 @@ 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:

    -
      -
    • -

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

      -
      • -
    • -

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

      -
      • -
    • -

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

      -
      • -
    -

    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.

    -
    -
    -
    pol_enforcer:
    -
    -

    OPTIONAL. 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 semantics and enforcement of that policy are -determined by the deployment environment. Implementations may -use any policy engine or framework (e.g., OPA/Rego, Cedar, XACML, -or custom solutions) provided that the evaluation outcome is -faithfully recorded in the ECT claims defined above.

    -
    -
    -
    +

    -4.2.4. Data Integrity +4.2.3. Data Integrity

    -

    The following claims provide integrity verification for task -inputs and outputs without revealing the data itself:

    -
    -
    inp_hash:
    -
    -

    OPTIONAL. String. A cryptographic hash of the input data, +

    The following claims provide integrity verification for task +inputs and outputs without revealing the data itself:

    +
    +
    inp_hash:
    +
    +

    OPTIONAL. String. A cryptographic hash of the input data, formatted as "hash-algorithm:base64url-encoded-hash" (e.g., "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The hash algorithm identifier MUST be a lowercase value from the @@ -2258,46 +2174,45 @@ IANA Named Information Hash Algorithm Registry (e.g., "sha-256", and SHOULD use "sha-256" unless a stronger algorithm is required. Implementations MUST NOT accept hash algorithms weaker than SHA-256 (e.g., MD5, SHA-1). The hash MUST be -computed over the raw octets of the input data.

    +computed over the raw octets of the input data.

    -
    out_hash:
    -
    -

    OPTIONAL. String. A cryptographic hash of the output data, -using the same format and algorithm requirements as "inp_hash".

    +
    out_hash:
    +
    +

    OPTIONAL. String. A cryptographic hash of the output data, +using the same format and algorithm requirements as "inp_hash".

    -
    +

    -4.2.5. Compensation and Rollback +4.2.4. Compensation and Rollback

    -

    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.

    +

    Compensation and rollback extensions are defined in +[I-D.nennemann-wimse-ect-policy-compensation]. 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 +4.2.5. Extensions

    -
    -
    ext:
    -
    -

    OPTIONAL. Object. An extension object for domain-specific +

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

    +that do not understand extension claims MUST ignore them.

    -

    To avoid key collisions between different domains, extension +

    To avoid key collisions between different domains, extension key names SHOULD use reverse domain notation (e.g., "com.example.custom_field") to avoid collisions between independently developed extensions. To prevent abuse and @@ -2305,46 +2220,34 @@ excessive token size, the serialized JSON representation of the "ext" object SHOULD NOT exceed 4096 bytes, and the JSON nesting depth within the "ext" object SHOULD NOT exceed 5 levels. Implementations SHOULD reject ECTs whose "ext" claim -exceeds these limits.

    -

    The following extension keys are defined by this specification +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:

      -
    • -

      "exec_time_ms": Integer. Execution duration in milliseconds.

      +
    • +

      "exec_time_ms": Integer. Execution duration in milliseconds.

      • -
    • -

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

      +
    • +

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

      • -
    • -

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

      +
    • +

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

      • -
    • -

      "witnessed_by": Array of StringOrURI. Identifiers of +

    • +

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

      -
      • -
    • -

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

      +
    • +

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

    +

    Additional extension keys for policy evaluation and compensation +are defined in [I-D.nennemann-wimse-ect-policy-compensation].

    @@ -2370,15 +2273,10 @@ to minimize information leakage (see 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". This rule only applies when the parent ECT -contains policy claims.

    -
    • -
  • -

    Trust Domain Consistency: Parent tasks SHOULD belong to the +

    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.

    +relationship has been established.

    • @@ -2654,16 +2542,11 @@ 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".

    +

    Perform DAG validation per Section 6.

  • -

    Perform DAG validation per Section 6.

    -
    • -
  • -

    If all checks pass and an audit ledger is deployed, the ECT -SHOULD be appended to the 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 @@ -2743,14 +2626,6 @@ 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: - return reject("pol and pol_decision must both be present") - if payload.pol_decision not in - ["approved", "rejected", "pending_human_review"]: - return reject("Invalid pol_decision value") - // Validate DAG (against ECT store or inline parent ECTs) result = validate_dag(payload, ect_store, clock_skew_tolerance) @@ -2838,28 +2713,22 @@ 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 Agent B (Code Generator): jti: task-002 par: [task-001] exec_act: implement_module - pol: coding_standards_v3 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 Agent D (Build Agent): jti: task-004 par: [task-003] exec_act: build_release_artifact - pol: build_validation_v2 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) @@ -2911,17 +2780,14 @@ task-005 (approve_release) [human, witnessed]

    Each phase was executed by an identified and authenticated agent.

  • -

    Policy checkpoints were evaluated at every phase transition.

    +

    The execution sequence was maintained (no step was bypassed).

  • -

    The execution sequence was maintained (no step was bypassed).

    +

    A human-in-the-loop approved the final release, with independent +witness attestation.

  • -

    A human-in-the-loop approved the final release, with independent -witness attestation.

    -
    • -
  • -

    Timestamps and execution durations are recorded for each step.

    +

    Timestamps and execution durations are recorded for each step.

    • This can contribute to compliance with:

    @@ -2963,17 +2829,14 @@ execution.

    Agent A (Risk Assessment): jti: task-001 par: [] exec_act: calculate_risk_exposure - pol: risk_limits_policy_v2 pol_decision: approved Agent B (Compliance): jti: task-002 par: [task-001] exec_act: verify_compliance - pol: compliance_check_v1 pol_decision: approved Agent C (Execution): jti: task-003 par: [task-002] exec_act: execute_trade - pol: execution_policy_v3 pol_decision: approved
    Figure 10: @@ -3001,39 +2864,10 @@ systems.

    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:

    -
    -
    -
    -
    -{
-  "iss": "spiffe://bank.example/agent/operations",
-  "aud": "spiffe://bank.example/system/ledger",
-  "iat": 1772150550,
-  "exp": 1772151150,
-  "jti": "550e8400-e29b-41d4-a716-446655440099",
-  "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",
-  "ext": {
-    "compensation_required": true,
-    "compensation_reason": "policy_violation_in_parent_trade"
-  }
-}
-
    -
    -
    Figure 11: -Compensation ECT Example -
    -
    -

    The "par" claim links the compensation action to the original -trade, creating an auditable chain from execution through -violation discovery to remediation.

    +

    Compensation and rollback use cases are described in +[I-D.nennemann-wimse-ect-policy-compensation]. The core +ECT mechanism supports compensation through the "par" claim, +which links a remediation ECT to the original task.

    @@ -3045,36 +2879,31 @@ violation discovery to remediation.

    -
    +
     Agent A (Route Planning):
   jti: task-001    par: []
   exec_act: plan_route
-  pol: route_policy_v1        pol_decision: approved
 
 Agent B (Customs):
   jti: task-002    par: [task-001]
   exec_act: validate_customs
-  pol: customs_policy_v2      pol_decision: approved
 
 Agent C (Safety):
   jti: task-003    par: [task-001]
   exec_act: verify_cargo_safety
-  pol: safety_policy_v1       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
 
 System (Commitment):
   jti: task-005    par: [task-004]
   exec_act: commit_shipment
-  pol: commitment_policy_v1   pol_decision: approved
    -
    Figure 12: +
    Figure 11: Logistics Workflow with Parallel Tasks
    @@ -3126,21 +2955,17 @@ 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., claiming an action was performed when it was not).

    ECTs do not independently verify that:

    • The claimed execution actually occurred as described

    • -

      The policy evaluation was correctly performed

      +

      The input/output hashes correspond to the actual data processed

    • -

      The input/output hashes correspond to the actual data processed

      -
      • -
    • -

      The agent faithfully performed the stated action

      +

      The agent faithfully performed the stated action

    The trustworthiness of ECT claims depends on the trustworthiness @@ -3178,12 +3003,8 @@ keys and how keys are protected.¶ entity independent of the workflow agents.

  • -

    Policy lifecycle management: Policy identifiers in ECTs map to -actual, validated policy rules.

    -
    • -
  • -

    Agent deployment governance: Agents are deployed and maintained -in a manner that preserves their integrity.

    +

    Agent deployment governance: Agents are deployed and maintained +in a manner that preserves their integrity.

    • @@ -3245,8 +3066,7 @@ transport security is already established. HTTP Message Signatures request authorization.

  • -

    ECT (execution accountability layer): Records what the agent did -and under what policy.

    +

    ECT (execution accountability layer): Records what the agent did.

    • @@ -3359,7 +3179,7 @@ array to a maximum of 256 entries. Workflows requiring more parent references SHOULD introduce intermediate aggregation tasks. The "ext" object SHOULD NOT exceed 4096 bytes when serialized as JSON and SHOULD NOT exceed a nesting depth of -5 levels (see also Section 4.2.6).

    +5 levels (see also Section 4.2.5).

    @@ -3383,11 +3203,7 @@ 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

    -
    • -
  • -

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

    +

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

    • ECTs are designed to NOT reveal:

    @@ -3416,13 +3232,10 @@ 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" 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.

    +Extension keys in "ext" (Section 4.2.5) deserve particular +attention: human-readable values risk exposing sensitive operational +details. See Section 4.2.5 for guidance on using +structured identifiers.

    @@ -3620,30 +3432,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 @@ -3651,7 +3439,7 @@ the "JSON Web Token Claims" registry maintained by IANA:Input Data Hash IETF - Section 4.2.4 + Section 4.2.3 @@ -3659,7 +3447,7 @@ the "JSON Web Token Claims" registry maintained by IANA:Output Data Hash IETF - Section 4.2.4 + Section 4.2.3 @@ -3667,65 +3455,15 @@ the "JSON Web Token Claims" registry maintained by IANA:Extension Object IETF - Section 4.2.6 - - - - - - - -
    -
    -

    -12.4. ECT Policy Decision Values Registry -

    -

    This document establishes the "ECT Policy Decision Values" -registry under the "JSON Web Token (JWT)" group. Registration -policy is Specification Required per [RFC8126].

    -

    The initial contents of the registry are:

    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    -Table 2: -ECT Policy Decision Values -
    ValueDescriptionChange ControllerReference
    approvedPolicy evaluation succeededIETF - Section 4.2.3 -
    rejectedPolicy evaluation failedIETF - Section 4.2.3 -
    pending_human_reviewAwaiting human judgmentIETF - Section 4.2.3 + Section 4.2.5
    +

    Policy evaluation claims and the ECT Policy Decision Values +registry are defined in +[I-D.nennemann-wimse-ect-policy-compensation].

    @@ -3769,10 +3507,6 @@ policy is Specification Required per [ Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/rfc/rfc7519>.
    -
    [RFC8126]
    -
    -Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/rfc/rfc8126>.
    -
    [RFC8174]
    Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
    @@ -3818,6 +3552,10 @@ policy is Specification Required per [ Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture-22, , <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-22>.
    +
    [I-D.nennemann-wimse-ect-policy-compensation]
    +
    +Nennemann, C., "Policy Evaluation and Compensation Extensions for Execution Context Tokens", <https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect-policy-compensation/>.
    +
    [I-D.ni-wimse-ai-agent-identity]
    Yuan, N. and P. C. Liu, "WIMSE Applicability for AI Agents", Work in Progress, Internet-Draft, draft-ni-wimse-ai-agent-identity-01, , <https://datatracker.ietf.org/doc/html/draft-ni-wimse-ai-agent-identity-01>.
    @@ -3869,9 +3607,9 @@ policy is Specification Required per [[I-D.ietf-wimse-s2s-protocol] provide the identity foundation upon which ECTs are built. WIT/WPT answer "who is this agent?" and "does it control the claimed key?" while -ECTs record "what did this agent do?" and "what policy was -evaluated?" Together they form an identity-plus-accountability -framework for regulated agentic systems.

    +ECTs record "what did this agent do?" Together they form an +identity-plus-accountability framework for regulated agentic +systems.

    @@ -3886,15 +3624,13 @@ delegation chain: "who is acting on behalf of whom." While the nesting superficially resembles a chain, it is strictly linear (each "act" object contains at most one nested "act"), represents authorization delegation rather than task execution, -and carries no task identifiers, policy decisions, or -input/output integrity data. The "act" chain cannot represent +and carries no task identifiers or input/output integrity data. The "act" chain cannot represent branching (fan-out) or convergence (fan-in) and therefore cannot form a DAG.

    ECTs intentionally use the distinct claim name "exec_act" for the action/task type to avoid collision with the "act" claim. The two concepts are orthogonal: "act" records "who authorized whom," -ECTs record "what was done, in what order, with what policy -outcomes."

    +ECTs record "what was done, in what order."

    @@ -3922,7 +3658,7 @@ workloads that forward the token unchanged are not recorded.

    It carries no task-level granularity, no parent references, -no policy evaluation outcomes, and no execution content.

    +and no execution content.

    Extensions for agentic use cases @@ -3933,7 +3669,7 @@ ordering or DAG structure.

    propagates authorization context ("this request is authorized for scope X on behalf of user Y"), while an ECT records execution accountability ("task T was performed, depending on -tasks P1 and P2, with policy Z evaluated and approved"). An +tasks P1 and P2"). An agent request could carry both a Txn-Token for authorization and an ECT for execution recording. The WPT "tth" claim defined in [I-D.ietf-wimse-s2s-protocol] can hash-bind a @@ -3987,7 +3723,7 @@ identifier referenced in SCITT Signed Statements, linking a complete ECT audit trail to a supply chain transparency record. For example, in a regulated manufacturing workflow, each agent step produces an ECT (recording what was done, by whom, under -what policy), while the overall workflow identified by "wid" is +under what constraints), while the overall workflow identified by "wid" is registered as a SCITT Signed Statement on a Transparency Service. This enables auditors to verify both the individual execution steps (via ECT DAG validation) and the end-to-end supply chain @@ -4004,7 +3740,7 @@ identifiers or Receipt references for tighter integration.W3C Verifiable Credentials represent claims about subjects (e.g., identity, qualifications). ECTs represent execution records of -actions (what happened, in what order, under what policy). While +actions (what happened, in what order). While both use JWT/JWS as a serialization format, their semantics and use cases are distinct.

    @@ -4025,8 +3761,7 @@ 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").

    2. Sign ECTs with the agent's private key using an algorithm @@ -4118,9 +3853,9 @@ compliance with various regulatory frameworks. ECTs are a technical building block; achieving compliance requires additional organizational measures beyond this specification.

      - +
      @@ -4200,8 +3935,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" } @@ -4219,9 +3952,7 @@ task, and creates its own ECT: @@ -4255,8 +3986,6 @@ autonomous agents and human release approval: @@ -4290,9 +4017,7 @@ autonomous agents and human release approval: @@ -4308,8 +4033,6 @@ autonomous agents and human release approval: @@ -4326,9 +4049,6 @@ autonomous agents and human release approval: diff --git a/draft-nennemann-wimse-execution-context-00.md b/draft-nennemann-wimse-execution-context-00.md index ecf565a..3f0ae04 100644 --- a/draft-nennemann-wimse-execution-context-00.md +++ b/draft-nennemann-wimse-execution-context-00.md @@ -28,7 +28,6 @@ normative: RFC7517: RFC7519: RFC7518: - RFC8126: RFC9562: RFC9110: I-D.ietf-wimse-arch: @@ -39,6 +38,12 @@ informative: RFC8693: RFC9421: I-D.ni-wimse-ai-agent-identity: + I-D.nennemann-wimse-ect-policy-compensation: + title: "Policy Evaluation and Compensation Extensions for Execution Context Tokens" + target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect-policy-compensation/ + date: false + author: + - fullname: Christian Nennemann SPIFFE: title: "Secure Production Identity Framework for Everyone (SPIFFE)" target: https://spiffe.io/docs/latest/spiffe-about/overview/ @@ -89,16 +94,16 @@ This document defines Execution Context Tokens (ECTs), an extension to the Workload Identity in Multi System Environments (WIMSE) architecture for distributed agentic workflows in regulated environments. ECTs provide signed, structured records of task -execution order, policy evaluation outcomes, and compliance state -across -agent-to-agent communication. By extending WIMSE Workload Identity +execution order and compliance state across agent-to-agent +communication. By extending WIMSE Workload Identity Tokens with execution context claims in JSON Web Token (JWT) format, this specification enables regulated systems to maintain structured audit trails that support compliance verification. ECTs use a directed acyclic graph (DAG) structure to represent task -dependencies, record policy evaluation outcomes at each decision -point, and integrate with WIMSE Workload Identity Tokens (WIT) -using the same signing model and cryptographic primitives. A new +dependencies and integrate with WIMSE Workload Identity Tokens (WIT) +using the same signing model and cryptographic primitives. +Policy evaluation and compensation extensions are defined in +{{I-D.nennemann-wimse-ect-policy-compensation}}. A new HTTP header field, Execution-Context, is defined for transporting ECTs alongside existing WIMSE headers. ECTs are a technical building block that @@ -121,8 +126,7 @@ Workload-Proof-Token HTTP headers. However, workload identity alone does not address execution accountability. Knowing who performed an action does not record -what was done, what policy was applied, or whether compliance -requirements were evaluated at each decision point. +what was done or in what order. Regulated environments increasingly deploy autonomous agents that coordinate across organizational boundaries. Multiple regulatory @@ -134,7 +138,7 @@ detailed mapping). This document defines an extension to the WIMSE architecture that addresses the gap between workload identity and execution accountability. WIMSE authenticates agents; this extension records -what they did, in what order, and what policy was evaluated. +what they did and in what order. As identified in {{I-D.ni-wimse-ai-agent-identity}}, call context in agentic workflows needs to be visible and preserved. ECTs @@ -148,13 +152,13 @@ systems: 1. WIMSE authenticates agents but does not record what they actually did. A WIT proves "Agent A is authorized" but not - "Agent A executed Task X, under Policy Y, producing Output Z." + "Agent A executed Task X, producing Output Z." -2. No standard mechanism exists to record policy evaluation - outcomes at each decision point in a multi-agent workflow. +2. No standard mechanism exists to cryptographically order and + link task execution across a multi-agent workflow. -3. No mechanism exists to cryptographically link compensation and - rollback decisions to original actions. +3. No mechanism exists to reconstruct the complete execution + history of a distributed workflow for audit purposes. Existing observability tools such as distributed tracing {{OPENTELEMETRY}} provide visibility for debugging and monitoring @@ -168,11 +172,12 @@ This document defines: - The Execution Context Token (ECT) format ({{ect-format}}) - DAG structure for task dependency ordering ({{dag-validation}}) -- Policy checkpoint recording ({{policy-claims}}) - Integration with the WIMSE identity framework ({{wimse-integration}}) - An HTTP header for ECT transport ({{http-header}}) - Audit ledger interface requirements ({{ledger-interface}}) +- Policy evaluation and compensation extensions are defined + separately in {{I-D.nennemann-wimse-ect-policy-compensation}} The following are out of scope and are handled by WIMSE: @@ -194,11 +199,10 @@ beyond the scope of this specification. The regulatory references in this document are intended to motivate the design requirements, not to claim that implementing ECTs satisfies these regulations. -ECTs provide evidence of claimed execution ordering and policy -evaluation. They do not independently verify that the claimed -execution actually occurred as described, that the policy -evaluation was correct, or that the agent faithfully performed the -stated action. The trustworthiness of ECT claims depends on the +ECTs provide evidence of claimed execution ordering. They do not +independently verify that the claimed execution actually occurred +as described or that the agent faithfully performed the stated +action. The trustworthiness of ECT claims depends on the trustworthiness of the signing agent and the integrity of the broader deployment environment. @@ -222,17 +226,13 @@ Directed Acyclic Graph (DAG): Execution Context Token (ECT): : A JSON Web Token {{RFC7519}} defined by this specification that - records task execution details and policy evaluation outcomes. + records task execution details. Audit Ledger: : An append-only, immutable log of all ECTs within a workflow or set of workflows, used for regulatory audit and compliance verification. -Policy Checkpoint: -: A point in a workflow where a policy evaluation outcome is - recorded within an ECT. - Workload Identity Token (WIT): : A WIMSE credential proving a workload's identity within a trust domain. @@ -268,9 +268,8 @@ the WIMSE scope and are not addressed by workload identity alone: - Recording what agents actually do with their authenticated identity -- Recording policy evaluation outcomes at each hop - Maintaining structured execution records -- Linking compensation or rollback actions to original tasks +- Linking actions to their predecessors with cryptographic assurance ## Extension Model @@ -288,7 +287,7 @@ between the identity layer and the application layer: +--------------------------------------------------+ | ECT Layer (Execution Accountability) [This Spec]| | ECT: "Task executed, dependencies met, | -| policy evaluated, outcome recorded" | +| inputs/outputs hashed" | +--------------------------------------------------+ | v @@ -343,8 +342,8 @@ The receiving agent (Agent B) verifies in order: trust domain. WPT verification, if present, per {{I-D.ietf-wimse-s2s-protocol}}. -2. ECT (this extension): Records what Agent A did, what policy was - evaluated, and what precedent tasks exist. +2. ECT (this extension): Records what Agent A did and what + precedent tasks exist. 3. Ledger (if deployed): Appends the verified ECT to the audit ledger. @@ -484,59 +483,6 @@ par: a root task with no dependencies. A workflow MAY contain multiple root tasks. -### Policy Evaluation {#policy-claims} - -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 ({{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. - - * "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". - - * "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. - - 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. - -pol_enforcer: -: OPTIONAL. 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 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. - ### Data Integrity {#data-integrity-claims} The following claims provide integrity verification for task @@ -560,12 +506,11 @@ out_hash: ### Compensation and Rollback {#compensation-claims} -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. +Compensation and rollback extensions are defined in +{{I-D.nennemann-wimse-ect-policy-compensation}}. 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} @@ -598,14 +543,9 @@ 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}}). + +Additional extension keys for policy evaluation and compensation +are defined in {{I-D.nennemann-wimse-ect-policy-compensation}}. ## Complete ECT Example @@ -623,15 +563,10 @@ 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_timestamp": 1772064145, "exec_time_ms": 245, "regulated_domain": "medtech", "model_version": "clinical-reasoning-v4.2" @@ -720,16 +655,7 @@ 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". This rule only applies when the parent ECT - contains policy claims. - -6. Trust Domain Consistency: Parent tasks SHOULD belong to the +5. 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. @@ -842,13 +768,9 @@ 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. Perform DAG validation per {{dag-validation}}. -14. Perform DAG validation per {{dag-validation}}. - -15. If all checks pass and an audit ledger is deployed, the ECT +14. 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 @@ -922,14 +844,6 @@ 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: - return reject("pol and pol_decision must both be present") - if payload.pol_decision not in - ["approved", "rejected", "pending_human_review"]: - return reject("Invalid pol_decision value") - // Validate DAG (against ECT store or inline parent ECTs) result = validate_dag(payload, ect_store, clock_skew_tolerance) @@ -996,28 +910,22 @@ 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 Agent B (Code Generator): jti: task-002 par: [task-001] exec_act: implement_module - pol: coding_standards_v3 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 Agent D (Build Agent): jti: task-004 par: [task-003] exec_act: build_release_artifact - pol: build_validation_v2 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) ~~~ {: #fig-medtech-sdlc title="Medical Device SDLC Workflow"} @@ -1056,7 +964,6 @@ task-005 (approve_release) [human, witnessed] The reconstructed DAG provides cryptographic evidence that: - Each phase was executed by an identified and authenticated agent. -- Policy checkpoints were evaluated at every phase transition. - The execution sequence was maintained (no step was bypassed). - A human-in-the-loop approved the final release, with independent witness attestation. @@ -1084,17 +991,14 @@ execution. Agent A (Risk Assessment): jti: task-001 par: [] exec_act: calculate_risk_exposure - pol: risk_limits_policy_v2 pol_decision: approved Agent B (Compliance): jti: task-002 par: [task-001] exec_act: verify_compliance - pol: compliance_check_v1 pol_decision: approved Agent C (Execution): jti: task-003 par: [task-002] exec_act: execute_trade - pol: execution_policy_v3 pol_decision: approved ~~~ {: #fig-finance title="Financial Trading Workflow"} @@ -1108,34 +1012,10 @@ This can contribute to compliance with: ## 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: - -~~~json -{ - "iss": "spiffe://bank.example/agent/operations", - "aud": "spiffe://bank.example/system/ledger", - "iat": 1772150550, - "exp": 1772151150, - "jti": "550e8400-e29b-41d4-a716-446655440099", - "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", - "ext": { - "compensation_required": true, - "compensation_reason": "policy_violation_in_parent_trade" - } -} -~~~ -{: #fig-compensation title="Compensation ECT Example"} - -The "par" claim links the compensation action to the original -trade, creating an auditable chain from execution through -violation discovery to remediation. +Compensation and rollback use cases are described in +{{I-D.nennemann-wimse-ect-policy-compensation}}. The core +ECT mechanism supports compensation through the "par" claim, +which links a remediation ECT to the original task. ## Autonomous Logistics Coordination @@ -1147,27 +1027,22 @@ required checks were completed: Agent A (Route Planning): jti: task-001 par: [] exec_act: plan_route - pol: route_policy_v1 pol_decision: approved Agent B (Customs): jti: task-002 par: [task-001] exec_act: validate_customs - pol: customs_policy_v2 pol_decision: approved Agent C (Safety): jti: task-003 par: [task-001] exec_act: verify_cargo_safety - pol: safety_policy_v1 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 System (Commitment): jti: task-005 par: [task-004] exec_act: commit_shipment - pol: commitment_policy_v1 pol_decision: approved ~~~ {: #fig-logistics title="Logistics Workflow with Parallel Tasks"} @@ -1198,13 +1073,11 @@ 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., claiming an action was performed when it was not). ECTs do not independently verify that: - The claimed execution actually occurred as described -- The policy evaluation was correctly performed - The input/output hashes correspond to the actual data processed - The agent faithfully performed the stated action @@ -1235,8 +1108,6 @@ organizational controls are in place: keys and how keys are protected. - Ledger integrity governance: The ledger is maintained by an entity independent of the workflow agents. -- Policy lifecycle management: Policy identifiers in ECTs map to - actual, validated policy rules. - Agent deployment governance: Agents are deployed and maintained in a manner that preserves their integrity. @@ -1286,8 +1157,7 @@ The defense-in-depth model provides: - TLS/mTLS (transport layer): Prevents network-level tampering. - WIT/WPT (WIMSE identity layer): Proves agent identity and request authorization. -- ECT (execution accountability layer): Records what the agent did - and under what policy. +- ECT (execution accountability layer): Records what the agent did. ## Key Compromise @@ -1375,8 +1245,6 @@ 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 - Timestamps ("iat", "exp") for temporal ordering ECTs are designed to NOT reveal: @@ -1392,12 +1260,8 @@ 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 "compensation_reason" extension key in "ext" -({{compensation-claims}}) deserves particular attention: because -it is human-readable, it risks exposing sensitive operational +Extension keys in "ext" ({{extension-claims}}) deserve particular +attention: human-readable values risk exposing sensitive operational details. See {{extension-claims}} for guidance on using structured identifiers. @@ -1417,8 +1281,7 @@ general access to the data values is not needed. ECTs are designed for interpretation by qualified human auditors and regulators. ECTs provide structural records of execution -ordering and policy evaluation; they are not intended for public -disclosure. +ordering; they are not intended for public disclosure. # IANA Considerations @@ -1502,28 +1365,14 @@ 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}} | | ext | Extension Object | IETF | {{extension-claims}} | {: #table-claims title="JWT Claims Registrations"} -## ECT Policy Decision Values Registry {#pol-decision-registry} - -This document establishes the "ECT Policy Decision Values" -registry under the "JSON Web Token (JWT)" group. Registration -policy is Specification Required per {{RFC8126}}. - -The initial contents of the registry are: - -| Value | Description | Change Controller | Reference | -|:---:|:---|:---:|:---:| -| approved | Policy evaluation succeeded | IETF | {{policy-claims}} | -| rejected | Policy evaluation failed | IETF | {{policy-claims}} | -| pending_human_review | Awaiting human judgment | IETF | {{policy-claims}} | -{: #table-pol-decision title="ECT Policy Decision Values"} +Policy evaluation claims and the ECT Policy Decision Values +registry are defined in +{{I-D.nennemann-wimse-ect-policy-compensation}}. --- back @@ -1537,9 +1386,9 @@ The WIMSE architecture {{I-D.ietf-wimse-arch}} and service-to- service protocol {{I-D.ietf-wimse-s2s-protocol}} provide the identity foundation upon which ECTs are built. WIT/WPT answer "who is this agent?" and "does it control the claimed key?" while -ECTs record "what did this agent do?" and "what policy was -evaluated?" Together they form an identity-plus-accountability -framework for regulated agentic systems. +ECTs record "what did this agent do?" Together they form an +identity-plus-accountability framework for regulated agentic +systems. ## OAuth 2.0 Token Exchange and the "act" Claim {:numbered="false"} @@ -1551,16 +1400,14 @@ delegation chain: "who is acting on behalf of whom." While the nesting superficially resembles a chain, it is strictly linear (each "act" object contains at most one nested "act"), represents authorization delegation rather than task execution, -and carries no task identifiers, policy decisions, or -input/output integrity data. The "act" chain cannot represent +and carries no task identifiers or input/output integrity data. The "act" chain cannot represent branching (fan-out) or convergence (fan-in) and therefore cannot form a DAG. ECTs intentionally use the distinct claim name "exec_act" for the action/task type to avoid collision with the "act" claim. The two concepts are orthogonal: "act" records "who authorized whom," -ECTs record "what was done, in what order, with what policy -outcomes." +ECTs record "what was done, in what order." ## Transaction Tokens {:numbered="false"} @@ -1581,7 +1428,7 @@ However, "req_wl" cannot form a DAG because: token from the Transaction Token Service appear in "req_wl"; workloads that forward the token unchanged are not recorded. - It carries no task-level granularity, no parent references, - no policy evaluation outcomes, and no execution content. + and no execution content. Extensions for agentic use cases ({{I-D.oauth-transaction-tokens-for-agents}}) add agent @@ -1592,7 +1439,7 @@ 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 ("task T was performed, depending on -tasks P1 and P2, with policy Z evaluated and approved"). An +tasks P1 and P2"). An agent request could carry both a Txn-Token for authorization and an ECT for execution recording. The WPT "tth" claim defined in {{I-D.ietf-wimse-s2s-protocol}} can hash-bind a @@ -1637,7 +1484,7 @@ identifier referenced in SCITT Signed Statements, linking a complete ECT audit trail to a supply chain transparency record. For example, in a regulated manufacturing workflow, each agent step produces an ECT (recording what was done, by whom, under -what policy), while the overall workflow identified by "wid" is +under what constraints), while the overall workflow identified by "wid" is registered as a SCITT Signed Statement on a Transparency Service. This enables auditors to verify both the individual execution steps (via ECT DAG validation) and the end-to-end supply chain @@ -1651,7 +1498,7 @@ identifiers or Receipt references for tighter integration. W3C Verifiable Credentials represent claims about subjects (e.g., identity, qualifications). ECTs represent execution records of -actions (what happened, in what order, under what policy). While +actions (what happened, in what order). While both use JWT/JWS as a serialization format, their semantics and use cases are distinct. @@ -1664,8 +1511,7 @@ 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"). 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. @@ -1754,8 +1600,6 @@ 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" } @@ -1773,9 +1617,7 @@ task, and creates its own ECT: "jti": "550e8400-e29b-41d4-a716-446655440002", "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", "exec_act": "validate_safety", - "par": ["550e8400-e29b-41d4-a716-446655440001"], - "pol": "safety_validation_policy_v2", - "pol_decision": "approved" + "par": ["550e8400-e29b-41d4-a716-446655440001"] } ~~~ @@ -1806,8 +1648,6 @@ 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" } @@ -1824,9 +1664,7 @@ Task 2 (Code Generation Agent): "jti": "a1b2c3d4-0001-0000-0000-000000000002", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "implement_module", - "par": ["a1b2c3d4-0001-0000-0000-000000000001"], - "pol": "coding_standards_v3", - "pol_decision": "approved" + "par": ["a1b2c3d4-0001-0000-0000-000000000001"] } ~~~ @@ -1841,9 +1679,7 @@ Task 3 (Autonomous Test Agent): "jti": "a1b2c3d4-0001-0000-0000-000000000003", "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" + "par": ["a1b2c3d4-0001-0000-0000-000000000002"] } ~~~ @@ -1859,8 +1695,6 @@ 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" } ~~~ @@ -1877,9 +1711,6 @@ 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": { "witnessed_by": [ "spiffe://meddev.example/audit/qa-observer-1" @@ -1948,9 +1779,7 @@ Task 004 ECT payload: "par": [ "f1e2d3c4-0002-0000-0000-000000000002", "f1e2d3c4-0003-0000-0000-000000000003" - ], - "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 c906d0c..038922b 100644 --- a/draft-nennemann-wimse-execution-context-00.txt +++ b/draft-nennemann-wimse-execution-context-00.txt @@ -17,19 +17,20 @@ Abstract to the Workload Identity in Multi System Environments (WIMSE) architecture for distributed agentic workflows in regulated environments. ECTs provide signed, structured records of task - execution order, policy evaluation outcomes, and compliance state - across agent-to-agent communication. By extending WIMSE Workload - Identity Tokens with execution context claims in JSON Web Token (JWT) - format, this specification enables regulated systems to maintain - structured audit trails that support compliance verification. ECTs - use a directed acyclic graph (DAG) structure to represent task - dependencies, record policy evaluation outcomes at each decision - point, and integrate with WIMSE Workload Identity Tokens (WIT) using - the same signing model and cryptographic primitives. A new HTTP - header field, Execution-Context, is defined for transporting ECTs - alongside existing WIMSE headers. ECTs are a technical building - block that supports, but does not by itself constitute, compliance - with regulatory frameworks. + execution order and compliance state across agent-to-agent + communication. By extending WIMSE Workload Identity Tokens with + execution context claims in JSON Web Token (JWT) format, this + specification enables regulated systems to maintain structured audit + trails that support compliance verification. ECTs use a directed + acyclic graph (DAG) structure to represent task dependencies and + integrate with WIMSE Workload Identity Tokens (WIT) using the same + signing model and cryptographic primitives. Policy evaluation and + compensation extensions are defined in + [I-D.nennemann-wimse-ect-policy-compensation]. A new HTTP header + field, Execution-Context, is defined for transporting ECTs alongside + existing WIMSE headers. ECTs are a technical building block that + supports, but does not by itself constitute, compliance with + regulatory frameworks. Status of This Memo @@ -52,7 +53,6 @@ Status of This Memo - Nennemann Expires 29 August 2026 [Page 1] Internet-Draft WIMSE Execution Context February 2026 @@ -80,32 +80,32 @@ Table of Contents 1.3. Scope and Applicability . . . . . . . . . . . . . . . . . 5 1.4. Relationship to Regulatory Compliance . . . . . . . . . . 5 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6 - 3. WIMSE Architecture Integration . . . . . . . . . . . . . . . 7 + 3. WIMSE Architecture Integration . . . . . . . . . . . . . . . 6 3.1. WIMSE Foundation . . . . . . . . . . . . . . . . . . . . 7 3.2. Extension Model . . . . . . . . . . . . . . . . . . . . . 7 3.3. Integration Points . . . . . . . . . . . . . . . . . . . 8 4. Execution Context Token Format . . . . . . . . . . . . . . . 9 4.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.2. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.2.1. Standard JWT Claims . . . . . . . . . . . . . . . . . 10 + 4.2. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.2.1. Standard JWT Claims . . . . . . . . . . . . . . . . . 9 4.2.2. Execution Context . . . . . . . . . . . . . . . . . . 11 - 4.2.3. Policy Evaluation . . . . . . . . . . . . . . . . . . 11 - 4.2.4. Data Integrity . . . . . . . . . . . . . . . . . . . 12 - 4.2.5. Compensation and Rollback . . . . . . . . . . . . . . 13 - 4.2.6. Extensions . . . . . . . . . . . . . . . . . . . . . 13 - 4.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 14 - 5. HTTP Header Transport . . . . . . . . . . . . . . . . . . . . 15 - 5.1. Execution-Context Header Field . . . . . . . . . . . . . 15 - 6. DAG Validation . . . . . . . . . . . . . . . . . . . . . . . 16 - 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 - 6.2. Validation Rules . . . . . . . . . . . . . . . . . . . . 16 - 6.3. DAG Validation Algorithm . . . . . . . . . . . . . . . . 17 - 7. Signature and Token Verification . . . . . . . . . . . . . . 19 - 7.1. Verification Procedure . . . . . . . . . . . . . . . . . 19 - 7.2. Verification Pseudocode . . . . . . . . . . . . . . . . . 20 - 8. Audit Ledger Interface . . . . . . . . . . . . . . . . . . . 22 - 9. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 9.1. Medical Device SDLC Workflow . . . . . . . . . . . . . . 23 + 4.2.3. Data Integrity . . . . . . . . . . . . . . . . . . . 11 + 4.2.4. Compensation and Rollback . . . . . . . . . . . . . . 12 + 4.2.5. Extensions . . . . . . . . . . . . . . . . . . . . . 12 + 4.3. Complete ECT Example . . . . . . . . . . . . . . . . . . 13 + 5. HTTP Header Transport . . . . . . . . . . . . . . . . . . . . 13 + 5.1. Execution-Context Header Field . . . . . . . . . . . . . 13 + 6. DAG Validation . . . . . . . . . . . . . . . . . . . . . . . 14 + 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 + 6.2. Validation Rules . . . . . . . . . . . . . . . . . . . . 14 + 6.3. DAG Validation Algorithm . . . . . . . . . . . . . . . . 15 + 7. Signature and Token Verification . . . . . . . . . . . . . . 17 + 7.1. Verification Procedure . . . . . . . . . . . . . . . . . 17 + 7.2. Verification Pseudocode . . . . . . . . . . . . . . . . . 18 + 8. Audit Ledger Interface . . . . . . . . . . . . . . . . . . . 20 + 9. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 9.1. Medical Device SDLC Workflow . . . . . . . . . . . . . . 20 + 9.1.1. FDA Audit with DAG Reconstruction . . . . . . . . . . 21 @@ -114,54 +114,54 @@ 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.4. Autonomous Logistics Coordination . . . . . . . . . . . . 26 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 10.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 27 - 10.2. Self-Assertion Limitation . . . . . . . . . . . . . . . 28 - 10.3. Organizational Prerequisites . . . . . . . . . . . . . . 28 - 10.4. Signature Verification . . . . . . . . . . . . . . . . . 29 - 10.5. Replay Attack Prevention . . . . . . . . . . . . . . . . 29 - 10.6. Man-in-the-Middle Protection . . . . . . . . . . . . . . 29 - 10.7. Key Compromise . . . . . . . . . . . . . . . . . . . . . 30 - 10.8. Collusion and False Claims . . . . . . . . . . . . . . . 30 - 10.9. Denial of Service . . . . . . . . . . . . . . . . . . . 31 - 10.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 31 - 10.11. ECT Size Constraints . . . . . . . . . . . . . . . . . . 31 - 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31 - 11.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . 31 - 11.2. Data Minimization . . . . . . . . . . . . . . . . . . . 32 - 11.3. Storage and Access Control . . . . . . . . . . . . . . . 32 - 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 . . . . . . . . . . . . . . . . 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 . . . . . . . . . 39 - Transaction Tokens . . . . . . . . . . . . . . . . . . . . . . 40 - Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 40 - Blockchain and Distributed Ledgers . . . . . . . . . . . . . . 41 - SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 41 - W3C Verifiable Credentials . . . . . . . . . . . . . . . . . . 41 - Implementation Guidance . . . . . . . . . . . . . . . . . . . . . 41 - Minimal Implementation . . . . . . . . . . . . . . . . . . . . 41 - Storage Recommendations . . . . . . . . . . . . . . . . . . . . 42 - Performance Considerations . . . . . . . . . . . . . . . . . . 42 - Interoperability . . . . . . . . . . . . . . . . . . . . . . . 42 - Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . . 43 - 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 + 9.2. Financial Trading Workflow . . . . . . . . . . . . . . . 22 + 9.3. Compensation and Rollback . . . . . . . . . . . . . . . . 23 + 9.4. Autonomous Logistics Coordination . . . . . . . . . . . . 23 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 10.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 24 + 10.2. Self-Assertion Limitation . . . . . . . . . . . . . . . 25 + 10.3. Organizational Prerequisites . . . . . . . . . . . . . . 25 + 10.4. Signature Verification . . . . . . . . . . . . . . . . . 26 + 10.5. Replay Attack Prevention . . . . . . . . . . . . . . . . 26 + 10.6. Man-in-the-Middle Protection . . . . . . . . . . . . . . 26 + 10.7. Key Compromise . . . . . . . . . . . . . . . . . . . . . 27 + 10.8. Collusion and False Claims . . . . . . . . . . . . . . . 27 + 10.9. Denial of Service . . . . . . . . . . . . . . . . . . . 28 + 10.10. Timestamp Accuracy . . . . . . . . . . . . . . . . . . . 28 + 10.11. ECT Size Constraints . . . . . . . . . . . . . . . . . . 28 + 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 + 11.1. Data Exposure in ECTs . . . . . . . . . . . . . . . . . 28 + 11.2. Data Minimization . . . . . . . . . . . . . . . . . . . 29 + 11.3. Storage and Access Control . . . . . . . . . . . . . . . 29 + 11.4. Regulatory Access . . . . . . . . . . . . . . . . . . . 29 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 + 12.1. Media Type Registration . . . . . . . . . . . . . . . . 29 + 12.2. HTTP Header Field Registration . . . . . . . . . . . . . 30 + 12.3. JWT Claims Registration . . . . . . . . . . . . . . . . 31 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 31 + 13.2. Informative References . . . . . . . . . . . . . . . . . 32 + Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . . 34 + OAuth 2.0 Token Exchange and the "act" Claim . . . . . . . . . 34 + Transaction Tokens . . . . . . . . . . . . . . . . . . . . . . 35 + Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . . 36 + Blockchain and Distributed Ledgers . . . . . . . . . . . . . . 36 + SCITT (Supply Chain Integrity, Transparency, and Trust) . . . . 36 + W3C Verifiable Credentials . . . . . . . . . . . . . . . . . . 37 + Implementation Guidance . . . . . . . . . . . . . . . . . . . . . 37 + Minimal Implementation . . . . . . . . . . . . . . . . . . . . 37 + Storage Recommendations . . . . . . . . . . . . . . . . . . . . 37 + Performance Considerations . . . . . . . . . . . . . . . . . . 37 + Interoperability . . . . . . . . . . . . . . . . . . . . . . . 38 + Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . . 38 + Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 + Example 1: Simple Two-Agent Workflow . . . . . . . . . . . . . 39 + Example 2: Medical Device SDLC with Release Approval . . . . . 40 + Example 3: Parallel Execution with Join . . . . . . . . . . . . 43 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44 + @@ -170,8 +170,6 @@ Nennemann Expires 29 August 2026 [Page 3] Internet-Draft WIMSE Execution Context February 2026 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 - 1. Introduction 1.1. Motivation @@ -185,19 +183,18 @@ Internet-Draft WIMSE Execution Context February 2026 However, workload identity alone does not address execution accountability. Knowing who performed an action does not record what - was done, what policy was applied, or whether compliance requirements - were evaluated at each decision point. + was done or in what order. Regulated environments increasingly deploy autonomous agents that coordinate across organizational boundaries. Multiple regulatory frameworks — including [EU-AI-ACT], [FDA-21CFR11], [MIFID-II], and [DORA] — require structured, auditable records of automated decision- - making and execution (see Table 3 for a detailed mapping). + making and execution (see Table 2 for a detailed mapping). This document defines an extension to the WIMSE architecture that addresses the gap between workload identity and execution accountability. WIMSE authenticates agents; this extension records - what they did, in what order, and what policy was evaluated. + what they did and in what order. As identified in [I-D.ni-wimse-ai-agent-identity], call context in agentic workflows needs to be visible and preserved. ECTs provide a @@ -210,13 +207,16 @@ Internet-Draft WIMSE Execution Context February 2026 1. WIMSE authenticates agents but does not record what they actually did. A WIT proves "Agent A is authorized" but not "Agent A - executed Task X, under Policy Y, producing Output Z." + executed Task X, producing Output Z." + + 2. No standard mechanism exists to cryptographically order and link + task execution across a multi-agent workflow. + + 3. No mechanism exists to reconstruct the complete execution history + of a distributed workflow for audit purposes. + - 2. No standard mechanism exists to record policy evaluation outcomes - at each decision point in a multi-agent workflow. - 3. No mechanism exists to cryptographically link compensation and - rollback decisions to original actions. @@ -240,14 +240,15 @@ Internet-Draft WIMSE Execution Context February 2026 * DAG structure for task dependency ordering (Section 6) - * Policy checkpoint recording (Section 4.2.3) - * Integration with the WIMSE identity framework (Section 3) * An HTTP header for ECT transport (Section 5) * Audit ledger interface requirements (Section 8) + * Policy evaluation and compensation extensions are defined + separately in [I-D.nennemann-wimse-ect-policy-compensation] + The following are out of scope and are handled by WIMSE: * Workload authentication and identity provisioning @@ -271,9 +272,8 @@ Internet-Draft WIMSE Execution Context February 2026 this document are intended to motivate the design requirements, not to claim that implementing ECTs satisfies these regulations. - ECTs provide evidence of claimed execution ordering and policy - evaluation. They do not independently verify that the claimed - execution actually occurred as described, that the policy evaluation + + @@ -282,10 +282,12 @@ Nennemann Expires 29 August 2026 [Page 5] Internet-Draft WIMSE Execution Context February 2026 - was correct, or that the agent faithfully performed the stated - action. The trustworthiness of ECT claims depends on the - trustworthiness of the signing agent and the integrity of the broader - deployment environment. + ECTs provide evidence of claimed execution ordering. They do not + independently verify that the claimed execution actually occurred as + described or that the agent faithfully performed the stated action. + The trustworthiness of ECT claims depends on the trustworthiness of + the signing agent and the integrity of the broader deployment + environment. 2. Conventions and Definitions @@ -307,16 +309,12 @@ Internet-Draft WIMSE Execution Context February 2026 dependency ordering where edges are directed and no cycles exist. Execution Context Token (ECT): A JSON Web Token [RFC7519] defined by - this specification that records task execution details and policy - evaluation outcomes. + this specification that records task execution details. Audit Ledger: An append-only, immutable log of all ECTs within a workflow or set of workflows, used for regulatory audit and compliance verification. - Policy Checkpoint: A point in a workflow where a policy evaluation - outcome is recorded within an ECT. - Workload Identity Token (WIT): A WIMSE credential proving a workload's identity within a trust domain. @@ -330,6 +328,8 @@ Internet-Draft WIMSE Execution Context February 2026 Witness: A third-party entity that observes and attests to the execution of a task, providing additional accountability. +3. WIMSE Architecture Integration + @@ -338,8 +338,6 @@ Nennemann Expires 29 August 2026 [Page 6] Internet-Draft WIMSE Execution Context February 2026 -3. WIMSE Architecture Integration - 3.1. WIMSE Foundation The WIMSE architecture [I-D.ietf-wimse-arch] defines: @@ -359,41 +357,15 @@ Internet-Draft WIMSE Execution Context February 2026 * Recording what agents actually do with their authenticated identity - * Recording policy evaluation outcomes at each hop - * Maintaining structured execution records - * Linking compensation or rollback actions to original tasks + * Linking actions to their predecessors with cryptographic assurance 3.2. Extension Model ECTs extend WIMSE by adding an execution accountability layer between the identity layer and the application layer: - - - - - - - - - - - - - - - - - - - -Nennemann Expires 29 August 2026 [Page 7] - -Internet-Draft WIMSE Execution Context February 2026 - - +--------------------------------------------------+ | WIMSE Layer (Identity) | | WIT: "I am Agent X (spiffe://td/agent/x)" | @@ -404,7 +376,7 @@ Internet-Draft WIMSE Execution Context February 2026 +--------------------------------------------------+ | ECT Layer (Execution Accountability) [This Spec]| | ECT: "Task executed, dependencies met, | - | policy evaluated, outcome recorded" | + | inputs/outputs hashed" | +--------------------------------------------------+ | v @@ -415,6 +387,13 @@ Internet-Draft WIMSE Execution Context February 2026 Figure 1: WIMSE Extension Architecture Layers + + +Nennemann Expires 29 August 2026 [Page 7] + +Internet-Draft WIMSE Execution Context February 2026 + + This extension reuses the WIMSE signing model, extends JWT claims using standard JWT extensibility [RFC7519], and maintains WIMSE concepts including trust domains and workload identifiers. @@ -443,13 +422,6 @@ Internet-Draft WIMSE Execution Context February 2026 Workload-Identity: Execution-Context: - - -Nennemann Expires 29 August 2026 [Page 8] - -Internet-Draft WIMSE Execution Context February 2026 - - Figure 2: HTTP Header Stacking When a Workload Proof Token (WPT) is available per @@ -463,12 +435,21 @@ Internet-Draft WIMSE Execution Context February 2026 domain. WPT verification, if present, per [I-D.ietf-wimse-s2s-protocol]. - 2. ECT (this extension): Records what Agent A did, what policy was - evaluated, and what precedent tasks exist. + 2. ECT (this extension): Records what Agent A did and what precedent + tasks exist. 3. Ledger (if deployed): Appends the verified ECT to the audit ledger. + + + + +Nennemann Expires 29 August 2026 [Page 8] + +Internet-Draft WIMSE Execution Context February 2026 + + 4. Execution Context Token Format An Execution Context Token is a JSON Web Token (JWT) [RFC7519] signed @@ -498,14 +479,6 @@ Internet-Draft WIMSE Execution Context February 2026 from other JWT types, consistent with the WIMSE convention for type parameter values. - - - -Nennemann Expires 29 August 2026 [Page 9] - -Internet-Draft WIMSE Execution Context February 2026 - - kid: REQUIRED. The key identifier referencing the public key from the agent's WIT [RFC7517]. Used by verifiers to look up the correct public key for signature verification. @@ -526,6 +499,13 @@ 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). + + +Nennemann Expires 29 August 2026 [Page 9] + +Internet-Draft WIMSE Execution Context February 2026 + + 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 @@ -555,13 +535,6 @@ 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. @@ -581,6 +554,14 @@ Internet-Draft WIMSE Execution Context February 2026 identifier (for replay detection) and the task identifier (for DAG parent references in "par"). Receivers MUST reject ECTs whose "jti" has already been seen within the expiration window. When + + + +Nennemann Expires 29 August 2026 [Page 10] + +Internet-Draft WIMSE Execution Context February 2026 + + "wid" is present, uniqueness is scoped to the workflow; when "wid" is absent, uniqueness MUST be enforced globally across the ECT store. @@ -605,75 +586,11 @@ Internet-Draft WIMSE Execution Context February 2026 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 - - - -Nennemann Expires 29 August 2026 [Page 11] - -Internet-Draft WIMSE Execution Context February 2026 - - - 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: - - * "approved": The policy evaluation succeeded and the task was - authorized to proceed. - - * "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". - - * "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. - - 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. - - pol_enforcer: OPTIONAL. 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 - semantics and enforcement of that policy are determined by the - deployment environment. Implementations may use any policy engine or - framework (e.g., OPA/Rego, Cedar, XACML, or custom solutions) - provided that the evaluation outcome is faithfully recorded in the - ECT claims defined above. - -4.2.4. Data Integrity +4.2.3. Data Integrity The following claims provide integrity verification for task inputs and outputs without revealing the data itself: - - -Nennemann Expires 29 August 2026 [Page 12] - -Internet-Draft WIMSE Execution Context February 2026 - - inp_hash: OPTIONAL. String. A cryptographic hash of the input data, formatted as "hash-algorithm:base64url-encoded-hash" (e.g., "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The hash @@ -689,16 +606,27 @@ Internet-Draft WIMSE Execution Context February 2026 data, using the same format and algorithm requirements as "inp_hash". -4.2.5. Compensation and Rollback - 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 + + + + + +Nennemann Expires 29 August 2026 [Page 11] + +Internet-Draft WIMSE Execution Context February 2026 + + +4.2.4. Compensation and Rollback + + Compensation and rollback extensions are defined in + [I-D.nennemann-wimse-ect-policy-compensation]. 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.5. Extensions ext: OPTIONAL. Object. An extension object for domain-specific claims not defined by this specification. Implementations that do @@ -722,14 +650,6 @@ Internet-Draft WIMSE Execution Context February 2026 * "regulated_domain": String. Regulatory domain (e.g., "medtech", "finance", "military"). - - - -Nennemann Expires 29 August 2026 [Page 13] - -Internet-Draft WIMSE Execution Context February 2026 - - * "model_version": String. AI/ML model version. * "witnessed_by": Array of StringOrURI. Identifiers of third-party @@ -740,52 +660,24 @@ 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". + Additional extension keys for policy evaluation and compensation are + defined in [I-D.nennemann-wimse-ect-policy-compensation]. - * "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). + + + + + +Nennemann Expires 29 August 2026 [Page 12] + +Internet-Draft WIMSE Execution Context February 2026 + 4.3. Complete ECT Example The following is a complete ECT payload example: - - - - - - - - - - - - - - - - - - - - - - - - - - -Nennemann Expires 29 August 2026 [Page 14] - -Internet-Draft WIMSE Execution Context February 2026 - - { "iss": "spiffe://example.com/agent/clinical", "aud": "spiffe://example.com/agent/safety", @@ -797,15 +689,10 @@ 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_timestamp": 1772064145, "exec_time_ms": 245, "regulated_domain": "medtech", "model_version": "clinical-reasoning-v4.2" @@ -837,7 +724,8 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 29 August 2026 [Page 15] + +Nennemann Expires 29 August 2026 [Page 13] Internet-Draft WIMSE Execution Context February 2026 @@ -893,7 +781,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 29 August 2026 [Page 16] +Nennemann Expires 29 August 2026 [Page 14] Internet-Draft WIMSE Execution Context February 2026 @@ -913,15 +801,7 @@ 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 - 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 contains policy claims. - - 6. Trust Domain Consistency: Parent tasks SHOULD belong to the same + 5. 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. @@ -949,7 +829,15 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 29 August 2026 [Page 17] + + + + + + + + +Nennemann Expires 29 August 2026 [Page 15] Internet-Draft WIMSE Execution Context February 2026 @@ -1005,7 +893,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 29 August 2026 [Page 18] +Nennemann Expires 29 August 2026 [Page 16] Internet-Draft WIMSE Execution Context February 2026 @@ -1061,7 +949,7 @@ Internet-Draft WIMSE Execution Context February 2026 -Nennemann Expires 29 August 2026 [Page 19] +Nennemann Expires 29 August 2026 [Page 17] Internet-Draft WIMSE Execution Context February 2026 @@ -1075,13 +963,9 @@ 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. Perform DAG validation per Section 6. - 14. Perform DAG validation per Section 6. - - 15. If all checks pass and an audit ledger is deployed, the ECT + 14. 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 @@ -1114,18 +998,18 @@ Internet-Draft WIMSE Execution Context February 2026 // Look up public key public_key = trust_domain_keys.get(header.kid) if public_key is null: - - - -Nennemann Expires 29 August 2026 [Page 20] - -Internet-Draft WIMSE Execution Context February 2026 - - return reject("Unknown key identifier") // Verify signature if not verify_jws_signature(header, payload, + + + +Nennemann Expires 29 August 2026 [Page 18] + +Internet-Draft WIMSE Execution Context February 2026 + + signature, public_key): return reject("Invalid signature") @@ -1161,23 +1045,7 @@ 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: - return reject("pol and pol_decision must both be present") - if payload.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 29 August 2026 [Page 21] - -Internet-Draft WIMSE Execution Context February 2026 - - result = validate_dag(payload, ect_store, clock_skew_tolerance) if result is error: @@ -1190,6 +1058,14 @@ Internet-Draft WIMSE Execution Context February 2026 Figure 7: ECT Verification Pseudocode + + + +Nennemann Expires 29 August 2026 [Page 19] + +Internet-Draft WIMSE Execution Context February 2026 + + 8. Audit Ledger Interface ECTs MAY be recorded in an immutable audit ledger for compliance @@ -1226,14 +1102,6 @@ Internet-Draft WIMSE Execution Context February 2026 include additional domain-specific requirements beyond the scope of this specification. - - - -Nennemann Expires 29 August 2026 [Page 22] - -Internet-Draft WIMSE Execution Context February 2026 - - Note: task identifiers in this section are abbreviated for readability. In production, all "jti" values are required to be UUIDs per Section 4.2.2. @@ -1246,31 +1114,33 @@ Internet-Draft WIMSE Execution Context February 2026 Section 11.10(e) and [EU-MDR] require audit trails documenting the complete development process for software used in medical devices. + + + +Nennemann Expires 29 August 2026 [Page 20] + +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 Agent B (Code Generator): jti: task-002 par: [task-001] exec_act: implement_module - pol: coding_standards_v3 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 Agent D (Build Agent): jti: task-004 par: [task-003] exec_act: build_release_artifact - pol: build_validation_v2 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) Figure 8: Medical Device SDLC Workflow @@ -1281,15 +1151,6 @@ Internet-Draft WIMSE Execution Context February 2026 explicitly approved the release. The DAG structure ensures no phase was skipped or reordered. - - - - -Nennemann Expires 29 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 @@ -1297,6 +1158,26 @@ Internet-Draft WIMSE Execution Context February 2026 authority retrieves all ECTs sharing the same workflow identifier ("wid") from the audit ledger and reconstructs the complete DAG: + + + + + + + + + + + + + + + +Nennemann Expires 29 August 2026 [Page 21] + +Internet-Draft WIMSE Execution Context February 2026 + + task-001 (review_requirements_spec) | v @@ -1317,8 +1198,6 @@ Internet-Draft WIMSE Execution Context February 2026 * Each phase was executed by an identified and authenticated agent. - * Policy checkpoints were evaluated at every phase transition. - * The execution sequence was maintained (no step was bypassed). * A human-in-the-loop approved the final release, with independent @@ -1337,15 +1216,6 @@ Internet-Draft WIMSE Execution Context February 2026 * [EU-AI-ACT] Article 12: Automatic logging capabilities for high- risk AI systems involved in the development process. - - - - -Nennemann Expires 29 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. @@ -1355,20 +1225,26 @@ Internet-Draft WIMSE Execution Context February 2026 compliance verification, and trade execution. The DAG structure records that compliance checks were evaluated before trade execution. + + + + +Nennemann Expires 29 August 2026 [Page 22] + +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 Agent B (Compliance): jti: task-002 par: [task-001] exec_act: verify_compliance - pol: compliance_check_v1 pol_decision: approved Agent C (Execution): jti: task-003 par: [task-002] exec_act: execute_trade - pol: execution_policy_v3 pol_decision: approved Figure 10: Financial Trading Workflow @@ -1384,47 +1260,10 @@ 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 29 August 2026 [Page 25] - -Internet-Draft WIMSE Execution Context February 2026 - - - { - "iss": "spiffe://bank.example/agent/operations", - "aud": "spiffe://bank.example/system/ledger", - "iat": 1772150550, - "exp": 1772151150, - "jti": "550e8400-e29b-41d4-a716-446655440099", - "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", - "ext": { - "compensation_required": true, - "compensation_reason": "policy_violation_in_parent_trade" - } - } - - Figure 11: Compensation ECT Example - - The "par" claim links the compensation action to the original trade, - creating an auditable chain from execution through violation - discovery to remediation. + Compensation and rollback use cases are described in + [I-D.nennemann-wimse-ect-policy-compensation]. The core ECT + mechanism supports compensation through the "par" claim, which links + a remediation ECT to the original task. 9.4. Autonomous Logistics Coordination @@ -1446,14 +1285,7 @@ Internet-Draft WIMSE Execution Context February 2026 - - - - - - - -Nennemann Expires 29 August 2026 [Page 26] +Nennemann Expires 29 August 2026 [Page 23] Internet-Draft WIMSE Execution Context February 2026 @@ -1461,29 +1293,24 @@ 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 Agent B (Customs): jti: task-002 par: [task-001] exec_act: validate_customs - pol: customs_policy_v2 pol_decision: approved Agent C (Safety): jti: task-003 par: [task-001] exec_act: verify_cargo_safety - pol: safety_policy_v1 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 System (Commitment): jti: task-005 par: [task-004] exec_act: commit_shipment - pol: commitment_policy_v1 pol_decision: approved - Figure 12: Logistics Workflow with Parallel Tasks + Figure 11: Logistics Workflow with Parallel Tasks Note that tasks 002 and 003 both depend only on task-001 and can execute in parallel. Task 004 depends on both, demonstrating the @@ -1507,29 +1334,29 @@ Internet-Draft WIMSE Execution Context February 2026 * Ledger tamperer: An entity attempting to modify or delete ledger entries after they have been recorded. + * Time manipulator: An entity attempting to manipulate timestamps to + alter perceived execution ordering. -Nennemann Expires 29 August 2026 [Page 27] + + + +Nennemann Expires 29 August 2026 [Page 24] Internet-Draft WIMSE Execution Context February 2026 - * Time manipulator: An entity attempting to manipulate timestamps to - alter perceived execution ordering. - 10.2. Self-Assertion Limitation ECTs are self-asserted by the executing agent. The agent claims what it did, and this claim is signed with its private key. A compromised - or malicious agent could create ECTs with false claims (e.g., setting - "pol_decision" to "approved" without actually evaluating the policy). + or malicious agent could create ECTs with false claims (e.g., + claiming an action was performed when it was not). ECTs do not independently verify that: * The claimed execution actually occurred as described - * The policy evaluation was correctly performed - * The input/output hashes correspond to the actual data processed * The agent faithfully performed the stated action @@ -1562,20 +1389,19 @@ Internet-Draft WIMSE Execution Context February 2026 * Ledger integrity governance: The ledger is maintained by an entity independent of the workflow agents. + * Agent deployment governance: Agents are deployed and maintained in + a manner that preserves their integrity. -Nennemann Expires 29 August 2026 [Page 28] + + + +Nennemann Expires 29 August 2026 [Page 25] Internet-Draft WIMSE Execution Context February 2026 - * Policy lifecycle management: Policy identifiers in ECTs map to - actual, validated policy rules. - - * Agent deployment governance: Agents are deployed and maintained in - a manner that preserves their integrity. - 10.4. Signature Verification ECTs MUST be signed with the agent's private key using JWS [RFC7515]. @@ -1618,21 +1444,19 @@ Internet-Draft WIMSE Execution Context February 2026 The defense-in-depth model provides: - - - -Nennemann Expires 29 August 2026 [Page 29] - -Internet-Draft WIMSE Execution Context February 2026 - - * TLS/mTLS (transport layer): Prevents network-level tampering. * WIT/WPT (WIMSE identity layer): Proves agent identity and request authorization. - * ECT (execution accountability layer): Records what the agent did - and under what policy. + * ECT (execution accountability layer): Records what the agent did. + + + +Nennemann Expires 29 August 2026 [Page 26] + +Internet-Draft WIMSE Execution Context February 2026 + 10.7. Key Compromise @@ -1673,18 +1497,23 @@ Internet-Draft WIMSE Execution Context February 2026 * Cross-verification: Multiple independent ledger replicas can be compared for consistency. + * Out-of-band audit: External auditors periodically verify ledger + contents against expected workflow patterns. -Nennemann Expires 29 August 2026 [Page 30] + + + + + + +Nennemann Expires 29 August 2026 [Page 27] Internet-Draft WIMSE Execution Context February 2026 - * Out-of-band audit: External auditors periodically verify ledger - contents against expected workflow patterns. - 10.9. Denial of Service ECT signature verification is computationally inexpensive @@ -1722,7 +1551,7 @@ Internet-Draft WIMSE Execution Context February 2026 maximum of 256 entries. Workflows requiring more parent references SHOULD introduce intermediate aggregation tasks. The "ext" object SHOULD NOT exceed 4096 bytes when serialized as JSON and SHOULD NOT - exceed a nesting depth of 5 levels (see also Section 4.2.6). + exceed a nesting depth of 5 levels (see also Section 4.2.5). 11. Privacy Considerations @@ -1730,20 +1559,16 @@ Internet-Draft WIMSE Execution Context February 2026 ECTs necessarily reveal: - - - -Nennemann Expires 29 August 2026 [Page 31] - -Internet-Draft WIMSE Execution Context February 2026 - - * Agent identities ("iss", "aud") for accountability purposes * Action descriptions ("exec_act") for audit trail completeness - * Policy evaluation outcomes ("pol", "pol_decision") for compliance - verification + + +Nennemann Expires 29 August 2026 [Page 28] + +Internet-Draft WIMSE Execution Context February 2026 + * Timestamps ("iat", "exp") for temporal ordering @@ -1762,14 +1587,10 @@ 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. - - 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. + "process_payment") rather than natural language descriptions. + Extension keys in "ext" (Section 4.2.5) deserve particular attention: + human-readable values risk exposing sensitive operational details. + See Section 4.2.5 for guidance on using structured identifiers. 11.3. Storage and Access Control @@ -1783,22 +1604,11 @@ Internet-Draft WIMSE Execution Context February 2026 controls, since auditors may need to verify hash correctness but general access to the data values is not needed. - - - - - - -Nennemann Expires 29 August 2026 [Page 32] - -Internet-Draft WIMSE Execution Context February 2026 - - 11.4. Regulatory Access ECTs are designed for interpretation by qualified human auditors and - regulators. ECTs provide structural records of execution ordering - and policy evaluation; they are not intended for public disclosure. + regulators. ECTs provide structural records of execution ordering; + they are not intended for public disclosure. 12. IANA Considerations @@ -1809,6 +1619,13 @@ Internet-Draft WIMSE Execution Context February 2026 Type name: application + + +Nennemann Expires 29 August 2026 [Page 29] + +Internet-Draft WIMSE Execution Context February 2026 + + Subtype name: wimse-exec+jwt Required parameters: none @@ -1842,14 +1659,6 @@ Internet-Draft WIMSE Execution Context February 2026 Author: Christian Nennemann - - - -Nennemann Expires 29 August 2026 [Page 33] - -Internet-Draft WIMSE Execution Context February 2026 - - Change controller: IETF 12.2. HTTP Header Field Registration @@ -1864,122 +1673,46 @@ Internet-Draft WIMSE Execution Context February 2026 Specification document: This document, Section 5 + + + + +Nennemann Expires 29 August 2026 [Page 30] + +Internet-Draft WIMSE Execution Context February 2026 + + 12.3. JWT Claims Registration This document requests registration of the following claims in the "JSON Web Token Claims" registry maintained by IANA: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Nennemann Expires 29 August 2026 [Page 34] - -Internet-Draft WIMSE Execution Context February 2026 - - - +==============+===================+===================+===========+ - | Claim Name | Claim Description | Change Controller | Reference | - +==============+===================+===================+===========+ - | wid | Workflow | IETF | Section | - | | Identifier | | 4.2.2 | - +--------------+-------------------+-------------------+-----------+ - | exec_act | Action/Task Type | IETF | Section | - | | | | 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 Hash | IETF | Section | - | | | | 4.2.4 | - +--------------+-------------------+-------------------+-----------+ - | ext | Extension Object | IETF | Section | - | | | | 4.2.6 | - +--------------+-------------------+-------------------+-----------+ + +============+=====================+===================+===========+ + | 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.3 | + +------------+---------------------+-------------------+-----------+ + | out_hash | Output Data Hash | IETF | Section | + | | | | 4.2.3 | + +------------+---------------------+-------------------+-----------+ + | ext | Extension Object | IETF | Section | + | | | | 4.2.5 | + +------------+---------------------+-------------------+-----------+ Table 1: JWT Claims Registrations -12.4. ECT Policy Decision Values Registry - - This document establishes the "ECT Policy Decision Values" registry - under the "JSON Web Token (JWT)" group. Registration policy is - Specification Required per [RFC8126]. - - The initial contents of the registry are: - - - - - - - - - - - -Nennemann Expires 29 August 2026 [Page 35] - -Internet-Draft WIMSE Execution Context February 2026 - - - +======================+===================+============+===========+ - | Value | Description | Change | Reference | - | | | Controller | | - +======================+===================+============+===========+ - | approved | Policy | IETF | Section | - | | evaluation | | 4.2.3 | - | | succeeded | | | - +----------------------+-------------------+------------+-----------+ - | rejected | Policy | IETF | Section | - | | evaluation | | 4.2.3 | - | | failed | | | - +----------------------+-------------------+------------+-----------+ - | pending_human_review | Awaiting | IETF | Section | - | | human | | 4.2.3 | - | | judgment | | | - +----------------------+-------------------+------------+-----------+ - - Table 2: ECT Policy Decision Values + Policy evaluation claims and the ECT Policy Decision Values registry + are defined in [I-D.nennemann-wimse-ect-policy-compensation]. 13. References @@ -1997,6 +1730,14 @@ Internet-Draft WIMSE Execution Context February 2026 Campbell, B., Salowey, J. A., Schwenkschuster, A., and Y. Sheffer, "WIMSE Workload-to-Workload Authentication", Work in Progress, Internet-Draft, draft-ietf-wimse-s2s- + + + +Nennemann Expires 29 August 2026 [Page 31] + +Internet-Draft WIMSE Execution Context February 2026 + + protocol-07, 16 October 2025, . @@ -2010,14 +1751,6 @@ 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, . @@ -2030,11 +1763,6 @@ Internet-Draft WIMSE Execution Context February 2026 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for - Writing an IANA Considerations Section in RFCs", BCP 26, - RFC 8126, DOI 10.17487/RFC8126, June 2017, - . - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . @@ -2058,6 +1786,14 @@ 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 + + + +Nennemann Expires 29 August 2026 [Page 32] + +Internet-Draft WIMSE Execution Context February 2026 + + of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)", 13 June 2024, . @@ -2066,14 +1802,6 @@ 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; @@ -2095,6 +1823,12 @@ Internet-Draft WIMSE Execution Context February 2026 October 2025, . + [I-D.nennemann-wimse-ect-policy-compensation] + Nennemann, C., "Policy Evaluation and Compensation + Extensions for Execution Context Tokens", + . + [I-D.ni-wimse-ai-agent-identity] Yuan, N. and P. C. Liu, "WIMSE Applicability for AI Agents", Work in Progress, Internet-Draft, draft-ni-wimse- @@ -2109,6 +1843,13 @@ Internet-Draft WIMSE Execution Context February 2026 . + + +Nennemann Expires 29 August 2026 [Page 33] + +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 @@ -2120,16 +1861,6 @@ 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, @@ -2156,9 +1887,8 @@ WIMSE Workload Identity protocol [I-D.ietf-wimse-s2s-protocol] provide the identity foundation upon which ECTs are built. WIT/WPT answer "who is this agent?" and "does it control the claimed key?" while ECTs record - "what did this agent do?" and "what policy was evaluated?" Together - they form an identity-plus-accountability framework for regulated - agentic systems. + "what did this agent do?" Together they form an identity-plus- + accountability framework for regulated agentic systems. OAuth 2.0 Token Exchange and the "act" Claim @@ -2168,23 +1898,22 @@ OAuth 2.0 Token Exchange and the "act" Claim acting on behalf of whom." While the nesting superficially resembles a chain, it is strictly linear (each "act" object contains at most one nested "act"), represents authorization delegation rather than - task execution, and carries no task identifiers, policy decisions, or - input/output integrity data. The "act" chain cannot represent - branching (fan-out) or convergence (fan-in) and therefore cannot form - a DAG. + + + +Nennemann Expires 29 August 2026 [Page 34] + +Internet-Draft WIMSE Execution Context February 2026 + + + task execution, and carries no task identifiers or input/output + integrity data. The "act" chain cannot represent branching (fan-out) + or convergence (fan-in) and therefore cannot form a DAG. ECTs intentionally use the distinct claim name "exec_act" for the action/task type to avoid collision with the "act" claim. The two 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 - + record "what was done, in what order." Transaction Tokens @@ -2205,8 +1934,8 @@ Transaction Tokens from the Transaction Token Service appear in "req_wl"; workloads that forward the token unchanged are not recorded. - * It carries no task-level granularity, no parent references, no - policy evaluation outcomes, and no execution content. + * It carries no task-level granularity, no parent references, and no + execution content. Extensions for agentic use cases ([I-D.oauth-transaction-tokens-for-agents]) add agent identity and @@ -2216,12 +1945,22 @@ 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 - ("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 - "tth" claim defined in [I-D.ietf-wimse-s2s-protocol] can hash-bind a - WPT to a co-present Txn-Token; a similar binding mechanism for ECTs - is a potential future extension. + ("task T was performed, depending on tasks P1 and P2"). An agent + request could carry both a Txn-Token for authorization and an ECT for + execution recording. The WPT "tth" claim defined in + [I-D.ietf-wimse-s2s-protocol] can hash-bind a WPT to a co-present + Txn-Token; a similar binding mechanism for ECTs is a potential future + extension. + + + + + + +Nennemann Expires 29 August 2026 [Page 35] + +Internet-Draft WIMSE Execution Context February 2026 + Distributed Tracing (OpenTelemetry) @@ -2234,14 +1973,6 @@ 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. @@ -2264,8 +1995,8 @@ SCITT (Supply Chain Integrity, Transparency, and Trust) SCITT Signed Statements, linking a complete ECT audit trail to a supply chain transparency record. For example, in a regulated manufacturing workflow, each agent step produces an ECT (recording - what was done, by whom, under what policy), while the overall - workflow identified by "wid" is registered as a SCITT Signed + what was done, by whom, under under what constraints), while the + overall workflow identified by "wid" is registered as a SCITT Signed Statement on a Transparency Service. This enables auditors to verify both the individual execution steps (via ECT DAG validation) and the end-to-end supply chain integrity (via SCITT Receipts) using the @@ -2274,13 +2005,25 @@ SCITT (Supply Chain Integrity, Transparency, and Trust) Transparency Service identifiers or Receipt references for tighter integration. + + + + + + + + +Nennemann Expires 29 August 2026 [Page 36] + +Internet-Draft WIMSE Execution Context February 2026 + + W3C Verifiable Credentials W3C Verifiable Credentials represent claims about subjects (e.g., identity, qualifications). ECTs represent execution records of - actions (what happened, in what order, under what policy). While - both use JWT/JWS as a serialization format, their semantics and use - cases are distinct. + actions (what happened, in what order). While both use JWT/JWS as a + serialization format, their semantics and use cases are distinct. Implementation Guidance @@ -2288,19 +2031,8 @@ 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"). 2. Sign ECTs with the agent's private key using an algorithm matching the WIT (ES256 recommended). @@ -2335,6 +2067,13 @@ Performance Considerations * JSON serialization: sub-millisecond per ECT. + + +Nennemann Expires 29 August 2026 [Page 37] + +Internet-Draft WIMSE Execution Context February 2026 + + * Total per-request overhead: approximately 5-10ms, acceptable for regulated workflows where correctness is prioritized over latency. @@ -2346,14 +2085,6 @@ 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 @@ -2361,6 +2092,44 @@ Regulatory Compliance Mapping block; achieving compliance requires additional organizational measures beyond this specification. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Nennemann Expires 29 August 2026 [Page 38] + +Internet-Draft WIMSE Execution Context February 2026 + + +============+========================+==========================+ | Regulation | Requirement | ECT Contribution | +============+========================+==========================+ @@ -2391,7 +2160,7 @@ Regulatory Compliance Mapping | | | trail | +------------+------------------------+--------------------------+ - Table 3: Regulatory Compliance Mapping + Table 2: Regulatory Compliance Mapping Examples @@ -2401,15 +2170,6 @@ 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", @@ -2418,6 +2178,14 @@ Internet-Draft WIMSE Execution Context February 2026 ECT Payload: + + + +Nennemann Expires 29 August 2026 [Page 39] + +Internet-Draft WIMSE Execution Context February 2026 + + { "iss": "spiffe://example.com/agent/data-retrieval", "aud": "spiffe://example.com/agent/validator", @@ -2427,8 +2195,6 @@ 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" } @@ -2444,9 +2210,7 @@ Internet-Draft WIMSE Execution Context February 2026 "jti": "550e8400-e29b-41d4-a716-446655440002", "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", "exec_act": "validate_safety", - "par": ["550e8400-e29b-41d4-a716-446655440001"], - "pol": "safety_validation_policy_v2", - "pol_decision": "approved" + "par": ["550e8400-e29b-41d4-a716-446655440001"] } The resulting DAG: @@ -2456,16 +2220,6 @@ Internet-Draft WIMSE Execution Context February 2026 v task-...-0002 (validate_safety) - - - - - -Nennemann Expires 29 August 2026 [Page 44] - -Internet-Draft WIMSE Execution Context February 2026 - - Example 2: Medical Device SDLC with Release Approval A multi-step medical device software lifecycle workflow with @@ -2473,6 +2227,21 @@ Example 2: Medical Device SDLC with Release Approval Task 1 (Spec Review Agent): + + + + + + + + + + +Nennemann Expires 29 August 2026 [Page 40] + +Internet-Draft WIMSE Execution Context February 2026 + + { "iss": "spiffe://meddev.example/agent/spec-reviewer", "aud": "spiffe://meddev.example/agent/code-gen", @@ -2482,8 +2251,6 @@ Example 2: Medical Device SDLC with 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" } @@ -2498,30 +2265,11 @@ Example 2: Medical Device SDLC with Release Approval "jti": "a1b2c3d4-0001-0000-0000-000000000002", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "implement_module", - "par": ["a1b2c3d4-0001-0000-0000-000000000001"], - "pol": "coding_standards_v3", - "pol_decision": "approved" + "par": ["a1b2c3d4-0001-0000-0000-000000000001"] } 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", "aud": "spiffe://meddev.example/agent/build", @@ -2530,13 +2278,26 @@ Internet-Draft WIMSE Execution Context February 2026 "jti": "a1b2c3d4-0001-0000-0000-000000000003", "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" + "par": ["a1b2c3d4-0001-0000-0000-000000000002"] } Task 4 (Build Agent): + + + + + + + + + + +Nennemann Expires 29 August 2026 [Page 41] + +Internet-Draft WIMSE Execution Context February 2026 + + { "iss": "spiffe://meddev.example/agent/build", "aud": "spiffe://meddev.example/human/release-mgr-42", @@ -2546,38 +2307,11 @@ 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" } 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", "aud": "spiffe://meddev.example/system/ledger", @@ -2587,9 +2321,6 @@ 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": { "witnessed_by": [ "spiffe://meddev.example/audit/qa-observer-1" @@ -2603,6 +2334,26 @@ Internet-Draft WIMSE Execution Context February 2026 "ext" object in task 5 carries witness metadata via the "witnessed_by" extension key. + + + + + + + + + + + + + + + +Nennemann Expires 29 August 2026 [Page 42] + +Internet-Draft WIMSE Execution Context February 2026 + + task-...-0001 (review_requirements_spec) | v @@ -2623,17 +2374,6 @@ 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 @@ -2651,6 +2391,25 @@ Example 3: Parallel Execution with Join Task 004 ECT payload: + + + + + + + + + + + + + + +Nennemann Expires 29 August 2026 [Page 43] + +Internet-Draft WIMSE Execution Context February 2026 + + { "iss": "spiffe://bank.example/agent/execution", "aud": "spiffe://bank.example/system/ledger", @@ -2662,9 +2421,7 @@ Example 3: Parallel Execution with Join "par": [ "f1e2d3c4-0002-0000-0000-000000000002", "f1e2d3c4-0003-0000-0000-000000000003" - ], - "pol": "trade_execution_policy_v3", - "pol_decision": "approved" + ] } The "par" array with two entries records that both compliance @@ -2682,14 +2439,6 @@ Author's Address Christian Nennemann Independent Researcher - - - -Nennemann Expires 29 August 2026 [Page 48] - -Internet-Draft WIMSE Execution Context February 2026 - - Email: ietf@nennemann.de @@ -2712,33 +2461,4 @@ Internet-Draft WIMSE Execution Context February 2026 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Nennemann Expires 29 August 2026 [Page 49] +Nennemann Expires 29 August 2026 [Page 44] diff --git a/draft-nennemann-wimse-execution-context-00.xml b/draft-nennemann-wimse-execution-context-00.xml index c4695da..19426e4 100644 --- a/draft-nennemann-wimse-execution-context-00.xml +++ b/draft-nennemann-wimse-execution-context-00.xml @@ -32,22 +32,22 @@ - + This document defines Execution Context Tokens (ECTs), an extension to the Workload Identity in Multi System Environments (WIMSE) architecture for distributed agentic workflows in regulated environments. ECTs provide signed, structured records of task -execution order, policy evaluation outcomes, and compliance state -across -agent-to-agent communication. By extending WIMSE Workload Identity +execution order and compliance state across agent-to-agent +communication. By extending WIMSE Workload Identity Tokens with execution context claims in JSON Web Token (JWT) format, this specification enables regulated systems to maintain structured audit trails that support compliance verification. ECTs use a directed acyclic graph (DAG) structure to represent task -dependencies, record policy evaluation outcomes at each decision -point, and integrate with WIMSE Workload Identity Tokens (WIT) -using the same signing model and cryptographic primitives. A new +dependencies and integrate with WIMSE Workload Identity Tokens (WIT) +using the same signing model and cryptographic primitives. +Policy evaluation and compensation extensions are defined in +. A new HTTP header field, Execution-Context, is defined for transporting ECTs alongside existing WIMSE headers. ECTs are a technical building block that @@ -65,7 +65,7 @@ regulatory frameworks. - +
      Introduction @@ -81,8 +81,7 @@ Workload-Proof-Token HTTP headers. However, workload identity alone does not address execution accountability. Knowing who performed an action does not record -what was done, what policy was applied, or whether compliance -requirements were evaluated at each decision point. +what was done or in what order. Regulated environments increasingly deploy autonomous agents that coordinate across organizational boundaries. Multiple regulatory @@ -94,7 +93,7 @@ detailed mapping). This document defines an extension to the WIMSE architecture that addresses the gap between workload identity and execution accountability. WIMSE authenticates agents; this extension records -what they did, in what order, and what policy was evaluated. +what they did and in what order. As identified in , call context in agentic workflows needs to be visible and preserved. ECTs @@ -110,11 +109,11 @@ systems: WIMSE authenticates agents but does not record what they actually did. A WIT proves "Agent A is authorized" but not -"Agent A executed Task X, under Policy Y, producing Output Z." - No standard mechanism exists to record policy evaluation -outcomes at each decision point in a multi-agent workflow. - No mechanism exists to cryptographically link compensation and -rollback decisions to original actions. +"Agent A executed Task X, producing Output Z." + No standard mechanism exists to cryptographically order and +link task execution across a multi-agent workflow. + No mechanism exists to reconstruct the complete execution +history of a distributed workflow for audit purposes. Existing observability tools such as distributed tracing @@ -131,11 +130,12 @@ regulatory audit scenarios. The Execution Context Token (ECT) format () DAG structure for task dependency ordering () - Policy checkpoint recording () Integration with the WIMSE identity framework () An HTTP header for ECT transport () Audit ledger interface requirements () + Policy evaluation and compensation extensions are defined +separately in The following are out of scope and are handled by WIMSE: @@ -161,11 +161,10 @@ beyond the scope of this specification. The regulatory references in this document are intended to motivate the design requirements, not to claim that implementing ECTs satisfies these regulations. -ECTs provide evidence of claimed execution ordering and policy -evaluation. They do not independently verify that the claimed -execution actually occurred as described, that the policy -evaluation was correct, or that the agent faithfully performed the -stated action. The trustworthiness of ECT claims depends on the +ECTs provide evidence of claimed execution ordering. They do not +independently verify that the claimed execution actually occurred +as described or that the agent faithfully performed the stated +action. The trustworthiness of ECT claims depends on the trustworthiness of the signing agent and the integrity of the broader deployment environment. @@ -202,18 +201,13 @@ edges are directed and no cycles exist.
      Execution Context Token (ECT):
      A JSON Web Token defined by this specification that -records task execution details and policy evaluation outcomes. +records task execution details.
      Audit Ledger:
      An append-only, immutable log of all ECTs within a workflow or set of workflows, used for regulatory audit and compliance verification. -
      -
      Policy Checkpoint:
      -
      - A point in a workflow where a policy evaluation outcome is -recorded within an ECT.
      Workload Identity Token (WIT):
      @@ -260,9 +254,8 @@ the WIMSE scope and are not addressed by workload identity alone: Recording what agents actually do with their authenticated identity - Recording policy evaluation outcomes at each hop Maintaining structured execution records - Linking compensation or rollback actions to original tasks + Linking actions to their predecessors with cryptographic assurance
      @@ -282,7 +275,7 @@ between the identity layer and the application layer: +--------------------------------------------------+ | ECT Layer (Execution Accountability) [This Spec]| | ECT: "Task executed, dependencies met, | -| policy evaluated, outcome recorded" | +| inputs/outputs hashed" | +--------------------------------------------------+ | v @@ -335,8 +328,8 @@ via the WIT public key. WIT (WIMSE layer): Verifies Agent A's identity within the trust domain. WPT verification, if present, per . - ECT (this extension): Records what Agent A did, what policy was -evaluated, and what precedent tasks exist. + ECT (this extension): Records what Agent A did and what +precedent tasks exist. Ledger (if deployed): Appends the verified ECT to the audit ledger. @@ -503,67 +496,6 @@ multiple root tasks. - -
      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 (). MUST be -present when "pol" is present. Initial values are: - - - - "approved": The policy evaluation succeeded and the task -was authorized to proceed. - "rejected": The policy evaluation failed. A "rejected" ECT -MUST still be 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". - "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. - - - 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. -
      -
      pol_enforcer:
      -
      - OPTIONAL. 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 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. -
      Data Integrity @@ -594,12 +526,11 @@ using the same format and algorithm requirements as "inp_hash".
      Compensation and Rollback -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. +Compensation and rollback extensions are defined in +. 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 @@ -638,16 +569,11 @@ 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 ). +Additional extension keys for policy evaluation and compensation +are defined in . +
      Complete ECT Example @@ -666,15 +592,10 @@ to minimize information leakage (see ). "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_timestamp": 1772064145, "exec_time_ms": 245, "regulated_domain": "medtech", "model_version": "clinical-reasoning-v4.2" @@ -763,14 +684,6 @@ 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". This rule only applies when the parent ECT -contains policy claims. 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. @@ -876,9 +789,6 @@ 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". Perform DAG validation per . If all checks pass and an audit ledger is deployed, the ECT SHOULD be appended to the ledger. @@ -956,14 +866,6 @@ 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: - return reject("pol and pol_decision must both be present") - if payload.pol_decision not in - ["approved", "rejected", "pending_human_review"]: - return reject("Invalid pol_decision value") - // Validate DAG (against ECT store or inline parent ECTs) result = validate_dag(payload, ect_store, clock_skew_tolerance) @@ -1031,28 +933,22 @@ 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 Agent B (Code Generator): jti: task-002 par: [task-001] exec_act: implement_module - pol: coding_standards_v3 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 Agent D (Build Agent): jti: task-004 par: [task-003] exec_act: build_release_artifact - pol: build_validation_v2 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) ]]> @@ -1090,7 +986,6 @@ task-005 (approve_release) [human, witnessed] Each phase was executed by an identified and authenticated agent. - Policy checkpoints were evaluated at every phase transition. The execution sequence was maintained (no step was bypassed). A human-in-the-loop approved the final release, with independent witness attestation. @@ -1123,17 +1018,14 @@ execution. Agent A (Risk Assessment): jti: task-001 par: [] exec_act: calculate_risk_exposure - pol: risk_limits_policy_v2 pol_decision: approved Agent B (Compliance): jti: task-002 par: [task-001] exec_act: verify_compliance - pol: compliance_check_v1 pol_decision: approved Agent C (Execution): jti: task-003 par: [task-002] exec_act: execute_trade - pol: execution_policy_v3 pol_decision: approved ]]> This can contribute to compliance with: @@ -1149,33 +1041,10 @@ systems.
      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: - -
      - -The "par" claim links the compensation action to the original -trade, creating an auditable chain from execution through -violation discovery to remediation. +Compensation and rollback use cases are described in +. The core +ECT mechanism supports compensation through the "par" claim, +which links a remediation ECT to the original task.
      Autonomous Logistics Coordination @@ -1188,27 +1057,22 @@ required checks were completed: Agent A (Route Planning): jti: task-001 par: [] exec_act: plan_route - pol: route_policy_v1 pol_decision: approved Agent B (Customs): jti: task-002 par: [task-001] exec_act: validate_customs - pol: customs_policy_v2 pol_decision: approved Agent C (Safety): jti: task-003 par: [task-001] exec_act: verify_cargo_safety - pol: safety_policy_v1 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 System (Commitment): jti: task-005 par: [task-004] exec_act: commit_shipment - pol: commitment_policy_v1 pol_decision: approved ]]> Note that tasks 002 and 003 both depend only on task-001 and can @@ -1243,14 +1107,12 @@ 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., claiming an action was performed when it was not). ECTs do not independently verify that: The claimed execution actually occurred as described - The policy evaluation was correctly performed The input/output hashes correspond to the actual data processed The agent faithfully performed the stated action @@ -1284,8 +1146,6 @@ organizational controls are in place: keys and how keys are protected. Ledger integrity governance: The ledger is maintained by an entity independent of the workflow agents. - Policy lifecycle management: Policy identifiers in ECTs map to -actual, validated policy rules. Agent deployment governance: Agents are deployed and maintained in a manner that preserves their integrity. @@ -1340,8 +1200,7 @@ transport security is already established. HTTP Message Signatures TLS/mTLS (transport layer): Prevents network-level tampering. WIT/WPT (WIMSE identity layer): Proves agent identity and request authorization. - ECT (execution accountability layer): Records what the agent did -and under what policy. + ECT (execution accountability layer): Records what the agent did.
      @@ -1442,8 +1301,6 @@ 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 Timestamps ("iat", "exp") for temporal ordering @@ -1463,12 +1320,8 @@ 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" extension key in "ext" -() deserves particular attention: because -it is human-readable, it risks exposing sensitive operational +Extension keys in "ext" () deserve particular +attention: human-readable values risk exposing sensitive operational details. See for guidance on using structured identifiers. @@ -1490,8 +1343,7 @@ general access to the data values is not needed. ECTs are designed for interpretation by qualified human auditors and regulators. ECTs provide structural records of execution -ordering and policy evaluation; they are not intended for public -disclosure. +ordering; they are not intended for public disclosure. @@ -1615,18 +1467,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 @@ -1641,33 +1481,9 @@ the "JSON Web Token Claims" registry maintained by IANA: - -
      ECT Policy Decision Values Registry - -This document establishes the "ECT Policy Decision Values" -registry under the "JSON Web Token (JWT)" group. Registration -policy is Specification Required per . - -The initial contents of the registry are: - - - Value - Description - Change Controller - Reference - approved - Policy evaluation succeeded - IETF - - rejected - Policy evaluation failed - IETF - - pending_human_review - Awaiting human judgment - IETF - - +Policy evaluation claims and the ECT Policy Decision Values +registry are defined in +.
      @@ -1736,23 +1552,6 @@ policy is Specification Required per . - - - Guidelines for Writing an IANA Considerations Section in RFCs - - - - - - Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). - To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. - This is the third edition of this document; it obsoletes RFC 5226. - - - - - - Universally Unique IDentifiers (UUIDs) @@ -1963,6 +1762,15 @@ been incorporated into this document. This document obsoletes RFC + + + Policy Evaluation and Compensation Extensions for Execution Context Tokens + + + + + + Secure Production Identity Framework for Everyone (SPIFFE) @@ -2128,7 +1936,7 @@ been incorporated into this document. This document obsoletes RFC - +
      Related Work @@ -2138,9 +1946,9 @@ been incorporated into this document. This document obsoletes RFC service protocol provide the identity foundation upon which ECTs are built. WIT/WPT answer "who is this agent?" and "does it control the claimed key?" while -ECTs record "what did this agent do?" and "what policy was -evaluated?" Together they form an identity-plus-accountability -framework for regulated agentic systems. +ECTs record "what did this agent do?" Together they form an +identity-plus-accountability framework for regulated agentic +systems.
      OAuth 2.0 Token Exchange and the "act" Claim @@ -2152,16 +1960,14 @@ delegation chain: "who is acting on behalf of whom." While the nesting superficially resembles a chain, it is strictly linear (each "act" object contains at most one nested "act"), represents authorization delegation rather than task execution, -and carries no task identifiers, policy decisions, or -input/output integrity data. The "act" chain cannot represent +and carries no task identifiers or input/output integrity data. The "act" chain cannot represent branching (fan-out) or convergence (fan-in) and therefore cannot form a DAG. ECTs intentionally use the distinct claim name "exec_act" for the action/task type to avoid collision with the "act" claim. The two concepts are orthogonal: "act" records "who authorized whom," -ECTs record "what was done, in what order, with what policy -outcomes." +ECTs record "what was done, in what order."
      Transaction Tokens @@ -2183,7 +1989,7 @@ the branching is invisible. token from the Transaction Token Service appear in "req_wl"; workloads that forward the token unchanged are not recorded. It carries no task-level granularity, no parent references, -no policy evaluation outcomes, and no execution content. +and no execution content. Extensions for agentic use cases @@ -2195,7 +2001,7 @@ ordering or DAG structure. propagates authorization context ("this request is authorized for scope X on behalf of user Y"), while an ECT records execution accountability ("task T was performed, depending on -tasks P1 and P2, with policy Z evaluated and approved"). An +tasks P1 and P2"). An agent request could carry both a Txn-Token for authorization and an ECT for execution recording. The WPT "tth" claim defined in can hash-bind a @@ -2240,7 +2046,7 @@ identifier referenced in SCITT Signed Statements, linking a complete ECT audit trail to a supply chain transparency record. For example, in a regulated manufacturing workflow, each agent step produces an ECT (recording what was done, by whom, under -what policy), while the overall workflow identified by "wid" is +under what constraints), while the overall workflow identified by "wid" is registered as a SCITT Signed Statement on a Transparency Service. This enables auditors to verify both the individual execution steps (via ECT DAG validation) and the end-to-end supply chain @@ -2254,7 +2060,7 @@ identifiers or Receipt references for tighter integration. W3C Verifiable Credentials represent claims about subjects (e.g., identity, qualifications). ECTs represent execution records of -actions (what happened, in what order, under what policy). While +actions (what happened, in what order). While both use JWT/JWS as a serialization format, their semantics and use cases are distinct. @@ -2268,8 +2074,7 @@ 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"). Sign ECTs with the agent's private key using an algorithm matching the WIT (ES256 recommended). Verify ECT signatures against WIT public keys. @@ -2377,8 +2182,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" } @@ -2396,9 +2199,7 @@ task, and creates its own ECT: "jti": "550e8400-e29b-41d4-a716-446655440002", "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890", "exec_act": "validate_safety", - "par": ["550e8400-e29b-41d4-a716-446655440001"], - "pol": "safety_validation_policy_v2", - "pol_decision": "approved" + "par": ["550e8400-e29b-41d4-a716-446655440001"] } ]]> @@ -2429,8 +2230,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" } @@ -2447,9 +2246,7 @@ autonomous agents and human release approval: "jti": "a1b2c3d4-0001-0000-0000-000000000002", "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901", "exec_act": "implement_module", - "par": ["a1b2c3d4-0001-0000-0000-000000000001"], - "pol": "coding_standards_v3", - "pol_decision": "approved" + "par": ["a1b2c3d4-0001-0000-0000-000000000001"] } ]]> @@ -2464,9 +2261,7 @@ autonomous agents and human release approval: "jti": "a1b2c3d4-0001-0000-0000-000000000003", "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" + "par": ["a1b2c3d4-0001-0000-0000-000000000002"] } ]]> @@ -2482,8 +2277,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" } ]]> @@ -2500,9 +2293,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": { "witnessed_by": [ "spiffe://meddev.example/audit/qa-observer-1" @@ -2571,9 +2361,7 @@ task-...-0004 (execute_trade) "par": [ "f1e2d3c4-0002-0000-0000-000000000002", "f1e2d3c4-0003-0000-0000-000000000003" - ], - "pol": "trade_execution_policy_v3", - "pol_decision": "approved" + ] } ]]> @@ -2597,523 +2385,477 @@ tracing is built.
      -Table 3: +Table 2: Regulatory Compliance Mapping