[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?

[JohnFen]

> Google doesn't want someone stealing your yubikey and having that suffice to log in to your account.

But it's not Google's place to make that decision for me.

[danShumway]

> Also consider that Apple zeroes out attestation for its devices

This may be the saving grace because it may end up being that whether or not attestation is part of the standard doesn't matter because companies won't be able to use it. But it doesn't mean that attestation is harmless, it means that we're very lucky that (for now) Apple is deciding to effectively make it impossible for a commercial service to actually use it reliably.

> It prevents you from using security keys that aren't configured for user verification, and they don't do that through attestation.

Fair point, I don't know that this is actually using attestation and that it's not just the Yubikey reporting back that it doesn't support that field. I do quibble somewhat with "they're not blocking Yubikeys, they're just blocking <description of a Yubikey>." But... yeah, I'll grant you're probably right that this is not using attestation.

> I don't see a world where you can export passkeys from Apple iCloud Keychain and import them into Google Password Manager.

That's exactly what I mean when I say it wouldn't be sufficient. When I talk about syncing, I'm talking about transferring into and out of ecosystems, not just specific devices. What you're describing is a system where I can use the KeePassXC ecosystem to use keys across multiple devices. But I can't transfer those keys out of the KeePassXC ecosystem (unless hopefully other vendors like 1Password add support), and if someone starts using iCloud, they're stuck with same vendor lock-in.

This is effectively saying, "you'll have a closed ecosystem for most people, but people who know enough beforehand to avoid it can somewhat avoid it." We should expect better from a standards body that purports to be building an Open standard.

I really don't see how this is an out-of-scope problem for the FIDO Alliance. They have input from every single major OS. All of the players are in the same space. And their entire job is to dictate how this is going to work. I'm just asking them to do that job. A spec for portability is not that big of an ask compared to everything else they're already working on as part of this.

It's not really that different than a spec for logging in using a standardized QR code, or over Bluetooth -- all of which was considered in-scope for them to to work on. Portability is just part of the general interoperability work that we should be expecting them to do.

> Do you want your browser deciding for you what websites you can log in to?

Of course not; in very typical fashion Google's solution to the problem may be worse than the problem itself. Google is very fond of recognizing that a feature is abusable and saying, "well, how about we prevent that abuse by giving ourselves even more capricious power?"

But I do think it shows I'm not being paranoid, that this is a legitimate worry that even Google recognizes is worth worrying about. Google is part of the FIDO Alliance and it's not looking at attestation as a theoretical risk; it's looking at it as a very plausible risk that it needs to have policies around.

Which I think is pretty reasonable given that every single instance of attestation in the past has been used for DRM, and there's nothing special about attestation in this spec that would stop that from happening. I really do think the burden of proof here is on you to describe why you think Netflix/Banks/etc... are suddenly going to act differently now than they have with every other attestation method they've had access to leading up to now.

The only answer I can think of is, "they'll act differently because Apple is effectively killing attestation for platform keys for everyone." But that's not really a defense of attestation, it's just something to thank Apple for.

[sebk]

let me restate, they're not "blocking the description of a Yubikey" either. You can register one, and in fact I just did to try it out. The Yubikey needs to be configured with a PIN which you do through Yubikey manager. They're blocking authenticators that don't have additional protection other than just presence.

> That's exactly what I mean when I say it wouldn't be sufficient

I think we're confusing what the role of a standard is, versus what other features can be built around a standard capability. With an open fabric, vendors like KeePassXC can allow exports in formats that can then be imported by other sync fabrics as I described previously. The standard mandating it would be a good reason for vendors not to adopt the standard, or adopt a crippled version. Given the fact that WebAuthn ties capabilites to the authenticator at registration time I think it's understandable that vendors like Apple want give RPs assurance that keys are entirely contained in an ecosystem that guarantees those assertions. You will have options, including not using Apple/Microsoft/Google's sync fabrics, and to move off these sync fabrics if you consider them insufficient, but not by exporting keys directly.

> I really don't see how this is an out-of-scope problem for the FIDO Alliance (...) It's not really that different than a spec for logging in using a standardized QR code

Logging in using a QR code or BLE is part of the hybrid transport in CTAP, which deals with how authenticators communicate with clients. It's very much within FIDO. Establishing trust between devices in different ecosystems to form a circle of trust so that key material can be shared doesn't really have anything to do with logging in to services, so it's not WebAuthn. It also doesn't deal with client to authenticator communication as there's no client. If anything, a standard like TPM (ISO/IEC 11889) is a better fit, but probably too low level for that exact use case.

> Which I think is pretty reasonable given that every single instance of attestation in the past has been used for DRM

Going back to attestation, I don't think that in general it's in the best interest of services to not allow you to log in to them, but I can see a bank in their typical backwards-fashion issuing some branded keys and only letting you use those (Symantec, I'm looking at you). The reality is that standard or not, if RPs want this functionality, it'll be there. Standards simply attempt to provide the bare minimum for interoperability that every party can agree to. The alternative is not an attestation-free world. It's a bank asking you to log in with a flawed key they purchased from an ancient vendor because there's no standard offering that does what they want. I'd much rather have a Bank of America branded Yubikey with enterprise attestation using WebAuthn than some weak and poorly implemented proprietary token like the ones they issue today.