Security model

The package owns the ceremony: challenge binding, origin and RP ID validation, the user-presence and verification policy, sign-counter reconciliation and attestation trust. Cryptography — CBOR/COSE decoding, key parsing and signature verification — runs on crypto-for-laravel, with no third-party crypto anywhere in the chain.

• Single-use, TTL-bound challenges in the cache — atomic get-and-forget, so they are replay-safe.
• Ceremony-bound challenges — a challenge minted for registration is rejected by the authentication verifier, and vice versa.
• User-bound registration challenges — the verifier rejects a response for a different user (defence-in-depth for admin-on-behalf flows).
• User-bound authentication challenges (WebAuthn L3 §7.2 steps 5–6) — any credential the options didn’t offer is refused before signature verification and before any write.
• Owner expectations — AuthenticationExpectation holds the credential to an owner type or an exact owner before the challenge is consumed.
• Origin allow-list and RP ID hash validation on every ceremony.
• Constant-time challenge and user-handle comparison.
• Signature verification for ES256 (with DER↔raw handling), RS256 and Ed25519; a verification error is a failure, never a pass.
• No algorithm confusion — the algorithm comes from the stored credential’s COSE key, never from the assertion.
• Sign-counter regression policy — reject, or flag plus an event — to surface cloned authenticators. The counter only moves forward, in one conditional UPDATE … WHERE sign_count < ?, so neither a regression nor two concurrent assertions can write a lower counter back.
• Usernameless assertions name their account (WebAuthn §7.2 step 6) — options minted for no user require the response’s userHandle, which must match the credential’s.
• No user enumeration — every sign-in miss returns a uniform CredentialNotFound.
• Backup flags per WebAuthn L3 — a backed-up credential must be backup-eligible; backup eligibility is fixed at registration and an assertion that changes it is refused; backup state is recorded from every accepted assertion.
• Monotone attestation trust (ignore ⊂ self ⊂ basic), with RFC 5280 CA constraints on every issuer in a chain and every trust ruling made in one place, AttestationGate.
• Roaming-key credential IDs are stored in full; the unique index is keyed on a sha-256 hash of the ID, so it fits every database’s key-length limit.

What it leaves to you

No login routes, controllers, views, cookies or CSRF handling; no session start or access-token issuance; no rate limiting. The package hands you verified credentials and typed events — add your own throttling to the ceremony endpoints and issue sessions or tokens yourself.