key-cape/workplans/KEY-WP-0036-platform-factor-recovery.md
tegwick 4d893ed3c2
All checks were successful
Authentication acceptance / acceptance (push) Successful in 1m6s
Authentication acceptance / provider-contract (push) Successful in 12s
Verify factor identity again after recovery mutation
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a092fe-13b1-7f12-ac74-7d258af4d79c
2026-09-13 17:30:23 +02:00

2.8 KiB

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 active 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 currently runs only as a provider-local operator procedure, not a portal API.

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: progress
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. Remaining: exercise the reviewed attended wrapper with a disposable provider identity and prove denied identity, preview, verified apply, audit and retry. Serialize owner operations until a concurrent authenticated service exists.

Integrate platform support recovery with the browser journey

id: KEY-WP-0036-T03
status: todo
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.