[sebk]

100k devices is the minimum. Also I already agreed that this is an expansion of information, were it to be requested in practice and the user chose to provide it. And I don't believe the use case for attestation in enterprise settings is narrow. For the "own locked down devices" is that Enterprise Attestation exists, which has management overhead in both its configurations, wheras normal attestation does not.

I can't comment on the intent link, as there's no information. But the "practice" link is simply incorrect. Google does in fact allow a Yubikey to be used as a passkey, I have one configured myself. It shows up as "FIDO2 security key". What I assume is happening in that link you sent is that the user's yubikey does not have a PIN set for the FIDO2 interface, which means that it can't provide user verification and therefore is not a passkey as far as Google is concerned. This is the kind of reasoning about the capabilities of the authenticator that I was talking about, and it doesn't have to do with attestation.

> it's their job to build a standard that appeals to me if they want me to use it

They're appealing to OEMs, vendors and service providers as well. I also don't quite see how merely having attestation in the standard is harmful. RPs and users can chose not to require or provide it. If RPs decided they needed it for malicious purposes, would not having it in the standard suffice for them to be benign?

> That wouldn't solve any of my problems; the sync fabric isn't the important part -- I want to control my own keys.

It would, because then the sync fabric is free to provide you with an exported version that's wrapped in a key of your choosing. It's open in the sense that any one software can import/export keys out of hardware devices that are currently restricted to the hardware vendor.

[JohnFen]

> I also don't quite see how merely having attestation in the standard is harmful.

Because having it there makes it an option, and I think that history is pretty clear that if you give the tech industry a bat, they will beat their users with it sooner or later.

[danShumway]

> This is the kind of reasoning about the capabilities of the authenticator that I was talking about, and it doesn't have to do with attestation.

It seems like it does though... correct me if I'm wrong, but attestation is how Google knows that it's a Yubikey and that it doesn't have a PIN/biometrics set. And in practice, it's not allowed to be used to provide user verification; there's a restriction on functionality. Yes, you can use it as a Yubikey, but you can't use it for the new passkey system.

> For the "own locked down devices" is that Enterprise Attestation exists, which has management overhead in both its configurations, wheras normal attestation does not.

Good? Attestation should have an overhead. Getting rid of the overhead is exactly what I don't want. You can have attestation today through existing methods, and they're basically sufficient for enterprises that need them. It costs a bit of money, which is good because it'll force enterprises to think about it. And importantly, it doesn't really work for restricting consumer accounts, it's mostly useful for orgs where devices are controlled. Which is again, good, that's the best outcome. Enterprises can restrict their devices, but there are barriers to entry that prevent those restrictions from being applied to general consumers using their own devices.

The other thing you can do if you don't want to go the hardware route is you can have a custom login app for your enterprise. You shouldn't, you should provide users with devices if you're going to restrict those devices -- but there's nothing stopping an org from having a custom authenticator that works outside of the standard.

The only problem they'll have is if they want general users outside of the org to install that app just to log in. Which again, is very good. It's good that you can build a custom solution for within an enterprise, but that there are significant challenges in front of trying to force that solution on regular users.

Heck, you can even use the Play Integrity API to help. Should the Play Integrity API exist? No, probably not. But it does and it's usable for dedicated authenticators, so we certainly don't need another solution on top of it.

This is a rare use-case, and it's probably fine for the orgs that need it to use something other than passkeys. There's no real danger to them of lock-out, they're already doing this today so they can just keep doing what they're already doing.

> I also don't quite see how merely having attestation in the standard is harmful.

Because every single time that we've had attestation in the past -- literally every single time -- it's been used for DRM. Hopefully this conversation doesn't matter because Apple is just blocking attestation, but what do you see in the industry that makes you think this time would be different? Has something radically changed at Netflix over the past couple of years?

When has attestation ever not been abused?

Here's the Chromium team expressing similar fears: https://www.chromium.org/security-keys/ Are those fears unfounded? I don't generally assume that Google is going to be leading the charge on user freedom, and if even they are kind of creeped out about the potential here, then I trust that there's a real risk of abuse.

> It's open in the sense that any one software can import/export keys out of hardware devices that are currently restricted to the hardware vendor.

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.

[sebk]

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?