c/ietf-wimse-ect
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Simplify spec: remove sub, move compensation and policy to ext

Browse Source 
- Remove sub claim (always equals iss, added no information)
- Move compensation_required and compensation_reason to ext keys
- Move pol, pol_decision, pol_enforcer to ext keys
- IANA JWT Claims table reduced from 11 to 6 registered claims
- Trim witness attestation section to concise guidance
- Fix remaining ledger-mandatory language in verification
  step 15 and minimal implementation guidance

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Christian Nennemann
2026-02-25 12:38:14 +01:00
parent 898b0f8747
commit bf0f94ab30
4 changed files with 1679 additions and 1773 deletions
Download Patch File Download Diff File Expand all files Collapse all files

342
draft-nennemann-wimse-execution-context-00.md
View File

@@ -167,7 +167,7 @@ This document defines:
- The Execution Context Token (ECT) format ({{ect-format}})
- DAG structure for task dependency ordering ({{dag-validation}})
- Policy checkpoint recording ({{policy-claims}})
- Policy checkpoint recording via extension keys ({{policy-claims}})
- Integration with the WIMSE identity framework
({{wimse-integration}})
- An HTTP header for ECT transport ({{http-header}})
@@ -403,12 +403,6 @@ iss:
deployments MAY use other URI schemes (e.g., HTTPS URLs or
URN:UUID identifiers).
sub:
: OPTIONAL. StringOrURI. The subject of the ECT. When present,
MUST equal the "iss" claim. This claim is included for
compatibility with JWT libraries and frameworks that expect a
"sub" claim to be present.
aud:
: REQUIRED. StringOrURI or array of StringOrURI. The intended
recipient(s) of the ECT. Because ECTs serve as both inter-agent
@@ -489,21 +483,25 @@ par:
a root task with no dependencies. A workflow MAY contain
multiple root tasks.
### Policy Evaluation {#policy-claims}
### Policy Evaluation Extension Keys {#policy-claims}
The following claims record policy evaluation outcomes:
Policy evaluation outcomes are recorded as extension keys within
the "ext" object ({{extension-claims}}). This keeps the core
registered claims focused on DAG structure and execution context,
while allowing deployments to add policy recording as needed.
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.
The following extension keys are defined for policy evaluation:
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:
"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.
@@ -522,25 +520,25 @@ pol_decision:
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.
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:
: OPTIONAL. StringOrURI. The identity of the entity (system or
person) that evaluated the policy decision. When present,
SHOULD use SPIFFE ID format.
"pol_enforcer":
: 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
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 ECT claims defined above.
faithfully recorded in the "ext" keys defined above.
### Data Integrity {#data-integrity-claims}
@@ -565,25 +563,12 @@ out_hash:
### Compensation and Rollback {#compensation-claims}
compensation_required:
: OPTIONAL. Boolean. Indicates whether this task is a
compensation or rollback action for a previous task.
compensation_reason:
: OPTIONAL. String. A human-readable reason for the compensation
action. MUST be present if "compensation_required" is true.
Values SHOULD use structured identifiers (e.g.,
"policy_violation_in_parent_trade") rather than free-form text
to minimize the risk of embedding sensitive information. See
{{data-minimization}} for privacy guidance.
If "compensation_reason" is present, "compensation_required"
MUST be true.
Note: compensation ECTs reference historical parent tasks via the
"par" claim. 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
ledger.
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.
### Extensions {#extension-claims}
@@ -604,7 +589,20 @@ exceeds these limits.
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:
they use short names without reverse domain prefixes.
Policy evaluation keys (see {{policy-claims}} for full
definitions and decision value semantics):
- "pol": String. Policy rule identifier.
- "pol\_decision": String. Policy evaluation outcome
("approved", "rejected", or "pending\_human\_review").
- "pol\_enforcer": StringOrURI. Identity of the policy
evaluator.
- "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.,
@@ -616,8 +614,12 @@ 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}}).
## Complete ECT Example
@@ -626,7 +628,6 @@ The following is a complete ECT payload example:
~~~json
{
"iss": "spiffe://example.com/agent/clinical",
"sub": "spiffe://example.com/agent/clinical",
"aud": "spiffe://example.com/agent/safety",
"iat": 1772064150,
"exp": 1772064750,
@@ -636,14 +637,13 @@ 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": "clinical_reasoning_policy_v2",
"pol_decision": "approved",
"pol_enforcer": "spiffe://example.com/policy/clinical-engine",
"pol_timestamp": 1772064145,
"exec_time_ms": 245,
"regulated_domain": "medtech",
@@ -733,15 +733,14 @@ 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", unless the current ECT has "compensation_required"
set to true. This rule only applies when the parent ECT
contains policy claims.
5. 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.
6. Trust Domain Consistency: Parent tasks SHOULD belong to the
same trust domain or to a trust domain with which a federation
@@ -856,19 +855,19 @@ 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. 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".
14. Perform DAG validation per {{dag-validation}}.
15. If all checks pass, the ECT MUST be appended to the audit
ledger.
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
failure MUST be logged for audit purposes. Error messages
SHOULD NOT reveal whether specific parent task IDs exist in the
ledger, to prevent information disclosure.
ECT store, to prevent information disclosure.
When ECT verification fails during HTTP request processing, the
receiving agent SHOULD respond with HTTP 403 (Forbidden) if the
@@ -936,11 +935,12 @@ 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:
// 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:
return reject("pol and pol_decision must both be present")
if payload.pol_decision not in
if ext.pol_decision not in
["approved", "rejected", "pending_human_review"]:
return reject("Invalid pol_decision value")
@@ -1010,29 +1010,34 @@ 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
ext.pol: spec_review_policy_v2
ext.pol_decision: approved
Agent B (Code Generator):
jti: task-002 par: [task-001]
exec_act: implement_module
pol: coding_standards_v3 pol_decision: approved
ext.pol: coding_standards_v3
ext.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
ext.pol: test_coverage_policy_v1
ext.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
ext.pol: build_validation_v2
ext.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)
ext.pol: release_approval_policy
ext.pol_decision: approved
ext.pol_enforcer: spiffe://meddev.example/human/release-mgr-42
ext.witnessed_by: [...]
~~~
{: #fig-medtech-sdlc title="Medical Device SDLC Workflow"}
@@ -1098,17 +1103,20 @@ execution.
Agent A (Risk Assessment):
jti: task-001 par: []
exec_act: calculate_risk_exposure
pol: risk_limits_policy_v2 pol_decision: approved
ext.pol: risk_limits_policy_v2
ext.pol_decision: approved
Agent B (Compliance):
jti: task-002 par: [task-001]
exec_act: verify_compliance
pol: compliance_check_v1 pol_decision: approved
ext.pol: compliance_check_v1
ext.pol_decision: approved
Agent C (Execution):
jti: task-003 par: [task-002]
exec_act: execute_trade
pol: execution_policy_v3 pol_decision: approved
ext.pol: execution_policy_v3
ext.pol_decision: approved
~~~
{: #fig-finance title="Financial Trading Workflow"}
@@ -1129,7 +1137,6 @@ a cryptographic link to the original task:
~~~json
{
"iss": "spiffe://bank.example/agent/operations",
"sub": "spiffe://bank.example/agent/operations",
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772150550,
"exp": 1772151150,
@@ -1137,11 +1144,13 @@ a cryptographic link to the original task:
"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",
"compensation_required": true,
"compensation_reason": "policy_violation_in_parent_trade"
"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"}
@@ -1160,27 +1169,32 @@ required checks were completed:
Agent A (Route Planning):
jti: task-001 par: []
exec_act: plan_route
pol: route_policy_v1 pol_decision: approved
ext.pol: route_policy_v1
ext.pol_decision: approved
Agent B (Customs):
jti: task-002 par: [task-001]
exec_act: validate_customs
pol: customs_policy_v2 pol_decision: approved
ext.pol: customs_policy_v2
ext.pol_decision: approved
Agent C (Safety):
jti: task-003 par: [task-001]
exec_act: verify_cargo_safety
pol: safety_policy_v1 pol_decision: approved
ext.pol: safety_policy_v1
ext.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
ext.pol: payment_policy_v3
ext.pol_decision: approved
System (Commitment):
jti: task-005 par: [task-004]
exec_act: commit_shipment
pol: commitment_policy_v1 pol_decision: approved
ext.pol: commitment_policy_v1
ext.pol_decision: approved
~~~
{: #fig-logistics title="Logistics Workflow with Parallel Tasks"}
@@ -1211,8 +1225,8 @@ 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., setting "pol_decision" in "ext" to "approved" without
actually evaluating the policy).
ECTs do not independently verify that:
@@ -1232,32 +1246,11 @@ evidence within a single ECT that the witnesses actually
observed the task. An issuing agent could list witnesses that
did not participate.
### Witness Attestation Model {#witness-attestation-model}
To address the self-assertion limitation of the
"witnessed_by" extension, witnesses SHOULD submit their
own independent signed ECTs to the audit ledger attesting to the
observed task. A witness attestation ECT:
- MUST set "iss" to the witness's own workload identity.
- MUST set "exec_act" to "witness_attestation" (or a domain-
specific equivalent).
- MUST include the observed task's "jti" in the "par" array,
linking the attestation to the original task.
- MUST set "pol_decision" to "approved" to indicate the witness
confirms the observation.
When a task's "witnessed_by" extension lists one or more
witnesses, auditors SHOULD verify that corresponding witness
attestation ECTs exist in the ledger for each listed witness. A
mismatch between the extension value and the set of independent
witness ECTs in the ledger SHOULD be flagged during audit review.
This model converts witness attestation from a self-asserted claim
to a cryptographically verifiable property of the ledger: the
witness independently signs their own ECT using their own key,
and the ledger records both the original task ECT and the witness
attestation ECTs.
To strengthen witness attestation beyond self-assertion, witnesses
SHOULD submit their own independent signed ECTs referencing the
observed task's "jti" in the "par" array. Auditors can then
cross-check the "witnessed_by" extension against independent
witness ECTs in the ECT store.
## Organizational Prerequisites
@@ -1409,8 +1402,8 @@ 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
- Policy evaluation outcomes (via "ext" keys "pol",
"pol_decision") when present, for compliance verification
- Timestamps ("iat", "exp") for temporal ordering
ECTs are designed to NOT reveal:
@@ -1426,18 +1419,14 @@ 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 "pol" extension key SHOULD reference policy identifiers
rather than embedding policy content.
The "compensation_reason" claim ({{compensation-claims}})
deserves particular attention: because it is human-readable and
may describe the circumstances of a failure or policy violation,
it risks exposing sensitive operational details. Implementations
SHOULD use short, structured reason codes (e.g.,
"policy_violation_in_parent_trade") rather than free-form
natural language explanations. Implementers SHOULD review
"compensation_reason" values for potential information leakage
before deploying to production.
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.
## Storage and Access Control
@@ -1540,16 +1529,16 @@ 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}} |
| compensation_required | Compensation Flag | IETF | {{compensation-claims}} |
| compensation_reason | Compensation Reason | IETF | {{compensation-claims}} |
| ext | Extension Object | IETF | {{extension-claims}} |
{: #table-claims title="JWT Claims Registrations"}
Note: Policy evaluation keys ("pol", "pol_decision",
"pol_enforcer") are carried within the "ext" object as
spec-defined extension keys ({{policy-claims}}) and do not
require separate JWT Claims registration.
## ECT Policy Decision Values Registry {#pol-decision-registry}
This document establishes the "ECT Policy Decision Values"
@@ -1704,14 +1693,15 @@ 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") and policy extension keys
("ext.pol", "ext.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.
4. Perform DAG validation (parent existence, temporal ordering,
cycle detection).
5. Append verified ECTs to the audit ledger.
5. If an audit ledger is deployed, append verified ECTs to it.
## Storage Recommendations
{:numbered="false"}
@@ -1787,7 +1777,6 @@ ECT Payload:
~~~json
{
"iss": "spiffe://example.com/agent/data-retrieval",
"sub": "spiffe://example.com/agent/data-retrieval",
"aud": "spiffe://example.com/agent/validator",
"iat": 1772064150,
"exp": 1772064750,
@@ -1795,10 +1784,12 @@ 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"
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"ext": {
"pol": "clinical_data_access_policy_v1",
"pol_decision": "approved"
}
}
~~~
@@ -1808,7 +1799,6 @@ task, and creates its own ECT:
~~~json
{
"iss": "spiffe://example.com/agent/validator",
"sub": "spiffe://example.com/agent/validator",
"aud": "spiffe://example.com/system/ledger",
"iat": 1772064160,
"exp": 1772064760,
@@ -1816,8 +1806,10 @@ task, and creates its own ECT:
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"exec_act": "validate_safety",
"par": ["550e8400-e29b-41d4-a716-446655440001"],
"pol": "safety_validation_policy_v2",
"pol_decision": "approved"
"ext": {
"pol": "safety_validation_policy_v2",
"pol_decision": "approved"
}
}
~~~
@@ -1841,7 +1833,6 @@ Task 1 (Spec Review Agent):
~~~json
{
"iss": "spiffe://meddev.example/agent/spec-reviewer",
"sub": "spiffe://meddev.example/agent/spec-reviewer",
"aud": "spiffe://meddev.example/agent/code-gen",
"iat": 1772064150,
"exp": 1772064750,
@@ -1849,10 +1840,12 @@ 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"
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"ext": {
"pol": "spec_review_policy_v2",
"pol_decision": "approved"
}
}
~~~
@@ -1861,7 +1854,6 @@ Task 2 (Code Generation Agent):
~~~json
{
"iss": "spiffe://meddev.example/agent/code-gen",
"sub": "spiffe://meddev.example/agent/code-gen",
"aud": "spiffe://meddev.example/agent/test-runner",
"iat": 1772064200,
"exp": 1772064800,
@@ -1869,8 +1861,10 @@ Task 2 (Code Generation Agent):
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "implement_module",
"par": ["a1b2c3d4-0001-0000-0000-000000000001"],
"pol": "coding_standards_v3",
"pol_decision": "approved"
"ext": {
"pol": "coding_standards_v3",
"pol_decision": "approved"
}
}
~~~
@@ -1879,7 +1873,6 @@ Task 3 (Autonomous Test Agent):
~~~json
{
"iss": "spiffe://meddev.example/agent/test-runner",
"sub": "spiffe://meddev.example/agent/test-runner",
"aud": "spiffe://meddev.example/agent/build",
"iat": 1772064260,
"exp": 1772064860,
@@ -1887,8 +1880,10 @@ Task 3 (Autonomous Test Agent):
"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"
"ext": {
"pol": "test_coverage_policy_v1",
"pol_decision": "approved"
}
}
~~~
@@ -1897,7 +1892,6 @@ Task 4 (Build Agent):
~~~json
{
"iss": "spiffe://meddev.example/agent/build",
"sub": "spiffe://meddev.example/agent/build",
"aud": "spiffe://meddev.example/human/release-mgr-42",
"iat": 1772064310,
"exp": 1772064910,
@@ -1905,9 +1899,11 @@ 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"
"out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc",
"ext": {
"pol": "build_validation_v2",
"pol_decision": "approved"
}
}
~~~
@@ -1916,7 +1912,6 @@ Task 5 (Human Release Manager Approval):
~~~json
{
"iss": "spiffe://meddev.example/human/release-mgr-42",
"sub": "spiffe://meddev.example/human/release-mgr-42",
"aud": "spiffe://meddev.example/system/ledger",
"iat": 1772064510,
"exp": 1772065110,
@@ -1924,10 +1919,10 @@ 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": {
"pol": "release_approval_policy",
"pol_decision": "approved",
"pol_enforcer": "spiffe://meddev.example/human/release-mgr-42",
"witnessed_by": [
"spiffe://meddev.example/audit/qa-observer-1"
]
@@ -1986,7 +1981,6 @@ Task 004 ECT payload:
~~~json
{
"iss": "spiffe://bank.example/agent/execution",
"sub": "spiffe://bank.example/agent/execution",
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772064250,
"exp": 1772064850,
@@ -1997,8 +1991,10 @@ Task 004 ECT payload:
"f1e2d3c4-0002-0000-0000-000000000002",
"f1e2d3c4-0003-0000-0000-000000000003"
],
"pol": "trade_execution_policy_v3",
"pol_decision": "approved"
"ext": {
"pol": "trade_execution_policy_v3",
"pol_decision": "approved"
}
}
~~~