State and precedence

The tables the implementation is written against. Where this document and the code

disagree, the code is wrong — every rule here has a test named after it in

endpoint/tests/.

1. Precedence when deciding what governs a sign-in

Evaluated in this order. The first rule that applies decides.

An expired pass_through_until falls through to rule 11, not to unrestricted login.

2. Precedence when Core cannot be reached

Evaluated in order, only for an intercepted path.

A completed exchange that returned 401, 403, 429 or any other protocol error takes none of

these branches: it is a decision from Core, or an authentication failure, and it denies.

3. Offline authorization refusals, in evaluation order

4. Policy snapshot commit

5. Denials

Recorded when a decision denies with a scope wider than attempt. An otp_incorrect

denial is attempt-scoped and is forgotten with the attempt.

Cleared only when all of these hold:

• the decision is not a deny;
• it names the scope in clear_denial_scopes;
• its policy_version is strictly greater than the version that recorded the denial;
• the subject matches (by Core identifier, or by SID for a user-scoped denial);
• it is bound to a fresh active attempt.

An ordinary allow clears nothing. A policy refresh at the same version clears nothing. A

late allow from an older version cannot defeat a newer denial. Core is required to

increment the device policy revision when it lifts a restriction, precisely so this rule

can be strict.

6. The attempt state machine

  Idle ──BeginValidation──▶ Validating ──┬── require_sms ─────▶ WaitingForCode
                                         ├── allow_password_only ─▶ AuthorizedOnce
                                         └── deny ───────────────▶ Denied

  WaitingForCode ──BeginVerification──▶ Verifying ──┬── allow_mfa ──▶ AuthorizedOnce
                                                    ├── incorrect, attempts remain
                                                    │              ──▶ WaitingForCode
                                                    └── otherwise ──▶ Denied

  Idle | Validating ──AuthorizeOffline──▶ AuthorizedOnce
        (grace · exception lease · tenant pass-through · bootstrap · not intercepted)

  AuthorizedOnce ──BeginSubmission──▶ SubmittingToWindows ──▶ Completed

  any ──Cancel──▶ Cancelled     any ──Fail──▶ Failed
  any ──OnCredentialChanged──▶ Idle, new generation, fresh nonce required

Invariants, each with a test:

• BeginSubmission succeeds exactly once per authorization. A second call is a conflict.
• AuthorizeOffline cannot produce mfa_verified. MFA success has exactly one source.
• AuthorizeOffline is unreachable from Verifying: once a code has been submitted, the

answer to this attempt is the verification result.

• A wrong Windows password does not leave a reusable approval. The next submission needs

fresh authorization.

• Cancelling before release consumes nothing, because nothing was released.

7. Authorization bases, and what each may be called

IsMfaSuccess() returns true for exactly one value. No report can aggregate an exception

with a verification, because the two never share a code path.

8. Trusted time

Now() is anchor_wall + monotonic_elapsed, never below the high-water mark. The wall

clock is read once, at construction: changing the system time mid-session moves nothing.

A wall clock more than 900 seconds behind the high-water mark latches

rollback_detected, which refuses all time-based offline authorization until a verified

server timestamp clears it. Ordinary NTP corrections and a VM resuming with a stale RTC

sit inside that tolerance.

What this does not do: it is not rollback resistance against an administrator who

restores a disk image or a VM snapshot. That would need a hardware or server mechanism

this MVP does not have, and the proposal says so in those words.