A desktop "secrets" API

There is often a fair amount of secret information that a Linux user might store on their computer—things like passwords for sensitive sites, private ssh keys, and Swiss bank account numbers. If multiple applications, typically desktop applications, need to access that information, there are solutions in the form of GNOME Keyring and KDE Wallet, but those solutions are only available to applications written for those specific desktop environments. A new freedesktop.org initiative, started by the developers of those two solutions, aims to create a "Secrets API" that can be used across desktop environments so that users can have access to their secrets from any application, regardless of which desktop it comes from.

The project was announced by KDE Wallet developer Michael Leupold on the XDG mailing list (as well as on his blog). The basic idea is fairly straightforward: users will still run Keyring or Wallet as part of their login session—which will depend on the desktop they use—but there will be an API that allows applications to extract these secrets without caring which secret storage program is providing them.

Not surprisingly, given that it is a cross-desktop API, D-Bus will be used to implement a protocol for extracting the needed secrets. Applications will then use the new API so that they are insulated from the underlying secret storage service. In his blog posting, Leupold notes that he will be trying to provide backward compatibility: "While I expect a new client-side API (which I imagine to be more OO style than KWallet::Wallet), I'll keep an eye on providing something the current class can wrap so even applications using the old API will be able to use the new system." It seems likely that Stef Walter, the Keyring developer, will do something similar for GNOME applications.

In the Secrets API, secrets are just arrays of bytes that get transferred, possibly encrypted, between the application and the storage facility. Each secret is associated with a simple dictionary (i.e. set of name, value pairs) called "lookup attributes", which are to be used to find the secret. In addition, secrets have a label and properties associated with them. Secrets can then be grouped into "collections", which more or less correspond to today's keyrings or wallets.

Items and collections can be locked, such that an unlocking process needs to happen before they can be accessed. In practice, that would generally mean that the user was prompted for a password before the item or collection could be retrieved by the application.

Clients can negotiate encryption of the secret information as it is transferred to or from the storage service. While that may seem like a good idea overall, the API documentation comes with some fairly strong caveats:

There are more details, of course, and the API specification is being discussed and revised on the freedesktop.org Authentication mailing list. In addition, there is discussion of higher-level topics on the list, such as how browsers will identify their secrets so that moving between browsers, while still being able to use the password information stored for the user, is easy. As Leupold notes that is one of the most likely scenarios for users needing the Secrets API.

With this API in place, GNOME users could use Konqueror and still have access to their passwords, and the same goes for KDE users and Epiphany. As Leupold points out in his blog posting, though, Mozilla has not shown any interest, at least yet. Integrating with the Linux desktop has not really ever been a priority for Mozilla, so one might expect Firefox, et al. to lag in this area.

Even for those not running one of the "big two" desktop environments, a suitably configured system—with D-Bus and one of the secret storage services enabled—could take advantage of the Secrets API. Interoperability between desktop environments is a good thing, and not having to store passwords somewhere external, so that one can "browser hop" can only be a good thing as well. As it matures, other applications needing to store secrets will presumably use it too. Having a single, hopefully well-vetted, location for storing this kind of information—encrypted and password-protected—may also lead to better security for users.