ietf-wimse-ect-pol/draft-nennemann-wimse-ect-policy-compensation-00.md

fullname: Christian Nennemann
organization: Independent Researcher
email: ietf@nennemann.de

normative: RFC7519: RFC8126: I-D.nennemann-wimse-execution-context: title: "Execution Context Tokens for Distributed Agentic Workflows" target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-execution-context/ date: false author: - fullname: Christian Nennemann

informative: MIFID-II: title: "Directive 2014/65/EU of the European Parliament and of the Council on markets in financial instruments (MiFID II)" target: https://eur-lex.europa.eu/eli/dir/2014/65 date: 2014-05-15 author: - org: European Parliament and Council of the European Union DORA: title: "Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)" target: https://eur-lex.europa.eu/eli/reg/2022/2554 date: 2022-12-14 author: - org: European Parliament and Council of the European Union EU-AI-ACT: title: "Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)" target: https://eur-lex.europa.eu/eli/reg/2024/1689 date: 2024-06-13 author: - org: European Parliament and Council of the European Union

--- abstract

This document defines policy evaluation and compensation extension keys for Execution Context Tokens (ECTs) as defined in {{I-D.nennemann-wimse-execution-context}}. These extensions enable regulated workflows to record policy evaluation outcomes at each decision point, link compensation and rollback actions to original tasks, and enforce DAG validation rules based on policy decisions. A new IANA registry for ECT Policy Decision Values is established.

--- middle

Introduction

The Execution Context Token (ECT) specification {{I-D.nennemann-wimse-execution-context}} defines a JWT-based format for recording task execution in distributed agentic workflows. ECTs provide identity, action recording, DAG-based dependency tracking, and data integrity verification.

This companion specification extends ECTs with two capabilities for regulated environments:

1. Policy evaluation recording: Extension keys that record which policy was evaluated, what decision was reached, and who evaluated it. This enables regulatory auditors to verify that required policy checkpoints were evaluated at each decision point in a workflow.

2. Compensation and rollback: A pattern for linking remediation actions to original tasks using existing ECT mechanics ("par" and "exec_act"), plus extension keys that explicitly mark compensation actions and their reasons.

These capabilities are defined as extensions to the core ECT format to keep the base specification focused on identity, action recording, lineage, and integrity, while providing a standardized approach for deployments that require policy and compensation recording.

Conventions and Definitions

{::boilerplate bcp14-tagged}

The following terms are used in this document in addition to those defined in {{I-D.nennemann-wimse-execution-context}}:

Policy Checkpoint:

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

Compensation Action:

A task that remediates or rolls back a previously executed task, linked via the ECT "par" claim.

Policy Evaluation Extension Keys

Policy evaluation outcomes are recorded as extension keys within the ECT "ext" object (as defined in {{I-D.nennemann-wimse-execution-context}}). This keeps the core registered claims focused on DAG structure and execution context, while allowing deployments to add policy recording as needed.

The following extension keys are defined for policy evaluation:

"pol":

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

"pol_decision":

String. The result of the policy evaluation. When present, MUST be one of the values registered in the ECT Policy Decision Values registry ({{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 from "ext", the ECT records task execution without a policy checkpoint. Regulated deployments SHOULD include policy keys on all ECTs to maintain complete audit trails.

"pol_enforcer":

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

"pol_timestamp":

NumericDate. Time at which the policy decision was made, if distinct from the ECT "iat" claim.

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" key is an opaque identifier referencing an external policy; the semantics and enforcement of that policy are determined by the deployment environment. Implementations may use any policy engine or framework (e.g., OPA/Rego, Cedar, XACML, or custom solutions) provided that the evaluation outcome is faithfully recorded in the "ext" keys defined above.

Compensation and Rollback

Compensation and rollback actions are recorded using the ECT "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.

The following extension keys are defined for compensation actions:

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

Compensation ECT Example

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"],
  "ext": {
    "pol": "compensation_policy_v1",
    "pol_decision": "approved",
    "pol_enforcer": "spiffe://bank.example/human/compliance-officer",
    "compensation_required": true,
    "compensation_reason": "policy_violation_in_parent_trade"
  }
}

{: #fig-compensation title="Compensation ECT Example"}

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

DAG Validation: Parent Policy Decision Rule

In addition to the DAG validation rules defined in {{I-D.nennemann-wimse-execution-context}}, implementations that support the policy extension keys defined in this document MUST enforce the following rule:

Parent Policy Decision:

If any parent ECT's "ext" object contains a "pol_decision" of "rejected" or "pending_human_review", the current ECT's "exec_act" MUST indicate a compensation, rollback, remediation, or human review action. Implementations MUST NOT accept an ECT representing normal workflow continuation when a parent's "pol_decision" is not "approved". This rule only applies when the parent ECT's "ext" contains policy keys.

Verification: Policy Key Pairing

When verifying an ECT that contains policy extension keys, implementations MUST perform the following additional check beyond the verification procedure defined in {{I-D.nennemann-wimse-execution-context}}:

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

Use Cases

Financial Trading Workflow

In a financial trading workflow, agents perform risk assessment, compliance verification, and trade execution. The DAG structure records that compliance checks were evaluated before trade execution.

Agent A (Risk Assessment):
  jti: task-001    par: []
  exec_act: calculate_risk_exposure
  ext.pol: risk_limits_policy_v2
  ext.pol_decision: approved

Agent B (Compliance):
  jti: task-002    par: [task-001]
  exec_act: verify_compliance
  ext.pol: compliance_check_v1
  ext.pol_decision: approved

Agent C (Execution):
  jti: task-003    par: [task-002]
  exec_act: execute_trade
  ext.pol: execution_policy_v3
  ext.pol_decision: approved

{: #fig-finance title="Financial Trading Workflow"}

This can contribute to compliance with:

• {{MIFID-II}}: ECTs provide cryptographic records of the execution sequence that can support transaction audit requirements.
• {{DORA}} Article 12: ECTs contribute to ICT activity logging.
• {{EU-AI-ACT}} Article 12: Logging of decisions made by AI-driven systems.

Compensation and Rollback Workflow

When a compliance violation is discovered after trade execution, the compensation pattern creates an auditable remediation chain:

Agent A (Risk Assessment):
  jti: task-001    par: []
  exec_act: calculate_risk_exposure
  ext.pol_decision: approved

Agent B (Compliance):
  jti: task-002    par: [task-001]
  exec_act: verify_compliance
  ext.pol_decision: approved

Agent C (Execution):
  jti: task-003    par: [task-002]
  exec_act: execute_trade
  ext.pol_decision: approved

     ... violation discovered ...

Agent D (Operations):
  jti: task-099    par: [task-003]
  exec_act: initiate_trade_rollback
  ext.compensation_required: true
  ext.compensation_reason: policy_violation_in_parent_trade
  ext.pol_decision: approved

{: #fig-compensation-workflow title="Compensation Workflow"}

The DAG links the rollback action (task-099) to the original trade (task-003), providing a complete audit trail from execution through violation discovery to remediation.

Privacy Considerations

Compensation Reason Data Minimization

The "compensation_reason" extension key deserves particular attention: because it is human-readable, it risks exposing sensitive operational details. Implementations SHOULD use structured identifiers (e.g., "policy_violation_in_parent_trade") rather than free-form text descriptions to minimize information leakage.

Security Considerations

The security considerations of {{I-D.nennemann-wimse-execution-context}} apply to all ECTs including those using the extensions defined in this document.

Policy evaluation outcomes recorded in ECTs are self-asserted by the executing agent. A compromised or malicious agent could create ECTs with false policy claims (e.g., setting "pol_decision" to "approved" without actually evaluating the policy). The trustworthiness of policy claims depends on the trustworthiness of the signing agent and the integrity of the broader deployment environment.

IANA Considerations

ECT Policy Decision Values Registry

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

The initial contents of the registry are:

Value	Description	Change 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"}

--- back

Acknowledgments

{:numbered="false"}

The policy evaluation and compensation patterns defined in this document were originally part of the core ECT specification {{I-D.nennemann-wimse-execution-context}} and were extracted into this companion document to keep the core specification focused on identity, action recording, lineage, and integrity.