railiance-platform/docs/credential-lane-designs/keycape-approval-clients-review.md

KeyCape approval-client custody: review packet

Prepared 2026-09-09 by the-custodian. Both requests are proposed; no named approval or custody mutation has been recorded. This is the review gate for RPF-WP-0035-T05, consumed by HFACT-WP-0001-T03.

Request	Secret path and field	Client authority	Pending decision
CCR-2026-0017	platform/workloads/secrets-engine/approval-client, CLIENT_SECRET	approval:read, approval:consume	b533a271-b704-4c5c-98a2-9a5951aadfb6
CCR-2026-0018	platform/workloads/approval-engine/operator-client, CLIENT_SECRET	create/read/approve/revoke/supersede/observe/emit; no consume	efa90517-0cae-4eb6-a68d-5b0489c84d65

Both require platform-operator and key-cape-owner review. Each has its own exact-path policy, Kubernetes auth role and ClusterSecretStore, bound to external-secrets/external-secrets, limited to sso. ESO owns the resulting Secret; authentication tokens have a 15-minute TTL. Client secrets require explicit rotation or registration disablement; token expiry does not revoke them.

The approved object would authorize verifier-side custody only. Client-side retrieval, audit sender/receiver custody, operator approval:consume, adoption of the Qonto Secret and factory spending remain outside these two requests.

Technical review completed: both CCRs validate, their generated policies match the two source HCL files, and the delivery manifests map exactly to the declared paths and fields. The signed upstream issuer is verified; NetKingdom's exact live pin is independently read back at Secret revision 58713343. The compatible KeyCape image and rollout patch are prepared. These checks are evidence for the review, not substitutes for either named approval.

Execution still follows the owner rollout sequence through the founder-attended Warden/OpenBao envelope: policy/roles, CAS=0 initial custody, Valid stores, SecretSynced delivery, compatible config/image replacement, then positive and negative acceptance and metadata-only receipts. The generated plan leaves initial secret provisioning to the contained owner procedure; it is not an already exercised end-to-end activation command. Finish and exercise that procedure before opening the activation window. Current proposed requests refuse apply-plan; no status has been changed to get around that refusal.

Review outcome: approve, deny or needs changes, naming the reviewer and the role they are accepting. Both required role confirmations must be recorded for each CCR before execution. A generic CLI status change alone is insufficient evidence that both reviews occurred. No owner messages or browser login were triggered by preparation of this packet.