- From: Fredrik Tolf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 24 Feb 2023 22:19:36 +0000
- To: public-webauthn@w3.org
dolda2000 has just created a new issue for https://github.com/w3c/webauthn: == Clarify how to differentiate between exceptions == ## Proposed Change As far as I have been able to tell, exceptions from the WebAuthn UI interactions fall into three general categories, that are fairly important to distinguish: 1. Totally normal exceptions that the user initiated and is aware of. An example would be the user simply cancelling the interaction. The user is well aware of what happened and doesn't (shouldn't, in fact) need to be further informed of it. 2. Semi-normal abortions of the UI, that happened because of user interaction, but where the user may not know exactly what happened and should be informed of it. An example would be that, on Firefox, if the user uses an authenticator that doesn't contain any of the credentials among `allowCredentials`, Firefox simply closes the UI and returns this fact to the RP as an exception. The user might not be aware that he used the wrong authenticator and should be told about it. (Interestingly this seems to be different on Chrome, where the UI directly informs the user of this fact and offers to retry or cancel.) 3. Actual exceptional conditions where the RP did something wrong. An example would be providing malformed or otherwise invalid options objects. In this case, the RP should be able to tell the user that something unexpected happened and to perhaps contact support if the problem persists. However, I cannot find anything in the spec about how to make these distinctions, and neither have I been able to infer anything from actually observed exceptions. Exceptions that fall into different categories seem to commonly use the same error name, leaving only the exception message to infer anything from, but they are apparently primarily intended to be human-readable, localizable, and differ between different browsers. I am currently just relying on Chrome's behavior to directly tell the user of various aborting conditions (which is nice) and the complete and entire bug-freeness of my site, but obviously neither of those are particularly functional assumptions, and in fact on Firefox several interactions are quite suboptimal, so I'd really appreciate some clarity on the issue. Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1859 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 24 February 2023 22:19:38 UTC