A passkey is just a "software yubikey". I highly recommend trying to implement a demo of this and you'll see how little difference there is between them unless you specifically go out of your way.
That's the point, if I'm reading this thread correctly. Google/Apple/Microsoft's implementation will be going out of their way to tie it specifically to a device and biometrics.
In fact, Google and Apple have recently started synchronizing Passkeys to the user‘s cloud account, which effectively undoes any specific device binding.
As a Relying Party, you can’t know what authentication method will be used for either enrolling a new device, or on the new device itself.
Glad to hear Apple's allowing import/export. The issue I was thinking of is setting up passkeys for your phone and now you can't use it on desktop, or switching to Android/iOS and it can't carry over.
> which is equally user-friendly, but which cannot be phished.
This is good to bring up. Without vendor lock-in and attestation, passkeys have huge benefits for blocking phishing attacks. It's not "stick with passwords" or "deal with lock-in", it's possible to get rid of the current problems and still end up with a system that's way more secure than traditional passwords.
> No part of the specification requires Google, cloud or third party trust.
AFAIK the only reason you need Google, Apple, or etc. is because the mobile OS needs to make the process of doing the bluetooth pairing between a random device and the phone seamless. Given the crap networking we have in the world you need a 3rd party everyone can reach to exchange the most basic information. Then everything is local via Bluetooth.
> The point is replacing passwords with something which is equally user-friendly, but which cannot be phished.
Yes, and biometrics (which pretty much everyone uses) are great! They're device ONLY. It's entirely a convenience feature that avoids needing to enter the Required To Setup PIN/Passphrase every time.
FIDO security keys don't store login-specific information. Passkeys do, which raises the lock-in problem.
To be clear, I want to be able to use passkeys, or something close, but I won't if I can't control my keys, and I can't if I can't use them cross-platform.
Effectively, they really do (yes, the Relying Party technically stored the encrypted credential, but to the user, their keys really "are in the Yubikey" in any meaningful way).
But more importantly, they (to my knowledge) don’t offer any in-ecosystem-only backup/sync functionality, which would make switching vendors that much harder and thereby create platform/vendor lock-in.
Security key backup was always the biggest obstacle. In principle you could create fungible keys flashed with the same private key, but in practice that isn't possible (outside of some obscure open-source implementations).
The second obstacle, of course, is the question: why do I need a separate microcontroller taking up a USB slot, when the host device is capable of running the same software? Passkeys do solve that (though so would soft-FIDO without resident keys), but the bait comes with the hook of vendor lock-in.
> In principle you could create fungible keys flashed with the same private key, but in practice that isn't possible (outside of some obscure open-source implementations).
> why do I need a separate microcontroller taking up a USB slot, when the host device is capable of running the same software? Passkeys do solve that (though so would soft-FIDO without resident keys), but the bait comes with the hook of vendor lock-in.
Trusted computing and vendor neutrality are unfortunately somewhat at odds with each other. Google has learned that the hard way with Google Pay – only when they finally gave up on Secure Elements (in favor of HEE and software-based OS attestation) did it become available on non-Google devices. The device vendors and mobile carriers (which control the SIM, the only other pragmatic trusted hardware).
It would be amazing if there was a sort of "embeddable Yubikey" specification that would allow you to, logically or physically, install your own Secure Element/TPM and have that be decoupled from both OS and OEM, but it would be a major upstream effort.
Current Yubikeys do allow you to store login information (Resident Keys in webauthn), and because Apple refuses to provide attestation for Passkeys, it's going to be very difficult for a website to force you to use a security key from any particular vendor.
Obviously Yubikeys (and most/all other hardware keys) do provide attestation, so in theory a website could refuse to let you register those -- but if that becomes common it would be easy for any company to create hardware keys which refuse attestation.
Higher Yubikeys do, but other FIDO2 keys, including Yubico's ‘Security Key’ series, don't.
Apple's current policy on attestation is good (for consumers; I don't deny there are closed conditions where you'd legitimately use it), but their refusal to allow 3P integration is not.
