Attestation doesn't carry that information. Also consider that Apple zeroes out attestation for its devices and works just fine with Google as passkeys. What's happening here is that when an RP is registering an authenticator, it can include a property that's called userVerification which in a Yubikey is backed by a PIN, and Google sets it as required. The restriction in functionality that you mention is exactly what Google wants though, but not for malicious purposes. Google doesn't want someone stealing your yubikey and having that suffice to log in to your account. They want user verification so that if that Yubikey is stolen, an attacker also needs to know the PIN, thus providing two factors. Again, Google does not prevent you from using Yubikeys. It prevents you from using security keys that aren't configured for user verification, and they don't do that through attestation.
> Right, but if you're talking about trusted devices, unless that's something the user controls, exporting/importing doesn't matter. The point is that the user should be able to export their key and import it to any authenticator they choose without fear that their authenticator is going to be blocked from logging in to a service.
No, not just physical devices. Anything that represents a device with a wrapping key. That could be a software implementation that's just a file you control. What I'm saying though is that for the general case which is what a standard is concerned with, we won't see the standard-mandated ability to export passkeys across sync fabrics. I don't see a world where you can export passkeys from Apple iCloud Keychain and import them into Google Password Manager. But I do see a world where you create passkeys in your Mac with KeePassXC, and can use an open sync fabric from KeePassXC to sync them to your Android device, and a flat file as well, and I believe this will happen not under the purview of FIDO. Whether those flat files can then hop on to another sync fabric (say, 1Password) to later be imported into hardware devices will definitely not be a part of a standard, but given the analogy to password managers, it doesn't matter; those capabilities can still be built.
As far as the Chromium post, I find that one slightly more dystopic than attestation as a feature. They say If Chrome becomes aware that websites are not meeting these expectations, we may withdraw Security Key privileges from those sites, and similar other warnings. They don't say that they will warn users, they say that they will withdraw privileges. Do you want your browser deciding for you what websites you can log in to?
> Right, but if you're talking about trusted devices, unless that's something the user controls, exporting/importing doesn't matter. The point is that the user should be able to export their key and import it to any authenticator they choose without fear that their authenticator is going to be blocked from logging in to a service.
No, not just physical devices. Anything that represents a device with a wrapping key. That could be a software implementation that's just a file you control. What I'm saying though is that for the general case which is what a standard is concerned with, we won't see the standard-mandated ability to export passkeys across sync fabrics. I don't see a world where you can export passkeys from Apple iCloud Keychain and import them into Google Password Manager. But I do see a world where you create passkeys in your Mac with KeePassXC, and can use an open sync fabric from KeePassXC to sync them to your Android device, and a flat file as well, and I believe this will happen not under the purview of FIDO. Whether those flat files can then hop on to another sync fabric (say, 1Password) to later be imported into hardware devices will definitely not be a part of a standard, but given the analogy to password managers, it doesn't matter; those capabilities can still be built.
As far as the Chromium post, I find that one slightly more dystopic than attestation as a feature. They say If Chrome becomes aware that websites are not meeting these expectations, we may withdraw Security Key privileges from those sites, and similar other warnings. They don't say that they will warn users, they say that they will withdraw privileges. Do you want your browser deciding for you what websites you can log in to?