Comment by agwa
8 days ago
Well, it's a fair question why Webauthn ended up so much more complicated, which has unquestionably been a hindrance to adoption.
8 days ago
Well, it's a fair question why Webauthn ended up so much more complicated, which has unquestionably been a hindrance to adoption.
Because the various cloud providers want to lock you into their own proprietary ecosystem, of course. How else could they in the future force you to pay a subscription to be allowed to log in to any website?
Backwards compatibility. Webauthn is the same standard that has been used for physical security keys for decades. Passkeys are a simplification UX layer on top of decades of hardware support and a complex ecosystem of key providers and key types.
1. It's not that complicated
2. The complexity in the standard is there to ensure things are done securely (think: not doing password checking via comparison loop).
3. The unnecessarily complexity in individual implementations in websites and passkey stores is due to general baseline corporate "incompetence".
Admittedly, my experience comes from OAuth and Webauthn. I have yet to try to implement passkeys. My exposer to passkeys comes completely from long blog posts complaining about it.
A passkey is webauthn you can use on another device, if you choose to store the key in a place that can be shared. Passkeys also include a protocol where you can log in over BLE from (for instance) your phone to your computer if you store your keys on a different device than the one you're logging into.
If you use webauthn, you're already using passkeys.
Passkeys is just a new brand name and UX flow on top of Webauthn. If you've handled Webauthn keys before you have already seen the code to "implement" passkeys.
Design by committee