Initial companion draft: policy evaluation and compensation extensions for ECTs
Extracted from the core ECT spec (draft-nennemann-wimse-execution-context-00) to keep the base specification focused on identity, action recording, lineage, and integrity. This companion draft defines policy evaluation extension keys (pol, pol_decision, pol_enforcer, pol_timestamp), compensation/rollback patterns, DAG validation rules for policy decisions, and the ECT Policy Decision Values IANA registry. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
376
draft-nennemann-wimse-ect-policy-compensation-00.md
Normal file
376
draft-nennemann-wimse-ect-policy-compensation-00.md
Normal file
@@ -0,0 +1,376 @@
|
||||
---
|
||||
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.
|
||||
Reference in New Issue
Block a user