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 <noreply@anthropic.com>

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
+execution order and compliance state across agent-to-agent
-across
+communication.  By extending WIMSE Workload Identity
-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
+dependencies and integrate with WIMSE Workload Identity Tokens (WIT)
-point, and integrate with WIMSE Workload Identity Tokens (WIT)
+using the same signing model and cryptographic primitives.
-using the same signing model and cryptographic primitives.  A new
+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
+what was done or in what order.
-requirements were evaluated at each decision point.
 
 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
+2.  No standard mechanism exists to cryptographically order and
-    outcomes at each decision point in a multi-agent workflow.
+    link task execution across a multi-agent workflow.
 
-3.  No mechanism exists to cryptographically link compensation and
+3.  No mechanism exists to reconstruct the complete execution
-    rollback decisions to original actions.
+    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
+ECTs provide evidence of claimed execution ordering.  They do not
-evaluation.  They do not independently verify that the claimed
+independently verify that the claimed execution actually occurred
-execution actually occurred as described, that the policy
+as described or that the agent faithfully performed the stated
-evaluation was correct, or that the agent faithfully performed the
+action.  The trustworthiness of ECT claims depends on 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
+2.  ECT (this extension): Records what Agent A did and what
-    evaluated, and what precedent tasks exist.
+    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"
+Compensation and rollback extensions are defined in
-claim to reference the original task and the "exec_act" claim to
+{{I-D.nennemann-wimse-ect-policy-compensation}}.  The referenced
-describe the remediation action.  The referenced parent ECTs may
+parent ECTs may have passed their own "exp" time; ECT expiration
-have passed their own "exp" time; ECT expiration applies to the
+applies to the verification window of the ECT itself, not to its
-verification window of the ECT itself, not to its validity as a
+validity as a parent reference in the ECT store.
-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".
+Additional extension keys for policy evaluation and compensation
-- "compensation\_required": Boolean.  Indicates whether this task
+are defined in {{I-D.nennemann-wimse-ect-policy-compensation}}.
-  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}}).
 
 ## 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
+5.  Trust Domain Consistency: Parent tasks SHOULD belong to the
-    "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 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
+13. Perform DAG validation per {{dag-validation}}.
-    present and that "pol_decision" is one of "approved",
-    "rejected", or "pending_human_review".
 
-14. Perform DAG validation per {{dag-validation}}.
+14. If all checks pass and an audit ledger is deployed, the ECT
-
-15. 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
+Compensation and rollback use cases are described in
-provide a mechanism to record authorized compensation actions with
+{{I-D.nennemann-wimse-ect-policy-compensation}}.  The core
-a cryptographic link to the original task:
+ECT mechanism supports compensation through the "par" claim,
-
+which links a remediation ECT 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.
 
 ## 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
+(e.g., claiming an action was performed when it was not).
-evaluating the policy).
 
 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
+- ECT (execution accountability layer): Records what the agent did.
-  and under what policy.
 
 ## 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
+Extension keys in "ext" ({{extension-claims}}) deserve particular
-embedding policy content.
+attention: human-readable values risk exposing sensitive operational
-
-The "compensation_reason" extension key in "ext"
-({{compensation-claims}}) deserves particular attention: because
-it is human-readable, it risks 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
+ordering; they are not intended for public disclosure.
-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}
+Policy evaluation claims and the ECT Policy Decision Values
-
+registry are defined in
-This document establishes the "ECT Policy Decision Values"
+{{I-D.nennemann-wimse-ect-policy-compensation}}.
-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
 
@@ -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
+ECTs record "what did this agent do?"  Together they form an
-evaluated?"  Together they form an identity-plus-accountability
+identity-plus-accountability framework for regulated agentic
-framework for regulated agentic systems.
+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
+and carries no task identifiers or input/output integrity data.  The "act" chain cannot represent
-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
+ECTs record "what was done, in what order."
-outcomes."
 
 ## 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",
+    "exp", "jti", "exec_act", "par").
-    "pol_decision") when policy evaluation was performed.
 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"],
+  "par": ["550e8400-e29b-41d4-a716-446655440001"]
-  "pol": "safety_validation_policy_v2",
-  "pol_decision": "approved"
 }
 ~~~
 
@@ -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"],
+  "par": ["a1b2c3d4-0001-0000-0000-000000000001"]
-  "pol": "coding_standards_v3",
-  "pol_decision": "approved"
 }
 ~~~
 
@@ -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"],
+  "par": ["a1b2c3d4-0001-0000-0000-000000000002"]
-  "pol": "test_coverage_policy_v1",
-  "pol_decision": "approved"
 }
 ~~~
 
@@ -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"
 }
 ~~~