Alfie Fresta’s blog

Credentials for Linux (FOSDEM 2026)

2026-02-01T12:00:00+00:00

Bringing Passkeys to the Linux desktop

Talk at FOSDEM 2026 in Brussels, Belgium.

Abstract

Passkeys are now first-class citizens on Windows, macOS, Android and iOS - but the Linux desktop still has no standard FIDO2 platform APIs for browsers and native apps.

This talk presents Credentials for Linux (github.com/linux-credentials), a cross-desktop effort to bring Passkeys and other credentials to Linux in a way that works for sandboxed apps and browsers alike.

We’ll cover:

Very short refresher on passkeys & platform authenticators: Why WebAuthn/FIDO2 passkeys matter, what platform authenticators are, and how this is solved on Windows Hello, Android and Apple platforms today, and the current state on Linux.
Architecture of Credentials for Linux
- libwebauthn: a Rust FIDO2/U2F platform library with support for USB, BLE and Hybrid authenticators (ie. Android & iOS smartphones), designed with pluggable transports and passkey features such as resident keys and user verification.
- credentialsd: a D-Bus service and proposed XDG portal for credential management, including a reference UI, Firefox integration (web extension + patched Flatpak build) and distro packages via OBS (Fedora/openSUSE).
What this looks like for apps and browsers: Demo and design walkthrough of a sandboxed Firefox using credentialsd to talk to hardware security keys and phones, and how native applications can use the same D-Bus API.
Roadmap, open problems and call for collaborators: TPM-backed platform authenticators, origin binding and unprivileged APIs for browsers, and how we’d like to work with GNOME, KDE, Flatpak, password managers and distributions.

The talk is aimed at people interested in identity and access management on the desktop: browser and desktop maintainers, distribution engineers, security practitioners and anyone who wants to help make passkeys a first-class citizen of the Linux platform.

A vision for Passkeys on the Linux desktop

2024-01-31T12:00:00+00:00

Introduction

Passwords are a scourge on the modern web, a relic of another time. I’m an advocate of FIDO2 and WebAuthn, and I believe that they will play a crucial role in the future of authentication. I’m excited to see the industry move towards more secure and user-friendly alternatives such as Passkeys.

However, the Linux desktop has lagged behind other platforms in adopting these technologies. I launched xdg-credentials-portal in 2020 with the goal of bringing FIDO2 authentication to the Linux desktop.

In this post I’ll discuss my vision for FIDO2 on Linux, and the main challenges that lie ahead.

A bit of history

Skip this section if you’re familiar with FIDO2, WebAuthn, and the limitations surrounding their use in Flatpak apps.

FIDO Universal Second Factor (FIDO U2F)

FIDO Universal Second Factor (U2F) was the first, widely-adopted open standard for two-factor authentication (2FA) on the web.

This allowed users to authenticate to websites using a physical security key, in addition to their password. The security key could be connected via USB, NFC, or Bluetooth Low Energy (BLE).

FIDO2 and Passkeys

FIDO2 builds on the success of U2F. It improves upon the original spec in a number of ways. Although it still supports the original use cases of U2F, its main focus is on enabling passwordless authentication scenarios - using a private-key credential as the sole factor for authentication.

FIDO2 comprises of two specifications:

W3C Web Authentication (WebAuthn), describing high-level APIs to create and use credentials.
Client to Authenticator Protocol (CTAP), describing the low-level protocol used by the client (eg. a browser, or an operating system) to communicate with authenticator devices.

The FIDO Alliance has selected the term Passkeys to describe the public-key credentials which can be used through these APIs. It’s worth noting the specs predate the term passkey, and use different terminology to refer to credentials.

For more details on Passkeys, see:

The advancements in the specs above which power the passkey experience are the following:

CTAP2 Hybrid Transport, previosuly known as Cloud-assisted Bluetooth Low Energy (caBLE v2). This transport builds on BLE - allowing for secure pairing, and proximity detection - but adds a standardised, and more convenient internet-based transport for subsequent communication. This allows phones to receive energy-efficient push notifications, rather than relying on slower, and occasionally less reliable, BLE.
WebAuthn Discoverable credentials, previously known as Resident keys. This allows credentials to be stored on the authenticator or client, rather than by the relying party (ie. the website).
Multi-device FIDO Credentials. This is a relaxation of the requirements on authenticator devices which no longer need to store private keys in Trusted Platform Modules (TPMs). Because of this, software implementations of authenticators can backup credentials to the cloud, as well as sync them across multiple devices.

Linux and Containerisation

Containerisation technology such as Flatpak and Snap have become increasingly popular on Linux. Containerisation promises to make software distribution easier, and more secure, by isolating applications from the host system.

However, in order to reap the security benefits, software must be distributed with the minimum set of permissions required to function. This is a challenge for software which requires access to sensitive resources, such as the user’s USB security keys.

To allow a Flatpak application to access a USB security key, the user must grant the application access to all devices (see Flatpak device access docs). This has two major security drawbacks:

It allows the application to access all USB devices on the system, not just the security key.
The application communicates with the security key directly, which allows it to bypass origin scoping: an application can use credentials for any website.

See flatpak/xdg-desktop-portal issue 989 for more details and discussion.

A vision for FIDO2 on Linux

This sections sets out a vision for FIDO2 on Linux, and discusses the challenges that lie ahead.

Prioritizing Passkey support

Passkeys are likely to be the most popular form of FIDO2 authentication by far. The convenience of passkeys being automatically synced across devices, and the fact that they don’t require specialised hardware, will make them the go-to choice for the vast majority of users.

For this reason, I believe that it’s crucial to prioritize passkey support. This means focusing on the CTAP2 Hybrid Transport, and the WebAuthn Discoverable Credentials, above other transports (eg. USB, NFC, etc).

Mozilla’s authenticator-rs currently solely targets USB security keys, and will need significant work to support additional transports such as BLE and Hybrid (CABLE).

Envisioning a Windows Hello experience on Linux

The goal of xdg-credentials-portal, or any other FIDO2 credentials portal on Linux, should be to provide a user experience similar to:

Passkeys on Windows (Windows Hello)
Android Credential Manager - Jetpack APIs superseding Android FIDO2 APIs
Apple Passkeys

The responsibilities of this portal should include:

Mediating the communication between the application and the authenticator, providing a simple, higher-level API for applications to use, resembling WebAuthn operations;
Enforcing security guarantees. For example, ensuring that the application can only access the credentials for domains it has authority over (see Android’s Asset Links);
Providing transparency to the user about which application is requesting access to their credentials, and which authenticator is being used to generate them;
Enabling fast reauthentication scenarios. For example, remembering the user’s choice to allow or deny access to credentials for a given application;
Sharing little to no information with the application. For example, the application should not be able to determine which authenticator was used to generate the credentials, or whether the authenticator failed to connect or the user denied access to the device.
Connecting to credential providers. See section below.

Bridging FIDO2 with Password Providers

Most users are likely to use Google Password Manager or iCloud to store their Passkeys. Others will prefer third-party password manages with support for passkeys such as BitWarden, Lastpass, and so on. Novel products with even better security guarantees will inevitably appeal to privacy-savy users.

The Linux desktop should allow users to choose their preferred password managers, and use passkeys created on other devices.

This is the same approach chosen for Android’s Credential Manager APIs - whenever an application requests the user to authentication, the platform is responsible for querying all registered providers and collect available passkeys. The user will then be presented with a dialog to choose their preferred credential amongst all those available.

The application requesting authentication should not have visibility as to which providers are configured, or the origin of the selected passkey.

This will require defining an interface between the Linux desktop component and pluggable providers, similar to the Android Credential Provider APIs. This interface is necessarily more complex that the WebAuthn and CTAP specs, as it includes enumerating and discovering credentials.

Delegating Passkeys to the platform

Applications, especially browsers, tend to come with their own implementation of passkey management. This is a problem for a number of reasons:

It couples password managers to specific applications. For example, Google Password Manager is only available in Chrome.
It’s a security risk. Applications accessing specialised hardware directly may not be as secure as the platform, and may leak credentials to the application developer, or to other websites and applications.
It’s a poor user experience. Users are forced to reauthenticate to each application, and to reconfigure their password manager for each application.

If history is any indication, Google may refuse to provide a Google Password Manager integration outside of the Chrome browser, and Apple may refuse to provide any iCloud integrations outside of its own operating systems.

FOSS groups should insist on a platform-level integration, and participate in adequate forums to ensure that their voices are heard.

Both Chrome and Firefox already delegate password management to the platform on Windows and macOS. Both browser vendors should be engaged to ensure that they do the same on Linux.

My limited attempts to engage with Mozilla on this issue have not proven successful so far. Google have informally indicated they are open to delegating FIDO2 to the platform.

The challenge of origin scoping

The WebAuthn spec requires that credentials are scoped to the origin of the website. This means that a credential created for https://example.com cannot be used by https://example.org. This is a crucial security guarantee, as it prevents a compromised or malicious website from using credentials to impersonate the user on other websites.

As Linux desktop applications request access to credentials, they must be forbidden from accessing credentials belonging to other applications. Two challenges need to be solved for this enforcement to occur: identifying allowed origins for an app, and authenticating the app.

Identifying allowed origins

Two modes of operation can be identified when accessing WebAuthn credentials:

Restricted scope, for most applications that are allowed access to credentials scoped to their respective origin. User interaction is only required for verification purposes, or selecting between credentials when multiple exist.
Privileged access, for applications that act on behalf of other origins, such as web browsers and remote desktop applications. An additional user interaction step must be required to validate the application should be able to access credentials for the specific origin.

Privileged access

Privileged access scenarios is the easiest mode to implement without compromising credential security - although this may sound counter intuitive at first.

The choice of allowing the web browser to access a specific credential can be given to the user, who should be able to easily identify whether the request is legitimate. I propose including user interaction in two key flows:

Granting privileged access at install time. The user acknowledges the privileged status of the app, for example by granting a “permission to access credentials for all apps and websites” - or other wording to the same effect;
Granting access to the specific origin. The platform requires the user to mediate access to credentials, explicitly indicating which origin the credential belongs to, for example: “Firefox is trying to use a credential for https://example.org.”. The user may choose for this preference to be remembered, ie. “Always allow for this website”.

A relevant example is provided by the Android FIDO2 APIs. On Android, different subsets of these APIs are available to privileged (Fido2PrivilegedApiClient) and non-privileged applications (Fido2ApiClient). Only applications that have the necessary web browser permissions can access the privileged APIs. Google reviews applications declaring this permission to verify they are indeed web browsers, before allowing them to be listed on Google Play Store. This solution effectively delegate trust to the distribution platform, which may not be desirable on the Linux desktop.

Restricted scope

In order to use the requirement for the user to validate the scope of the request, it must be possible to automatically validate an origin for a given application.

A basic approach is that of requiring origin owners to enumerate application identifiers to be allowed access to their credentials. Android employs a manifest published at a well-known URI (.well-known/assetlinks.json) for this very purpose, although DNS could be used as well.

The platform may retrieve the manifest, or perform a DNS query, at the time of the request. However, this has two disadvadvantages:

It doesn’t allow for offline (or limited connectivity) scenarios. This would be quite unfortunate as WebAuthn can be useful in offline scenarios, such as using the PRF extension for symmetric data encryption.
Requests can be tracked. The application owner can determine when the user is using their application, and which origin they are accessing. This may be undesirable for privacy reasons.

These problems can be mitigated by the platform caching the origin validation information. However, this is not a perfect solution, as the application owner can still determine whether the user is using their application, and it doesn’t provide a good user experience for offline scenarios.

A better approach is to delegate the origin validation to the distribution platform. For example, Flathub could validate the allowed origins for a given application, and provide this information to the platform in a way that can be verified cryptographically. This would allow for offline scenarios, and would prevent the application owner from tracking the user.

The downside of this approach is that it requires the distribution platform to be trusted. This may not be desirable for some users, and may be a blocker for some distributions.

It’s unclear to me what approach is used on Android.

Avoiding the good-enough trap

A privileged mode is the easiest to implement, and may be good enough for many use cases. However, it’s important to ensure that a restricted mode is not forgotten, and that it’s implemented as soon as possible.

I fear that if the privileged mode is implemented first, applications that do not require privileged access may never be updated to use the restricted mode. This would be a major setback for the security of FIDO2 on Linux.

Authenticating the app

The solutions proposed in the section above assumes that the user can be presented with a dialog that includes the origin of the credential, and the application requesting access to it, e.g.:

Firefox is trying to use a credential for https://example.org

This requires the platform to be able to authenticate the application, and to verify that the application is indeed the one requesting access to the credential.

On Android, each application has a unique identifier and a signing key. FIDO2 requests are signed by the application, and the platform can verify that the application requesting access to the credential is indeed the one that created it, and that it’s not a malicious application impersonating the original one.

On Linux, this may be trickier to implement. D-Bus requests are not signed but may it may be possible to trace them back to the process that created them (eg. via GetConnectionUnixProcessID).

It would then be necessary to map the process ID to the Flatpak application, and in turn to the list of allowed origins (or a privileged status). This may be possible via existing Flatpak APIs, or by extending them.

What next?

Development for xdg-credentials-portal has been slow, partly because of the changing nature of the FIDO2 specs. However, I’m optimistic about the future of FIDO2 on Linux. FOSS groups have a strong track record of collaborating to solve complex problems, and for-profit contributors are bound to emerge as the technology becomes more popular.

If you’re interested in the cause, but you’re unsure where to start, please get in touch.

Engaging with the FIDO Alliance, Mozilla, Google, the GNOME Foundation, and other stakeholders is going to be crucial to ensure that the Linux desktop is not left behind. If you represent an organisation that may be interested in contributing to this effort, please consider reaching out to me, and I’d be happy to help you get started and connect you with the right people.

Feedback

If you have any feedback, please reach out to me on GitHub, LinkedIn, or via e-mail.

No Place to Hide

2022-01-30T14:50:00+00:00

The UK Home Office is running a campaign named “No Place to Hide”. Once more Priti Patel’s department is trying to undermine public support for end-to-end encryption.

The goal of reducing online child abuse is most noble, but it cannot be achieved by breaking encryption. It cannot be achieved at the cost of the privacy of all.

End-to-end encryption means that texting or calling your friend can be as private as whispering in their ears. It means you don’t have to entrust corporations with your secrets, nor their disgruntled employees. It means that in a day and age when large scale data breaches are scarily commonplace, you can sleep well, knowing that your most private conversations won’t fall in the hands of hackers so easily. It allows journalists to report safely on injustices and advance democracy. It means that billions of people who live under questionably democratic governments can express their opinions freely. Even for those who currently live under a government they trust, encryption means they can speak their mind without fear of repercussions, worrying about a repressive leader being elected 20 years from now.

The primary argument of the government is unchanged: if you have nothing to hide, you have nothing to fear. As Edward Snowden said, “Arguing that you don’t care about the right to privacy because you have nothing to hide is no different than saying you don’t care about free speech because you have nothing to say.”

What’s new about this campaign is that it states the government is “not opposed to end-to-encryption in principle”, as long as it’s implemented in a way that allows access to your data when required. I expect this is because they don’t want to be seen to oppose end-to-end encryption, which has gained wider public support in recent years.

However, this new argument is fundamentally flawed. It’s just not how end-to-end encryption works. There is no way to place a backdoor to user’s texts and guarantee it is not abused. Backdoors are not wiretaps - targeted intelligence devices requiring pre-approval - they’re mass surveillance devices. They’re master keys that can end up in the wrong hands. They’re a gift to undemocratic governments, hackers, and those disgruntled employees.

We must find other ways to combat crime. The UK must lead the way, recognising that digital privacy is a fundamental human right. It is a link in the chain of civil liberties that define democracy.

Originally posted on Facebook, on 2021-01-19.