railiance-platform/workplans/RPF-WP-0035-credential-lane-implementation.md

---
id: RPF-WP-0035
type: workplan
title: "Implement reviewed credential lanes with separate owner gates"
domain: financials
repo: railiance-platform
status: blocked
owner: codex
created: "2026-09-05"
updated: "2026-09-10"
related:
  - RPF-WP-0032
  - RPF-WP-0033
  - RPF-WP-0034
state_hub_workstream_id: "975db491-5412-5e27-8e34-14a2417bb039"
---

# Credential lane implementation

One S3 queue for three designed lanes; each task keeps its own approval,
execution and closure boundary. This replaces the implementation tasks in the
three completed design workplans, not the designs themselves. No approval is
inherited by consolidation. INTENT binding: secure custody, dependable delivery,
stable consumer interfaces. Incident custody remains in RPF-WP-0027/0029.

## Consolidate completed designs and owner dependencies

```task
id: RPF-WP-0035-T01
status: done
priority: medium
state_hub_task_id: "0f3606bb-e95b-5484-8a57-bcdd6e3916fd"
```

Completed 2026-09-05. Preserved the three designs under
`docs/credential-lane-designs/`, identified native owner responsibilities and
linked each superseded task below. Owners have not been sent new requests and
no new external acceptance is claimed. STATE-WP-0085-T09 is already done;
the signing dependency belongs to the proposed FLEX-WP-0020-T05 cutover.

## Accept and provision secrets-engine service JWT login

```task
id: RPF-WP-0035-T02
status: wait
priority: high
state_hub_task_id: "e0c82ea9-05a5-537e-8fbf-67534263572e"
```

Supersedes RPF-WP-0032-T02. Design:
`docs/credential-lane-designs/secrets-engine-service-jwt.md`.

Platform owns the exact JWT mount/role/policy, effective-policy negative tests
and a metadata-only custody receipt. KeyCape owns issuer/JWKS and service
registration (KEY-WP-0009); secrets-engine owns service authentication and
authority consumption (SECRETS-WP-0008-T06, SECRETS-WP-0007-T04).

**Unblock:** confirmed HTTPS issuer/JWKS, exact claims and audience, consumer
readiness, approved source and attended apply authority. A service login does
not grant lane mutation authority. Do not build another identity provider or
lifecycle engine here.

**Done when:** approved exact role succeeds for the intended service, wrong
issuer/audience/subject/claims and unrelated secret access fail, bounded TTL
and revocation are proven, the consumer explicitly opts into the verified
contract, and rollback/cleanup receipts contain no secret material.

## Implement the platform operator-write CCR contract and Fluid lane

```task
id: RPF-WP-0035-T03
status: wait
priority: high
state_hub_task_id: "f47e5bc5-6f3c-54bb-aa35-260ad03892ba"
```

Supersedes RPF-WP-0033-T02. Design:
`docs/credential-lane-designs/fluid-telegram-operator-kv.md`.

Platform owns the per-path capability schema/validator, exact OpenBao policy
and accepted custody coordinates. MASON-WP-0005 owns construction coordination
and engine integration; KeyCape/NetKingdom own OIDC/MFA and group membership;
FT-WP-0002 owns client CAS, prefix correction, output containment and Telegram
application acceptance. Retain the existing read-only CCR semantics.

**Unblock:** accept tenant/path and per-entry field/capability matrix; confirm
actual group/assurance and callbacks, reviewed construction contract and writer
authority. Contract review can proceed without a live credential; the final
schema cannot be treated as accepted solely because a draft exists.

**Done when:** validation rejects broad/unsupported grants, the consumer proves
CAS=0 first-write behavior and no value output, approved identities can perform
only the exact matrix, negative/expiry/revocation checks pass, custody is seeded
through the separate writer, and the verified route has a safe handoff receipt.
The unattended adapter remains a separate demand and gets no operator session.

## Accept the needed signing lane and deliver it to the owning runtime

```task
id: RPF-WP-0035-T04
status: done
priority: medium
state_hub_task_id: "35a85846-61d5-54ce-8b18-ede45733d53c"
```

Supersedes RPF-WP-0034-T02. Design:
`docs/credential-lane-designs/state-hub-preflight-signing.md`.

Platform owns signing-key custody, exact read policy/role and scoped delivery
acceptance. State Hub owns API chart/env wiring, all-replica rotation fencing
and health. FLEX-WP-0020-T05 owns the rename preflight/cutover dependency;
STATE-WP-0085-T09's adoption-plan delivery is already complete.

**Unblock:** State Hub/repo-manager and the consuming migration owner confirm
that this transitional State Hub lane is still needed during retirement;
record the target runtime, namespace/SA/auth audience and an executable
rotation fence, plus approved writer and deployment window. Do not broaden the
lane into a general repository-rename authority or provision for a stale demand.

**Done when:** protected one-time generation, API-only ESO delivery, negative
access checks and a non-mutating signed preflight pass; every API replica uses
the accepted version; rotation/invalidation and recovery are evidenced. No
repository rename is part of S3 lane acceptance. If demand is withdrawn, record
the owning decision and cancel this task explicitly rather than provision it.

2026-09-05 continuation: verified the live primary cluster identity and healthy
single API replica; the signing ExternalSecret is still absent. Added a writer
guard against wrong-cluster kubeconfigs before any OpenBao access. The default
workstation kubeconfig's local port-forward listener was unavailable. Activation
still needs the contained attended OIDC/MFA login and the acceptance evidence
above; source preparation is not live completion. See
`history/2026-09-05-preflight-signing-activation-readiness.md`.


Completed 2026-09-05: user-led attended activation generated version 1 and
rotated to version 2 with every API replica stopped. Exact access and negative
identity checks passed; ESO delivery and API-only exposure passed; the recovered
single API replica accepts new signed preflight and rejects its predecessor by
signature, with healthy primary identity and no preflight blockers. State Hub
chart commit `49e3182`, Helm revision 59. No repository rename executed.
Evidence: `docs/evidence/RPF-WP-0035-T04-signing-activation-2026-09-05.json`;
closure: `history/2026-09-05-preflight-signing-activation-complete.md`.

## Admit KeyCape approval-engine client custody and delivery

```task
id: RPF-WP-0035-T05
status: done
needs_human: false
intervention_note: ""
priority: high
state_hub_task_id: "e15d62c9-e5da-5721-a135-87c050f7851c"
```

Answers KEY-WP-0013-T02 (State Hub message
`278a3ebe-b529-49f6-bd1a-e3ebcf318260`). Admission:
`docs/credential-lane-designs/keycape-approval-clients.md`; requests
`CCR-2026-0017` (secrets-engine-approval) and `CCR-2026-0018`
(approval-engine-operator).

Platform owns the two custody paths, exact-path read policies, Kubernetes auth
roles and the KeyCape-side ESO delivery. KeyCape owns the client registrations,
issuance, claim set and disablement; approval-engine owns approval semantics and
audit of emitted actions.

2026-09-08 admission response: both proposed KV paths confirmed unchanged; field
`client_secret` corrected to `CLIENT_SECRET` for the uppercase KV convention and
CCR validator. Kubernetes delivery references confirmed against the live `sso`
namespace, which already resolves `KEYCAPE_RAPP_QONTO_CLIENT_SECRET` through the
same `secretKeyRef{key: client-secret}` shape on image `main-153258b`. Attended
authority named as the governed `openbao-platform-admin-login` lane
(`founder_required`); KeyCape's refusal to treat its generic `warden plan`
database match as authorization was correct. Rollout agreed as one attended
session with the KeyCape reading build pinned but undeployed, ordered after the
Authelia issuer precondition in message `c8b1ad10-dae8-48fb-a0ea-7e2a101c54bf`.
Policies, ClusterSecretStores and ExternalSecrets are written and validated,
none applied.

**Unblock:** owner approval of both CCRs, a KeyCape image that reads both
environment names, the settled Authelia `iss` pin, and a founder-attended window
date. Verifier-side custody only — no client-side read lane is admitted, and no
scope beyond the two declared sets.

**Done when:** both CCRs are approved, the attended window seeds both KV paths
with CAS=0, policies/roles/stores/ExternalSecrets apply and sync, the KeyCape
build resolves both environment names, KeyCape evidences live JWKS signature and
exact claim bindings with excess scopes denied (operator `consume`, human
`consume`), platform evidences cross-path/wrong-identity/out-of-namespace denial,
and every receipt is metadata-only. If either registration is abandoned, KeyCape
disables it before the KV version is destroyed.

### 2026-09-08 actual upstream issuer returned

The admitted KeyCape one-shot probe verified the actual signed upstream issuer
as **`https://auth.coulomb.social`** at 21:44:44 UTC. Signature, audience,
validity window and nonce checks passed and the pinned Job exited 0. All
five temporary resources and the Pod were removed; normal KeyCape Deployment
and config Secret metadata are unchanged. See
`docs/evidence/2026-09-08-keycape-upstream-issuer-proof.json`.

T05's unknown-issuer input is resolved. The configuration owner still ensures
`authelia.issuer` equals that exact HTTPS value before the custody window.
Both CCRs remain proposed and await the named reviews; this probe grants no
custody mutation or client-side read. Keep the current authority preflight and
this signed-token proof as separate receipts. Live ESO/client/approval and
separate audit/client-side custody acceptance remain open.


2026-09-09 configuration and review-queue return: NetKingdom pinned the verified
HTTPS issuer, using an atomic UID/resourceVersion test and independent readback.
Secret revision `58713343`; unrelated configuration and signing key unchanged;
no Deployment rollout. Receipt: `docs/evidence/2026-09-09-keycape-upstream-issuer-pin.json`.

The two existing CCRs remain proposed. They now link to concrete pending review
decisions, with platform-operator and key-cape-owner named explicitly. See
`docs/credential-lane-designs/keycape-approval-clients-review.md`. T05 owns this
human dependency; HFACT consumes it without a duplicate approval request.
Custody/ESO activation, client verification and the separate client-side/audit
lanes remain open. Current CLI apply plans refuse the proposed requests.


2026-09-09 admission: the user explicitly approved both CCRs in the named
platform-operator and key-cape-owner roles. Both source requests are approved
and both linked Hub decisions are resolved. Receipt:
`docs/evidence/2026-09-09-keycape-approval-admission.json`. The completed review
intervention is cleared; T05 is progress while the contained first-provision
procedure is exercised and the admitted attended rollout is carried through.
Verifier-side scope, separate client-side/audit lanes and live acceptance remain
as defined in the reviewed requests.

2026-09-09 verifier-side return: both CCRs are verified after recorded user approval,
CAS=0 version-1 custody, native read/auth denials and revocation, Valid stores,
SecretSynced delivery, compatible KeyCape rollout and live positive/negative
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 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.

## Dispose of the ungoverned whynot-design npm duplicate

```task
id: RPF-WP-0035-T07
status: todo
priority: high
state_hub_task_id: "0dd7c9a5-65a0-53fc-b6c3-5ad96ee56f7b"
```

Found by the attended session on 2026-09-10 while settling the npm field
question. `secret/coulomb/whynot-design/npm/publish` exists at version 1,
created 2026-07-03T15:00:44Z and never updated — five days after the governed
lane at `platform/workloads/coulomb/whynot-design/npm-publish` was verified
(CCR-2026-0001, 2026-06-28). It sits outside that lane's exact-path policy and
outside any CCR here. Receipt:
`docs/evidence/2026-09-10-npm-lane-field-resolution.json`.

Only metadata was read. Its field names were not enumerated, its value was not
read, and nothing was deleted — a location holding real credential material is
disposed of deliberately, not tidied away in the session that found it.

The likely explanation, unconfirmed: secrets-engine reports the lane's field
under a lowercase name that is absent from the governed path, and their catalog
declares this legacy location. If their proven pilot publish read from here,
then a working production lane has been running off an ungoverned duplicate,
and the governed lane's acceptance evidence describes a path the consumer does
not use. That is worth establishing before anything is removed.

**Unblock:** secrets-engine confirms which location their publish actually reads
and whether the two hold the same value; the owner of the legacy path is
identified; and a metadata-or-field-name read of the legacy path is admitted so
the duplicate can be characterised without reading its value.

**Done when:** the legacy path's provenance and consumer are established, the
governed lane is confirmed as the one in use or the consumer is moved to it as a
reviewed lane change, the duplicate is destroyed or brought under a CCR with an
owner, and the disposition is recorded. If the value proves to be live and
ungoverned, treat it as an exposure with the same custody rules as RPF-WP-0027:
never record the value, fingerprint, length or shape.

## Admit the separate approval client-side readers

```task
id: RPF-WP-0035-T06
status: wait
priority: high
needs_human: false
intervention_note: ""
state_hub_task_id: "68bff751-e48b-548b-8fb4-dfb3b16210c2"
```

**Current return, 2026-09-10:** CCR-2026-0020 is cancelled on the requesting
Approval Engine owner's explicit withdrawal, source
`849c75bb094613ff6ac1a1d4cda56a745520c5a1:docs/keycape-service-registrations.md`.
No presenter exists and no reader is wanted. The validator now accepts terminal
cancellation of an incomplete request only with owner/source/reason evidence,
retained declared omissions and a disabled, non-resolvable front door. Apply
remains refused. No live identity, policy, role, custody or verifier was changed.
Human approval follows existing INFD-WP-0001-T07/T08; future service requesters
need a separate narrow registration, not this withdrawn bundle.

**Remaining unblock:** CCR-2026-0019 needs the exact authorized operator group
from NetKingdom/KeyCape, then reviewed attended file delivery and its scoped
positive/negative proof. Completed CCR-2026-0017/0018 remain closed. T06 stays
`wait`; its historical two-reader notes below are superseded for reader 2.

Consumer procedure returned in source, 2026-09-10:
`secrets-engine@98d72ceb1dbcff2d2a80fb8c3058d76777a0ac93:docs/approval-service-auth.md`
specifies the requested private 0700 runtime directory, 0600 file outside Git,
path-only use, claim/consume lifetime and attended cleanup including hard-stop
residual inspection. CCR-2026-0019 retains this source-review comment without
changing admission status. Exact group, required-owner review, attended apply and
native positive/negative/cleanup evidence remain. No role or credential changed.

Separate retained owner decision: KeyCape's 2026-09-10 return
`21427688-725f-4dea-aab4-7c78fd4328d2` identifies the already-live, unpresented
CCR-2026-0018 registration. Approval Engine, KeyCape and Platform must explicitly
decide retention/expiry or coordinated disablement. Reader cancellation neither
disables that live registration nor accepts indefinite retention. Keep this
disposition in T06; it is separate from the wanted CCR-2026-0019 factory reader.
No unilateral issuer/config/Secret change is authorized by this closeout.

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.

2026-09-09 preparation return: both exact-reader admissions are prepared as
`CCR-2026-0019` (secrets-engine) and `CCR-2026-0020` (approval-engine-operator),
with their exact-path read policies written and committed. Design:
`docs/credential-lane-designs/keycape-approval-client-side-readers.md`. Both
reuse existing version-1 custody; no reseed, rotation, shared reader or verifier
Secret reuse. Both are `in_flight` and unapproved; nothing is applied.

Read-only survey findings that decided the two shapes. Namespace
`secrets-engine` holds only ServiceAccount `secrets-engine` with no workload,
and `flex-auth/flex-auth-secrets-engine` is that consumer's PDP, not the
service; secrets-engine consumes the client secret through an operator-run CLI
reading `SECRETS_ENGINE_APPROVAL_CLIENT_SECRET_FILE` (SECRETS-WP-0009-T03,
revision `9eb07fd`). So reader 1 is an attended operator-workstation OIDC lane,
not an ESO lane. approval-engine has no namespace, workload or Service; its
manifest is unapplied, and no owner source names who presents the operator
client — approval-engine verifies these tokens and never holds them.

**Unblock:** reader 1 needs the exact NetKingdom/KeyCape group claim for the
authorized operator, plus secrets-engine confirming the file mode and removal
step; `openbao.auth` is declared missing rather than filled with a placeholder
that would later read as a confirmed binding. Reader 2 needs its owner to name
the presenting actor and placement, or to record that no client-side reader is
wanted so the request is cancelled. Naming a reader for the widest approval
scope without that decision is the failure this task exists to avoid.

**Done when:** each reader has a named actor and placement, a completed and
reviewed auth binding, admitted delivery, and its owner approvals; positive and
negative checks pass, including cross-path, wrong-identity and parent-list
denial and operator `consume` denial; or the request is explicitly cancelled by
its owner. Rotation stays a distinct version-guarded operation shared with
CCR-2026-0017/0018.


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:** each retained consumer admission is approved and implemented, or
its requesting owner explicitly cancels it (CCR-2026-0020 now satisfies that branch);
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

### 2026-09-09 tenant question resolved — no change needed

The `tenant:coulomb` / `tenant:platform` discrepancy raised against T02 is not a
discrepancy. KeyCape confirms decision `5ed3fb35-eca9-413a-82b9-95171ba85bf6`
binds the *approval chain* to the landlord zone and was applied to exactly two
registrations, `secrets-engine-approval` and `approval-engine-operator`.
`codex-railiance-platform` is not in that chain and correctly stays
`tenant:coulomb`, as do `secrets-engine-openbao` and the human directory default.
KEY-WP-0013-T04 records this and their
`TestServiceRegistrationTenantsAreExactPerDecision` pins every reviewed client's
tenant against the real fixture, so a reintroduced alias fails their build.

`docs/credential-lane-designs/secrets-engine-service-jwt.md` already says
`tenant:coulomb` and is therefore correct as written. Bind the exact role to
`tenant:coulomb`. Do not "correct" it to `tenant:platform` later; that would
break the issued claim.

SECRETS-WP-0008-T02 now records the local PIP claim/validation join implemented
and tested. Its remaining gate is the unreachable approval-engine claim endpoint
and access-engine Check (SECRETS-WP-0007-T04). Do not carry forward the old local
stub as a blocker. T02 still needs the accepted service issuer/JWKS, claims,
audience and consumer binding. T03 still needs confirmed operator group/tenant
and consumer semantics; T04 is already complete. No new owner acceptance inferred.


### 2026-09-08 attended capability preflight

HFACT-WP-0001's continued execution verified the existing first-provision
front door without provisioning anything. `warden plan` selected
`openbao-platform-admin-login` / founder_required / one oidc_login. The native
`scripts/openbao-attended-exec.py` supplied the existing WSL browser launcher;
a direct attempt had no launcher and failed before handoff. Its first revocation
result was unconfirmed and is preserved in the receipt rather than silently
reclassified. The two subsequent contained sessions completed self-revocation
and helper cleanup.

`scripts/keycape-approval-custody-preflight.py --receipt <new-private-file>` is
a silent, read-only command for that envelope. The installed Bao CLI supports
one path per `token capabilities` call; the final run used six single-path calls.
Create/update authority is present on both exact policy paths, both Kubernetes
auth-role paths and both KV data paths from CCR-2026-0017/0018. This is authority
metadata, not a secret-data read or policy/role/KV mutation. Receipt:
`docs/evidence/2026-09-08-keycape-approval-custody-preflight.json`.

T05 remains wait: both CCRs are still proposed, the actual upstream ID-token
issuer precondition remains open, and no verifier-side credential is provisioned.
Client-side retrieval and audit-sender custody are still separate owner returns.
The capability receipt is not a review approval or service readiness proof.