One issue is the limited support for resident keys on many hardware tokens. IIRC the limit on recent YubiKey 5 firmware versions is 25 resident keys. As Passkey adoption accelerates, people will hit that limit rather quickly.
Also the UI around managing resident keys is not great and uncoupled from where they are typically used (the browser).
Finally, only a tiny part of the population uses dedicated hardware tokens, whereas pretty much all popular password managers supports or will support Passkeys (Apple Keychain, 1Password, whatever the Chrome password manager is called, Samsung Pass, etc.).
So, it’s not surprising that hardware tokens are tested less these days.
(I don’t think that is a good, just trying to speculate on the reasons.)
> Also the UI around managing resident keys is not great and uncoupled from where they are typically used (the browser).
Chrome allows you to see stored resident keys and delete individual resident keys on any hardware token which supports CTAP 2.1. (to be fair, it is a bit hidden: Settings -> Privacy and security -> Security -> Manage security keys -> Sign-in data).
I don't think discoverable credentials on hardware authenticators are a good default pattern (even though requiring(!) resident/discoverable keys is the suggested behavior [2] by the FIDO alliance!?)
They have their uses for special use cases for authentication against local or otherwise non-synchronized relying parties or as a component of authentication protocols that aren't a good fit for native WebaAuthN (like SSH), but a regular old website can just ask me for my user ID (which is my email address in 99% of all cases).
Unfortunately, there isn't [1] a way to say (in WebAuthN API terms) something like "give me a discoverable credential if you have unlimited storage, otherwise nevermind", so as far as I understand, a relying party can only say "preferred" (taking up a scarce slot on a HW authenticator) or "discouraged" (making a platform credential non-discoverable needlessly, except on platforms that ignore that flag anyway like Apple/iCloud Keychain).
As an aside, that issue [1] having been closed without any accomodation for that use case fits with my anecdotal observation of the WebAuthN working group having largely pivoted towards the "Passkey paradigm". Hardware authenticators somehow don't feel like a first-class API concern anymore.
I'm kinda hoping Yubi come out with a version 6 with many more "passkey" CTAP2 slots too. Because I don't only use FIDO functionality but I heavily use the OpenPGP slots as well. Not for email but for other things (file encryption, password manager, SSH). Not planning to change any of that to fido any time soon either.
Yeah, but without resident keys you’ll have to carry a file containing the key handle around with you from computer to computer (where you want to use the Yubikey-resident SSH key). And if you ever lose the file, your key is lost too!
This is because SSH doesn’t have a centralized RP model that’s kind of implied in FIDO and WebAuthN for non-resident keys.
Also the UI around managing resident keys is not great and uncoupled from where they are typically used (the browser).
Finally, only a tiny part of the population uses dedicated hardware tokens, whereas pretty much all popular password managers supports or will support Passkeys (Apple Keychain, 1Password, whatever the Chrome password manager is called, Samsung Pass, etc.).
So, it’s not surprising that hardware tokens are tested less these days.
(I don’t think that is a good, just trying to speculate on the reasons.)