Policy checkpoint recording via extension keys (Section 4.2.3)¶
+Policy checkpoint recording (Section 4.2.3)¶
Integration with the WIMSE identity framework @@ -2173,73 +2173,70 @@ multiple root tasks.¶
Policy evaluation outcomes are recorded as extension keys within -the "ext" object (Section 4.2.6). 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:¶
-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.¶
+The following claims record policy evaluation outcomes:¶
+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.¶
String. The result of the policy evaluation. When present, -MUST be one of the values registered in the ECT Policy Decision -Values registry (Section 12.4). MUST be present -when "pol" is present. Initial values are:¶
+OPTIONAL. String. The result of the policy evaluation. When +present, MUST be one of the values registered in the ECT Policy +Decision Values registry (Section 12.4). MUST be +present when "pol" is present. Initial values are:¶
"approved": The policy evaluation succeeded and the task -was authorized to proceed.¶
+"approved": The policy evaluation succeeded and the task +was authorized to proceed.¶
"rejected": The policy evaluation failed. A "rejected" ECT +
"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".¶
+"pol_decision" is "rejected".¶"pending_human_review": The policy evaluation requires human +
"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.¶
+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.¶
+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.¶
StringOrURI. The identity of the entity (system or person) -that evaluated the policy decision. When present, SHOULD use -SPIFFE ID format.¶
+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 +
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 +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 "ext" keys defined above.¶
+faithfully recorded in the ECT claims defined above.¶OPTIONAL. Object. An extension object for claims beyond the -core registered claims. This specification defines several -extension keys for policy evaluation (Section 4.2.3) and -operational metadata; deployments MAY also include -domain-specific keys. Implementations MUST ignore extension -keys they do not recognize.¶
+OPTIONAL. Object. An extension object for domain-specific +claims not defined by this specification. Implementations +that do not understand extension claims MUST ignore them.¶
The following extension keys are defined by this specification for common use cases. Because these keys are documented here, -they use short names without reverse domain prefixes.¶
-Policy evaluation keys (see Section 4.2.3 for full -definitions and decision value semantics):¶
+they use short names without reverse domain prefixes:¶"pol": String. Policy rule identifier.¶
+"exec_time_ms": Integer. Execution duration in milliseconds.¶
"pol_decision": String. Policy evaluation outcome -("approved", "rejected", or "pending_human_review").¶
+"regulated_domain": String. Regulatory domain (e.g., +"medtech", "finance", "military").¶
"pol_enforcer": StringOrURI. Identity of the policy -evaluator.¶
+"model_version": String. AI/ML model version.¶
"pol_timestamp": NumericDate. Time at which the policy -decision was made, if distinct from "iat".¶
-Operational metadata keys:¶
-"exec_time_ms": Integer. Execution duration in milliseconds.¶
-"regulated_domain": String. Regulatory domain (e.g., -"medtech", "finance", "military").¶
-"model_version": String. AI/ML model version.¶
-"witnessed_by": Array of StringOrURI. Identifiers of +
"witnessed_by": Array of StringOrURI. Identifiers of third-party entities that the issuer claims observed the task. Note: this is self-asserted; for verifiable witness -attestation, witnesses should submit independent signed ECTs.¶
+attestation, witnesses should submit independent signed ECTs.¶"inp_classification": String. Data sensitivity classification -(e.g., "public", "confidential", "restricted").¶
+"inp_classification": String. Data sensitivity classification +(e.g., "public", "confidential", "restricted").¶
"compensation_required": Boolean. Indicates whether this task -is a compensation or rollback action.¶
+"pol_timestamp": NumericDate. Time at which the policy +decision was made, if distinct from "iat".¶
"compensation_reason": String. Structured reason code for the +
"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 Section 11.2).¶
+to minimize information leakage (see Section 11.2).¶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.¶
+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.¶
Trust Domain Consistency: Parent tasks SHOULD belong to the @@ -2675,9 +2654,9 @@ verifier's current time, to account for clock skew).¶
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".¶
+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".¶
Perform DAG validation per Section 6.¶
@@ -2764,12 +2743,11 @@ function verify_ect(ect_jws, verifier_id, if claim not in payload: return reject("Missing required claim: " + claim) - // Validate policy extension keys (optional, but must be paired) - ext = payload.ext or {} - if "pol" in ext or "pol_decision" in ext: - if "pol" not in ext or "pol_decision" not in ext: + // 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 ext.pol_decision not in + if payload.pol_decision not in ["approved", "rejected", "pending_human_review"]: return reject("Invalid pol_decision value") @@ -2860,34 +2838,29 @@ software used in medical devices.¶ Agent A (Spec Reviewer): jti: task-001 par: [] exec_act: review_requirements_spec - ext.pol: spec_review_policy_v2 - ext.pol_decision: approved + pol: spec_review_policy_v2 pol_decision: approved Agent B (Code Generator): jti: task-002 par: [task-001] exec_act: implement_module - ext.pol: coding_standards_v3 - ext.pol_decision: approved + pol: coding_standards_v3 pol_decision: approved Agent C (Test Agent): jti: task-003 par: [task-002] exec_act: execute_test_suite - ext.pol: test_coverage_policy_v1 - ext.pol_decision: approved + pol: test_coverage_policy_v1 pol_decision: approved Agent D (Build Agent): jti: task-004 par: [task-003] exec_act: build_release_artifact - ext.pol: build_validation_v2 - ext.pol_decision: approved + pol: build_validation_v2 pol_decision: approved Human Release Manager: jti: task-005 par: [task-004] exec_act: approve_release - ext.pol: release_approval_policy - ext.pol_decision: approved - ext.pol_enforcer: spiffe://meddev.example/human/release-mgr-42 - ext.witnessed_by: [...] + pol: release_approval_policy pol_decision: approved + pol_enforcer: spiffe://meddev.example/human/release-mgr-42 + ext: {witnessed_by: [...]} (extension metadata)ECTs do not independently verify that:¶
Action descriptions ("exec_act") for audit trail completeness¶
Policy evaluation outcomes (via "ext" keys "pol", -"pol_decision") when present, for compliance verification¶
+Policy evaluation outcomes ("pol", "pol_decision") for +compliance verification¶
Timestamps ("iat", "exp") for temporal ordering¶
@@ -3451,8 +3416,8 @@ hashes via "inp_hash" and "out_hash")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" extension key SHOULD reference policy identifiers -rather than embedding policy content.¶ +The "pol" claim SHOULD reference policy identifiers rather than +embedding policy content.¶The "compensation_reason" extension key in "ext" (Section 4.2.5) deserves particular attention: because it is human-readable, it risks exposing sensitive operational @@ -3655,6 +3620,30 @@ the "JSON Web Token Claims" registry maintained by IANA:IETF
Create JWTs with all required claims ("iss", "aud", "iat", -"exp", "jti", "exec_act", "par") and policy extension keys -("ext.pol", "ext.pol_decision") when policy evaluation was -performed.¶
+"exp", "jti", "exec_act", "par") and policy claims ("pol", +"pol_decision") when policy evaluation was performed.¶Sign ECTs with the agent's private key using an algorithm @@ -4216,12 +4200,10 @@ Agent B:¶
"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", - "ext": { - "pol": "clinical_data_access_policy_v1", - "pol_decision": "approved" - } + "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564" } ¶