Playground

UserVerification can be changed for both register & login

For register the client will guide the user through setting up user verification if needed to create a discoverable credential. This takes precedence over the setting of userVerification.

pubKeyCredParams, ordered by preference — the client makes a best-effort to create the most preferred type it can, and fails if it can create none of them. Unchecking everything falls back to the library's defaults. Level 3 recommends against offering the fully-specified -9/-19/-51/-52 here.

The ML-DSA entries are the post-quantum algorithms RFC 9964 registers for COSE. This server can verify them, but no shipping authenticator produces them yet, so expect the client to fall through to whichever conventional algorithm you also offer — and, if you offer nothing else, to sit waiting for a security key that can never answer rather than failing outright. Press Cancel on the prompt to back out.

§5.8.8. Guides how the browser presents the ceremony, in the order checked here. Hints are advisory — they do not restrict what the user may actually use. Setting a hint also derives the authenticator attachment, so it takes precedence over the Authenticator setting above.

§5.4. The attestation statement formats this Relying Party prefers, most preferred first. Advisory: the authenticator may still use a format that is not listed. Only meaningful when the attestation type above is not None.

§5.1.3. A conditional create is offered quietly by the browser rather than in a modal prompt. Because no user presence test happens, the UP flag is not set and the server has to know the ceremony was conditional in order to accept it.

§10.1.4. At registration this only asks whether the authenticator can evaluate a pseudo-random function for this credential; the client reports the answer back as prf.enabled.