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-10	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: 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

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

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.