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](../../credential-change-requests/CCR-2026-0019-secrets-engine-approval-client-read.yaml)
and [CCR-2026-0020](../../credential-change-requests/CCR-2026-0020-approval-engine-operator-client-read.yaml).
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.