WebAuthn.wtf
webauthn.wtf
webauthn.wtf
For example: Apple native (not) allowed, 1Password (not) allowed, Bitwarden (not) allowed, KeePassXC (not) allowed, etc.
Example for Yubikey
https://support.yubico.com/hc/en-us/articles/360016648959
So you could technically restrict which FIDO2 key models are allowed at the server level.
For attested authenticators, the server needs to have a way to keep a list of them. I know some bank/finance sites (Vanguard I think is one) restrict to Yubikey or historically have restricted to that.
For non-attested authenticators, the server could unreliably fingerprint the response and decide to selectively allow. Obviously this is completely spoofable, if it's differentiable at all.
Currently, iOS zeros out attestation information for roaming keys, but that's not dictated by the spec and different authenticators may choose to provide attestation.
----
Relying Parties can also specify feature requirements for user validation/verification:
> The user verification requirement. The ability to provide user verification enhances the security of the ceremony, but it may not be necessary for all use cases.
Interestingly, user verification can not only be required, it can also be discouraged(https://www.w3.org/TR/2021/WD-webauthn-3-20210427/#enum-user...):
> This value indicates that the Relying Party does not want user verification employed during the operation (e.g., in the interest of minimizing disruption to the user interaction flow).
And they can indicate that they only want to be used with a platform authenticator instead of a roaming authenticator.
----
Of course, without attestation there is no way to force the authenticator to actually do anything that is asked of it or to identify itself in any way, but it can be assumed that most 3rd-party authenticators are probably not going to lie? Certainly not if they're trying to get certified.
Relying parties can set preferred authenticators and they can query authenticators on a device to get a list of discoverable keys, but I'm not sure if there's any expectation that platforms should refuse to work if a preferred authenticator isn't present.
----
There's more information at https://webauthn.wtf/how-it-works/registration#the-options and https://www.w3.org/TR/2021/WD-webauthn-3-20210427/#dictionar.... In particular, Relying parties can dictate that duplicate passkeys should not be created for an account. They can also specify extensions that open the door to other requirements:
> This member contains additional parameters requesting additional processing by the client and authenticator. For example, the caller may request that only authenticators with certain capabilities be used to create the credential, or that particular information be returned in the attestation object.
To me, https://www.w3.org/TR/2021/WD-webauthn-3-20210427/#dictdef-a... seems to suggest that specific authenticators can be required, but I very well could be misreading that section, so don't quote me on that. And again, without attestation, there's nothing to prevent an authenticator from lying, but... will they lie if push comes to shove? And will the FIDO Alliance tolerate that?
----
In general, the FIDO Alliance's attitude towards all of this is "yes, we're giving Relying Parties a ton of power, but come on, it's not like they would ever use it." There is no requirement in the spec that I'm aware of that would dictate that certified Relying Parties must be vendor neutral and must not try to restrict smaller authenticators.
I don't want to have to drive to my parents/bank safety deposit box each time I register on a new website
(and allowing the private key to be exported and shared defeats the point entirely)
> WebAuthn is supported by a wide range of devices and platforms, including desktop computers, laptops, smartphones, and tablets. Check out passkeys.dev for more information on device support and compatibility of passkeys across different devices.
And then the support table is at https://passkeys.dev/device-support, via website that is maintained by members of the WebAuthn working group.
Still no real Linux support, general Linux is still not listed as a target for support, only Ubuntu. The most important support categories have no support planned according to the passkeys.dev website.
And no, FIDO hardware keys or cross-device authentication are not sufficient support, as this site itself admits:
> One option is to register passkeys on two devices: one that is carried for everyday use and another that is kept in a secure location as a backup. That solution is cumbersome, and most people are not going to bother.
If you only have a phone and a Linux desktop computer, it means that backup that's available immediately on multiple devices is going to be much more difficult.
Of course, the Passkeys.dev site is out of date; in theory 1Password can actually be used as a local provider on Linux (although I haven't tested it, so in before I'm wrong about that). 1Password is proprietary and doesn't allow export currently, but even so you'd think that the site would be updated. But nah, we'll just force everyone with questions to browse blogs and Twitter to get them answered. It's a fun scavenger hunt we're all doing where we try to figure out where the heck Passkeys can and can't be used.
----
Also no mention at all from either site about cross-ecosystem compatibility (ie, export/import); it's nice that passkey proponents have done a 180 from "ecosystem transfer is harmful and shouldn't be supported" to "of course we always intended to support ecosystem transfer and it's definitely coming" -- but again, would be nice to see anything at all official about that or a timeline. Why am I finding out about cross-ecosystem compatibility from Reddit posts, isn't there an alliance somewhere around here made up of some of the richest companies on earth that could help with messaging?
----
Passkeys have the potential to be great, but they are early development, they have heavy caveats, there are problems with the spec, and they are being recommended to people today even though there is no officially advertised Open implementation for local providers that works cross-platform (Bitwarden support hasn't launched yet, and I haven't been able to find another Open Source provider advertised through FIDO's certification program). So in their current state they are objectively, factually, vendor lock-in, even if that is intended to change in the future.
They shouldn't be recommended to ordinary users today, it is irresponsible for tech companies to be advertising them in a half-finished state.
----
This website appears to be a 3rd-party effort, so it's unreasonable to blame it for the problems that the actual FIDO Alliance has with messaging and communication and development priorities. The company that made this site very likely has no power to change anything about what the FIDO Alliance is doing.
And it's good to get more informative resources about Passkeys, I particularly appreciate clear developer guides around providers. So I don't want to make it sound like I'm complaining about the site; I'm happy that FusionAuth set this up. And FusionAuth is aiming this site primarily at developers, not users, so I'm not even mad about that.
But it's still kind of a band-aide over communication problems that the FIDO Alliance itself needs to address, and it papers over the reality that passkeys in their current form aren't ready for normal users yet. Stuff like export/import isn't optional; if I can't export keys from iCloud or Android, then passkeys are not ready for normal users.
> What is not working / is missing / won't be implemented:
> Some extensions are still missing (authentication doesn't support them at all, yet).
> Support for Resident Key.
> Support for triggering unlock from extension.
> Support for root certificates.
> Support for PIN/TouchID when authenticating.
> What is not tested:
> Support for Passkeys with Google/Apple and other common sites
So... can anyone confirm to me whether the passkey implementation in KeePassXC actually works with any of the sites implementing passkeys? I'll be happy if it ends being great and works everywhere. But what should I take away about the spec that the developers who have implemented the spec in KeePassXC aren't certain whether it will work with every site that claims to support passkeys?
I know it won't work with any site requesting hardware-bound keys: https://fosstodon.org/@keepassxc/111301312353785552
I'm happy for KeePassXC to add support, it's a big deal, but it seems pretty early to say, "see the Linux situation is solved now." I go back to the complaint about passkeys being recommended for people to use today, even though they're still kind-of half finished. This is on a release candidate branch, and we're already acting like Linux is just supported now.
Never mind the fact that it's a partial implementation, never mind the fact that we have no idea if browsers like Chrome will allow KeePassXC to be treated as a platform provider without installing an additional extension to bypass the browser's built-in behavior. Never mind the fact that its import/export format only works with itself. Linux is supported now and you can export your keys, what's the problem? /s
----
And ignoring all of that, if Linux has support now, I would repeat: why do I need to find out about this on Mastodon? Seriously, the FIDO Alliance is made of the richest tech companies on the planet. Why is the official user-facing dev site -- a site maintained by W3C members and organizations -- giving incorrect information?
Why are supported features, goals, and timelines being communicated entirely via social media?
Linux situation is definitely not solved yet, and some sites still ignore Firefox because of missing support. The only reason I mentioned KeePassXC because it's the first free and open source solution that actually supports importing and exporting Passkeys. Even if it's still beta/rc phase.
Every other password manager browser extension injects same kind of scripts to every page (1Password included), because browsers lack an open API for WebAuthn.
I'm just frustrated about stuff like this:
> and some sites still ignore Firefox because of missing support
> Apple does not work because they have restricted the Passkey creation outside the browser.
> Every other password manager browser extension injects same kind of scripts to every page (1Password included), because browsers lack an open API for WebAuthn.
These are all failures of the FIDO Alliance. This is a really bad position for implementations to be in, and it is on the FIDO Alliance that doing things like restricting passkey creation isn't a blocker for certification. It's on the FIDO Alliance that there are recommendations going out from passkey providers that ordinary users should start using passkeys via browser extensions when there literally isn't an API for those extensions to hook into yet. If sites are blocking log-in from browsers even just via user-agents, that's on the FIDO Alliance for not shutting that crap down, especially in the occasional instances where the companies doing it are FIDO Alliance members.
Passkeys just aren't ready. It's a technology that is conceptually really cool that could in an alternate universe be easy to recommend as a full replacement for passwords -- but because it's getting rushed out with serious caveats and with a complete disregard to user autonomy and freedom or even just consistency between implementations, the first experience most users have with this is going to be awful.
Honestly, it's a failure of the FIDO Alliance that to talk about Linux support I need to know the difference between a hardware bound and roaming key; that is too much complication for a password replacement. Especially when the actual documentation about which platforms support what is basically nonexistent. It's just a giant incomprehensible mess.
----
To kind of emphasize the point: I can't give you a genuinely confident answer about whether or not Linux is intended to be able to support devices without gesture or biometric support. KeePassXC doesn't require this as far as I can tell, and nobody is shutting them down so maybe it's OK? But also there is no official acknowledgement outside of social media from the FIDO Alliance that this exists (at least, not that I can find anywhere), and from my own reading of the WebAuthn spec my instinct would have been that biometric/gesture support (validation of user presence) is a device requirement in the spec and that pins aren't a substitute.
Am I reading wrong? Is this just a part of the spec we're ignoring? Is KeePassXC doing something behind the scenes to get around that requirement? I don't know. Sure would be nice if there was an Alliance that could clarify those things in official documentation on a user-facing site. But I guess in the meantime I can settle for more Arstechnica and EFF articles about how you should consider using passkeys today...
Not your fault, it was good for you to point out KeePassXC. I just don't want people looking at that and saying, "oh, so the Linux situation is solved." It's not only not solved, I don't think I could give a fully accurate description of what the Linux situation even is or what the main problems are standing in front of it, because the current status of the blockers are ambiguous and messy, and the FIDO Alliance does not seem to think that is a problem that is has any obligation to care about.