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

70 lines
2.8 KiB
Markdown

---
id: KEY-WP-0036
type: workplan
title: "Audited platform administrator lost-factor recovery"
domain: infotech
repo: key-cape
status: active
owner: codex
topic_slug: infotech
created: "2026-09-13"
updated: "2026-09-13"
state_hub_workstream_id: "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
```task
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
```task
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
```task
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.