This is a standalone service which aims to offer FIDO2 platform functionality (FIDO U2F, and WebAuthn) on Linux, over a D-Bus Portal interface.
The project is composed of multiple crates:
- libwebauthn: Linux native implementation of FIDO2 and FIDO U2F Platform APIs.
- Fully written in Rust.
- No longer relies on Mozilla's authenticator-rs.
- Supporting multiple transports (currently USB HID and BLE). The library is designed to have pluggable transport implementations, making it easy to add transport backends (planned: NFC, caBLEv2).
- xdg-credentials-portal: API proposal and reference implementation for a service which will expose FIDO2 and FIDO U2F Platform APIs via a D-Bus interface, for desktop applications to use - including conteinerized apps such as Flatpaks.
- Similarly to xdg-desktop-portal and xdg-documents-portal, the service is intended to be accessed over a proposed D-Bus portal: org.freedesktop.portal.Credentials.
- FIDO U2F
- π’ Registration (U2F_REGISTER)
- π’ Authentication (U2F_AUTHENTICATE)
- π’ Version (U2F_VERSION)
- FIDO2
- π’ Create credential
- π’ Verify assertion
- π’ Biometric user verification
- π’ Discoverable credentials (resident keys)
- FIDO2 to FIDO U2F downgrade
- π’ Basic functionality
- π’ Support for excludeList and pre-flight requests
- PIN/UV Protocols
- π’ PIN/UV Auth Protocol One
- π’ PIN/UV Auth Protocol Two
- PIN/UV Operations
- π’ GetPinToken
- π’ GetPinUvAuthTokenUsingPinWithPermissions
- π’ GetPinUvAuthTokenUsingUvWithPermissions
- Passkey Authentication
- π’ Discoverable credentials (resident keys)
- π΄ Cloud-Assisted BLE (caBLE) transport (#31 blocked: spec not yet published)
USB (HID) | Bluetooth Low Energy (BLE) | NFC | TPM 2.0 (Platform) | |
---|---|---|---|---|
FIDO U2F | π’ Supported (via hidapi) | π’ Supported (via bluez) | π Planned (#5) | π Planned (#4) |
WebAuthn (FIDO2) | π’ Supported (via hidapi) | π’ Supported (via bluez) | π Planned (#5) | π Planned (#4) |
This is a very early stage idea, no proposed spec exists yet.
Here is an high-level architecture diagram of the proposed service and how it will interact with its clients:
Footnotes:
- *: Better alternatives for UI should be considered, e.g. native UI implementations via xdg-credentials-portal-{gnome, kde}.
- Ξ: See Roadmap section below
-
Sandboxed Browsers. A modern solutions is required to allow sandboxed applications (Flatpaks, Snaps) to access U2F and FIDO2 devices, without granting blanket access to all devices.
- Firefox has now officially been released on Flathub, but is unable to access U2F devices. See flatpak issue #2764
-
Passwordless Authentication. FIDO2/WebAuthn brings the promise of a world without passwords, and related security incidents, which is worth pursuing. A platform API would make it easier for applications to support stronger authentication.
-
Platform Authenticators are an important part of the FIDO2 specification, and fundamental for widespread adoption of passwordless authentication. Windows Hello, Android's FIDO2 support, Apple's TouchID and FaceID, are all examples of platform authenticators. There is no reason why the Linux desktop community could not enjoy similar benefits
-
Native Apps FIDO2 Support. FIDO2 should not be segregated to web applications.
- FIDO2 API for Android (native apps)
Here is a list of related APIs available on other platforms, which offer similar functionality:
- Android SDK: Fido2ApiClient
- Windows Hello: FIDO2 Win32 APIs
- macOS, iOS: WebAuthn via ASWebAuthenticationSession
Further references:
- D-Bus API Design Guidelines
- Relevant FIDO2 specifications:
If you'd like to contribute but you don't know where to start, take a look at available tasks in the Issues tab.
Alternatively, any investigation or expertise on the following would be very helpful. Please reach out!
-
Platform Authenticator support. Similarly to Android devices, and Windows Hello. In order to implement this (and request FIDO2 certification), support for the following is needed:
- Trusted Platform Modules (TPMs)
- User-verification devices (e.g. fingerprint readers)
-
Unprivileged access. FIDO2 credentials are scoped to an origin (e.g.
https://example.org
). The proposed API allows applications to specify any origin (as needed by browsers). Hence, it requires an additional user confirmation step for security purposes. This extra step may not be needed if the request sender could be verified, as the legitimate owner of the specified origin.- As an example, Android has implemented two APIs: Fido2ApiClient (unprivileged), and Fido2PrivilegedApiClient (privileged) for use by web browsers. The main difference between the two is that the privileged API allows specifying an arbitrary origin, whilst the unprivileged API requires linking your app to your origin.
-
PAM, and passwordless login (long-term goal). A PAM module would allow using FIDO2 for user login purposes, e.g. using the platform authenticator (similar to Windows Hello).
-
D-Bus Portal API design
-
Proposal and contribution processes (Flatpak, GNOME, etc.)
-
UI/UX