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

---
title: "Policy Evaluation and Compensation Extensions for Execution Context Tokens"
abbrev: "ECT Policy & Compensation"
category: std
docname: draft-nennemann-wimse-ect-policy-compensation-00
submissiontype: IETF
number:
date:
v: 3
area: "Security"
workgroup: "WIMSE"
keyword:
  - execution context
  - policy evaluation
  - compensation
  - rollback
  - regulated systems

author:
  -
    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-claims}

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-claims}

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:

~~~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"],
  "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 {#dag-policy-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 {#verification-policy}

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 {#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 {#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 {#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"}

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