Re: [webauthn] Can RPs assume that `InvalidStateError` for `create()` means an excludeCredentials match? (#1566)

I just realized that there may be an assumption that may lead to miscommunication: whether 2FA is required.

At GitHub, we currently have the following situation:

A user with "normal 2FA enabled" must use the following to sign in:
- A password AND a 2FA challenge (SMS, OTP, or security key) to log in.

A user with "normal 2FA disabled":
- A password.

We intend to start by using trusted devices as [described here](https://w3c.github.io/webauthn/#sctn-authenticator-attachment-modality), to make re-authentication on a device easy. If a user registers or uses a trusted device in a given browser profile, then we we will offer that option instead of password login.

➡️ But we want to make this feature available to all users, **even those who do not have "normal 2FA enabled"**.  ⬅️

This means users will be able to authenticate as follows:

A user with "normal 2FA enabled" must use the following to sign in:  
- Either of:
  - A user-verifying authenticator.
  - A password AND a 2FA challenge (SMS, OTP, security key*.

A user with "normal 2FA disabled":
- Either of:
  - A user-verifying authenticator.
  - A password.

It's important that the registration of a trusted device does not turn a user without "normal 2FA" into a 2FA users, because otherwise their only 2FA mechanism would be a trusted device — in fact, a platform authenticator that cannot be moved between devices. This means that they will only need to provide their password in a fresh browser profile in order to be completely logged in. Since we don't prompt them for 2FA, we can't tell if this new browser profile already has a trusted device registered. We coud:

- Make a wild guess about whether they have a trusted device registered (e.g. based on their current UA and `isUserVerifyingPlatformAuthenticatorAvailable()` compared to past registrations and their UAs).
- Prompt them to register a device.

We're currently trying to figure out how to deal with the latter. As described above, we need to handle both the case where there is already a trusted device registered for this browser profile (in which a `get` prompt is appropriate) or not (in which a `create`) prompt is appropriate. This issue is about the situation where the user goes through a `create` prompt first, when `get` was the appropriate choice. We'd like to follow up by showing the `get` prompt we "should" have shown in the first place, but we'd like to be confident that we're showing the `get` fallback because of an excluded registration — not because of an arbitrary registration error.

Does that help clarify our concern?

* A trusted device can be here as well, but that's not relevant to the discussion about users without "normal 2FA".

-- 
GitHub Notification of comment by lgarron
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1566#issuecomment-782444786 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 19 February 2021 23:21:13 UTC