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

[danShumway]

> They're blocking authenticators that don't have additional protection other than just presence.

I know this isn't strictly attestation, but this is blocking authentication based on attributes of the device, correct? I'm sort of quibbling over details here I know, but this is basically saying "we are checking for a pin protection or biometric protection and limiting how an authenticator is used based on the presence of that feature."

> 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.

And that is a good reason to reject the standard as harmful.

I'd love to use keys for log-in, it would be a huge boost to security. But if portability between sync fabrics as you call them isn't supported, then we can stick with passwords. I'm fine with that, and I think other people are as well. Ultimately, passkeys have to be better than what we have, and out of luck or history or whatever reason password vaults are extremely portable between different ecosystems. Even ecosystems that try to lock down passwords struggle to do so, because ultimately passwords are text and in the worst case they can be copied and pasted between managers. So if passkeys aren't similarly portable and they become another tool for holding people down into a single OS ecosystem (even if there are options that allow avoiding that), then they're harmful -- the security gains are not worth the downside.

It does not address my concerns to say that a user who knows about the dangers of vendor lock-in in advance can avoid it in some situations.

> 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

It absolutely does, it dictates how that login information gets shared between devices. As far as I'm concerned it's just another part of transport.

It's also relevant to FIDO in the sense that it is a major barrier of entry to getting passkeys to be accepted by the general public. At the end of the day, the highest-level responsibility for FIDO is to figure out a standard that's usable. The lack of portability keeps the standard from being usable. It is the single biggest complaint that people have about passkeys.

Yes, that is a problem they should solve, particularly because everyone who would be required to be in the same room to solve that problem is currently in the same room, and all of them have a vested interest in getting rid of barriers to passkey adoption.

Ultimately, does FIDO want this to be adopted by normal people or not? If the answer is yes, then portability is a problem they need to tackle. Again, every single company required to tackle this problem is currently a member of that alliance.

> Standards simply attempt to provide the bare minimum for interoperability that every party can agree to.

That bare minimum of interoperability should not exist for abusive uses of the technology. Like you said, there are solutions for this today. Companies that are abusing their customers should not get extra support from OSes and standard bodies to help them do it.

Bank of America can already use a Yubikey today. Or they can use a poorly implemented proprietary token. And maybe if that goes badly for them, they'll use an actually more secure option instead of LARPing security.

But look, this is exactly what people said about web video DRM, it's exactly what people say every time these conversations around DRM and fingerprinting come up. Companies are going to fingerprint your device anyway, we might as well give them a device ID for advertising. Companies are going to build weird browser extensions, we might as well get rid of them and make DRM part of the spec. It's really just an excuse, the standards make it easier to do this stuff. They're pursued because they get rid of the inconvenient parts of abusing users. And in doing so, they remove a barrier of entry that should exist.

And integrating this into web browsers on desktop platforms is a huge gift to companies that want to do this. I already can't use my bank's app on a deGoogled phone but at least I can sign in on a web browser, because in the world that currently exists attestation through a general web browser is just difficult and just annoying enough that my bank isn't willing to do it. Please stop trying to change that.

When a company is doing something awful, it should have to leave the beaten path and work outside of the standard to do it. Because that helps us call out that they are doing something awful, and it helps us point to their solution and say, "no, that's not intended."

[sebk]

> but this is blocking authentication based on attributes of the device, correct?

Not precisely. It's requesting capabilities that the Yubikey is not configured to deliver so the browser doesn't show it as an option. There is no attestation or in fact no signed communication other than the RP requesting it in the registration. I don't understand what your desired behavior is here. Do you want to log in to Google with a bearer Yubikey (what do you do when it gets stolen?). Do you want all FIDO2 keys to require PINs, even if they're being used in a traditional "something you have" 2FA fashion?

> It absolutely does, it dictates how that login information gets shared between devices. As far as I'm concerned it's just another part of transport. (...) The lack of portability keeps the standard from being usable

In the same way that a keyboard dictates how a password is typed. Transport has a very well defined meaning in FIDO and it's not about transporting key material but rather signed challenges and responses.

Remember I'm suggesting a mechanism for open sync fabrics to exist, not the opposite. I simply don't see either the value in mandating interoperable sync fabrics, or for a particular vendor in control of the ecosystem like Apple or Google wanting to weaken the security posture of their keys given how the standard works if they allow them to be exported. Also remember that the standard doesn't just cater to users, it caters to these vendors implementing it as well, and more so.

> it's exactly what people say every time these conversations around DRM and fingerprinting come up

Except Webauthn doesn't have any fingerprinting capabilities beyond those in enterprise attestation (not regular attestation). In fact, it's much more privacy preserving that past alternatives. And fully realized, you wouldn't even need a username as an identifier with an RP that can be used to correlate you across services.