How should website authors "get or create"?

[lgarron]

Suppose a site is trying to implement "trusted device" functionality, as suggested at https://w3c.github.io/webauthn/#sctn-authenticator-attachment-modality.

The first registration is easy:

• Call isUserVerifyingPlatformAuthenticatorAvailable().
• If so, prompt the user to register a trusted device.

Suppose that the user now signs into another browser that shares the same platform authenticator (e.g. using Windows Hello).

Also suppose that the site would like the user to be able to associate the new browser with the existing trusted device, so that they can be managed together. (Among other things, this allows users to manage and trust actual physical devices like "Alice's Surface Pro" instead of browser sessions.) In this case, the site would need to either get which platform authenticator is associated with the existing device, or create a new one if needed. I see two options:

• Ask the user to register a device, and let the user run into a duplicate registration error. Then offer the user to associate the device instead.
• Ask the user "is this a new or an existing trusted device?" and show the corresponding prompt (with a fallback to the other).

Both of these cause "unnecessary" confusion for the user — compare this to the simplicity of authenticator flows for any native mobile app. Is there any way to avoid this, either with the current spec or any likely future changes?

[equalsJeffH]

I think your answers ought to be addressed in https://github.com/fido-alliance/how-to-fido/blob/master/HowToFIDO.md --- a subtle-but-important aspect of making this work smoothly is for the platform authenticator to support discoverable credentials, such that the RP does navigator.credential.get() using an empty allow list and the platform authnr can find the cred and utilize it, regardless of the browser that's being used at the time.

[lgarron]

I think your answers ought to be addressed in https://github.com/fido-alliance/how-to-fido/blob/master/HowToFIDO.md --- a subtle-but-important aspect of making this work smoothly is for the platform authenticator to support discoverable credentials, such the RP does navigator.credential.get() using an empty allow list and the platform authnr can find the cred and utilize it, regardless of the browser that's being used at the time.

Indeed, I'd love to be able to rely on resident key/client-side discoverable credentials. But since Android Chrome doesn't support them (yet), is there something better if we want to support all the major platform authenticators in the short term?

[ptoomey3]

such that the RP does navigator.credential.get() using an empty allow list and the platform authnr can find the cred and utilize it, regardless of the browser that's being used at the time.

Another point that has been fuzzy for me...when would a site know to trigger a call to navigator.credential.get() unless they are tracking state to know that a user has a credential and that a call to navigator.credential.get() is going to be useful? But, if the site is already tracking state to know that navigator.credential.get() is going to be useful, then they could also be tracking state to know which registration they should trigger the flow with anyway. I know there were privacy reasons why the API decided against letting a site query on whether there is a credential for the site available. But, it seems like the net result is that you kinda have to keep track of state to know when to use the API for a given user. And, once that state is lost (i.e. cookies are cleared), the RP is in a bit of a tough spot.

[equalsJeffH]

Though, I failed to note (apologies) that how-to-FIDO does guide one on how to have a good user experience even in the abscence of platform authenticator discoverable credentials. i.e., discoverable credentials are not necessarily essential.

[equalsJeffH]

We suggest further discussion of this be taken up at https://github.com/fido-alliance/how-to-fido/blob/master/HowToFIDO.md since there is not an issue here with the webauthn spec per se, and are closing this issue.