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