You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Adding `authenticator_selection_options` allows implementors to
customize their authentication selection needs to match the needs of
their userbase.
* By default, `RegistrationHelpers` should explicitly require that the
credentials must be discoverable:
> Passkeys are primarily driven by the use of discoverable credentials
> Discoverable credentials are a mechanism provided by the WebAuthn
> specification that allows for seamless authentication without the
> user having to provide either a username or password. In fact,
> WebAuthn credentials are determined to be passkeys based on
> their “discoverability”.
> ...
> It’s important in our context of passkeys to focus primarily on
> discoverable credentials; a WebAuthn credential is not considered a
> passkey unless it’s discoverable.
> https://developers.yubico.com/Passkeys/Passkey_concepts/Discoverable_vs_non-discoverable_credentials.html
* This detail, and the desire to have the gem as secure by default,
means that the `resident_key` should be `required`. Some problems with
non-discoverable credentials are:
* We would have make assumptions on what user identifier is used
(eg: username, email, phone number, employee ID, etc.), which makes
this gem less flexible & usable in a variety of contexts
* It opens up the possibility for dictionary/phishing on those user
identifiers. If there is an endpoint where someone can query to
return a list of credentials for an identifier, they can determine
if someone is using a service by the presence of credentials.
* However, there is this caveat in the Yubico documentation:
> Supporting non-discoverable credential flows is important for two
> distinct reasons:
> - A user may be using a pre-FIDO2 authenticator that does not
> support discoverable credentials
> - A user may be using an authenticator that does not have available
> room for more discoverable credentials
> This will be especially important for consumer use cases where you
> may not have control over the types of authenticators that your user
> base will attempt to leverage.
> https://developers.yubico.com/Passkeys/Passkey_concepts/Discoverable_vs_non-discoverable_credentials.html
* While this edge case is **not** something that `warden-webauthn`
supports out of the box, allowing `authenticator_selection_options`
to be easily customizable makes it easy for an implementor to handle
the edge case if it's truly needed.
0 commit comments