coulomb/secrets-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
secrets-engine/tests/fixtures/flex-auth-replay/decision_rotate.json

111 lines
3.5 KiB
JSON
Raw Normal View History

fix: exclude correlation fields from the flex-auth request digest Verified the digest join against flex-auth's T03 replay fixtures and found request_digest was hashing fields docs/canonical-request-digest.md excludes. The material is tenant, subject, action, resource, context only: id is correlation, policy_version lives in provenance, caring_context is hashed separately. This engine included all three when present. Because the join adopts the served request id, every real production request would have carried one, so the computed digest would have matched no issued decision and failed closed against every correct allow. Same unsatisfiable shape as the removed AUTHORITY constant. The old pinned constant was computed with the id inside the material, so it was wrong and its passing proved nothing. Replaced with fixture-driven tests over two real envelopes (vendored with provenance) plus a structural test that correlation fields do not move the digest. Both fixtures are needed: input_claim_digests.context appears only with a non-empty context. Also stops computing the native claim digest. The claim's binding.action and binding.target speak approval-engine's vocabulary while ours speaks the catalog's, and no mapping is published; flex-auth makes no cross-check and states the correspondence is ours via pdp_digest. A claim recording no pdp_digest now fails closed naming the missing mapping rather than comparing two different languages. That mapping is a prerequisite for destroy. 274 tests pass. Production still fails closed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M65ovP3eiiPHubibvWs9mD Assistant: claude-code Assistant-Model: opus Assistant-Process: 393550@bnt-lap001 Assistant-Session: 4bb359f9-1f12-4410-9e76-079cf23c82e4
2026-09-06 14:17:38 +02:00
{
fix: send the tenant the policy package scopes us to, and adopt v2 build_action_request emitted no tenant field at all. The deployed secrets-engine.catalog-lane.lifecycle v2 package reads known_tenant := "tenant:platform" request_tenant := object.get(input, "tenant", "") so an absent tenant is not an ignored field, it matches the wrong_tenant first-denial branch. Every gated action this engine sent would have been denied -- and the omission also produced a request_digest that could match no correctly issued decision, since tenant is hashed material. That is the same class of defect as hashing excluded fields, arriving from the other direction, and again only a real artifact exposed it. Found by answering the GLAS-WP-0015 tenant-alignment question instead of assuming the values lined up. - REQUEST_TENANT is pinned against the vendored allow envelopes, so a package retenanting fails a test rather than denying production. - An empty tenant is refused at build time. - Accepted policy version moves v1 -> v2. v1 had no tenant rule and failed open: a rotate under tenant:coulomb returned allow against the deployed package. flex-auth superseded rather than amended it, because a fail-open correction has to be visible as a version change. A test pins that a v1 decision is refused. - Vendored decision_wrong_tenant_deny.json as the denial evidence glas asked for, with tests that we refuse it on effect before anything else and that a deny legally carries no lifetime. docs/tenant-alignment.md states the three tenant values as this repo holds them. It does not resolve the JWT/store mapping: service_auth.TENANT is tenant:coulomb, which is exactly the value the package denies. That is either two layers sharing a namespace format or one wrong constant, and picking between them without an owner ruling is the fail-open shape GH-DEC-2026-008 rejected for action vocabularies. Both constants stay as they are, deliberately not unified. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E4tNMAYcSQmZWUE4wqP4ij Assistant: claude-code Assistant-Model: opus Assistant-Process: 715726@bnt-lap001 Assistant-Session: 80a42b32-cba6-4b23-8be0-68819b1a6092
2026-09-06 22:32:54 +02:00
"id": "decision:414734bb30381ff7",
fix: exclude correlation fields from the flex-auth request digest Verified the digest join against flex-auth's T03 replay fixtures and found request_digest was hashing fields docs/canonical-request-digest.md excludes. The material is tenant, subject, action, resource, context only: id is correlation, policy_version lives in provenance, caring_context is hashed separately. This engine included all three when present. Because the join adopts the served request id, every real production request would have carried one, so the computed digest would have matched no issued decision and failed closed against every correct allow. Same unsatisfiable shape as the removed AUTHORITY constant. The old pinned constant was computed with the id inside the material, so it was wrong and its passing proved nothing. Replaced with fixture-driven tests over two real envelopes (vendored with provenance) plus a structural test that correlation fields do not move the digest. Both fixtures are needed: input_claim_digests.context appears only with a non-empty context. Also stops computing the native claim digest. The claim's binding.action and binding.target speak approval-engine's vocabulary while ours speaks the catalog's, and no mapping is published; flex-auth makes no cross-check and states the correspondence is ours via pdp_digest. A claim recording no pdp_digest now fails closed naming the missing mapping rather than comparing two different languages. That mapping is a prerequisite for destroy. 274 tests pass. Production still fails closed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M65ovP3eiiPHubibvWs9mD Assistant: claude-code Assistant-Model: opus Assistant-Process: 393550@bnt-lap001 Assistant-Session: 4bb359f9-1f12-4410-9e76-079cf23c82e4
2026-09-06 14:17:38 +02:00
"contract_version": "flex-auth.decision-record.v1",
"request_id": "check:secrets-engine-rotate",
"effect": "allow",
"reason": "catalog_lane_policy_matched",
fix: send the tenant the policy package scopes us to, and adopt v2 build_action_request emitted no tenant field at all. The deployed secrets-engine.catalog-lane.lifecycle v2 package reads known_tenant := "tenant:platform" request_tenant := object.get(input, "tenant", "") so an absent tenant is not an ignored field, it matches the wrong_tenant first-denial branch. Every gated action this engine sent would have been denied -- and the omission also produced a request_digest that could match no correctly issued decision, since tenant is hashed material. That is the same class of defect as hashing excluded fields, arriving from the other direction, and again only a real artifact exposed it. Found by answering the GLAS-WP-0015 tenant-alignment question instead of assuming the values lined up. - REQUEST_TENANT is pinned against the vendored allow envelopes, so a package retenanting fails a test rather than denying production. - An empty tenant is refused at build time. - Accepted policy version moves v1 -> v2. v1 had no tenant rule and failed open: a rotate under tenant:coulomb returned allow against the deployed package. flex-auth superseded rather than amended it, because a fail-open correction has to be visible as a version change. A test pins that a v1 decision is refused. - Vendored decision_wrong_tenant_deny.json as the denial evidence glas asked for, with tests that we refuse it on effect before anything else and that a deny legally carries no lifetime. docs/tenant-alignment.md states the three tenant values as this repo holds them. It does not resolve the JWT/store mapping: service_auth.TENANT is tenant:coulomb, which is exactly the value the package denies. That is either two layers sharing a namespace format or one wrong constant, and picking between them without an owner ruling is the fail-open shape GH-DEC-2026-008 rejected for action vocabularies. Both constants stay as they are, deliberately not unified. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E4tNMAYcSQmZWUE4wqP4ij Assistant: claude-code Assistant-Model: opus Assistant-Process: 715726@bnt-lap001 Assistant-Session: 80a42b32-cba6-4b23-8be0-68819b1a6092
2026-09-06 22:32:54 +02:00
"matched_policy_version": "v2",
fix: exclude correlation fields from the flex-auth request digest Verified the digest join against flex-auth's T03 replay fixtures and found request_digest was hashing fields docs/canonical-request-digest.md excludes. The material is tenant, subject, action, resource, context only: id is correlation, policy_version lives in provenance, caring_context is hashed separately. This engine included all three when present. Because the join adopts the served request id, every real production request would have carried one, so the computed digest would have matched no issued decision and failed closed against every correct allow. Same unsatisfiable shape as the removed AUTHORITY constant. The old pinned constant was computed with the id inside the material, so it was wrong and its passing proved nothing. Replaced with fixture-driven tests over two real envelopes (vendored with provenance) plus a structural test that correlation fields do not move the digest. Both fixtures are needed: input_claim_digests.context appears only with a non-empty context. Also stops computing the native claim digest. The claim's binding.action and binding.target speak approval-engine's vocabulary while ours speaks the catalog's, and no mapping is published; flex-auth makes no cross-check and states the correspondence is ours via pdp_digest. A claim recording no pdp_digest now fails closed naming the missing mapping rather than comparing two different languages. That mapping is a prerequisite for destroy. 274 tests pass. Production still fails closed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M65ovP3eiiPHubibvWs9mD Assistant: claude-code Assistant-Model: opus Assistant-Process: 393550@bnt-lap001 Assistant-Session: 4bb359f9-1f12-4410-9e76-079cf23c82e4
2026-09-06 14:17:38 +02:00
"matched_rule": "catalog_lane_policy_matched",
"resource": {
"id": "lane:glas-primary",
"type": "secret-catalog-lane",
"system": "secrets-engine",
"tenant": "tenant:platform",
"attributes": {
"auth_targets": [],
"fields": [
"password"
],
"policy_targets": [],
"stage": "prod"
}
},
"subject": {
"id": "secrets-engine",
"type": "service",
"tenant": "tenant:platform",
"attributes": {
"description": "secrets-engine's own service identity, the single calling identity for the twelve gated catalog-lane actions it sends to POST /v1/check. Because it is the only subject, the package has no action_not_granted branch (FLEX-WP-0021-T02); registering a second identity is the revisit trigger.",
"display_name": "secrets-engine service principal",
"groups": [
"group:secrets-engine-lane-operators"
],
"organization_relation": "ServiceProvider",
"roles": [
"Operator"
]
}
},
"binding": {
"tenant": "tenant:platform",
"subject": {
"id": "secrets-engine",
"type": "service",
"tenant": "tenant:platform",
"attributes": {
"description": "secrets-engine's own service identity, the single calling identity for the twelve gated catalog-lane actions it sends to POST /v1/check. Because it is the only subject, the package has no action_not_granted branch (FLEX-WP-0021-T02); registering a second identity is the revisit trigger.",
"display_name": "secrets-engine service principal",
"groups": [
"group:secrets-engine-lane-operators"
],
"organization_relation": "ServiceProvider",
"roles": [
"Operator"
]
}
},
"action": "rotate",
"resource": {
"id": "lane:glas-primary",
"type": "secret-catalog-lane",
"system": "secrets-engine",
"tenant": "tenant:platform",
"attributes": {
"auth_targets": [],
"fields": [
"password"
],
"policy_targets": [],
"stage": "prod"
}
},
"request_digest": "sha256:de67324f54187055307a833235f83ced9fcd3a20952a27b3d19493ed39734345"
},
"lifetime": {
"kind": "ttl",
"ttl": "15m",
fix: send the tenant the policy package scopes us to, and adopt v2 build_action_request emitted no tenant field at all. The deployed secrets-engine.catalog-lane.lifecycle v2 package reads known_tenant := "tenant:platform" request_tenant := object.get(input, "tenant", "") so an absent tenant is not an ignored field, it matches the wrong_tenant first-denial branch. Every gated action this engine sent would have been denied -- and the omission also produced a request_digest that could match no correctly issued decision, since tenant is hashed material. That is the same class of defect as hashing excluded fields, arriving from the other direction, and again only a real artifact exposed it. Found by answering the GLAS-WP-0015 tenant-alignment question instead of assuming the values lined up. - REQUEST_TENANT is pinned against the vendored allow envelopes, so a package retenanting fails a test rather than denying production. - An empty tenant is refused at build time. - Accepted policy version moves v1 -> v2. v1 had no tenant rule and failed open: a rotate under tenant:coulomb returned allow against the deployed package. flex-auth superseded rather than amended it, because a fail-open correction has to be visible as a version change. A test pins that a v1 decision is refused. - Vendored decision_wrong_tenant_deny.json as the denial evidence glas asked for, with tests that we refuse it on effect before anything else and that a deny legally carries no lifetime. docs/tenant-alignment.md states the three tenant values as this repo holds them. It does not resolve the JWT/store mapping: service_auth.TENANT is tenant:coulomb, which is exactly the value the package denies. That is either two layers sharing a namespace format or one wrong constant, and picking between them without an owner ruling is the fail-open shape GH-DEC-2026-008 rejected for action vocabularies. Both constants stay as they are, deliberately not unified. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E4tNMAYcSQmZWUE4wqP4ij Assistant: claude-code Assistant-Model: opus Assistant-Process: 715726@bnt-lap001 Assistant-Session: 80a42b32-cba6-4b23-8be0-68819b1a6092
2026-09-06 22:32:54 +02:00
"not_before": "2026-09-06T18:35:18Z",
"expires_at": "2026-09-06T18:50:18Z"
fix: exclude correlation fields from the flex-auth request digest Verified the digest join against flex-auth's T03 replay fixtures and found request_digest was hashing fields docs/canonical-request-digest.md excludes. The material is tenant, subject, action, resource, context only: id is correlation, policy_version lives in provenance, caring_context is hashed separately. This engine included all three when present. Because the join adopts the served request id, every real production request would have carried one, so the computed digest would have matched no issued decision and failed closed against every correct allow. Same unsatisfiable shape as the removed AUTHORITY constant. The old pinned constant was computed with the id inside the material, so it was wrong and its passing proved nothing. Replaced with fixture-driven tests over two real envelopes (vendored with provenance) plus a structural test that correlation fields do not move the digest. Both fixtures are needed: input_claim_digests.context appears only with a non-empty context. Also stops computing the native claim digest. The claim's binding.action and binding.target speak approval-engine's vocabulary while ours speaks the catalog's, and no mapping is published; flex-auth makes no cross-check and states the correspondence is ours via pdp_digest. A claim recording no pdp_digest now fails closed naming the missing mapping rather than comparing two different languages. That mapping is a prerequisite for destroy. 274 tests pass. Production still fails closed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M65ovP3eiiPHubibvWs9mD Assistant: claude-code Assistant-Model: opus Assistant-Process: 393550@bnt-lap001 Assistant-Session: 4bb359f9-1f12-4410-9e76-079cf23c82e4
2026-09-06 14:17:38 +02:00
},
"diagnostics": {
"action": "rotate",
"matched_relationship": "",
"policy_package": "secrets-engine.catalog-lane.lifecycle",
"policy_status": "ready",
"registry_resource": false,
"registry_subject": true
},
"provenance": {
"evaluator": "flex-auth/local",
"mode": "standalone",
"policy_package": "secrets-engine.catalog-lane.lifecycle",
fix: send the tenant the policy package scopes us to, and adopt v2 build_action_request emitted no tenant field at all. The deployed secrets-engine.catalog-lane.lifecycle v2 package reads known_tenant := "tenant:platform" request_tenant := object.get(input, "tenant", "") so an absent tenant is not an ignored field, it matches the wrong_tenant first-denial branch. Every gated action this engine sent would have been denied -- and the omission also produced a request_digest that could match no correctly issued decision, since tenant is hashed material. That is the same class of defect as hashing excluded fields, arriving from the other direction, and again only a real artifact exposed it. Found by answering the GLAS-WP-0015 tenant-alignment question instead of assuming the values lined up. - REQUEST_TENANT is pinned against the vendored allow envelopes, so a package retenanting fails a test rather than denying production. - An empty tenant is refused at build time. - Accepted policy version moves v1 -> v2. v1 had no tenant rule and failed open: a rotate under tenant:coulomb returned allow against the deployed package. flex-auth superseded rather than amended it, because a fail-open correction has to be visible as a version change. A test pins that a v1 decision is refused. - Vendored decision_wrong_tenant_deny.json as the denial evidence glas asked for, with tests that we refuse it on effect before anything else and that a deny legally carries no lifetime. docs/tenant-alignment.md states the three tenant values as this repo holds them. It does not resolve the JWT/store mapping: service_auth.TENANT is tenant:coulomb, which is exactly the value the package denies. That is either two layers sharing a namespace format or one wrong constant, and picking between them without an owner ruling is the fail-open shape GH-DEC-2026-008 rejected for action vocabularies. Both constants stay as they are, deliberately not unified. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E4tNMAYcSQmZWUE4wqP4ij Assistant: claude-code Assistant-Model: opus Assistant-Process: 715726@bnt-lap001 Assistant-Session: 80a42b32-cba6-4b23-8be0-68819b1a6092
2026-09-06 22:32:54 +02:00
"policy_version": "v2",
"policy_package_digest": "sha256:bd11c5fe77ce6439c65fea225ad6b71d2110efc5e7b5bc9b499c59cd0a53b8b4",
fix: exclude correlation fields from the flex-auth request digest Verified the digest join against flex-auth's T03 replay fixtures and found request_digest was hashing fields docs/canonical-request-digest.md excludes. The material is tenant, subject, action, resource, context only: id is correlation, policy_version lives in provenance, caring_context is hashed separately. This engine included all three when present. Because the join adopts the served request id, every real production request would have carried one, so the computed digest would have matched no issued decision and failed closed against every correct allow. Same unsatisfiable shape as the removed AUTHORITY constant. The old pinned constant was computed with the id inside the material, so it was wrong and its passing proved nothing. Replaced with fixture-driven tests over two real envelopes (vendored with provenance) plus a structural test that correlation fields do not move the digest. Both fixtures are needed: input_claim_digests.context appears only with a non-empty context. Also stops computing the native claim digest. The claim's binding.action and binding.target speak approval-engine's vocabulary while ours speaks the catalog's, and no mapping is published; flex-auth makes no cross-check and states the correspondence is ours via pdp_digest. A claim recording no pdp_digest now fails closed naming the missing mapping rather than comparing two different languages. That mapping is a prerequisite for destroy. 274 tests pass. Production still fails closed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M65ovP3eiiPHubibvWs9mD Assistant: claude-code Assistant-Model: opus Assistant-Process: 393550@bnt-lap001 Assistant-Session: 4bb359f9-1f12-4410-9e76-079cf23c82e4
2026-09-06 14:17:38 +02:00
"registry_snapshot_digest": "sha256:f5a309bc0b36721fd6d9ad7f53eb21222162bc2eac62a0ab0802a9a1d51340bb",
fix: send the tenant the policy package scopes us to, and adopt v2 build_action_request emitted no tenant field at all. The deployed secrets-engine.catalog-lane.lifecycle v2 package reads known_tenant := "tenant:platform" request_tenant := object.get(input, "tenant", "") so an absent tenant is not an ignored field, it matches the wrong_tenant first-denial branch. Every gated action this engine sent would have been denied -- and the omission also produced a request_digest that could match no correctly issued decision, since tenant is hashed material. That is the same class of defect as hashing excluded fields, arriving from the other direction, and again only a real artifact exposed it. Found by answering the GLAS-WP-0015 tenant-alignment question instead of assuming the values lined up. - REQUEST_TENANT is pinned against the vendored allow envelopes, so a package retenanting fails a test rather than denying production. - An empty tenant is refused at build time. - Accepted policy version moves v1 -> v2. v1 had no tenant rule and failed open: a rotate under tenant:coulomb returned allow against the deployed package. flex-auth superseded rather than amended it, because a fail-open correction has to be visible as a version change. A test pins that a v1 decision is refused. - Vendored decision_wrong_tenant_deny.json as the denial evidence glas asked for, with tests that we refuse it on effect before anything else and that a deny legally carries no lifetime. docs/tenant-alignment.md states the three tenant values as this repo holds them. It does not resolve the JWT/store mapping: service_auth.TENANT is tenant:coulomb, which is exactly the value the package denies. That is either two layers sharing a namespace format or one wrong constant, and picking between them without an owner ruling is the fail-open shape GH-DEC-2026-008 rejected for action vocabularies. Both constants stay as they are, deliberately not unified. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E4tNMAYcSQmZWUE4wqP4ij Assistant: claude-code Assistant-Model: opus Assistant-Process: 715726@bnt-lap001 Assistant-Session: 80a42b32-cba6-4b23-8be0-68819b1a6092
2026-09-06 22:32:54 +02:00
"decision_time": "2026-09-06T18:35:18Z"
fix: exclude correlation fields from the flex-auth request digest Verified the digest join against flex-auth's T03 replay fixtures and found request_digest was hashing fields docs/canonical-request-digest.md excludes. The material is tenant, subject, action, resource, context only: id is correlation, policy_version lives in provenance, caring_context is hashed separately. This engine included all three when present. Because the join adopts the served request id, every real production request would have carried one, so the computed digest would have matched no issued decision and failed closed against every correct allow. Same unsatisfiable shape as the removed AUTHORITY constant. The old pinned constant was computed with the id inside the material, so it was wrong and its passing proved nothing. Replaced with fixture-driven tests over two real envelopes (vendored with provenance) plus a structural test that correlation fields do not move the digest. Both fixtures are needed: input_claim_digests.context appears only with a non-empty context. Also stops computing the native claim digest. The claim's binding.action and binding.target speak approval-engine's vocabulary while ours speaks the catalog's, and no mapping is published; flex-auth makes no cross-check and states the correspondence is ours via pdp_digest. A claim recording no pdp_digest now fails closed naming the missing mapping rather than comparing two different languages. That mapping is a prerequisite for destroy. 274 tests pass. Production still fails closed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M65ovP3eiiPHubibvWs9mD Assistant: claude-code Assistant-Model: opus Assistant-Process: 393550@bnt-lap001 Assistant-Session: 4bb359f9-1f12-4410-9e76-079cf23c82e4
2026-09-06 14:17:38 +02:00
},
"caring": {
"profile": "caring-0.4.0-rc2",
"conformance_findings": [
{
"code": "CARING-DESCRIPTOR-MISSING",
"severity": "warning",
"message": "no CARING descriptor matched the request",
"fields": [
"caring_context"
]
}
]
}
}
Reference in a new issue Copy permalink