Local Authentication (Biometrics) Portal

[quexten]

Some applications - password managers (1Password, Bitwarden), crypto wallets, secure chat applications need to verify that the user present is actually the logged in user upon opening the app. On other operating systems, there are platform APIs for this that authenticate the user using biometrics or the system password, and provide some kind of secret that can be used for en-/de-cryption.

In un-sandboxed applications, the authentication part can somewhat be achieved by installing polkit policies for the application, or by using something like fprintd directly. For sandboxed applications this is not possible.

My specific use-case is implementing biometric auth in Bitwarden in a more sane way that also supports Flatpaks (and Snap), and especially makes it easier in immutable environments (Fedora Silverblue) (bitwarden/clients#4586, quexten/goldwarden#90), but at least 1Password would also benefit here.

Interactions

There are two basic interactions that are required. These could possibly be just one interface with different options, I'm open to discussion here.

Local Authentication

This would basically be the same as just calling polkit for authentication. In the implementing frontends, this should show the app (maybe with Icon from the .desktop file?) and a message passed by the caller.

Local Authentication with Credentials

This should provide a secret, much like the org.freedesktop.portal.Secret portal, but locked behind authentication. This would make it possible to have apps locked by biometrics/local authentication and decrypted only upon authentication.

For both of these use-cases, I feel like configurable options for whether to allow password / biometrics makes sense.

[quexten]

It seems that on the ui-side, the Gnome team has a relevant mock-up: https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/232 .

[Mikenux]

Is this about unlocking an app so it can be used?

What is expected? Does the application need to acquire the credentials or can we do without them (e.g. set a master password without the application acquiring it?)

a message passed by the caller.

What type of message are you thinking of?

[Mikenux]

It is possible to have an app-reported reason if you find wording that clearly communicates to users that the portal is not the culprit in case of app misbehavior (e.g. the reported action is not performed).

[bb010g]

Would the following sort of dialog work?

---

[Title: Authentication required]
“<Application>” is requesting to verify the identity “<identity>”.

“<Application>” claims this is to “<reason>”.

[Button: Cancel] [Button: Authenticate]

---

If the application does not provide a reason, that respective paragraph could be skipped. If the application does provide a reason, the claimed reason is clearly from the application and is clearly separate from information about the identity.

[Mikenux]

Of course, having something like this seems like the way to go.

Additionally (I'm working on other mockups) and if I'm not mistaken, I would clarify in the dialog that the identity is not given to the app, because this doesn't seem to be the app that verifies the identity but the system. Additionally, even if credentials are given to the app, they are credentials that appear to have been created for the app itself, meaning they can be given to it - and this can also be mentioned in this case.

[bb010g]

Additionally (I'm working on other mockups) and if I'm not mistaken, I would clarify in the dialog that the identity is not given to the app, because this doesn't seem to be the app that verifies the identity but the system.

I should note that I pulled that wording from @snwh's https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/232#note_1874679.

[Mikenux]

Okay. Feel free to help on this as well. It's helpful to have other wording suggestions to better reflect what is being requested by apps.