From 9f6d03850758e421cdbef950f8ffc4605c21cef4 Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 6 Sep 2026 14:52:29 +0200 Subject: [PATCH] Record what pdp_digest can and cannot cover 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 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 --- docs/approval-claim.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/docs/approval-claim.md b/docs/approval-claim.md index cec57ae..3a99d2d 100644 --- a/docs/approval-claim.md +++ b/docs/approval-claim.md @@ -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