proposed core.sign-in

Decide a sign-in, one round at a time

A transport hands the engine a round: the transaction so far, an answer, and the realm, the client and the request the round is for. The engine reads the realm's and the client's MFA policy, runs the hooks of the limiters, the request checks and the bot challenge, takes the identifier from the request's login_hint or from an answer, and asks for the password. Until a factor succeeds, every answer is the same for every account: an unknown identifier, a password-only, passkey-only, disabled or locked account all get the password step again with invalid_credentials, after one Argon2id verification and the 500 ms floor. A correct password fixes the subject; an account whose address is not proved yet then verifies it with an emailed code, whatever REQUIRE_VERIFIED_ACCOUNT says; the sign-in completes when the account's strongest bound factor and the MFA policy are met, and the transport then mints the session or the code. A right password on the realm's breach list, or an update the account owes, first asks for a new password, after a mailed code when the password is the account's only factor. A different identifier in a later round ends the transaction.

What this view shows

one sign-in transaction of the engine, round by round, from the transport's call to the engine's answer, with the identifier and password steps.

Open world: what is not drawn here is not ruled out. Only the guarantees below are binding.

Left out of this view:

the transport's own checks and client authentication (rules 1 and 2 of ADR-017 Decision 4), its wire, and what it mints once the engine answers complete: a browser session (the Interaction API) or an authorization code (the FiPA endpoint)
what the hooks decide inside: the limiters (#636), the request checks (#628, #665), the bot challenge and its captcha step (#643), the ladder's waits, counts and disable ceiling (#615); with no hook registered, each one lets the round through
the steps drawn by their own flows: passkeys, passkey-first, the downgrade rule and the enrolment offer (flows/core/passkey, #651), registration (#640), reset (#642), recovery codes (#649); and TOTP (#653), until which an MFA policy that requires a second factor answers a redirect
the rounds of the inline verification, drawn by flows/core/account-verification: the code, its mail through the send caps, its ladder, its expiry and its burn. An engine built without email codes, which no transport of the auth server is, refuses an unverified account under REQUIRE_VERIFIED_ACCOUNT like a wrong password instead
the per-transaction budgets of the FiPA auth_session (#647): rounds and failures per step
the forced update's screens, which the CER issue adds as this flow's ui.yaml; and the legacy /auth/login and /ui/login, which keep their own rules (flows/core/sign-in-token, flows/core/sign-in-page) and check no breach list until the browser sign-in runs on this engine (#709)
the second factor an account has, which it answers before the forced update (TOTP, #653): until its step exists the engine answers a redirect; an account with a passkey proves it by the downgrade rule before the update (#651)
how the breach list is checked: the operator's local list (BREACHED_PASSWORD_LIST_PATH), loaded at boot and again when its file changes, matched by the password's SHA-1; or a k-anonymity range lookup through the egress client to the operator's host (BREACHED_PASSWORD_RANGE_URL), which carries the first five hex characters of that SHA-1 and nothing else of the password
the rounds of the forced update's new password: each runs rules 3 to 8 again first, as drawn above, and this graph draws what follows them
the required actions other than update_password (setup_mfa, setup_passkey, complete_profile): the steps of PRO-28 and PRO-29
a store failure while an audit record is written: the round fails, and the transport answers it as a failed round of its own
a password answer outside the password step's answer schema (an empty password, one over 256 UTF-16 code units) is refused as a request fault when the password step is next, and ignored like any other answer otherwise; it verifies nothing and counts nothing
an answer to a step the engine did not ask for, a password_reset answer included, is ignored with its login_hint; only the identifier and password answers carry one
a failure of the password verifier or of the identifier key refuses the round as unavailable, alike for every identifier; a failure to settle the ladder's reservation is reported and changes no answer; a failure to write the identifier's audit record leaves the identifier unfixed, so the next round records it
a later round of a transaction whose subject is fixed reads the account again: one that is gone, belongs to another user or was disabled since ends the transaction, audited under the subject; another user's proof does too, whatever that user's state
a step refused before the transaction holds any identifier (a bot challenge, a discoverable passkey from #651) is audited naming nobody
the transaction is not sealed, so the transport keeps it server-side under an unguessable handle bound to the realm and the client. Before anything else a round ends one that is not well formed, belongs to another realm or client, begins more than a minute in the future or is older than two hours, audited as transaction_invalid or transaction_expired naming nobody
a factor that names its account by itself (a discoverable passkey, #651), answered while the transaction holds an identifier, must prove the account that identifier names; another account ends the transaction as subject_mismatch

The main story

When: The authorization request carries no login_hint, an enabled, verified account whose only factor is its password, the answered password is the account's, REQUIRE_VERIFIED_ACCOUNT is on, the default; an unverified account is verified inline, neither the realm nor the client requires a second factor for this account: the default until the policy has its storage (Foundations, the admin console), the realm checks no breach list: password.breachListSource is off, the default, the account holds no update_password required action, the realm's password policy accepts it, and it is not on the realm's breach list or the realm checks none, every hook lets the round through, the transport does not serve the captcha step, the provider can issue a challenge and check its answer, every identifier a round brings is the one the transaction holds, after normalisation.

Wait for the first round: the first round carries no answer
Read the realm's and the client's MFA policy: the policy is read
Ask the limiters (rule 3): the limiters let the round through
Ask the transport's request checks (rule 4): the request checks let the round through
Ask whether a bot challenge is due (rule 5): no bot challenge is due
Take the identifier (rule 6): no identifier is held and the round brings none; a password answer is ignored, with no verification and no failure counted, and the floor is waited out
Ask for the identifier: the person types the identifier
Read the realm's and the client's MFA policy: the policy is read
Ask the limiters (rule 3): the limiters let the round through
Ask the transport's request checks (rule 4): the request checks let the round through
Ask whether a bot challenge is due (rule 5): no bot challenge is due
Take the identifier (rule 6): the transaction holds the identifier
Pick the first factor (rule 7): the round answered the identifier, or nothing; the floor is waited out
Ask for the password: the person types the password
Read the realm's and the client's MFA policy: the policy is read
Ask the limiters (rule 3): the limiters let the round through
Ask the transport's request checks (rule 4): the request checks let the round through
Ask whether a bot challenge is due (rule 5): no bot challenge is due
Take the identifier (rule 6): the transaction holds the identifier
Pick the first factor (rule 7): the round answers the password step, the one the engine asks for
Reserve the attempt on the ladder: the attempt is reserved
Read what the password needs of the account the identifier names: the account is read, or none holds the identifier
Verify the password, at the cost of one Argon2id verification for every account: the password is right and the realm checks no breach list: the attempt settles as a success, the subject is fixed, auth_time is now, and the step is audited with the user as its subject; nothing is checked or sent anywhere
Read the whole account the password proved

Result: Read the whole account the password proved.

The flow

Show failure paths and “the user closes the page”

blue line: the main storyred dashed line: a failure path (shown with “Show failure paths”)dotted line: decided by a rule, nobody actsdashed grey box: the server decides, nothing is showndouble border: another flow

What each step answers

Step	The outside world sees
Ask for the identifier offeringIdentifier	kind: step · body: {"current":{"step":"identifier","params":{}},"alternatives":[],"personal":{}}
Ask for the password offeringPassword	kind: step · body: {"current":{"step":"password","params":{}},"alternatives":[],"personal":{"identifier":"the transaction's identifier"}}
Ask for the password again passwordRefused	kind: step · body: {"current":{"step":"password","params":{},"error":"invalid_credentials"},"alternatives":[],"personal":{"identifier":"the transaction's identifier"}}
Ask for a new password offeringNewPassword	kind: step · body: {"current":{"step":"new_password","params":{"purpose":"update_required","min_length":"the realm's password.minLength","max_length":256}},"alternatives":[],"personal":{"identifier":"the transaction's identifier"}}
Ask for a new password again newPasswordRefused	kind: step · body: {"current":{"step":"new_password","params":{"purpose":"update_required","min_length":"the realm's password.minLength","max_length":256,"reasons":"why the new password was refused"},"error":"password_rejected"},"alternatives":[],"personal":{"identifier":"the transaction's identifier"}}
Complete the sign-in completed	kind: complete · body: {"transaction":null,"subject":"the account's user id","identifier":"the transaction's identifier, normalised","amr":"[\"pwd\"], from the step grammar's transactionAmr over the verified steps","authTime":"when the password was verified, in epoch milliseconds"}
Ask for the account's passkey passkeyOwed	kind: continue · body: {"next":"flows/core/passkey, from afterFirstFactor"}
Continue elsewhere redirected	kind: redirect · body: {"reason":"step_not_available","transaction":null}
End the transaction ended	kind: refused · body: {"reason":"transaction_ended","transaction":null}
Refuse a round of the inline verification for the send caps or the email-code ladder verificationThrottled	kind: refused · body: {"reason":"throttled","retryAfterSeconds":"the send cap's or the email-code ladder's"}
End the transaction for a burned code or an account that changed verificationEnded	kind: refused · body: {"reason":"transaction_ended","transaction":null}
Refuse the round for a limiter throttled	kind: refused · body: {"reason":"throttled","retryAfterSeconds":"the limiter's"}
Refuse the round inside the ladder's wait lockedOut	kind: refused · body: {"reason":"throttled","retryAfterSeconds":"the ladder's"}
Refuse the round for the request checks requestRefused	kind: refused · body: {"reason":"request_refused","code":"the check's code, such as unmet_authentication_requirements"}
Offer the bot challenge botChallengeDue	kind: step · body: {"current":{"step":"captcha","params":"the provider's: the built-in proof of work's challenge and difficulty, or a hosted provider's name and site key"},"alternatives":[],"personal":{}}
Refuse a malformed answer answerRefused	kind: refused · body: {"reason":"invalid_answer"}
Refuse the round while a store is down unavailable	kind: refused · body: {"reason":"unavailable"}

How it decides what happens next

Ask the limiters (rule 3)

#	If	Then
1	a limiter refuses the round; the floor is waited out	Refuse the round for a limiter
2	the limiters let the round through	Ask the transport's request checks (rule 4)

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`limited`	`throttled`	163840 of 1228800
2	otherwise	`checkingRequest`	1064960 of 1228800

limited: gate == 'limited'

Ask the transport's request checks (rule 4)

#	If	Then
1	the request checks refuse the round; the floor is waited out	Refuse the round for the request checks
2	the request checks let the round through	Ask whether a bot challenge is due (rule 5)

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`requestRefused`	`requestRefused`	163840 of 1064960
2	otherwise	`checkingBotChallenge`	901120 of 1064960

requestRefused: gate == 'requestRefused'

Ask whether a bot challenge is due (rule 5)

#	If	Then
1	a bot challenge is due and no provider can answer it: refused, never waved through	Refuse the round while a store is down
2	a bot challenge is due; any other answer is ignored, and the floor is waited out	Offer the bot challenge
3	a bot challenge is due and the transport does not serve the captcha step: the round goes on, under the delay and the 429 of the limiters and the ladder alone, never a redirect	Take the identifier (rule 6)
4	no bot challenge is due	Take the identifier (rule 6)

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`challengeUnanswerable`	`unavailable`	40960 of 901120
2	`challengeOffered`	`botChallengeDue`	40960 of 901120
3	`botChallengeDue`	`takingIdentifier`	163840 of 901120
4	otherwise	`takingIdentifier`	655360 of 901120

botChallengeDue: gate == 'botChallengeDue'
challengeOffered: gate == 'botChallengeDue' and captchaServed and challengeProvider == 'answers'
challengeUnanswerable: gate == 'botChallengeDue' and captchaServed and challengeProvider == 'down'

Take the identifier (rule 6)

#	If	Then
1	the answer's login_hint is not an identifier (an email address of at most 254 bytes); nothing is verified or counted	Refuse a malformed answer
2	the round brings another identifier than the one the transaction holds, or the request's and the answer's differ: the transaction ends, and subject_mismatch is audited under the identifier HMAC	End the transaction
3	no identifier is held and the round brings none; a password answer is ignored, with no verification and no failure counted, and the floor is waited out	Ask for the identifier
4	the transaction holds the identifier	Pick the first factor (rule 7)

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`malformedAnswer`	`answerRefused`	163840 of 819200
2	`identifierMismatch`	`ended`	163840 of 819200
3	`noIdentifier`	`offeringIdentifier`	81920 of 819200
4	otherwise	`choosingFirstFactor`	409600 of 819200

malformedAnswer: answer == 'malformed'
identifierMismatch: differentIdentifier and ((identifierHeld and roundBringsIdentifier) or (loginHint == 'given' and answerBringsIdentifier))
noIdentifier: not identifierHeld and not roundBringsIdentifier

Pick the first factor (rule 7)

#	If	Then
1	the round answers the password step, the one the engine asks for	Reserve the attempt on the ladder
2	the round answered the identifier, or nothing; the floor is waited out	Ask for the password

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`passwordAnswered`	`reservingAttempt`	143360 of 286720
2	otherwise	`offeringPassword`	143360 of 286720

passwordAnswered: answer in ['password', 'passwordWithHint']

Verify the password, at the cost of one Argon2id verification for every account

#	If	Then
1	no usable password: the dummy hash is verified, the attempt settles as a failure, invalid_credentials is audited under the identifier HMAC, and the floor is waited out	Ask for the password again
2	the password is wrong; the attempt settles as a failure, audited under the identifier HMAC	Ask for the password again
3	the password is right and the user is disabled: refused like a wrong password, audited as account_disabled under the identifier HMAC; no subject is fixed and the user is not changed	Ask for the password again
4	the password is right: the attempt settles as a success, and the realm's breach list is checked	Check the right password against the realm's breach list
5	the password is right and the realm checks no breach list: the attempt settles as a success, the subject is fixed, auth_time is now, and the step is audited with the user as its subject; nothing is checked or sent anywhere	Read the whole account the password proved

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`noUsablePassword`	`passwordRefused`	32256 of 86016
2	`wrongPassword`	`passwordRefused`	26880 of 86016
3	`userDisabled`	`passwordRefused`	5376 of 86016
4	`breachListChecked`	`checkingBreachList`	16128 of 86016
5	otherwise	`readingProvenAccount`	5376 of 86016

noUsablePassword: account in ['unknown', 'passkeyOnly', 'passwordDisabled']
wrongPassword: password == 'wrong'
userDisabled: account == 'disabled'
breachListChecked: breachList != 'off'

Apply the rules after a first factor (rule 8)

#	If	Then
1	the account has a passkey bound: the password does not complete the sign-in	Ask for the account's passkey
2	the policy requires a second factor, and no second-factor step exists yet (#653): the set-up step, which a later issue builds, and never a code	Continue elsewhere
3	the account's address is not proved yet: it is verified inline	Verify the account's address with an emailed code
4	every factor the sign-in needs is proved	Ask whether the password must be replaced first (rule 8)

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`passkeyBound`	`passkeyOwed`	5376 of 21504
2	`mfaRequired`	`redirected`	8064 of 21504
3	`unverified`	`verifyingAccount`	2688 of 21504
4	otherwise	`checkingPasswordUpdate`	5376 of 21504

unverified: account == 'unverified'
passkeyBound: account == 'passwordAndPasskey'
mfaRequired: mfa == 'required'

Ask whether the password must be replaced first (rule 8)

#	If	Then
1	the code that verified the address in this transaction proved the mailbox: the new password is asked for	Ask for a new password
2	the account has a second factor: it is asked for before the update; until the TOTP step exists (#653), the engine answers a redirect	Continue elsewhere
3	the password is the account's only factor: a code is mailed to its address first, as a reset asks	Prove the account's mailbox with an emailed code before the update
4	no update is due: every rule is met	Complete the sign-in

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`updateDue and mailboxShown`	`offeringNewPassword`	1680 of 8064
2	`updateDue and secondFactorBound`	`redirected`	1680 of 8064
3	`updateDue`	`confirmingMailbox`	1680 of 8064
4	otherwise	`completed`	3024 of 8064

updateDue: (breachedHeld or updateRequested) and not passwordUpdated
secondFactorBound: account == 'passwordAndSecondFactor'
mailboxShown: addressVerified or mailboxProved

Check the new password against the realm's password policy

#	If	Then
1	the policy refuses it: the step again with password_rejected and its reasons, audited under the subject	Ask for a new password again
2	the policy accepts it	Check the new password against the realm's breach list

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`newPasswordRejected`	`newPasswordRefused`	840 of 3360
2	otherwise	`checkingNewBreachList`	2520 of 3360

newPasswordRejected: newPassword == 'rejected'

Every way it can end

It ends with	When	What happens
Complete the sign-in ends here	The authorization request carries no login_hint, an enabled, verified account whose only factor is its password, the answered password is the account's, REQUIRE_VERIFIED_ACCOUNT is on, the default; an unverified account is verified inline, neither the realm nor the client requires a second factor for this account: the default until the policy has its storage (Foundations, the admin console), the realm checks no breach list: password.breachListSource is off, the default, the account holds no update_password required action, the realm's password policy accepts it, and it is not on the realm's breach list or the realm checks none, every hook lets the round through, the transport does not serve the captcha step, the provider can issue a challenge and check its answer, every identifier a round brings is the one the transaction holds, after normalisation	Wait for the first round: the first round carries a password and its login_hint: the one-call path of ADR-017 Decision 3 Read the realm's and the client's MFA policy: the policy is read Ask the limiters (rule 3): the limiters let the round through Ask the transport's request checks (rule 4): the request checks let the round through Ask whether a bot challenge is due (rule 5): no bot challenge is due Take the identifier (rule 6): the transaction holds the identifier Pick the first factor (rule 7): the round answers the password step, the one the engine asks for Reserve the attempt on the ladder: the attempt is reserved Read what the password needs of the account the identifier names: the account is read, or none holds the identifier Verify the password, at the cost of one Argon2id verification for every account: the password is right and the realm checks no breach list: the attempt settles as a success, the subject is fixed, auth_time is now, and the step is audited with the user as its subject; nothing is checked or sent anywhere Read the whole account the password proved: the account is read again, with every factor Apply the rules after a first factor (rule 8): every factor the sign-in needs is proved Ask whether the password must be replaced first (rule 8): no update is due: every rule is met
Ask for the account's passkey ends here	The authorization request carries no login_hint, an enabled, verified account with a password and a passkey; the passkey counts as bound even while it is disabled, the answered password is the account's, REQUIRE_VERIFIED_ACCOUNT is on, the default; an unverified account is verified inline, neither the realm nor the client requires a second factor for this account: the default until the policy has its storage (Foundations, the admin console), the realm checks no breach list: password.breachListSource is off, the default, the account holds no update_password required action, the realm's password policy accepts it, and it is not on the realm's breach list or the realm checks none, every hook lets the round through, the transport does not serve the captcha step, the provider can issue a challenge and check its answer, every identifier a round brings is the one the transaction holds, after normalisation	Wait for the first round: the first round carries a password and its login_hint: the one-call path of ADR-017 Decision 3 Read the realm's and the client's MFA policy: the policy is read Ask the limiters (rule 3): the limiters let the round through Ask the transport's request checks (rule 4): the request checks let the round through Ask whether a bot challenge is due (rule 5): no bot challenge is due Take the identifier (rule 6): the transaction holds the identifier Pick the first factor (rule 7): the round answers the password step, the one the engine asks for Reserve the attempt on the ladder: the attempt is reserved Read what the password needs of the account the identifier names: the account is read, or none holds the identifier Verify the password, at the cost of one Argon2id verification for every account: the password is right and the realm checks no breach list: the attempt settles as a success, the subject is fixed, auth_time is now, and the step is audited with the user as its subject; nothing is checked or sent anywhere Read the whole account the password proved: the account is read again, with every factor Apply the rules after a first factor (rule 8): the account has a passkey bound: the password does not complete the sign-in
Continue elsewhere ends here	The authorization request carries no login_hint, an enabled, verified account whose only factor is its password, the answered password is the account's, REQUIRE_VERIFIED_ACCOUNT is on, the default; an unverified account is verified inline, the realm or the client requires a second factor, or requires one for admins and the account is one, the realm checks no breach list: password.breachListSource is off, the default, the account holds no update_password required action, the realm's password policy accepts it, and it is not on the realm's breach list or the realm checks none, every hook lets the round through, the transport does not serve the captcha step, the provider can issue a challenge and check its answer, every identifier a round brings is the one the transaction holds, after normalisation	Wait for the first round: the first round carries a password and its login_hint: the one-call path of ADR-017 Decision 3 Read the realm's and the client's MFA policy: the policy is read Ask the limiters (rule 3): the limiters let the round through Ask the transport's request checks (rule 4): the request checks let the round through Ask whether a bot challenge is due (rule 5): no bot challenge is due Take the identifier (rule 6): the transaction holds the identifier Pick the first factor (rule 7): the round answers the password step, the one the engine asks for Reserve the attempt on the ladder: the attempt is reserved Read what the password needs of the account the identifier names: the account is read, or none holds the identifier Verify the password, at the cost of one Argon2id verification for every account: the password is right and the realm checks no breach list: the attempt settles as a success, the subject is fixed, auth_time is now, and the step is audited with the user as its subject; nothing is checked or sent anywhere Read the whole account the password proved: the account is read again, with every factor Apply the rules after a first factor (rule 8): the policy requires a second factor, and no second-factor step exists yet (#653): the set-up step, which a later issue builds, and never a code
End the transaction ends here	The authorization request carries a login_hint, a valid email address of at most 254 bytes, no account in the realm holds the identifier, the answered password is the account's, REQUIRE_VERIFIED_ACCOUNT is on, the default; an unverified account is verified inline, neither the realm nor the client requires a second factor for this account: the default until the policy has its storage (Foundations, the admin console), the realm checks no breach list: password.breachListSource is off, the default, the account holds no update_password required action, the realm's password policy accepts it, and it is not on the realm's breach list or the realm checks none, every hook lets the round through, the transport does not serve the captcha step, the provider can issue a challenge and check its answer, a round brings another identifier than the one the transaction holds (another login_hint, another identifier answer), or the request's login_hint and the answer's differ	Wait for the first round: the first round answers the identifier step Read the realm's and the client's MFA policy: the policy is read Ask the limiters (rule 3): the limiters let the round through Ask the transport's request checks (rule 4): the request checks let the round through Ask whether a bot challenge is due (rule 5): no bot challenge is due Take the identifier (rule 6): the round brings another identifier than the one the transaction holds, or the request's and the answer's differ: the transaction ends, and subject_mismatch is audited under the identifier HMAC
Refuse a round of the inline verification for the send caps or the email-code ladder ends here	The authorization request carries no login_hint, an enabled account with a password whose primary identity, its address, is not proven yet: it is verified inline after its correct password, the answered password is the account's, REQUIRE_VERIFIED_ACCOUNT is on, the default; an unverified account is verified inline, neither the realm nor the client requires a second factor for this account: the default until the policy has its storage (Foundations, the admin console), the realm checks no breach list: password.breachListSource is off, the default, the account holds no update_password required action, the realm's password policy accepts it, and it is not on the realm's breach list or the realm checks none, every hook lets the round through, the transport does not serve the captcha step, the provider can issue a challenge and check its answer, every identifier a round brings is the one the transaction holds, after normalisation	Wait for the first round: the first round carries a password and its login_hint: the one-call path of ADR-017 Decision 3 Read the realm's and the client's MFA policy: the policy is read Ask the limiters (rule 3): the limiters let the round through Ask the transport's request checks (rule 4): the request checks let the round through Ask whether a bot challenge is due (rule 5): no bot challenge is due Take the identifier (rule 6): the transaction holds the identifier Pick the first factor (rule 7): the round answers the password step, the one the engine asks for Reserve the attempt on the ladder: the attempt is reserved Read what the password needs of the account the identifier names: the account is read, or none holds the identifier Verify the password, at the cost of one Argon2id verification for every account: the password is right and the realm checks no breach list: the attempt settles as a success, the subject is fixed, auth_time is now, and the step is audited with the user as its subject; nothing is checked or sent anywhere Read the whole account the password proved: the account is read again, with every factor Apply the rules after a first factor (rule 8): the account's address is not proved yet: it is verified inline Verify the account's address with an emailed code: it fails, because the send caps or the email-code ladder's wait refuse the round
End the transaction for a burned code or an account that changed ends here	The authorization request carries no login_hint, an enabled account with a password whose primary identity, its address, is not proven yet: it is verified inline after its correct password, the answered password is the account's, REQUIRE_VERIFIED_ACCOUNT is on, the default; an unverified account is verified inline, neither the realm nor the client requires a second factor for this account: the default until the policy has its storage (Foundations, the admin console), the realm checks no breach list: password.breachListSource is off, the default, the account holds no update_password required action, the realm's password policy accepts it, and it is not on the realm's breach list or the realm checks none, every hook lets the round through, the transport does not serve the captcha step, the provider can issue a challenge and check its answer, every identifier a round brings is the one the transaction holds, after normalisation	Wait for the first round: the first round carries a password and its login_hint: the one-call path of ADR-017 Decision 3 Read the realm's and the client's MFA policy: the policy is read Ask the limiters (rule 3): the limiters let the round through Ask the transport's request checks (rule 4): the request checks let the round through Ask whether a bot challenge is due (rule 5): no bot challenge is due Take the identifier (rule 6): the transaction holds the identifier Pick the first factor (rule 7): the round answers the password step, the one the engine asks for Reserve the attempt on the ladder: the attempt is reserved Read what the password needs of the account the identifier names: the account is read, or none holds the identifier Verify the password, at the cost of one Argon2id verification for every account: the password is right and the realm checks no breach list: the attempt settles as a success, the subject is fixed, auth_time is now, and the step is audited with the user as its subject; nothing is checked or sent anywhere Read the whole account the password proved: the account is read again, with every factor Apply the rules after a first factor (rule 8): the account's address is not proved yet: it is verified inline Verify the account's address with an emailed code: it fails, because the fifth wrong code burned the code, or the account changed: the transaction ends
Refuse the round for a limiter ends here	The authorization request carries no login_hint, no account in the realm holds the identifier, the answered password is the account's, REQUIRE_VERIFIED_ACCOUNT is on, the default; an unverified account is verified inline, neither the realm nor the client requires a second factor for this account: the default until the policy has its storage (Foundations, the admin console), the realm checks no breach list: password.breachListSource is off, the default, the account holds no update_password required action, the realm's password policy accepts it, and it is not on the realm's breach list or the realm checks none, a limiter refuses the round (per client, per end-user IP): a 429 with Retry-After, the transport does not serve the captcha step, the provider can issue a challenge and check its answer, every identifier a round brings is the one the transaction holds, after normalisation	Wait for the first round: the first round carries no answer Read the realm's and the client's MFA policy: the policy is read Ask the limiters (rule 3): a limiter refuses the round; the floor is waited out
Refuse the round inside the ladder's wait ends here	The authorization request carries no login_hint, no account in the realm holds the identifier, the answered password is the account's, REQUIRE_VERIFIED_ACCOUNT is on, the default; an unverified account is verified inline, neither the realm nor the client requires a second factor for this account: the default until the policy has its storage (Foundations, the admin console), the realm checks no breach list: password.breachListSource is off, the default, the account holds no update_password required action, the realm's password policy accepts it, and it is not on the realm's breach list or the realm checks none, the identifier's ladder is inside a wait: the identifier HMAC's counter, whether or not an account holds it, the transport does not serve the captcha step, the provider can issue a challenge and check its answer, every identifier a round brings is the one the transaction holds, after normalisation	Wait for the first round: the first round carries a password and its login_hint: the one-call path of ADR-017 Decision 3 Read the realm's and the client's MFA policy: the policy is read Ask the limiters (rule 3): the limiters let the round through Ask the transport's request checks (rule 4): the request checks let the round through Ask whether a bot challenge is due (rule 5): no bot challenge is due Take the identifier (rule 6): the transaction holds the identifier Pick the first factor (rule 7): the round answers the password step, the one the engine asks for Reserve the attempt on the ladder: the identifier is inside a wait: the round is refused, neither verified nor counted, and audited under the identifier HMAC
Refuse the round for the request checks ends here	The authorization request carries no login_hint, no account in the realm holds the identifier, the answered password is the account's, REQUIRE_VERIFIED_ACCOUNT is on, the default; an unverified account is verified inline, neither the realm nor the client requires a second factor for this account: the default until the policy has its storage (Foundations, the admin console), the realm checks no breach list: password.breachListSource is off, the default, the account holds no update_password required action, the realm's password policy accepts it, and it is not on the realm's breach list or the realm checks none, the transport's request checks refuse the round, such as acr_values, prompt=none or a frozen parameter at the FiPA endpoint, the transport does not serve the captcha step, the provider can issue a challenge and check its answer, every identifier a round brings is the one the transaction holds, after normalisation	Wait for the first round: the first round carries no answer Read the realm's and the client's MFA policy: the policy is read Ask the limiters (rule 3): the limiters let the round through Ask the transport's request checks (rule 4): the request checks refuse the round; the floor is waited out
Offer the bot challenge ends here	The authorization request carries no login_hint, no account in the realm holds the identifier, the answered password is the account's, REQUIRE_VERIFIED_ACCOUNT is on, the default; an unverified account is verified inline, neither the realm nor the client requires a second factor for this account: the default until the policy has its storage (Foundations, the admin console), the realm checks no breach list: password.breachListSource is off, the default, the account holds no update_password required action, the realm's password policy accepts it, and it is not on the realm's breach list or the realm checks none, a soft threshold asks for a bot challenge (#643): of the limiters (an end-user IP, its bucket or the client past its free failures) or of the ladder (the round's identifier past the password's or the email code's free failures), while the transaction holds no unspent pass of an earlier challenge, the transport serves the captcha step, the provider can issue a challenge and check its answer, every identifier a round brings is the one the transaction holds, after normalisation	Wait for the first round: the first round carries no answer Read the realm's and the client's MFA policy: the policy is read Ask the limiters (rule 3): the limiters let the round through Ask the transport's request checks (rule 4): the request checks let the round through Ask whether a bot challenge is due (rule 5): a bot challenge is due; any other answer is ignored, and the floor is waited out
Refuse a malformed answer ends here	The authorization request carries no login_hint, no account in the realm holds the identifier, the answered password is the account's, REQUIRE_VERIFIED_ACCOUNT is on, the default; an unverified account is verified inline, neither the realm nor the client requires a second factor for this account: the default until the policy has its storage (Foundations, the admin console), the realm checks no breach list: password.breachListSource is off, the default, the account holds no update_password required action, the realm's password policy accepts it, and it is not on the realm's breach list or the realm checks none, every hook lets the round through, the transport does not serve the captcha step, the provider can issue a challenge and check its answer, every identifier a round brings is the one the transaction holds, after normalisation	Wait for the first round: the first round carries an answer whose login_hint is not an identifier Read the realm's and the client's MFA policy: the policy is read Ask the limiters (rule 3): the limiters let the round through Ask the transport's request checks (rule 4): the request checks let the round through Ask whether a bot challenge is due (rule 5): no bot challenge is due Take the identifier (rule 6): the answer's login_hint is not an identifier (an email address of at most 254 bytes); nothing is verified or counted
Refuse the round while a store is down ends here	The authorization request carries no login_hint, no account in the realm holds the identifier, the answered password is the account's, REQUIRE_VERIFIED_ACCOUNT is on, the default; an unverified account is verified inline, neither the realm nor the client requires a second factor for this account: the default until the policy has its storage (Foundations, the admin console), the realm checks no breach list: password.breachListSource is off, the default, the account holds no update_password required action, the realm's password policy accepts it, and it is not on the realm's breach list or the realm checks none, every hook lets the round through, the transport does not serve the captcha step, the provider can issue a challenge and check its answer, every identifier a round brings is the one the transaction holds, after normalisation	Wait for the first round: the first round carries no answer Read the realm's and the client's MFA policy: it fails, because the policy cannot be read; the floor is waited out

Each row is also a generated test: set the starting situation, send the events, expect the ending.

What is guaranteed

These hold in all 8516792 situations the model can reach, from 163840 different starting situations.

A step offered without an error never read the account, so before a factor succeeds it is the same for every account the identifier may name, and for none; login_hint changes it for no account
A sign-in completes only for an enabled account, its right password and a verified address, whatever REQUIRE_VERIFIED_ACCOUNT says
A disabled user is answered as a wrong password: no subject is fixed, so no transport mints anything for it
Every refused password costs one Argon2id verification, against the dummy hash when no usable password exists
An identifier no account holds, or an account with no usable password, runs the dummy hash
Every verified password was reserved on the ladder first
A password sent while the identifier step is next is ignored: it is neither verified nor counted
A refused round, a store outage or an unreadable policy included, checks no credential, unless the credential already proved the account: a store that fails after the proof keeps the subject in the transaction, so a refusal never tells a right password from a wrong one
A round that brings another identifier than the one the transaction holds ends it, and the end is audited as subject_mismatch
A sign-in never completes below the account's strongest bound factor, a disabled one included, or without the second factor the policy requires
Every round answers no earlier than 500 ms after it arrived: those that resolve an identifier or carry a credential, as ADR-017 Decision 7 asks, and every other one, so that no answer is timed apart
While no user is proven, the audit names the person only by the identifier HMAC, never by the identifier itself
A sign-in whose password is on the breach list, or whose account holds an update_password required action, completes only once a new password is set: no session and no code before it
A new password is asked for only after a proof beyond the password: here, a code that proved the account's mailbox in this transaction; a second factor the account has is asked for first and, until its step exists, answers a redirect
A new password the policy refuses or the realm's breach list holds is never written
A breach-list check that fails never refuses a right password: the subject is fixed and the sign-in goes on, as for a password that is not listed
A breach-list check that fails is counted on the metric and recorded in the audit log
With password.breachListSource off and no update_password required action, the sign-in is the one drawn before #635: nothing is checked or sent, and no new password is asked for

Exact rules

Id	Never
`same-first-response-for-every-account`	`state in ['offeringIdentifier', 'offeringPassword'] and accountRead`
`no-completion-without-a-usable-enabled-account`	`state == 'completed' and (noUsablePassword or wrongPassword or userDisabled or (unverified and not addressVerified))`
`disabled-user-never-gets-a-subject`	`subjectFixed and account == 'disabled'`
`every-refused-password-costs-one-verification`	`state == 'passwordRefused' and not (hashVerified or decoyVerified)`
`unknown-identifier-verifies-the-dummy-hash`	`state == 'passwordRefused' and noUsablePassword and not decoyVerified`
`reserve-before-verify`	`(hashVerified or decoyVerified) and not attemptReserved`
`eager-answer-ignored`	`state == 'offeringIdentifier' and (attemptReserved or hashVerified or decoyVerified)`
`refused-rounds-verify-nothing`	`state in ['unavailable', 'throttled', 'lockedOut', 'requestRefused', 'botChallengeDue', 'answerRefused'] and (hashVerified or decoyVerified) and not subjectFixed`
`subject-mismatch-is-audited`	`state == 'ended' and not auditedByHmac`
`no-completion-below-the-strongest-factor`	`state == 'completed' and (passkeyBound or mfaRequired)`
`every-round-waits-the-floor`	`state in ['offeringIdentifier', 'offeringPassword', 'passwordRefused', 'completed', 'redirected', 'ended', 'throttled', 'lockedOut', 'requestRefused', 'botChallengeDue', 'answerRefused', 'unavailable', 'verificationThrottled', 'verificationEnded', 'offeringNewPassword', 'newPasswordRefused'] and not floorWaited`
`no-raw-identifier-before-a-subject`	`state in ['passwordRefused', 'lockedOut', 'ended'] and not subjectFixed and not auditedByHmac`
`no-completion-while-an-update-is-due`	`state == 'completed' and (breachedHeld or updateRequested) and not passwordUpdated`
`the-password-alone-never-sets-a-new-one`	`state in ['offeringNewPassword', 'newPasswordRefused', 'writingPassword'] and not mailboxShown`
`the-new-password-passes-the-checks`	`passwordUpdated and newPassword in ['rejected', 'listed']`
`a-failed-check-never-blocks`	`breachCheckFailed and state in ['passwordRefused', 'lockedOut'] and subjectFixed`
`every-failed-check-is-recorded`	`breachCheckFailed and subjectFixed and not breachFailureRecorded`
`nothing-changes-with-the-setting-off`	`breachList == 'off' and not updateRequested and state in ['checkingBreachList', 'confirmingMailbox', 'offeringNewPassword', 'newPasswordRefused', 'writingPassword']`

Reference

All transitions (81)

From	Event	Guard	To	Effects	Taken
`idle`	`ROUND`		`readingPolicy`	`newRound` `answerNone`	yes
`idle`	`IDENTIFIER`		`readingPolicy`	`newRound` `answerIdentifier`	yes
`idle`	`PASSWORD`		`readingPolicy`	`newRound` `answerPassword`	yes
`idle`	`PASSWORD_WITH_HINT`		`readingPolicy`	`newRound` `answerPasswordWithHint`	yes
`idle`	`MALFORMED`		`readingPolicy`	`newRound` `answerMalformed`	yes
`readingPolicy`	`DONE`		`checkingLimits`		yes
`readingPolicy`	`FAIL.store`		`unavailable`	`waitFloor`	yes
`checkingLimits`	`rule 1`	`limited`	`throttled`	`waitFloor`	yes
`checkingLimits`	`rule 2`		`checkingRequest`		yes
`checkingRequest`	`rule 1`	`requestRefused`	`requestRefused`	`waitFloor`	yes
`checkingRequest`	`rule 2`		`checkingBotChallenge`		yes
`checkingBotChallenge`	`rule 1`	`challengeUnanswerable`	`unavailable`	`waitFloor`	yes
`checkingBotChallenge`	`rule 2`	`challengeOffered`	`botChallengeDue`	`waitFloor`	yes
`checkingBotChallenge`	`rule 3`	`botChallengeDue`	`takingIdentifier`		yes
`checkingBotChallenge`	`rule 4`		`takingIdentifier`		yes
`takingIdentifier`	`rule 1`	`malformedAnswer`	`answerRefused`	`waitFloor`	yes
`takingIdentifier`	`rule 2`	`identifierMismatch`	`ended`	`auditByHmac` `waitFloor`	yes
`takingIdentifier`	`rule 3`	`noIdentifier`	`offeringIdentifier`	`waitFloor`	yes
`takingIdentifier`	`rule 4`		`choosingFirstFactor`	`holdIdentifier`	yes
`choosingFirstFactor`	`rule 1`	`passwordAnswered`	`reservingAttempt`		yes
`choosingFirstFactor`	`rule 2`		`offeringPassword`	`waitFloor`	yes
`reservingAttempt`	`DONE`	`lockedOut`	`lockedOut`	`auditByHmac` `waitFloor`	yes
`reservingAttempt`	`DONE`		`readingAccount`	`reserveAttempt`	yes
`reservingAttempt`	`FAIL.store`		`unavailable`	`waitFloor`	yes
`readingAccount`	`DONE`		`verifyingPassword`	`readAccount`	yes
`readingAccount`	`FAIL.store`		`unavailable`	`waitFloor`	yes
`verifyingPassword`	`rule 1`	`noUsablePassword`	`passwordRefused`	`verifyDecoy` `auditByHmac` `waitFloor`	yes
`verifyingPassword`	`rule 2`	`wrongPassword`	`passwordRefused`	`verifyHash` `auditByHmac` `waitFloor`	yes
`verifyingPassword`	`rule 3`	`userDisabled`	`passwordRefused`	`verifyHash` `auditByHmac` `waitFloor`	yes
`verifyingPassword`	`rule 4`	`breachListChecked`	`checkingBreachList`	`verifyHash`	yes
`verifyingPassword`	`rule 5`		`readingProvenAccount`	`verifyHash` `fixSubject`	yes
`checkingBreachList`	`DONE`	`passwordListed`	`readingProvenAccount`	`fixSubject` `holdBreached`	yes
`checkingBreachList`	`DONE`	`breachList == 'notListed'`	`readingProvenAccount`	`fixSubject`	yes
`checkingBreachList`	`FAIL.lookup`	`breachCheckFailed`	`readingProvenAccount`	`fixSubject` `recordBreachFailure`	yes
`readingProvenAccount`	`DONE`		`afterFirstFactor`	`readProvenAccount`	yes
`readingProvenAccount`	`FAIL.store`		`unavailable`	`waitFloor`	yes
`afterFirstFactor`	`rule 1`	`passkeyBound`	`passkeyOwed`	`waitFloor`	yes
`afterFirstFactor`	`rule 2`	`mfaRequired`	`redirected`	`waitFloor`	yes
`afterFirstFactor`	`rule 3`	`unverified`	`verifyingAccount`		yes
`afterFirstFactor`	`rule 4`		`checkingPasswordUpdate`		yes
`verifyingAccount`	`DONE`		`checkingPasswordUpdate`	`verifyAddress`	yes
`verifyingAccount`	`FAIL.throttled`		`verificationThrottled`	`waitFloor`	yes
`verifyingAccount`	`FAIL.ended`		`verificationEnded`	`waitFloor`	yes
`verifyingAccount`	`FAIL.invalid`		`answerRefused`	`waitFloor`	yes
`verifyingAccount`	`FAIL.store`		`unavailable`	`waitFloor`	yes
`checkingPasswordUpdate`	`rule 1`	`updateDue and mailboxShown`	`offeringNewPassword`	`waitFloor`	yes
`checkingPasswordUpdate`	`rule 2`	`updateDue and secondFactorBound`	`redirected`	`waitFloor`	yes
`checkingPasswordUpdate`	`rule 3`	`updateDue`	`confirmingMailbox`		yes
`checkingPasswordUpdate`	`rule 4`		`completed`	`waitFloor`	yes
`confirmingMailbox`	`DONE`		`offeringNewPassword`	`proveMailbox` `waitFloor`	yes
`confirmingMailbox`	`FAIL.throttled`		`verificationThrottled`	`waitFloor`	yes
`confirmingMailbox`	`FAIL.ended`		`verificationEnded`	`waitFloor`	yes
`confirmingMailbox`	`FAIL.invalid`		`answerRefused`	`waitFloor`	yes
`confirmingMailbox`	`FAIL.store`		`unavailable`	`waitFloor`	yes
`checkingNewPassword`	`rule 1`	`newPasswordRejected`	`newPasswordRefused`	`waitFloor`	yes
`checkingNewPassword`	`rule 2`		`checkingNewBreachList`		yes
`checkingNewBreachList`	`DONE`	`newPasswordListed`	`newPasswordRefused`	`waitFloor`	yes
`checkingNewBreachList`	`DONE`	`newPassword == 'accepted'`	`writingPassword`		yes
`checkingNewBreachList`	`FAIL.lookup`	`newPassword == 'checkFailed'`	`writingPassword`	`recordBreachFailure`	yes
`writingPassword`	`DONE`		`completed`	`updatePassword` `waitFloor`	yes
`writingPassword`	`FAIL.ended`		`verificationEnded`	`waitFloor`	yes
`writingPassword`	`FAIL.store`		`unavailable`	`waitFloor`	yes
`offeringIdentifier`	`ROUND`		`readingPolicy`	`newRound` `answerNone`	yes
`offeringIdentifier`	`IDENTIFIER`		`readingPolicy`	`newRound` `answerIdentifier`	yes
`offeringIdentifier`	`PASSWORD`		`readingPolicy`	`newRound` `answerPassword`	yes
`offeringIdentifier`	`PASSWORD_WITH_HINT`		`readingPolicy`	`newRound` `answerPasswordWithHint`	yes
`offeringIdentifier`	`MALFORMED`		`readingPolicy`	`newRound` `answerMalformed`	yes
`offeringPassword`	`ROUND`		`readingPolicy`	`newRound` `answerNone`	yes
`offeringPassword`	`IDENTIFIER`		`readingPolicy`	`newRound` `answerIdentifier`	yes
`offeringPassword`	`PASSWORD`		`readingPolicy`	`newRound` `answerPassword`	yes
`offeringPassword`	`PASSWORD_WITH_HINT`		`readingPolicy`	`newRound` `answerPasswordWithHint`	yes
`offeringPassword`	`MALFORMED`		`readingPolicy`	`newRound` `answerMalformed`	yes
`passwordRefused`	`ROUND`		`readingPolicy`	`newRound` `answerNone`	yes
`passwordRefused`	`IDENTIFIER`		`readingPolicy`	`newRound` `answerIdentifier`	yes
`passwordRefused`	`PASSWORD`		`readingPolicy`	`newRound` `answerPassword`	yes
`passwordRefused`	`PASSWORD_WITH_HINT`		`readingPolicy`	`newRound` `answerPasswordWithHint`	yes
`passwordRefused`	`MALFORMED`		`readingPolicy`	`newRound` `answerMalformed`	yes
`offeringNewPassword`	`ROUND`		`offeringNewPassword`	`newRound` `waitFloor`	yes
`offeringNewPassword`	`NEW_PASSWORD`		`checkingNewPassword`	`newRound`	yes
`newPasswordRefused`	`ROUND`		`offeringNewPassword`	`newRound` `waitFloor`	yes
`newPasswordRefused`	`NEW_PASSWORD`		`checkingNewPassword`	`newRound`	yes