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.
Sure, not having to type your username is nice, but I'll gladly still do that if it allows "passphrase-based paper-restore-able authenticators" such as the one you describe. (I have one of these, in fact!)
Many services I use that do support WebAuthN allow either variant to be used (i.e. they'll prefer discoverable credentials but will work just fine with non-discoverable ones), and arguably that should be how almost everybody ought to implement it.
Unfortunately, at least as many other services completely botch it, e.g. by making discoverable credentials mandatory, by allowlisting browsers (e.g. Paypal), allowlisting authenticators (e.g. my government's e-signature platform), or by using them in a functionally braindead way (e.g. Amazon, who for completely unfathomable reasons still requires TOTP behind WebAuthn, i.e. they replace the password with it, not the second factor).
So far I haven't noticed a strong trend towards enforcing discoverable credentials, but let's please name and shame everybody doing that. It's completely unnecessary.
IMHO that and a TOTP seems to be a sweet spot.
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.
If you don’t offer password as method I will not use your service. The worst are those that only offer code via email/sms or social login - miss me with that …
2 factor authentication using 2 simple mechanisms is great.
Password for most cases. And then in high value things, ask me for 2FA. For things like banks and anything money related, SMS 2FA already exists and is good enough. For normal websites, uncommon yet important actions, such as logging in (everyone can use long lived sessions these days), repo deletion on GitHub, etc, ask for me for 2FA.
TOTP is also a really nice mechanism, especially in authenticator apps today that can backup your keys to cloud storage.
I know "SMS" and "backup keys to cloud storage" gets the security folks off their chairs, but outside a theoretical setting they're both a perfectly good tradeoff.
I'll still take them over SMS-OTP any day, but admittedly even that at least offers some technical benefits over TOTP, e.g. in that the relying party can tell me what I am consenting to in the message ("by entering this code, you approve a payment of $1000 to evilshop.com").
sadly the world became too dumbly complacent to question their devices.
Would you argue that loading a public key (load it where, actually?) is much faster? How'd you do it practically?
The problem with "many" is that unless it's 100% of the ones someone cares about, the solution can't really solve the problem, adding an additional pain in the ass and making it easier to just stick with passwords.
Sometimes, a lack of choices is a feature. (Compare e.g.: IPSec vs. Wireguard).
yes, when you get your phone stolen in a trip and can't log into anything.
or when you realize nobody cares for the 5 nerds using those and require an apple or google passkey.
> Sometimes, a lack of choices is a feature. (Compare e.g.: IPSec vs. Wireguard).
HTTP vs. HTTPS seems like a more appropriate comparison in this context. Passwords and OTPs are really, really phishable.