fix(audit): retain authenticated consume identity and exact binding

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a140c4-354a-7823-8f0d-8f717397f786
This commit is contained in:
tegwick 2026-10-16 07:51:39 +02:00
parent 9491d1d3a7
commit 477c683991
6 changed files with 221 additions and 0 deletions

View file

@ -130,3 +130,32 @@ where the identities are the point. A consumer that wants the threshold reads
Distinctness itself is a storage invariant rather than a recomputation:
`entries` is UNIQUE on `(approval_id, subject_id)`, so a repeat approver is
refused at insert.
## Exact use provenance (source refinement, 2026-10-16)
New `approval.use` rows additionally retain `details.binding` (the native
five-field act), its existing `binding_digest`, nullable `pdp_digest` and
explicit `pdp_path`. `request_digest` remains the full decision-bound request,
and `decision_id` remains caller-supplied correlation, not a verified PDP verdict.
These distinct digests must never be substituted for each other.
`details.consumer` records the authenticated consume caller's `subject_id`,
`issuer`, `principal_type`, exact `tenant`, nullable verified `tenant_source` and
token-fingerprint `evidence_ref`. It comes solely from the HTTP authenticator;
body fields cannot override it. Top-level `actor` retains its existing meaning:
the actor captured on the approved act. Consumer provenance distinguishes the
service spending the object from that initiating actor. Bearer values, scopes,
roles and assurance are not copied into this record.
In-process calls without an authenticated caller record `consumer: null`.
Existing outbox rows remain unchanged; missing/null consumer evidence cannot be
backfilled as authenticated. Same-digest retries preserve the first use row and
never replace its original consumer or decision correspondence. All fields are
inserted atomically with the consumption CAS, survive restart, and pass unchanged
through the existing asynchronous audit adapter. No schema migration is needed.
This source evidence is not a portable signed receipt, execution grant or
server-identity proof. Consumer confirmation still uses the existing trusted
authenticated read/consume transport and a separate live execution journal.
Audit source admission, deployed issuer/profile, lifecycle readback and actual
served-PEP proof remain APPROVAL-WP-0002-T01/T04/T05 native gates.