Vord

Enhancement Proposal

Proposal: Account recovery and contact verification

A security-posture review found that the most-attacked identity flow has no design: account recovery / password reset, and proof-of-control of an email or phone. This proposal specs them within the existing architecture — they are Modgud (ADR-0009) ceremonies built on the authentication-method (ADR-0015), session (ADR-0016), revocation (ADR-0005), and event-stream (ADR-0022) seams, and add only a versioned principal-record extension permitted by ADR-0011. No new architecture; no ADR required.

Motivation

The recovery flow is the #1 account-takeover vector in real identity systems — it routinely bypasses MFA and is the attacker's path around strong login. Contact verification (proving control of an email/phone) is what stops trivial impersonation at registration and on contact change. Both are entirely absent, and this is sharpest for CIAM at scale.

Design

  • Contact verification. At registration and on any email/phone change, control is proven by a single-use, short-TTL, rate-limited verification code/link issued at Modgud. A contact is unverified until proven; verified contacts are an optional, versioned extension to the principal record (ADR-0011's extension rule) — not a schema fork.
  • Recovery methods, by per-realm policy (ADR-0012): a verified-contact reset link/code; recovery codes (one-time, generated at MFA enrollment, ADR-0020); and audited admin-assisted recovery (ADR-0021). Phone/SMS is allowed only as a verified contact, never the primary reset channel (SIM-swap risk), and the choice is a realm risk decision.
  • Recovery never silently lowers assurance. A reset re-establishes a factor; it does not skip an MFA requirement. The resulting token carries the actual acr/amr reached (ADR-0015/0020) — a recovery that yields lower assurance is stamped as such, so Vör enforces step-up for sensitive operations rather than being fooled.
  • A completed reset invalidates the past. On reset, existing sessions are ended and live tokens revoked (ADR-0016/0005), so an attacker holding a pre-reset session cannot ride the recovered account.
  • Everything is an event (ADR-0022): recovery and verification are high-signal for abuse detection, and are rate-limited / anti-automated together with registration (proposal 0006).

Alternatives considered

  • SMS as the primary reset channel — rejected (SIM-swap, SMS interception); phone is a verified contact only.
  • Knowledge-based "security questions" — rejected (guessable, public-record, breach-reused).

Graduation criteria

A reset requires proven contact control and is rate-limited; completing a reset ends existing sessions and revokes live tokens; recovery never bypasses a realm's required assurance. Abuse-case tests (ADR-0028): a reset without contact proof is rejected; a reset invalidates prior sessions/tokens; recovery to a lower factor yields a lower acr.

Backward compatibility

Adds a versioned principal-record extension (verified contacts) under ADR-0011's versioning rule; no token-format or API-contract change.

Open questions

  • Per-realm phone/SMS risk posture and whether SMS is offered at all.
  • Recovery-code storage (hashed like other verify-only secrets — proposal 0004).