commit ef475359a02357f1cd887d8b93d882a2e82001f6 Author: Christian Nennemann Date: Wed Feb 25 13:58:51 2026 +0100 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 diff --git a/draft-nennemann-wimse-ect-policy-compensation-00.md b/draft-nennemann-wimse-ect-policy-compensation-00.md new file mode 100644 index 0000000..0d4116c --- /dev/null +++ b/draft-nennemann-wimse-ect-policy-compensation-00.md @@ -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.