Record completed P04 recovery rollout and acceptance

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a092fe-13b1-7f12-ac74-7d258af4d79c

docs/evidence/2026-09-13-p04-recovery.md

@@ -0,0 +1,63 @@
+# P04 administrator recovery release — 2026-09-13
+
+P04 is implemented and deployed. Entry: https://users.coulomb.social/platform/factor-recovery.
+A platform operator signs in with MFA within five minutes, enters the exact
+directory login and support reference, reviews one factor and shared-identity
+scope, and attests that the person's ownership was verified through the support
+process. A missing attestation denies the operation; the software does not
+pretend a checkbox independently proves ownership.
+
+Recovery disables one selected factor and preserves password, directory identity,
+tenant access and other factors. Provider audit persists before mutation; stale
+state, changed ownership and conflicting references are rejected. PostgreSQL
+advisory locking serializes recovery requests; row locking protects the selected
+factor and a final fingerprint protects readback. Retries reconcile completion.
+Check recovery result by support reference if the page or response was lost;
+the original administrator can obtain a fresh confirmation for an interrupted
+operation. A completed receipt is rechecked against current provider state.
+
+The private provider-side service independently verifies RS256 signature, exact
+KeyCape issuer and portal audience, human platform-operator role and fresh AAL2
+assurance. Actor comes from the signed subject. Confirmation tickets bind actor,
+target, version, realm, support reference and expiry. Portal sessions retain the
+signed ID token server-side; it is never rendered into HTML or receipts. The
+portal receives no provider credentials or Kubernetes permissions. Network policy
+permits the recovery endpoint only from portal pods. Public signing-key access
+is separately scoped. No OpenBao owner handoff is needed for routine recovery.
+
+The user then signs in to https://pink-account.coulomb.social with their own
+password, enrolls a replacement TOTP, proves possession and tests a fresh
+application login. The live `keycape-confirm-totp-enrollment` policy requires
+possession confirmation for new TOTP enrollments in coulomb. Existing factors
+were not changed. KeyCape already requires confirmed enrollment and OTP evidence
+before AAL2. Recovery does not automatically relax application MFA policy.
+
+## Release and verification
+
+- Portal source: 11dfaf5 (including 58e07dd).
+- Portal image: forgejo.coulomb.social/coulomb/user-engine@sha256:86112f2f0bb6388344d0260a3611da2a19c609b8f08bd79858d51e1a271e5fa6.
+- Provider service source: key-cape d15f4dd (including cb51584).
+- Immutable service code: mfa/factor-recovery-626517ff9acb0ef7.
+- Provider image: ghcr.io/gpappsoft/privacyidea-docker@sha256:af7841adad262f129e0c1d4f553af13f21cb2f4dc713533f316cfe43ed0b4473.
+- net-kingdom deployment procedure: sso-mfa/k8s/privacyidea/deploy-factor-recovery.py;
+  possession policy: enable-factor-confirmation.py. Cluster and deployment UID
+  checks plus resource-version preconditions protect rollout targets.
+- 219 portal regression tests passed with disposable PostgreSQL, no skips.
+- 15 recovery core/service tests passed, including lost-confirmation reconciliation.
+- 19 isolated Chromium checks passed, including P04 role denial, scope/proof
+  confirmation, completion receipt and replacement instructions.
+- Installed-provider Job provider-p04-contract-02 passed signed administrator
+  recovery, wrong role/audience, stale MFA, unsigned requests, unknown-user
+  isolation, tampered confirmation, durable audit, retry, reference readback,
+  replacement possession and authentication. Its databases, identities, JWT
+  signing key and OTP seeds were disposable fixtures, not production accounts.
+- Exact source CI passed: KeyCape run60; portal runs161/162/163.
+- Both deployments completed rollout. Live portal health/readiness returned 200;
+  anonymous recovery page returned 403 with sign-in recovery navigation. Native
+  portal-to-provider health returned 200; missing/invalid authentication returned
+  403. Provider signing-key access and policy readback passed.
+
+No real user's authenticator was disabled for testing. Production authenticated
+recovery was not exercised against a real account; positive mutation and browser
+acceptance used disposable fixtures. P05 service operations and P06 broader
+policy/self-service work remain USER-WP-0030-T03; P04 is removed from that gap.