- From: Matthew Miller via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 May 2024 22:08:15 +0000
- To: public-webauthn@w3.org
> Please keep in mind the concern that WebAuthn should not leak information about whther or not the user has credentials to the RP without user consent. Good call out @sbweeden, this has been top of mind for me since I started pondering improved error messaging. Previous conversations over the years have made it clear that any changes to error messaging without a user interaction before it is verboten. @AdamEisfeld's proposed changes require user interaction, and the additional error messages I'm proposing below do as well. Earlier this week I met with some colleagues internally and brainstormed some new error messages that would be nice to have as an RP that wants more visibility into why users are having issues signing in, and to potentially offer inline remediation advice: ## `NoCredentialsError` and `UserCancelledError` We independently came up with the same two `NoCredentialsError` and `UserCancelledError` errors that @AdamEisfeld has already proposed, so I'm in support of these. For `NoCredentialsError`, we agree that if the user cancels out of the browser's "you have no credentials for this site" it necessarily means they tried to auth. That should count as consent, so why not let that propagate through to the RP? For `UserCancelledError`, it would be great to pull this out of `NotAllowedError` as a new default error that gets returned **after the user specifically cancels out** of the modal experience. `NotAllowedError` is currently so overloaded it's difficult to understand whether the user experienced a legitimate issue with their browser + OS + authenticator, or simply decided to cancel out. ## `HybridPrerequisitesError` The thinking here is that there are prerequisites that must be met for the browser and/or platform to facilitate successful hybrid registration and auth. If these prerequisites aren't met, and the browser notifies the user of it...    ...why not let this propagate through to the RP **after the user cancels out**? In response to this the RP could e.g. show custom UI to guide the user through setting everything up to try again. ## `UserHybridCancelError` Currently, browsers typically show the hybrid QR code to users when `allowCredentials` contains no locally usable credentials. An RP that could catch this kind of error **after the user cancels out** could better understand that the user cancelled out of the auth because they didn't know how to proceed, and guide the user accordingly. Right now there's no way to understand this because an RP would receive a `NotAllowedError` in response to the user cancelling the modal experience. ## `UserVerificationError` Passkeys are typically paired with a requirement to perform UV, both during registration and auth. If **the user clicks through the modal experience** to create a passkey or try to auth, but has no authenticator available that can perform UV or can't enter the correct PIN or scan the correct biometric, can WebAuthn not let the RP know that that's why the user failed the ceremony? The browser definitely tells the user that this is the case...  _U2F token in a `userVerification:required` registration ceremony_  _Security key PIN entry issue during auth ceremony_ ...so why not propagate this through to the RP? I also pondered breaking this one up, into two separate errors: 1. `UserVerificationSupportError` (e.g. U2F token when UV is required) 2. `UserVerificationCollectionError` (e.g. User can't enter correct PIN or scan correct biometric) ...but maybe these are less useful/too complex for a single "`UserVerificationError`" 🤔 ## `TimeoutError` If the user clicks to start a WebAuthn ceremony but gets distracted and walks away to the point that the ceremony times out, couldn't that signal be sent to the RP? It's not quite a true "error" that happened, which it can currently appear to be due to the currently ambiguous `NotAllowedError`, but would be helpful nonetheless in understanding that nothing actually went wrong during the ceremony. --- Anyway as I mentioned earlier these were new errors that came out of a brainstorming session. I'd love to hear your thoughts, and welcome any suggestions from other RP's on other types of errors that we could try to incorporate into WebAuthn for sake of better understanding of the user's interaction with WebAuthn. -- GitHub Notification of comment by MasterKale Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2062#issuecomment-2093823953 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 3 May 2024 22:08:16 UTC