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

Record what pdp_digest can and cannot cover

Browse source 
secrets-engine found that flex-auth hashes context into the request
digest while the dual-control pattern carries the claim in
context.approval, so a pdp_digest recorded at issue cannot equal the
digest of the request that carries the claim.

The resolution is forced by ordering rather than chosen: issue precedes
the decision, so pdp_digest is necessarily the digest of the underlying
action request before any claim is embedded in it. A claim cannot carry
the digest of a document containing that claim -- the value would have to
be known before it could be computed.

Record that, and record the limit of our authority: the exact exclusion
rule belongs to the PDP's digest contract, not here. This engine stores
what it was given at issue and does not compute it. Warn consumers not to
guess the exclusion, because comparing digests derived under different
rules fails open toward accepting a claim bound to a different request.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TvyJPAaVCGsVheVhcCwNND

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 411227@bnt-lap001
Assistant-Session: d566f6d3-bcaf-43c3-bc5e-3ddd0f64b535
This commit is contained in:
tegwick 2026-09-06 14:52:29 +02:00
parent 7e756773de
commit 9f6d038507
1 changed files with 24 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

24
docs/approval-claim.md
View file

@ -122,6 +122,30 @@ was not issued against a PDP decision — a stated fact rather than a missing
key, so a consumer cannot read absence as an oversight. It is not required on
every approval, because approvals legitimately exist that no decision preceded.
### What `pdp_digest` can and cannot cover
`pdp_digest` is recorded **at issue**, and issue precedes the decision — the
claim is step 1, the decision is step 2. So it is necessarily the digest of the
underlying action request *as it stands before any approval claim is embedded
in it*. That is not a design preference; it is forced by ordering. A claim
cannot carry the digest of a document that contains that claim: the value would
have to be known before it could be computed.
This matters because a PDP may hash `context` into its request digest while a
dual-control pattern carries the claim in `context.approval`. Embedding the
claim then changes the digest of the request carrying it, and a `pdp_digest`
recorded at issue will match neither the full request nor, necessarily, any
particular reconstruction of it.
The exact rule — which fields the PDP excludes when computing the digest a
claim is bound to, or whether the claim travels alongside the hashed context
rather than inside it — belongs to the PDP's digest contract, not here. This
engine records what it was given at issue and does not compute it. **A consumer
must not guess the exclusion.** Computing a digest under an assumed rule
produces a confident wrong answer, and comparing two digests derived under
different rules fails open in the direction of accepting a claim bound to a
different request.
### Declared path intent — `binding.pdp_path`
`GH-DEC-2026-008` requires `pdp_digest` on the `GH-DEC-2026-003` path. This