From a10c2f7f983cf52834dd62e80b6f320cc1c2a637 Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 13 Sep 2026 21:19:13 +0200 Subject: [PATCH] Record completed P04 recovery rollout and acceptance Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a092fe-13b1-7f12-ac74-7d258af4d79c --- .../KEY-WP-0036-platform-factor-recovery.md | 27 ++++++++++++++----- 1 file changed, 20 insertions(+), 7 deletions(-) diff --git a/workplans/KEY-WP-0036-platform-factor-recovery.md b/workplans/KEY-WP-0036-platform-factor-recovery.md index b77b9f1..c2ea960 100644 --- a/workplans/KEY-WP-0036-platform-factor-recovery.md +++ b/workplans/KEY-WP-0036-platform-factor-recovery.md @@ -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.