railiance-platform/docs/credential-lane-designs/keycape-approval-client-side-readers.md

Approval client-side readers

RPF-WP-0035-T06, the residual handed over by the completed verifier custody (T05). Requests: CCR-2026-0019 and CCR-2026-0020. CCR-2026-0019 remains in_flight and unapproved. CCR-2026-0020 is cancelled on its requesting owner's explicit withdrawal; neither reader was applied.

Why this exists as separate requests

CCR-2026-0017/0018 admitted the verifier copies: KeyCape holds the two client secrets so it can authenticate credentials presented to it. Presenting them is a different power with a different holder, so it needs its own admission. The two Warden fetch selectors that the verifier review left unresolved are exactly this gap. Both readers use the existing version-1 custody — no reseed, no rotation, no shared reader, no reuse of the sso verifier Secrets.

Survey, 2026-09-09

Read-only, against owner source and the live cluster.

Question	Finding
Is there an in-cluster secrets-engine consumer?	No. Namespace secrets-engine holds only ServiceAccount secrets-engine and no workload. flex-auth/flex-auth-secrets-engine is the flex-auth PDP for that consumer, not the service.
How does secrets-engine consume the client secret?	Operator-run CLI reading SECRETS_ENGINE_APPROVAL_CLIENT_SECRET_FILE, exchanged for a fresh token before each request, held in memory only, no refresh token or fallback identity. Implemented 2026-09-09, SECRETS-WP-0009-T03, secrets-engine revision 9eb07fd.
Is approval-engine deployed?	No. No namespace, workload or Service. The owner manifest targets namespace approval-engine with a digest-pinned image and is unapplied.
Who presents approval-engine-operator?	Not identified by any owner source. approval-engine verifies these tokens and never presents them.

Reader 1 — secrets-engine-approval (CCR-2026-0019)

Shape is determined; one input is missing.

Item	Value
Path / field	platform/workloads/secrets-engine/approval-client / CLIENT_SECRET
Policy	workload-kv-read-secrets-engine-approval-client (exact data + metadata read, written and committed)
Auth	oidc on mount netkingdom, role secrets-engine-approval-client-read, standard three redirect URIs, scopes openid profile email groups, user_claim: sub, groups_claim: groups, ttl 15m
Front door	warden access secrets-engine-approval-client --out FILE
Delivery	Protected owner-only file outside any Git work tree, consumed as SECRETS_ENGINE_APPROVAL_CLIENT_SECRET_FILE, removed at end of session

Missing: the exact group claim for the authorized operator. NetKingdom and KeyCape own it; this repo and secrets-engine cannot supply it. The role cannot be created without it, so openbao.auth is declared missing rather than recorded with a placeholder that would later be mistaken for a confirmed binding.

This is an operator-workstation lane, not an External Secrets lane — because the consumer is a CLI, not a pod. A file-delivered credential outlives the process that read it, so removal depends on operator hygiene. That is weaker than the pod-lifetime bound of the verifier delivery and is recorded as a consequence of the consumer's shape rather than engineered away.

Reader 2 — approval-engine-operator (CCR-2026-0020)

Cancelled 2026-09-10. Approval Engine explicitly requests cancellation because no presenter exists and no client-side reader is wanted. Source: approval-engine@849c75bb094613ff6ac1a1d4cda56a745520c5a1, docs/keycape-service-registrations.md, operator withdrawal section. The retained exact-path policy is an unapplied historical artifact, not an admission. No role, credential delivery, rotation or verifier change follows.

Human approval belongs to informed-decision's PKCE client, INFD-WP-0001-T07/T08; a future service requester needs its own narrow registration under the existing Approval Engine owner work. Do not recreate the combined create/approve bundle. The completed CCR-2026-0018 verifier custody remains unchanged.

Not in scope

• No reseed or rotation of either custody path. Rotation is one version-guarded operation shared with the verifier copies and needs both owners.
• No approval:consume on the operator client, now or by later scope edit.
• No reuse of the sso verifier Secrets or the KeyCape verifier roles.
• No audit-sender custody; that stays with the existing owner records.