Record completed P04 recovery rollout and acceptance

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a092fe-13b1-7f12-ac74-7d258af4d79c
This commit is contained in:
tegwick 2026-09-13 21:19:13 +02:00
parent d15f4dde0b
commit a10c2f7f98

View file

@ -4,7 +4,7 @@ type: workplan
title: "Audited platform administrator lost-factor recovery"
domain: infotech
repo: key-cape
status: active
status: finished
owner: codex
topic_slug: infotech
created: "2026-09-13"
@ -14,7 +14,7 @@ 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.
now has a private signed-OIDC service and platform-only portal browser flow.
## Implement bounded and audited provider recovery
@ -38,7 +38,7 @@ fixture. Acceptance CI includes both suites. No real user's factor was changed.
```task
id: KEY-WP-0036-T02
status: progress
status: cancel
priority: high
state_hub_task_id: "2d59da13-782e-5aeb-8957-69e41a15ddb1"
```
@ -47,15 +47,16 @@ 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.
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
```task
id: KEY-WP-0036-T03
status: todo
status: done
priority: high
state_hub_task_id: "f7248d5e-6f68-5637-ada5-2527436f5f9e"
```
@ -68,3 +69,15 @@ 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.