-
-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What USB vendor/ID is WearAuthn? #17
Comments
Devices paired via Bluetooth don't open a USB bus. They do, however, open a raw HID device, so you may want to look into a udev rule. |
I'm not completely sure how the snap permissions work. It's possible you would need both a udev rule and allowlist the Bluetooth adapter. But as @Thesola10 said, I would try adding a udev rule first. |
Allowing access to the Bluetooth adapter through USB would be pointless. The Linux Bluetooth stack has a single daemon take over the adapter and communicate with |
As far as I understand it, all the snap permission system needs is a way of identifying the key - and for most of them, that's through a specific vendor/ID combination. So should the rule for the snap permission be for the Bluetooth adapter or the watch itself? |
For reference, if it helps, the list of properties for the |
I think that this approach is problematic since vendor and product ID depend on the watch model and can't be set by WearAuthn. Thus, all WearOS watches would have to be allowlisted individually. A more sustainable approach I implemented in systemd: systemd/systemd@d45ee2f |
Hi!
I'm going to open a request for Snap to add WearAuthn as a supported key for the
u2f-devices
plug, to allow keys to work in snapped apps like Firefox.Problem is, WearAuthn doesn't show up in
lsusb
, so I can't determine what ID to submit.Here's my output of
lsusb
(it's the same before and after attaching):Is it
8087:0a2b Intel Corp. Bluetooth wireless interface
, or something else?Thanks,
MrConorAE
The text was updated successfully, but these errors were encountered: