You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We took a good look at libfido2, to investigate its suitability for use by a Relying Party server. We conclude that it’s not suited for a number of reasons:
It’s meant as a library for Webauthn clients to interact with authenticators, and as such comes with a lot of additional code for that. Only a small part of the library could be used by a server (fido_cred, fido_assert and possibly fido_cbor)
It doesn’t support the attestation formats android-key, android-safetynet and apple, used on mobile platforms, and there doesn’t seem to be any effort to implement these .
libfido2 being a C library, a lot of complexity is involved in order to interact with it. The C interface is awkward to use from Haskell, and deferring to another library makes it much harder to understand what’s going on.
No active server library from other language ecosystems makes use of libfido2
The scope of the libfido2 library is unknown. In some instances the author responds to questions, but doesn’t explain the overall scope of the library. See for example Android support Yubico/libfido2#247
Three wrappers around libfido2 exists, but none of them is actively maintained
Most of these issues could be worked around at the cost of added complexity to the library. At some point, however, the added complexity outweighs the benefits of using an established library.
Motivation from #4
The text was updated successfully, but these errors were encountered: