tegwick
dd3ce4c109
secrets-engine confirmed T03, and re-verifying against the regenerated destroy fixture found something neither repository can fix alone: a pdp_digest recorded at issue time can never equal the request_digest of a request that carries the claim in its context, because the claim is part of the context that is hashed. Embedding the claim changes the very digest the claim would need to name. Not fixture staleness. It holds for every dual-control request whose claim travels in context -- the shape GH-DEC-2026-008 had just ruled mandatory. Left unresolved that ruling was unimplementable for exactly the case it was written for, and destroy would have been permanently un-allowable in production, failing closed forever on a check that could never pass. flex-auth owns the canonical request digest, so the fix is ours. binding.approval_binding_digest is the same material with context.approval removed, emitted only when a claim was carried. An approval issued against a claim-free Check records that Check's request_digest; the claim-bearing request reproduces it here. DELIBERATELY ADDITIVE, and the reason matters. The tempting fix is to drop context.approval from request_digest entirely. That is wrong: request_digest is the replay identity, and two requests differing only in which approval was presented must not share one, because their decisions differ -- one allows, the other denies dual_control_required. Collapsing them would let an allow obtained with a valid claim be replayed against a request carrying none. So request_digest still covers the claim and still moves; approval_binding_digest deliberately does not, and is documented as not a replay identity. The tests assert the two functions DISAGREE on a claim-bearing request, which is approval-engine's formulation of how to defend a distinction that looks like duplication. The fixture now demonstrates the property rather than asserting it: its claim's pdp_digest equals the envelope's approval_binding_digest with pdp_path true, and changing the claim's contents moved request_digest while leaving approval_binding_digest untouched. Two files a consumer can diff. Also picked up approval-engine's new required binding.pdp_path via the cross-repo schema test added yesterday -- which is the test doing exactly what it was built for, one day later. T03 is done. secrets-engine's own digest-material defect, which our two real envelopes caught, is recorded in the workplan. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JTbVXpEiXA7mNJVpDnEPcB Assistant: claude-code Assistant-Model: opus Assistant-Process: 412054@bnt-lap001 Assistant-Session: 3968fae1-8d59-4209-9bd6-c22594b8ab19
3.2 KiB
T03 replay fixtures
Real DecisionEnvelopes emitted from the published package, for secrets-engine
to verify its digest join (627810b) unchanged. FLEX-WP-0021-T03.
| File | From |
|---|---|
decision_rotate.json |
../check_request_allow_rotate.json — plain allow, empty context |
decision_destroy_dual_control.json |
../check_request_allow_destroy_dual_control.json — dual control, valid approval-claim |
Regenerate either with:
go run ./cmd/flex-auth check \
-policy examples/secrets-engine/policy_package.md \
-registry examples/secrets-engine/registry_snapshot.json \
-request examples/secrets-engine/check_request_allow_rotate.json
What is stable and what is not
Stable across runs — these are the fields to pin a contract test against:
| Field | rotate |
destroy |
|---|---|---|
binding.request_digest |
sha256:de67324f…4345 |
sha256:c749ee2…091a |
provenance.policy_package_digest |
sha256:fe0070b7…bd8c |
same |
provenance.registry_snapshot_digest |
sha256:f5a309bc…40bb |
same |
provenance.input_claim_digests.context |
absent (empty context) | sha256:8b73d29…2800 |
Verified identical across two runs.
| binding.approval_binding_digest | absent (no claim) | sha256:fa07bec…cd56 |
That last row is the value an approval's pdp_digest must equal — never
request_digest, which a claim can never match on the request that carries it.
It equals the request_digest of the same request with context.approval
removed, which is verifiable from this directory: strip the context from
../check_request_allow_destroy_dual_control.json, re-run check, and the
claim-free request digest is the same value (it denies dual_control_required,
which is the point).
This fixture verifies itself. The claim inside the request carries
binding.pdp_digest equal to the envelope's approval_binding_digest, and
binding.pdp_path: true. Compare the two values in the two files. Note that
request_digest moved when the claim's contents changed while
approval_binding_digest did not — that is the stability property, demonstrated
in the artifact rather than asserted in prose.
Not stable: id, provenance.decision_time, and lifetime.not_before /
lifetime.expires_at move with the clock. lifetime.ttl is 15m from the
package's allow_ttl. Do not pin the record as a whole.
input_claim_digests.context appears only when the request carries a non-empty
context — which is why both fixtures are here rather than just one. A consumer
asserting the field is always present would pass on destroy and fail on
rotate.
The destroy request's context.approval is a complete approval-claim,
valid against approval-engine/schemas/approval_claim.schema.json including the
now-required binding.pdp_digest. It was regenerated on 2026-09-06 when that
claim was completed, so its digests differ from the first emission — a partial
claim in a fixture is how a consumer learns the wrong shape.
Not a deployment
These come from flex-auth/local in standalone mode
(provenance.evaluator / mode), not from a cluster pin. No
flex-auth-secrets-engine pin exists yet (FLEX-WP-0021-T04), and the consumer
policy pin stays unset until T05.