-
Notifications
You must be signed in to change notification settings - Fork 155
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
Implement support for HID report sizes != 64 bytes #165
Comments
Hi, CC'ing @James-ZHANG, who might be interested in this. A PR implementing this feature, in the lines described (tests, fuzzer integration), and without adding much complexity to existing code, would definitely be welcome. I unfortunately lack the time to work on it myself, but please count on me for help and support. -p. |
I found code style and in particular use of whitespace to be rather inconsistent between (and sometimes within) files. Is there an official policy on this or should I try to preserve the existing local structure as far as possible? |
Hi, We try to abide by https://man.openbsd.org/style. -p. |
Describe the feature you would like.
The U2F/CTAPHID specs allow FIDO devices to use any HID report size, not just the very common value 64 bytes. The report size can be extracted from the HID report descriptor, which has to be parsed anyway to determine whether the device declares the FIDO usage (page).
Currently, libfido2 assumes that all FIDO devices understand HID reports of size 64 bytes, which e.g. is not the case with WearAuthn and in general limits the (underexplored) design space for Bluetooth HID authenticators. I would like to see libfido2 become fully spec compliant and support any (sensible) report size, as do the Windows 10 and Chrome implementations.
Describe the impact to existing functionality.
This new feature can be implemented in a backwards compatible manner. If the HID report descriptor cannot be parsed correctly, the implementation would fall back to the default 64 bytes. Fuzzing and tests could also easily be extended to cover arbitrary report sizes.
Describe how you are willing to help.
If it is reasonably likely that a PR adding this functionality, accompanied by tests and fuzzer integration, will be accepted, I would gladly start working on it.
The text was updated successfully, but these errors were encountered: