I don't understand which part of FIDO/WebAuthn requires "trusting Google or Microsoft"?
The only part where MS comes into the picture is the "Microsoft Windows" sticker on the bottom of the laptop, since HP shipped windows pre-installed.
We shouldn’t be forced to spend money at any company. Where are the Free (beer and Libre) methods??
I think there was also an implementation for mac os based on the t1/t2 chip, but since I've never had such a mac, I've never looked properly into that. But that probably means that you could roll your own.
A quick google search yields this for Linux with a TPM: https://github.com/psanford/tpm-fido
But ultimately you need to get some hardware _somehow_ which costs money, though some conferences give out free Yubikeys (or equivalent) and most enterprises would provide them to users directly.
Sadly enough it's a near guarantee that the less secure implementations of passkeys (the software ones, allowing cloning and backups in the cloud) are likely to be the most accepted.
While actually secure implementation with the secret hidden deep down behind an HSM and never leaving it, made by smaller companies who do care about security, are likely to be rejected on the ground that it's too much of an "obscure" vendor.
I already posted about it today but if you think about it it's literally insane that cloning was meant to be detectable (and detection was enforced and upon detecting a cloned key, one of the two keys would stop working) and that this feature has now been removed with the sole justification being: "Because software backups to the cloud".
It is not good.
That's an excellent way of telling your customers you want them to go somewhere else. What's the upside?
There's also the AAGUID, but without attestation, every implementation is free to provide Apple's or Google's, should websites ever start requiring that.
If Google wants to only accepts its own Passkeys to log in to your Google account, that's as much its choice as any other site has for its authentication.
A site having the technical ability to determine not just its authentication mechanism but how that authentication mechanism is stored is not its choice and should not be its choice and is not its business.
And its a clear degradation in user freedom over passwords, a system where it's impossible for Google to dictate that you use only a specific password manager to store and sync that password. It shouldn't be possible for Google to know how I'm storing a passkey.
It's not their right to decide anything about that. They've never had that right. We're not taking a freedom away from Google, we're saying that Google should not have the ability to take away a freedom that we've always had, because they're our devices and it's our login information; it doesn't belong to Google.
It's honestly kind of the best possible situation short of attestation being outright removed from the spec. My bank doesn't understand "I should be able to use real 2FA instead of a text message", but they will understand "I should be able to log in from a Mac."
Removing it from the spec would be better for precisely this reason, but making it harder to use is the next best answer. Bing AI's browser restrictions for example are a pretty big restriction on the service -- that comes with penalties that will discourage many sites from going down that route.
If Google also drops attestation for synced keys then it would become even harder to use attestation, and harder for Apple to go back on its decision. But yes, you're right, it would be better to have stronger guarantees about the future.
If that site is legally held liable for fraud happening due to credential compromise, as (hopefully!) would be the case for e.g. consumer bank accounts, I'd say there is at least some legitimate interest.
I kind of disagree honestly. I think consumer bank accounts are some of the least secure accounts I have online. My consumer bank account has removed 2FA options over time. They've literally gone backwards on security.
I don't think there's much evidence that holding banks liable for fraud means that they're going to responsibly make their services more secure. Consumer banks in the US at least are wildly behind the times on account security, and I really don't trust them to make choices about what device I use.
What I do think banks do is invest a lot of effort into looking secure, and I think that stuff like attestation would (if supported) provide an easy mechanism for them to look secure at the same time that they allowed anyone to get into my account with just a social security number and my mother's maiden name. So I feel like, don't even give them the option. There's so much they can do to improve security before we ever start talking about requiring users to use specific hardware devices. Let's have them catch up on basic industry practices before we have that conversation.
EU regulations require 2FA both for logins on unknown devices and for every transaction initiation (whether on a known/trusted or new session), for example. Often, this happens in the form of dedicated "authenticator apps" that currently take quite frustrating/ineffective security measures like trying to detect whether the device is rooted.
Attestation could at the same time make this actually secure and give users more freedom to e.g. use whatever OS/mod they want to (since the actual root of trust would be an external authenticator or potentially their phone's TEE/Secure Element, not the OS).
But we don't have those regulations in the US, and banks here shouldn't have access to this. We are so behind on security, it just doesn't make sense to give them yet another tool to lock down devices while they're ignoring everything else they could be doing. I would at least advocate for some kind of pact from FIDO Alliance members that attestation will only be implemented for devices sold in countries that have that kind of regulation.
Or, maybe there's a way to do attestation where it's entirely user opt-in and isn't something that the service provider can dictate? Or maybe there's a way to do it where it can't be used to verify the OS/manufacturer during signup, and can only be used to verify that it's the same device where the credentials were created? I think I'd be OK with that existing.