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

id	type	title	domain	repo	status	owner	created	updated	related	state_hub_workstream_id
RPF-WP-0035	workplan	Implement reviewed credential lanes with separate owner gates	financials	railiance-platform	blocked	codex	2026-09-05	2026-09-08	RPF-WP-0032 RPF-WP-0033 RPF-WP-0034	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

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

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

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

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

id: RPF-WP-0035-T05
status: wait
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.

Dependency review — 2026-09-06

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.