WICG
Blocklist implementation conflicts with Chrome
@agl of the chrome team [directs developers who want to communicate with U2F (FIDO/WebAuthN device) to use WebHID.(https://bugs.chromium.org/p/chromium/issues/detail?id=1179077)
subject: Issue 1179077: Disallow tunneling of unrelated protocols over U2F interfaces Chromium allows websites relatively direct communication with security keys. This is permitted because:
a) we understand the security and privacy implications of the CTAP protocols, and b) we formulate the protocol messages ourselves and are reasonably sure that websites won't be able to exploit bugs in security keys because the variable fields are subject only to simple processing by the security key.
Both of these factors are nullified if other protocols are tunneled with the security key protocols, which some devices have done. This is presumably attractive because the U2F API does not have a UI and, while that will be going away and WebAuthn does have a UI, some devices simply put up with flashing the WebAuthn UI repeatedly.
Websites that wish to communicate with USB devices can use the WebUSB and WebHID APIs to do so without such shenanigans.
SoloKeys supports seeding their security keys via a CTAP protocol (the one explicitly permitted -- no tunneling) an so we (me/DiceKeys) have built a web app to do that using WebHID.
By introducing a block list that removes all access to any device that supports FIDO, with no ability for vendors to opt out, it would seem that Google's @nodebug has made it impossible to do what Google's @agl is telling developers they should do ("Websites that wish to communicate with USB devices can use the WebUSB and WebHID APIs to do so").
Having written an app that assumes I'll be able to do what @agl directs developers to do, I would hope that the spec can either remove FIDO from the block list, or to supplement the block list with an allow list that allows vendors to override it.
@agl of the chrome team directs developers who want to communicate with U2F (FIDO/WebAuthN device) to use WebHID.
I don't think that's an accurate summary of the quoted text but, to be clear:
Devices that are stuffing unrelated protocols inside U2F in order to skip the device-selection UI of WebUSB / WebHID / etc should stop doing so. (Hopefully that's not too surprising.)
What you're talking about are devices that are security keys, but want a side-channel for configuration. You say that SoloKeys “supports seeding their security keys via a CTAP protocol”. I'm not sure what that means but if it means that there are magic structures in opaque makeCredential or getAssertion commands, then that's tunneling and not allowed. If it means that there are CTAP2 vendor commands then that's fine, but you won't be able to exercise them via the browser as the CTAP channel is reserved for security reasons. On Windows you will need Administrator access since otherwise security keys are blocked at the system level.
If the configuration is on a different HID usage page then the problem is that I'm not sure whether it's possible to reliably separate reports on a per-usage-page basis. Most robustly, if the device presents as two different devices on the USB bus then the second can be used for configuration via WebUSB. Perhaps just a separate USB interface is sufficient but that might fall afoul of the Windows restrictions.
We are not trying to circumvent the device-selection UI, but if access to WebHID is blocked it sounds like developers are being pushed toward tunneling.
Correct, that SoloKeys supports a CTAP vendor command. Why not allow vendors to opt onto an allow list, at least where platforms don't require chrome to have root? Why address the question of tunneling over U2F by telling developers to use WebHID when communicating with U2F then forbid WebHID for U2F?
Why address the question of tunneling over U2F by telling developers to use WebHID when communicating with U2F then forbid WebHID for U2F?
People are building devices that are unrelated anything security keys, but choosing to export a FIDO usage page and using the U2F API in the browser, because it avoids any user interaction. They should not be advertising the device as a security key but rather using WebHID / WebUSB as intended.
You are in a niche where you're trying to interact with additional functionality on a device that really is a security key. In that case you'll need to expose only that functionality via a separate USB device, or at least interface, to provide separation.