Close the binding-correspondence gap as GH-DEC-2026-008
access-engine raised, and declined to solve locally, a hole in the split GH-DEC-2026-005 ruled on. approval-claim verification item 4 is a disjunction and neither limb delivers "approved for THIS request" on the PDP path: limb one requires translating between two engines' vocabularies and no mapping is published, limb two (pdp_digest) is optional. Where the digest is absent a consumer can hold valid_now true, receive an ALLOW, consume and act with nothing establishing that approval and decision concern the same action and target. Ruled: the PDP digest is the correspondence and is required on that path; a claim without one fails closed; the native limb survives only for consumers already in approval-engine's vocabulary, including T-06. No mapping is published — a translation can be wrong while still producing a confident answer, it fails open, it would be owned by neither engine, and recomputing another layer's binding is the re-derivation GH-DEC-2026-005 already forbids. The cost is stated: an approval issued without a bound CheckRequest is unusable on this path, which is correct behaviour. Also: adopted hub row b606e8ce as canonical for GH-DEC-2026-005 rather than registering a duplicate; recorded approval-engine's narrowing of the approver-threshold consequence (distinctness is a UNIQUE storage invariant, so the PEP stopped checking that the engine applied its own invariant, not whether dual control could be forged); and drafted A7/T08, a §11 marking obligation and §12 consumer rule for derived summaries, after four instances in one week across four repositories. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WtJBr77gMFLrN93iEevqQJ Assistant: claude-code Assistant-Model: opus Assistant-Process: 425128@bnt-lap001 Assistant-Session: f5944d8b-dac4-4e1a-87eb-8b3d8f314a63
This commit is contained in:
parent
865bab3955
commit
f0f888ca7e
4 changed files with 196 additions and 4 deletions
|
|
@ -4,7 +4,8 @@
|
|||
**PIP:** approval-engine
|
||||
**PDP:** access-engine (currently flex-auth)
|
||||
**Status:** normative for GH-WP-0002-T06; recorded as `GH-DEC-2026-003`,
|
||||
amended by `GH-DEC-2026-005` (step-1 artifact and split validation)
|
||||
amended by `GH-DEC-2026-005` (step-1 artifact and split validation) and
|
||||
`GH-DEC-2026-008` (the PDP digest is the binding correspondence)
|
||||
**Date:** 2026-09-06
|
||||
**Statute:** `net-kingdom/canon/standards/security-layer-model_v0.7.md` §9.4, §9.7.3–4, §16
|
||||
**Blocks:** `APPROVAL-WP-0001-T05`, `FLEX-WP-0017-T05`
|
||||
|
|
@ -60,6 +61,20 @@ claim.
|
|||
holds no runtime approval authority; the issuer to check is the engine that
|
||||
served the claim.
|
||||
|
||||
**The correspondence is the PDP digest.** Amended by `GH-DEC-2026-008`. A consumer
|
||||
on this path MUST verify that `claim.binding.pdp_digest` equals the decision's
|
||||
`NewDecisionBinding.request_digest`, and MUST NOT use a claim that carries no
|
||||
`pdp_digest`. Recomputing `approval-engine`'s native `binding.digest` from a
|
||||
`CheckRequest` is **not** a permitted fallback here: it requires translating between
|
||||
two engines' vocabularies, no mapping is published, and a wrong translation fails
|
||||
open by silently accepting a claim approved for something else. The native limb
|
||||
survives only for consumers already in `approval-engine`'s vocabulary, including the
|
||||
`T-06` assurance case.
|
||||
|
||||
Without this, `valid_now: true` plus an ALLOW establishes *approved* and *permitted*
|
||||
but never *approved for this request*, which is the property the binding exists to
|
||||
carry.
|
||||
|
||||
## Why consume is before the side effect
|
||||
|
||||
§9.7.3 says consumption MUST NOT be inferred from a decision record. That
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue