zlacker

>>caust1+(OP)
There are some hairy edge cases during registration that many get wrong. (At least GitHub and google had this bug) that if create() returns but the passkey never reaches the server due to bad networking conditions that your password manager thinks it can log in but the server never recorded the passkey for the user. Basically there is no transactionality and you can get in a split brain situation where your password manager and your server don't agree and it's very confusing for end users.

https://github.com/w3c/webauthn/issues/2038

They apparently came up with a fix for this using something called Signals API but I don't think any browser implemented that yet.

Just wanted to highlight that this part of the UX is hairy and hard to get right

>>arianv+Lx
Chrome on desktop did: https://developer.chrome.com/docs/identity/webauthn-signal-a...

>>arnarb+vC
now just 27 absurdly insane implementation hacks to solve.

webauthn is the only spec born like a 60 yr old legacy technology with global adoption. everything about it is insane.

they didn't even think about having more than one key plugged in (mostly because the use case was just so that the device own your identity so they never thought the use would have control over the hardware), and the solution is to just blink all the keys and use the first one the use touches while hoping the other keys with timeout before the use actually have to use them. so much insanity.

>>1oooqo+kE1
“They” in this case included me and this was a deliberate fix for poor UX many years ago. We definitely thought about it and we used to blink only the key that had a credential from the allow list, because like you we thought that made the most sense. But people got routinely stuck because they just tapped a different key out of habit and nothing happened. There was no way for the browser to tell them “not that key”. Best case the reports would say the key was dead because it didn’t blink.

We changed it to blink all keys, so that if you tap the wrong one, the browser can at least tell you something sensible and get you unstuck. This wasn’t a hypothetical shot in the dark, but something we tested and actually worked well for real users.

I don’t disagree that WebAuthn has grown well beyond anything we could call good spec design. But it’s worth remembering that there’s /a lot/ of context behind it, and that the average user doesn’t behave anything like an average HN reader.

> hoping the other keys with timeout before the use actually have to use them

Both Chrome and Android will cancel requests to all other keys. If your keys are locking up until a timeout it’s more likely the key itself is buggy.

>>arnarb+gt2
that's the kind of compromise you don't want to see on authentication code though.

that's just the one i hit yesterday. Making software do crazy things "for the uneducated user" is a sure way to alienate both.

but anyway. what bothers me most about passkey is that tomorrow someone will realize requiring passkeys trhu google and apple only, cuts spam more than captcha. it will happen and everyone knows it.