coulomb/gate-house
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Collect v0.8 assent findings; correct GH-DEC-2026-008 for implementability

Browse source 
Four findings returned so far, all from access-engine and
approval-engine. F1 is the serious one: GH-DEC-2026-008 as written
mandated a comparison that could never pass, because a claim travelling
inside a hashed request cannot name the digest of the request containing
it. A fail-closed consumer obeying it would have denied destroy
permanently — the ruling and its own fail-closed requirement compounded
rather than cancelled.

Ruling and its four obligations stand; the comparison target is corrected
to the PDP's published exclusion-scoped digest, verified in flex-auth's
schema and canonical.go before amending. A consumer must not guess the
exclusion rule, and until a PDP publishes one the path is fail-closed
rather than complete.

F2 adds the general property access-engine flagged as a near miss it was
not asking to have written: an evidence-bearing input may be excluded
from a correspondence digest but never from the replay identity.

The round record notes what this says about the process. GH-DEC-2026-008
was correct in substance, argued from doctrine, and verified against
another repository's schema before issue — and none of that caught a
defect three repositories found within hours of building on it.

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:
tegwick 2026-09-06 15:28:01 +02:00
parent 6f4bd56ee5
commit d97e8efa6e
3 changed files with 209 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

26
docs/contracts/approval-consumption.md
View file

@ -5,7 +5,7 @@
**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) and
`GH-DEC-2026-008` (the PDP digest is the binding correspondence)
`GH-DEC-2026-008` (the binding correspondence, amended for implementability)
**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`
@ -61,10 +61,26 @@ 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
**The correspondence is a digest, and it is the PDP's to define.** Amended by
`GH-DEC-2026-008`. A consumer on this path MUST verify that the approval's recorded
PDP digest equals the digest the PDP publishes **for the request with the approval
evidence excluded** — `binding.approval_binding_digest` in `access-engine` — and MUST
NOT use a claim carrying no such digest.
The comparison is **not** against the full request digest. Where the claim travels
inside the hashed request, embedding it changes that request's digest, so a digest
recorded at issue can never equal the final one: a hash cycle whose resolution is
forced, not chosen. The first form of this rule mandated a check that could never
pass, and a fail-closed consumer obeying it would have denied the action permanently.
A consumer MUST NOT guess the exclusion rule. A digest computed under an assumed rule
produces a confident wrong answer, and comparing two digests derived under different
rules fails open toward accepting a claim bound to a different request. Until a PDP
publishes its exclusion rule, this path is correctly fail-closed rather than complete.
An **evidence-bearing input may be excluded from a correspondence digest but never
from the replay identity** — two requests differing only in which approval was
presented decide differently, so one digest cannot serve both purposes. 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