2026-10-10 00:45:03 +02:00
# Attended MFA acceptance run: U05–
Prepared 2026-10-10 for the founder request relayed by ops-mason (hub message
ab89a591). It covers USER-WP-0028-T03 and USER-WP-0027-T04 and is gated by hub
decision cef97ccd (D10). The pilot is set in [mfa-pilot-decision.md ](mfa-pilot-decision.md ).
## What already exists
- **Enrollment surface.** privacyIDEA self-service runs at
`https://pink-account.coulomb.social/` (net-kingdom `sso-mfa/k8s/privacyidea` ).
Realm `coulomb` resolves every LLDAP user. Policy `totp-self-enrollment` lets
any user in that realm enroll, delete or disable their own TOTP token. Tokens
are labelled `{user}@{realm}` and issued as `Coulomb` , so the app shows
`tegwick@coulomb` .
- **Portal guidance.** `/security` explains setup, cancellation, a rejected
code and a lost authenticator. It also covers the no-factor-yet case. Until
`USER_ENGINE_MFA_MANAGEMENT_URL` is set, it says setup is unavailable and
points to the tenant administrator.
- **Recovery and replacement.** P04 recovery and P06 policy are deployed and
were verified with installed-provider fixtures
([P06 evidence ](evidence/2026-09-13-p06-authentication-policy.md )).
What is missing is a real person going through it, plus the portal handoff
link.
## Does tegwick need to join the coulomb-social pilot?
Not to enroll. Enrollment is per realm, not per client. Joining is needed only
to observe U05 and U07 on the pilot client, where MFA is optional. On
`openbao-admin` , KeyCape asks every user for an OTP, so password-only sign-in
2026-10-10 10:20:33 +02:00
(U05) cannot be observed there. **Decided (founder, 2026-10-10):** tegwick
runs on coulomb-social, so all four journeys run on one client. There is no
pilot member list. coulomb-social is a KeyCape client in realm `coulomb` , so
"joining" means tegwick signs in to coulomb-social once (U05). `openbao-admin` then serves as the second U07 check that ops-mason
2026-10-10 00:45:03 +02:00
needs (MASON-WP-0005-T05).
2026-10-10 10:20:33 +02:00
## Before the run (operator)
2026-10-10 00:45:03 +02:00
2026-10-10 12:41:16 +02:00
1. Done. `USER_ENGINE_MFA_MANAGEMENT_URL=https://pink-account.coulomb.social`
is live. Its apply home is `rapp-user-engine` `manifests/runtime.yaml` ; the
net-kingdom `sso-mfa/k8s/user-engine/runtime.yaml` is only migration input.
Verified on 2026-10-10: the public `https://users.coulomb.social/security`
shows *Manage authenticator app* pointing to pink-account.
2026-10-10 00:45:03 +02:00
2. Confirm tegwick has no active token: privacyIDEA admin token list for
`tegwick@coulomb` , token count only.
## Attended steps (tegwick at the keyboard, operator observing)
| Step | Journey | Where | Expected | Record |
| --- | --- | --- | --- | --- |
| 1 | U05 | coulomb-social sign-in | Password-only sign-in succeeds; no OTP prompt | time, client, outcome |
| 2 | U06 | portal `/security` → *Manage authenticator app* | Lands on pink-account; provider asks for the password; account shown is `tegwick` | time, account name seen (yes/no) |
| 3 | U06 cancel | pink-account → Enroll TOTP, then delete the pending token | Pending token removed; nothing reports enabled | outcome |
| 4 | U06 | pink-account → Enroll TOTP, scan, confirm with a current code | Token active; label `tegwick@coulomb` | token serial suffix only, status |
2026-10-11 23:02:23 +02:00
| 5 | U07 | close **all** private windows, new one, users.coulomb.social (user-engine-portal, enrollment-dependent MFA), then `openbao-admin` (ops-mason, CLI via tunnel) | OTP is asked and a current code completes sign-in; a wrong code is retried | outcome per client |
| 6 | U08 | portal `/security` → lost-authenticator guidance; operator (platform-root, own fresh MFA) uses `/platform/factor-recovery` (P04) | Operator disables the lost factor first (audited, attested); the user then re-enrolls on pink-account and proves a fresh login; no bypass link | recovery record id, outcome |
2026-10-10 00:45:03 +02:00
Steps 5 and 6 can be split. Once step 5 passes, reply to ops-mason (tegwick
has an active factor) and MASON-WP-0005-T05 can run. Step 6 may follow later.
2026-10-11 23:02:23 +02:00
> 2026-10-11 corrections after the first run: coulomb-social is `mfaRequired: false` by founder
> intent and never asks for OTP, so U07 runs on user-engine-portal. The P04 order is disable first,
> then re-enroll. See `docs/evidence/2026-10-11-mfa-attended-u05-u08.md`.
2026-10-10 00:45:03 +02:00
## Evidence rules
Record times, outcomes, client ids, token serial suffixes and recovery record
ids in `docs/evidence/<date>-mfa-attended-u05-u08.md` . **Never** record a seed,
a QR code or image, an OTP value, a password or a session cookie, and do not
take screenshots of the enrollment page. No step is inferred from a redirect,
a return parameter or an assurance claim.
## After acceptance
Keep `USER_ENGINE_MFA_MANAGEMENT_URL` set for all users. It covers every LLDAP
user in realm `coulomb` and every KeyCape client, because enrollment does not
depend on the client. MFA stays optional except where KeyCape already asks for
it (`openbao-admin` ).
Still deferred:
- admin-required MFA, which would be an issuer-side client policy applied
through P06 and needs the founder's go;
- showing authoritative enrollment status in the portal;
- a link from KeyCape's OTP prompt to `/security` for users who have no factor
yet. That page belongs to key-cape, and today it is the dead end tegwick hit.
## Hand-off
USER-WP-0028-T03, USER-WP-0027-T04 and decision cef97ccd close only on the
recorded evidence.
