Optional ReadonlymayAn optional extra registration policy, consulted AFTER the built-in
rules: a principal who already holds a passkey must have proved a second
factor (otp or pop) in this session, and — when signIn.mfa is
configured and this option is ABSENT — so must one registering a FIRST
passkey, because the plugin cannot see a factor the application stores
itself (a TOTP secret). Supplying mayRegister hands the first-passkey
decision to it: it receives the recorded methods and credentialCount
and should admit a password-only first enrolment only for a principal
that holds no other factor. Answering false (or throwing) refuses the
registration with 403 registration-refused.
ReadonlyoriginsThe exact-match origin allowlist clientDataJSON.origin is verified
against. Each origin must be https, or http on a loopback host, and
carry no path, query or fragment.
ReadonlyresolveResolves a credential's stored principal id to a principal at sign-in.
Returning null refuses the sign-in with 403, which is how a
deactivation or a revoked account takes effect without deleting the
credential.
ReadonlyrpThe RP ID: the origin's host or a registrable suffix of it. Compared
against SHA-256 as the ceremony's rpIdHash; the browser refuses an RP ID
that is not a registrable suffix of the origin at the ceremony.
ReadonlyrpThe RP name the browser shows the user during the ceremony.
ReadonlystoreThe credential store. Credentials are the application's data — a
production store should encrypt the public keys' records at rest and
honour IPasskeyStore.updateCounter as an atomic compare-and-advance.
Optional ReadonlyuserThe user-verification policy the ceremonies request and enforce. Defaults
to required, which refuses a UV-unset assertion everywhere — registration,
username-less sign-in and the second factor. preferred and discouraged
accept a UV-unset assertion at registration and as the second factor after
a first one, but never for a username-less sign-in.
Passkeys (WebAuthn) configuration for sign-in (plan §3.6).
Since
0.8.0