Module challenge 

Challenge generation, single-use consumption (replay protection), freshness/expiry enforcement, and the sign-count clone-detection state machine.

This module lifts the challenge/replay/sign-count logic that was previously entangled with application storage into a self-contained, storage-free helper. Pending challenges are held in-process; challenge consumption is atomic (single-use) and time-bounded.

Storage contract

ChallengeStore keeps only pending challenges in memory. It never touches credentials. Integrators persisting state across restarts should either accept that pending challenges are lost on restart (users simply retry) or implement their own store using ChallengeStore as reference.

Threat model

• Replay: a consumed challenge is removed from the store before the result is returned, so the same challenge can never complete two ceremonies, even with concurrent requests (single map entry).
• Staleness: challenges carry a creation timestamp; consumption fails with WebauthnError::ChallengeExpired once older than the caller’s timeout.
• Predictability: challenge bytes come from the OS CSPRNG (see generate_challenge_bytes).
• Cloned authenticators: check_sign_count rejects counters that do not strictly increase, per WebAuthn §7.2.

Structs

ChallengeStore

In-memory store of pending WebAuthn challenges with single-use consumption and expiry enforcement.

DeferredSignCountUpdate

A sign-count advance held back until the host’s own checks have passed.

SignCountPolicy

The relying party’s sign-count policy.

Enums

OnRegression

What a relying party does when the counter does not increase.

SignCountVerdict

What a sign-count comparison says, independent of any policy.

Functions

check_sign_count

Enforce the sign-count freshness state machine under the default policy.

classify_sign_count

Classify a sign-count comparison. Never fails; see SignCountVerdict.