docs: close verifier custody and track client admission residual

Assistant: codex
Assistant-Model: gpt-5.6-luna
Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
This commit is contained in:
codex 2026-09-09 07:06:05 +02:00
parent c6dc4286e2
commit 5679b86281

View file

@ -145,7 +145,7 @@ closure: `history/2026-09-05-preflight-signing-activation-complete.md`.
```task
id: RPF-WP-0035-T05
status: progress
status: done
needs_human: false
intervention_note: ""
priority: high
@ -235,10 +235,57 @@ service checks. Existing human OpenBao login passed again on the new image.
Receipt: `docs/evidence/2026-09-09-keycape-verifier-admission.json`. Failed attempts restored the compatible
configuration/image and detached delivery; final resume reused version 1.
T05 remains progress for the separately admitted client-side read lanes and
associated owner handoffs. Neither Warden fetch selector is resolvable through
these verifier-only CCRs. Do not re-request the completed two named reviews or
reseed these paths. Rotation is a distinct, version-guarded operation.
T05 is done against its verifier-only acceptance criteria. Its former
"remains progress for client-side reads" statement expanded the task past its
reviewed scope; that residual now has the live owner task RPF-WP-0035-T06 below.
Neither Warden fetch selector is resolvable through these verifier-only CCRs.
Do not re-request the completed two named reviews or reseed these paths.
Rotation is a distinct, version-guarded operation.
## Admit the separate approval client-side readers
```task
id: RPF-WP-0035-T06
status: todo
priority: high
needs_human: false
intervention_note: ""
```
Residual handoff from RPF-WP-0035-T05; consumes the completed verifier custody
without extending CCR-2026-0017/0018. Owner: railiance-platform with the named
secrets-engine and approval-engine operator consumers.
Prepare separate exact-reader admissions for existing version-1 paths:
`platform/workloads/secrets-engine/approval-client` and
`platform/workloads/approval-engine/operator-client`, field `CLIENT_SECRET`.
Name each actual actor/placement, bounded authentication/reader policy, protected
consumer delivery, cleanup/revocation and rollback, then obtain the required
owner reviews for those concrete requests. No reseeding, rotation, shared reader,
reuse of the sso verifier Secret, or implicit operator consume grant.
Consumer input supplied 2026-09-09: secrets-engine now implements per-request
`secrets-engine-approval` exchange from a protected temporary client-secret file,
with exact approval-engine / tenant:platform / read-or-consume scope, no token
file and no fallback. The pinned KeyCape image and actual Approval Engine source
passed its disposable component exercise; only the PDP was a sequencing double.
See `secrets-engine/docs/approval-service-auth.md` and the metadata receipt
`secrets-engine/docs/evidence/2026-09-09-approval-identity-exercise.json`.
Routing check: `warden route show keycape-secrets-engine-approval-client` is
unknown; generic `openbao-api-key` routes ownership only and is not a delegable
lane. Do not advertise a working fetch command before this task supplies its
own accepted native delivery return. Client-side admission is not ready for a
new human decision until exact requests and contained execution/rollback checks
are reviewable; the completed verifier reviews must not recur in that queue.
**Done when:** both separate consumer admissions are approved and implemented;
actual consumer authentication/delivery succeeds; sibling/listing/wrong-reader
and scope refusals plus reader expiry/revocation/cleanup are evidenced; version-1
custody and verifier availability remain intact. Return the source and metadata
receipts to HFACT-WP-0001-T03, SECRETS-WP-0009-T03 and APPROVAL-WP-0002-T01/T05.
Audit receiver/sender custody remains AUDIT-WP-0009-T09 and must not be folded
into this client-identity grant.
## Dependency review — 2026-09-06