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