Where does the desktop environment come into this?

[pontaoski]

I am struggling to follow the API sketches/prototype code

[iinuwa]

Hi! Thanks for commenting!

Could you explain more about what you mean by desktop environment?

I'll answer based on what I understand, and you can clarify. I understand desktop environment to mean projects like GNOME, KDE Plasma, Budgie, Cinnamon, etc.

XDG portals are designed to be implemented as a pair of services: a frontend which handles all the logic and security enforcement and can communicate with hardware on the device, and a backend which provides the UI.

There will be only one frontend implementation across desktop environments as the logic stays the same, but a separate backend implementation may be written for each desktop environment. (Some of these backends may be shared, for example, there may be a generic "GTK" backend that works fine with GNOME, Budgie and friends.) This is because different desktop environments may use different UI libraries or design patterns for interacting with the user about the state of the credential selection. So instead of requiring each desktop environment to reimplement all the logic for the portal, each only needs to worry about rendering the UI and interacting with the frontend D-Bus API.

The backend implementation in this repository is merely for prototyping the interactions required between backend<->frontend and backend<->user. The backend will allow the user to select devices that hold credentials, updating the UI as it receives notifications from the frontend about changed system state.

For example:

• A user may use the backend to choose a USB device for authentication.
• The backend will tell the frontend to begin polling for a USB device.
• The frontend will poll for FIDO USB devices on the system.
• When it finds one, the frontend will notify the backend to update its UI.
• The backend will update the UI to tell the user to tap their device to release the credential.

This prototype backend uses GTK and doesn't use many desktop environment-specific features, though it does make use of Adwaita, which is used heavily in GNOME, but not in other GTK-based desktop environments.

Does that help?

[pontaoski]

Could you explain more about what you mean by desktop environment?

I am a KDE dev and would be interested in getting the KDE side of the equation put together, as well as more generally helping out w/ figuring out the division of responsibilities between DEs vs xdp vs shared code vs ... for webauthn on Linux.

[iinuwa]

Gotcha. Thanks for the offer! This project is still in the early phases, so it's not clear where others can contribute.

For now, for the backend prototype, I'm putting the APIs that the frontend will need to provide (and that the backend will need to call to render the UI) in the portal::frontend module. These are just Rust functions right now as mocks, but eventually those methods will become D-Bus calls that the frontend will need to implement.

It may be helpful for you to view the interactions in doc/scenarios.md. GitHub doesn't render these diagrams automatically for some reason, so you'll have to copy/paste them into mermaid.live or something. (I'd accept a PR that places the rendered diagram images in scenarios.md.) Those outline the major scenarios I'd like for this API to cover, and the part that the backend (DE) vs. the frontend (credential service) is supposed to do.

Maybe by the end of next month, I'll have things more stable where I could ask you to start building a KDE implementation of the backend, using the same mocked functions above. Having multiple implementations can help to find oddities in the spec, and will speed up how quickly we can get KDE family of DEs on board. I can keep you posted with my progress.