coulomb/key-cape
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Implement audited lost-factor recovery and track remaining P04 acceptance
All checks were successful
Authentication acceptance / acceptance (push) Successful in 58s
Details
Authentication acceptance / provider-contract (push) Successful in 14s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a092fe-13b1-7f12-ac74-7d258af4d79c
This commit is contained in:
tegwick 2026-09-13 17:28:45 +02:00
parent 244e7e096f
commit 3b7df9047e
5 changed files with 229 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

70
workplans/KEY-WP-0036-platform-factor-recovery.md Normal file
View file

@ -0,0 +1,70 @@
---
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. Eight isolated unit tests pass.
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.