2

I'm currently in the process of evaluating the implementation of WebAuthn/Passkeys on a website, and one thing that I'm having trouble finding information on is what exceptions from the WebAuthn API the user should be notified about.

There are many conditions in both the create and get functions on PublicKeyCredential that throw exceptions, and I find that these fit in three broad categories:

  1. For many exceptions (arguably the most common ones), the user is already well aware of the condition and any notification about it would just be weird. These common cases include the user simply cancelling the transaction. Handling these should just be silent.

  2. There are other conditions that the user should probably be made aware of. For example, if my options object is malformed, the browser encounters an internal error, or some other actual erroneous condition occurs, I'd like to at least notify the user that an error has occurred. The "silent treatment" is very weird in these cases.

  3. Confusingly enough, there are also some conditions that seem to differ from browser to browser. For example, if the key the user decides to use isn't in the allowCredentials list, Chrome will notify the user of this in its WebAuthn UI and allow the user to retry or cancel, whereas Firefox will close the UI and report that condition to my script as an exception instead.

So my question is: Is there any way of distinguishing these conditions, either formally specified or otherwise? I haven't found anything in the specification, but it's rather long and I wouldn't be surprised if I've simply missed it. If there isn't, I'm not sure what the alternative is. The same exception type is reused for many different conditions, and the user-readable messages aren't standardized across browsers.

If there isn't a way to do this, I'm kind of on the edge if supporting WebAuthn/Passkeys is even a good idea.

Dolda2000
  • 25,216
  • 4
  • 51
  • 92

1 Answers1

2

This is a great question, and you've called out some really important considerations that lead to issues with error handling in WebAuthn scenarios.

If you scroll down to the end of the spec, to the Terms defined by reference section, under "[WebIDL] defines the following terms", you'll find a list of error types (ex. ConstraintError, EncodingError, etc...). These definitions will link to the areas in the document where each error type is related.

From experience, it might help to look at errors through three different buckets:

  • Errors from the relying party
  • Errors from the client/platform (browser, os)
  • Errors due to user action

For the most part, errors from the first category will be out of the users control (Maybe your RP sends a malformed PublicKey options object). With errors like this, it's important to let the user know something was wrong, and to consider contacting support as there may be an issue with your app.

The second category is tricky. Errors from the client can be a variety of things. Maybe the OS doesn't support discoverable credentials, maybe autofill/conditional Ui isn't supported, maybe your client app caused the PublicKey to become malformed. While these issues can be due to a user's action, the blame falls more on the client/platform that may not support the implementation.

In this case, you can't display an error message saying "this platform doesn't support discoverable credentials" - normal user's aren't going to know what that means. IMO, handling these errors is less about showing an error message, and more about preventing the user from taking an action they have no control over. (ex .If a client doesn't support autofill, then leverage another auth mechanism)

Last but not least are errors due to user action. Maybe the user cancelled the ceremony, maybe the user didn't perform UV when it was required, maybe the user tried to register a credential already in an allowCredentials list. In this case don't directly display the error provided by the client - try and come up with a user friendly message the constructively helps the user understand what they did wrong.

I hope this helps - sadly this issue isn't as clear cut as a single technical solution, and will continue to evolve as changes to the spec are made.

Cody Salas
  • 431
  • 1
  • 6
  • 2
    Your categorization seems to agree fairly well with mine, but the real problem is that I see no way to distinguish between these categories with any information that can be gleaned from the exceptions. – Dolda2000 Feb 21 '23 at 19:00