Some kind of changelog / to-dos / readiness indicator for normal users?

[Leseratte10]

The title of the discussion sounds a bit odd but I didn't know how to best title it.

I've been using passkeys on Linux for a while, using KeePassXC and the browser extension on Linux. Then I eventually stumbled upon this repository and the three blog posts in the organization readme.

When looking at websites like https://passkeys.dev/device-support/ the Linux support for Passkeys doesn't look that good. While other OSes have natively supported passkeys for multiple years, on Linux we're still restricted to browser extensions created for a particular password manager and don't have any native integration.

If I understood this repo and the blog posts correctly, credentialsd and all its other components / dependencies are intended to change exactly that, by providing a daemon that'll take WebAuthn requests from any browser or application and either store them in the TPM or forward them to any supported password manager.

However, for a normal user who's not involved with the development of this software, it's fairly difficult to know which part of the project is already done, which parts are currently worked on, where you're waiting on upstream feedback to merge PRs or otherwise adapt.

I can see the changelog for credentialsd on Github, and that new PRs get merged regularly and new issues closed/fixed; but for a normal user that doesn't really tell me about how ready this software and all its dependencies are.

I found the PR for xdg-desktop-portal and the one for Firefox, but I was wondering if there was some kind of high-level to-do list on which things are still left to do or which things still need to happen before normal users can start using Passkeys on a normal desktop Linux out-of-the-box using this software?

[iinuwa]

Hi @Leseratte10, thanks for checking out the project!

You're right, I haven't done a great job of keeping a changelog. I've had some major [positive!] life changes in the past few months, so I don't have as much time for the administrative/community part of this project. I would love for someone to come alongside and help with that.

But generally, yes, the main things we would need for this to be generally available are:

• an integration in XDG Desktop Portal, released as GA

  • This, in turn, depends on some major async and permission framework refactorings in XDG Desktop Portal code
  • On our side, we also need to rework how the portal and credentialsd interact, but we should be able to merge this in experimental status before we work that out.

• an integration in major browsers

  • This likely means prioritizing Firefox and Chromium.
    • We have a patch for Firefox, but the reviewers want to wait until the API is more broadly available before reviewing and integrating into Firefox.
    • I have a couple of contacts at Google that I could ask for pointers about integrating credentialsd into Chromium, but this would likely require someone outside of Google to work on the patch. This is lower priority because Chromium provides hybrid support directly, while Firefox on Linux is missing that altogether.
  • Similarly, we'd probably want to add support in WebKitGTK so that web views and dependent browsers like Epiphany get support

• Some other polish features:

  • inline CTAP2 PIN management (help the user set a PIN if the site requires one to be set.)
  • implement credential discovery for WebAuthn condition mediation
  • Solidify and document the errors that the API returns back to the caller.

  Hopefully that helps give a better overview of the ecosystem.