Re: [webauthn] Provide a mechanism to indicate backend registration success or failure (#2067)

@arianvp Yes, I think we're reporting effectively the same thing.

It was a browser bug rather than adverse network conditions that prompted me to suggest this, but the end result is about the same. There's also the (less important compared to end-user experience) matter of developers being stuck with dozens of passkeys when trying to initially build out an integration.

@timcappalli That's great additional context - and I fully agree that anything here is necessarily opportunistic (if only for BC reasons). I tried to touch on that with the "AND the created credential is discoverable" bit, but there's room for improvement in specifics. My thinking is probably best summarized as "opportunistic two-phase commit" though that's still somewhat of a misnomer.


After sleeping on the concept, I think the report API is (assuming widespread adoption and certain implementation details) enough to _eventually_ resolve the issue, but I'd like to consider an additional real-world scenario before calling it sufficient:

1. A user tries to register for a service using a passkey. In the event that a credential doesn't get registered with the RP (due to an implementation bug, bad network, etc), the user is almost certainly _already_ having a bad and confusing experience. My real-world experience is getting stuck indefinitely on a loading spinner or equivalent, or being provided zero feedback whatsoever.
2. After this happens, let's assume the user refreshes the page. The page's UI might be structured where there's a dual-purpose form, such as a register flow that also adds `autocomplete="username webauthn"` and runs the conditional flow to sign in. The user focuses the field and is prompted by the browser to use their (useless) credential
3. That auth attempt of course fails, the user is perhaps shown an error message. They're now _incredibly_ confused and frustrated. Perhaps they write to support (who's also confused, as they don't see an account for that user), or give up outright. They could be so annoyed that they swear off using passkeys on any other site.

Even if during the third step the RP uses the Report API[^1] in response to the failed auth attempt to invalidate that credential (which could result in a less-confusing _second_ auth attempt and hinting the user towards trying to register again), their frustration and confusion levels are probably through the roof - likely to the point of giving up.

My thinking is that if there's an additional API to support this during registration, RPs can _significantly_ reduce user confusion and frustration by heading off the problem after step 1 rather than after step 3.

This behavior is also more or less **how password managers work today** - they tend to not immediately save the password on form submit, but rather _once the next network request comes back `OK`_. What we have today for webauthn and specifically passkeys is in practice a step backwards on that narrow aspect, so I'm hoping we can close the gap in the next version of the spec!

[^1]: I'm also assuming that the API would _always_ result in the credential being removed when called. Unless the spec were to indicate otherwise, I suspect browsers or credential managers might refuse to remove the _last_ credential for an RP in an effort to prevent account lock-out. If they were to do that, the user is still left in the lurch.


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


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

Received on Saturday, 4 May 2024 18:14:25 UTC