zlacker

>>caust1+(OP)
This is an excellent write-up that finally motivated me to try to understand the mess that was left behind as new standards kept being layered on top of each other.

Given the requirement for discoverable credentials and sync, truly open/independent passkey implementations seem impossible/impractical. For example, you couldn't just have a set of Trezor-style devices that you load with the same seed and use that as your passkey without syncing the "discoverable" part of the credentials through some kind of cloud service. (The cloud service wouldn't need to be trusted with the actual keys, but you couldn't operate without it.)

As a result, it looks like you can essentially choose which ecosystem you want to lock yourself into...

With authenticatorAttachment, sites have been given a convenient foot-gun to make sure no single setup actually works for all sites, and with both the discoverable and non-discoverable credentials supported, inconsistency in the login flow for maximum confusion is guaranteed.

Add to it that this is like the 4th or 5th iteration of a standard in the field in about 10 years, and there's endless opportunity to get locked out because providers migrated from one standard (or buggy implementation) to another, or start setting things up only for the 6th standard to obsolete what you had (again, potentially locking you out).

And then people are surprised that users stick with passwords.

>>tgsovl+3D
Even the closed-system solution pose problems. I think it didn't get much airtime, but when Chrome switched their approach to save passwords, a lot of users lost access to their accounts. A case where a feature wasn't sensibly discontinued.

The workaround now isn't using passkeys, something few people understand. Instead most seem to be migrating to an external password managers. Honestly, I don't have many arguments against this as these at least generate save passwords. There are many advantages to this approach.

I believe moving forward, sticking to passwords might indeed be more viable. I think explaining users to upload their public ssl key is safer and more universal at this point.

>>raxxor+701
Passkeys are too complicated, so let's have users manage public keys manually instead? You can't be serious.

>>lxgr+RB1
except passkeys bought you a false sense of security and easy. yeah the happy path is easier because you're just generating new keys... but if the user ever gets a new phone or sit in front of another device, now passkeys are more complicated than the alternative.

sadly the world became too dumbly complacent to question their devices.