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
|
|
|
# flex-auth T03 replay fixtures
|
|
|
|
|
|
|
|
|
|
Copied verbatim from `flex-auth/examples/secrets-engine/replay/` (commit
|
|
|
|
|
`9e10d1c`, `FLEX-WP-0021-T03`). Real `DecisionEnvelope`s emitted by the
|
|
|
|
|
published `secrets-engine.catalog-lane.lifecycle` v1 package via
|
|
|
|
|
`go run ./cmd/flex-auth check`, from `flex-auth/local` in `standalone` mode.
|
|
|
|
|
|
|
|
|
|
Vendored so the digest contract test is hermetic. Regenerate upstream and
|
|
|
|
|
re-copy if the contract version changes.
|
|
|
|
|
|
feat: bind the destroy gate to approval_binding_digest and pdp_path
The vocabulary mapping this path was waiting on is not coming: gate-house
rejected it in GH-DEC-2026-008, because a translation can be confidently
wrong and fails open by accepting a claim approved for a different action.
The stronger option arrived instead, and both halves are enforced here.
flex-auth published binding.approval_binding_digest (FLEX-DEC-2026-007) to
fix the circularity this repo reported: a pdp_digest recorded at issue time
can never equal the request_digest of the request that carries the claim in
its hashed context, so with GH-DEC-2026-008 requiring that equality, destroy
would have failed closed forever on a check no correct record could pass.
- authorization.approval_binding_digest implements the published exclusion
rule, including Go's context,omitempty behaviour when stripping empties
the context; digest_material drops an empty context for the same reason.
- validate_decision_envelope recomputes the field rather than trusting it,
refuses a claim-bearing request whose decision records none, and compares
the claim's digest from step 1 against it -- never against request_digest,
which still covers the claim so it stays a sound replay identity.
- validate_approval_claim requires binding.pdp_path true before using
pdp_digest at all. Path intent is never inferred from a digest that
happens to be present; pre-schema-v3 approvals carry pdp_path false
regardless of any digest they hold.
Replay fixtures re-vendored from dd3ce4c. The destroy pins moved a second
and final time; approval_binding_digest did not, which is the point. The
fixture now demonstrates the property instead of asserting it: we rederive
fa07becf... from its own request through our canonical implementation,
proving we hash the same material flex-auth does rather than pinning a
constant we cannot reproduce.
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 20:39:59 +02:00
|
|
|
Re-copied 2026-09-06 (twice, both upstream regenerations):
|
|
|
|
|
|
|
|
|
|
1. commit `9f3e7e3` completed the approval-claim on `context.approval`. Because
|
|
|
|
|
`context` is hashed material, completing the claim moved the request digest.
|
|
|
|
|
2. commit `dd3ce4c` (`FLEX-DEC-2026-007`) published
|
|
|
|
|
`binding.approval_binding_digest` and set the embedded claim's
|
|
|
|
|
`binding.pdp_digest` to it with `binding.pdp_path` true. The request digest
|
|
|
|
|
moved once more with the claim's contents; the approval-binding digest did
|
|
|
|
|
**not**, which is the property the fixture now demonstrates rather than
|
|
|
|
|
asserts.
|
|
|
|
|
|
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
|
|
|
3. commit `d98323b` published **v2**, which adds the `input.tenant` rule v1
|
|
|
|
|
never had, and a third fixture: `decision_wrong_tenant_deny.json`. The
|
|
|
|
|
request digests did **not** move — every allow fixture already carried
|
|
|
|
|
`tenant: tenant:platform` — but `provenance.policy_version` is now `v2` and
|
|
|
|
|
`policy_package_digest` moved to `sha256:bd11c5fe…`.
|
|
|
|
|
|
|
|
|
|
`decision_rotate.json` carries no `approval_binding_digest` — the field is
|
|
|
|
|
omitted on claim-free decisions rather than duplicated onto them, and a test
|
|
|
|
|
pins that omission.
|
|
|
|
|
|
|
|
|
|
`decision_wrong_tenant_deny.json` is an `effect: deny` envelope and carries no
|
|
|
|
|
`lifetime`, which is legal: the schema requires `lifetime` only for an allow.
|
|
|
|
|
It is the wrong-tenant denial evidence `GLAS-WP-0015` asked for. Do not
|
|
|
|
|
lifetime-refresh it in tests.
|
|
|
|
|
|
|
|
|
|
**v1 must not be pinned.** It had no tenant rule and failed open; flex-auth
|
|
|
|
|
superseded rather than amended it so the change is visible in the version
|
|
|
|
|
string. See `docs/tenant-alignment.md`.
|
2026-09-06 14:20:16 +02:00
|
|
|
|
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
|
|
|
**Pinned here** (stable across runs, per the upstream README):
|
feat: bind the destroy gate to approval_binding_digest and pdp_path
The vocabulary mapping this path was waiting on is not coming: gate-house
rejected it in GH-DEC-2026-008, because a translation can be confidently
wrong and fails open by accepting a claim approved for a different action.
The stronger option arrived instead, and both halves are enforced here.
flex-auth published binding.approval_binding_digest (FLEX-DEC-2026-007) to
fix the circularity this repo reported: a pdp_digest recorded at issue time
can never equal the request_digest of the request that carries the claim in
its hashed context, so with GH-DEC-2026-008 requiring that equality, destroy
would have failed closed forever on a check no correct record could pass.
- authorization.approval_binding_digest implements the published exclusion
rule, including Go's context,omitempty behaviour when stripping empties
the context; digest_material drops an empty context for the same reason.
- validate_decision_envelope recomputes the field rather than trusting it,
refuses a claim-bearing request whose decision records none, and compares
the claim's digest from step 1 against it -- never against request_digest,
which still covers the claim so it stays a sound replay identity.
- validate_approval_claim requires binding.pdp_path true before using
pdp_digest at all. Path intent is never inferred from a digest that
happens to be present; pre-schema-v3 approvals carry pdp_path false
regardless of any digest they hold.
Replay fixtures re-vendored from dd3ce4c. The destroy pins moved a second
and final time; approval_binding_digest did not, which is the point. The
fixture now demonstrates the property instead of asserting it: we rederive
fa07becf... from its own request through our canonical implementation,
proving we hash the same material flex-auth does rather than pinning a
constant we cannot reproduce.
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 20:39:59 +02:00
|
|
|
`binding.request_digest`, `binding.approval_binding_digest`,
|
|
|
|
|
`provenance.policy_package_digest`, `provenance.registry_snapshot_digest`, and
|
|
|
|
|
the presence/absence of `provenance.input_claim_digests.context`.
|
|
|
|
|
|
|
|
|
|
`approval_binding_digest` is not only pinned but **rederived** by
|
|
|
|
|
`test_pdp_digest_equals_the_published_approval_binding_digest`: our canonical
|
|
|
|
|
implementation must reproduce it from the fixture's own request. A pin asserts
|
|
|
|
|
the constant; rederiving it proves we hash the same material flex-auth does.
|
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
|
|
|
|
|
|
|
|
**Never pin:** `id`, `provenance.decision_time`, `lifetime.not_before`,
|
|
|
|
|
`lifetime.expires_at` — all move with the clock.
|