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
2.7 KiB
Decision-record contract
Status: published
Contract: flex-auth.decision-record.v1
Schema: ../schemas/decision_envelope.schema.json
Date: 2026-09-02
This is flex-auth's output artifact under the NetKingdom Security Layer Model v0.7 §17. Taxonomy holds only the shared field vocabulary. Consumers may rely on this schema.
A decision record is a DecisionEnvelope returned by POST /v1/check and the
CLI check / batch-check / list-allowed commands. Standalone evaluation
and every delegated adapter (Topaz, relationship, rule, Keycloak) emit the
same shape.
Required fields
| Field | Meaning |
|---|---|
id |
Deterministic decision identifier |
effect |
allow, deny, redact, audit_only, or not_applicable |
subject / resource |
Normalized refs the evaluator used |
provenance |
Who evaluated, over which policy and facts |
Contract fields consumers may rely on
| Field | Meaning |
|---|---|
contract_version |
flex-auth.decision-record.v1 |
binding |
Structured subject, action, resource, context, and request_digest |
binding.approval_binding_digest |
Present only when the request carried context.approval. The digest an approval's pdp_digest must equal — see canonical-request-digest.md. Not a replay identity |
lifetime |
Required on every allow. A TTL with not_before and expires_at |
provenance.policy_package / policy_version |
Named package pin |
provenance.policy_package_digest |
SHA-256 of package metadata plus compiled Rego |
provenance.registry_snapshot_digest |
SHA-256 of the canonical registry snapshot |
provenance.directory_etag |
Directory consistency token when a delegated directory was joined |
provenance.input_claim_digests |
SHA-256 per request-time claim class (context, caring_context) |
provenance.decision_time |
UTC timestamp used to compute lifetime |
reason, diagnostics, and CARING prose are not an authorization contract.
Allow lifetime
Every allow carries lifetime.kind = ttl. The duration comes from the policy
package allow_ttl field, or from the engine default of 15m when the package
omits it. A package that declares allow_ttl: none (or 0s) produces a deny
with reason allow_lifetime_unstated instead of a standing grant.
Replay is permitted only while lifetime.expires_at is still in the future.
See canonical-request-digest.md and
decision-input-freshness.md.
Versioning
This is contract version 1. Additive optional fields may appear. Removing or
redefining a required field requires a new contract_version value and a new
schema id.