key-cape/workplans/KEY-WP-0036-platform-factor-recovery.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
KEY-WP-0036	workplan	Audited platform administrator lost-factor recovery	infotech	key-cape	finished	codex	infotech	2026-09-13	2026-09-13	f9ba00a6-5758-5677-9a49-da1e35875f7a

Implements the provider part of P04 under USER-WP-0030-T03. The existing factor read credential is deliberately not elevated to recovery authority. Recovery now has a private signed-OIDC service and platform-only portal browser flow.

Implement bounded and audited provider recovery

id: KEY-WP-0036-T01
status: done
priority: high
state_hub_task_id: "f3287544-8412-5b1f-9d16-9f7b9e895ceb"

scripts/factor_recovery.py previews exact ownership and shared-identity scope, requires an operator verification attestation and matching metadata version, disables one factor with a row lock, requires pre-mutation audit durability, reads back state, records completion and reconciles retries. Reject changed or replaced factors and reference conflicts. Nine isolated unit tests pass, including replacement between disable and readback. The installed-provider Job provider-recovery-contract-02 passed real database and audit persistence, disable/readback and replay assertions in an isolated fixture. Acceptance CI includes both suites. No real user's factor was changed.

Validate the attended owner entry point

id: KEY-WP-0036-T02
status: cancel
priority: high
state_hub_task_id: "2d59da13-782e-5aeb-8957-69e41a15ddb1"

railiance-platform/scripts/keycape_factor_recovery.py derives actor from an OpenBao platform-admin entity, rejects root/workload substitutes, checks cluster identity, and emits only a private metadata receipt. Runbook: railiance-platform/docs/keycape-factor-recovery.md. Offline owner tests pass. Superseded: routine recovery now independently verifies the platform operator's signed KeyCape session through the private service. The extra OpenBao/Kubernetes operator front door is not part of the supported P04 journey; its native acceptance is cancelled rather than falsely marked passed. No credential handoff is pending.

Integrate platform support recovery with the browser journey

id: KEY-WP-0036-T03
status: done
priority: high
state_hub_task_id: "f7248d5e-6f68-5637-ada5-2527436f5f9e"

Implement an authenticated bounded recovery service and platform-only portal flow with fresh assurance, server-derived actor, CSRF, ownership-verification process, exact target/scope confirmation, audit/reference readback and safe retry. Never grant Kubernetes access to the portal. Test unauthorized/tenant admin denial, stale confirmation, provider failure, retry and replacement OTP enrollment using disposable identities. Mandatory-AAL2 access is restored only after possession of a replacement factor is proven. Keep P04 incomplete until browser success, failure and recovery paths pass; CLI tests alone do not close it.

Completion evidence: user-engine/docs/evidence/2026-09-13-p04-recovery.md. KeyCape d15f4dd and portal 11dfaf5 are released. Fifteen recovery tests, 219 portal regressions with PostgreSQL and 19 Chromium checks pass. Installed-provider provider-p04-contract-02 verifies signature/role/assurance denials, confirmation, audited mutation/retry/reference lookup and replacement OTP possession/login. Production health, anonymous/invalid-token denials, signing-key connectivity, rollout and new-enrollment policy readback pass. Positive mutation used disposable fixtures; no real account was changed. Provider and portal implement the same supported recovery contract; no outstanding P04 implementation remains. Broader policy/self-service and notification operations remain live under USER-WP-0030-T03 and KEY-WP-0035, not residuals of this bounded recovery plan.