Make WebAuthn params configurable

[FlxMgdnz]

Add config options for

• User Verification (UV): Discouraged, Preferred, Required
• Attachment: Platform, Cross-Platform
• Discoverable Credential: Discouraged, Preferred, Required
• Attestation: None, Direct (not really useful until we add attestation check via MDS to backend)
• Registration Hints: Security Key, Client Device, Hybrid (WebAuthn lvl3 feature, but already implemented in Chrome)

[shentschel]

I cannot find registration hints in the webauthn library. Do they also have another name?

[FlxMgdnz]

I cannot find registration hints in the webauthn library. Do they also have another name?

It's a level 3 feature, but it seems that Google has already implemented hints.

[FlxMgdnz]

Discussed this with @FreddyDevelop yesterday. We currently see three different use cases for WebAuthn that we should support:

Passkey as first factor

The default passkey use case. The login page offers either a "Sign in with a passkey" button, or passkey autofill, or both. No username entry is required to initialize the passkey flow. Passkey creation happens during user onboarding or on the account setting page for authenticated users.

Create()

• User Verification (UV): Preferred (For high security requirements, Required may work better https://web.dev/articles/webauthn-user-verification)
• Attachment: not set (allow passkey creation on all devices)
• Discoverable Credential: Required (the only way to support usernameless first-factor passkeys)
• Attestation: Direct (to support AAGUID-based authenticator naming)

Get()

• No user ID known when initializing the request
• AllowList = empty
• User Verification (UV): Preferred (same as on registration), result should be checked and made available for RP for risk analysis

Passkeys for reauthentication

Prompt for a passkey to reauthenticate a user, e.g. when accessing the account settings page or other high-value features of the RP app.

Get()

• User ID known when initializing the request
• AllowList should be populated based on user ID
• User Verification (UV): Preferred (same as on registration), result should be checked and made available for RP for risk analysis

2FA

Usually a security key, but Hybrid flow can also be used in current browser implementations, so 2nd factor synced passkeys cannot be prevented without nuking the UX through attestation. It is nice to allow existing passkeys to be used for 2FA as well, but Create() should probably be limited to security keys as 2nd factors as described below.

Create()

• User Verification (UV): Discouraged (to prevent forcing the user to set up a pin for the security key)
• Attachment: Cross-Platform
• Discoverable Credential: Discouraged (typical security keys can only store ~25 Discoverable Credentials)
• Attestation: Direct (to support AAGUID-based authenticator naming)
• Store "is2ndFactor" flag for credential, should not be used as regular passkey

Get()

• User ID known when initializing the request
• AllowList should be populated based on user ID. Contains all "is2ndFactor" credentials as well as existing passkeys.
• User Verification (UV): Preferred (same as on registration), result should be checked and made available for RP for risk analysis

[shentschel]

So that and https://github.com/teamhanko/passkeys/issues/33 are required to offer these options?