Require userVerification during registration to ensure ability to perform MFA during auth?

[MasterKale]

Issue with existing content

Link to content

https://passkeys.dev/docs/use-cases/bootstrapping/#opting-the-user-into-passkeys

What is the issue?

Right now the site suggests RP's set "userVerification": "preferred' in the options for both .create() and .get(). But I was thinking about this the other day, why are we suggesting a configuration that allows for a user to complete registration without completing multi-factor authentication?

I can understand potentially allowing for UV to be skipped during auth for users that can't interact with a biometric sensor, to avoid anything resembling password entry when a biometric sensor is unavailable (e.g. Touch ID being unusable in clamshell mode). And perhaps we could suggest a "step-up" to "userVerification": "required" auth when needed in this scenario. But registration specifically feels like it should be more stringent in the name of ensuring that multiple factors can indeed be provided in subsequent authentications.

Proposed changes

Update the options specified in the Opting the user into passkeys section to pass "userVerification": "required" to the .create() call.

Any other notes

N/A

[timcappalli]

I agree from a technical standpoint and also for higher assurance RPs, but it has the same challenge as getAssertion.

Thinking about a user who is new to passkeys, they get asked to create one to replace their password, and then they're immediately asked for a password to complete. That is super confusing for an end user.

We do, absolutely, need to cross-reference the UV warning to the enrollment section. I missed that when I updated the auth section.

[Kieun]

I'm feeling that userVerificaiton preference is up to the relying party's policy.
If the RP intends to replace password + any other additional auth factor with single passkey gesture, RP would like to set userVerification as required during registration and authentication.

It would make some user confusion when asking the user to input local password, but I think this is the same while the local PIN input is requested in order to replace RP's server PIN for authentication (typical mobile payment scenario - 6 digit PIN).

Platforms and browsers need to improve the user interface when they need to verify the user with local authentication based on the something you know factor.

[lwe]

👍 From an RP aspect we usually always recommend setting userVerification to required.

While it may decrease UX on some combinations (e.g. when no biometric sensor is available, or users have to switch to hybrid mode etc.) the required is what enables the ability to have a real multi-factor authentication (something you are/know + something you have). Setting this to required for registration, while keeping it to preferred for authentication sounds like a sensible balance here.

[irew]

How about in the case, such as a Google account today, where a passkey is being introduced as an alternative to the existing password - which could be how many services introduce passkeys. Should they still go with uv:required?

[lwe]

How about in the case, such as a Google account today, where a passkey is being introduced as an alternative to the existing password - which could be how many services introduce passkeys. Should they still go with uv:required?

I think yes, as it's a still a registration, because you register a new passkey for the user. You'd also set uv:required in case of adding a second passkey to an account.

[MasterKale]

From WACG meeting on July 17:

It's probably okay to require UV during registration, and also explain caveat of it potentially including (system) password entry when biometrics are unavailable. This would not change guidance on authentication.

[MasterKale]

Attempting to tag @rmondello to see what their take on this might be 🤔

[rmondello]

But registration specifically feels like it should be more stringent in the name of ensuring that multiple factors can indeed be provided in subsequent authentications.

I'm not sure about this. With syncing credentials, credentials can move to a device without UV capability after a device with UV capability registers it.

I see uv:required during registration to provide a questionable signal of future behavior at the cost of making registration more cumbersome on some devices, potentially decreasing user registration rates.

[MasterKale]

With syncing credentials, credentials can move to a device without UV capability after a device with UV capability registers it.

Dang, that's a good point I hadn't considered. I guess the transfer to non-uv-capable authenticator can't ever be ruled out as a possibility, even for as simple as things would get if we could assume almost exclusively transfer between devices with UV-capable platform authenticators. There'd still be the current edge case of MBPs-in-clamshell-mode and Mac-Minis-without-biometrics, not to mention now third-party passkey providers moving credentials around devices with differing biometric availability...

I see uv:required during registration to provide a questionable signal of future behavior at the cost of making registration more cumbersome on some devices, potentially decreasing user registration rates.

Maybe I'm getting too hung up on trying to ensure that multiple factors of auth happen at all. Can passkeys provide enough protection with just UP? The fact that we suggest UV=preferred during auth suggests we're not significantly weakening RP's that follow our advice when uv=false in the return, that there's enough value in the phishing-resistance of passkeys to be a win even when only UP is provided.

[timcappalli]

Can passkeys provide enough protection with just UP?

RPs should make that determination based on the user, the protect resources, and other session context.