Re: [webauthn] Support a "create or get [or replace]" credential re-association operation (#1568)

To sum up:

1. The current paradigm creates a bad UX, because we have no way of knowing if a user has connected their current device to web auth, and so we either need to show them UI for both Create and Get paths, relying on their memory of what they have done, or we need to conditionally only show them the Get path if we "think" the user has connected their current device (based on some information passed to us from our backend), potentially causing the user to attempt web auth and fail if their connection has been destroyed for some reason.

2. Proposed Solution A is to implement a "Get OR Create" mechanism that handles the details under the hood. This would solve the primary issue but introduces other concerns around state / the desire for frontends to provide a bit of a custom Create path (eg; entering a custom "device name" to associate with the key).

3. Proposed Solution B is to implement a "does key exist" function that returns a simple boolean depending on whether or not the current device is indeed found in the list of allowed credentials. This would solve the primary issue but introduces possible anonymity / privacy concerns.

I would like to suggest 1 other option:

##Solution C##
Additional Error Codes

Currently, if a user attempts to Get credentials for a device that does not have any, they see some form of automatic "Passkey does not exist" UI, requiring the user to click a Cancel button to back out of the procedure.

The error thrown from clicking this Cancel button is a DOMException, with a name of "NotAllowedError". This is the same error that is thrown if a user DOES have credentials for their device but still opts to manually cancel out of the procedure.

If instead, a specific error was thrown in the case of the user not having credentials on their device during Get credentials, eg "NoCredentialsError", this information could be used to push the user through to the device registration UX automatically.

Further, a specific error was thrown in the case of the user manually cancelling the Get credentials process, eg "UserCancelledError", then we could back the user out of the process gracefully while using the NotAllowedError to explicitly alert the user that their device is not capable of providing credentials due to some permission issues.

This is similar to Solution B ("does key exist"), however the information of whether or not the credentials exist is obtained as a result of the user attempting to get them, instead of hidden from the user as a preliminary background step.

The benefit of this approach is we could also use the NoCredentialsError to:
1. Store some cookie on the device in order to avoid showing the Get flow and instead show the Create flow, until the user goes through with the creation. Meaning if they close the website entirely and come back, they won't need to go through this unhappy path again.
2. Automatically push the user through to the Create flow as a result of the NoCredentialsError, instead of continuing to rely on the user to figure out the correct path to take.






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


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

Received on Wednesday, 24 April 2024 18:21:09 UTC