[Authentication] Proposal for a common secrets handling in web browsers

[Michael Leupold]

On Wednesday 15 July 2009 17:23:55 Guillaume Martres wrote:
> Hi all,
> As an Arora[0] developer I am very interested in this project, as it will
> allow us to have cross-desktop password handling. Since this project is
> still at an early stage, I'd like to take the chance to standardize the way
> "secrets" will be stored by web browsers. In this post I'll almost only
> speak of forms handling since that's the most important part but the goal
> is to cover every "secret" a browser may have.

I'm generally much in favour of this because browsers are an application 
people might switch more often than any other application type.

> - General stuff:
> * Add a "network" collection. KWallet already does that and this seems a
> good idea to keep things together and not clutter the default collection.
> It would be available using
> org.freedesktop.Secrets.Service.NetworkCollection

I generally agree but I don't necessarily like the name as it's misleading :) 
As I see it we'd use it to store form data and login passwords for anything a 
browser can access, right? Sorry, can't come up with anything useful.. ideas 
anyone?

> - Forms handling:
> * Use the attribute "URL" to indicate the page where the form lies.

+1

For transport related passwords I'd use a scheme similar to what gnome-keyring 
currently uses [0].
@Stef: did that work out well for the moment?

> * Store every field content in a different item, as a secret. The label of
> the item will be the name of the field. If an item with the same label
> already exists, overwrite it.

I'd actually like to use a dictionary/map to store all of the fields in the 
secrets. In my opinion one item should match one form. This will also be a lot 
less troublesome if you want to store several sets of data for the same url.

> * Use the encryption algorithm "plain" for every secret, except if it is a
> password field secret. In this case, use whatever encryption the
> specification recommends.

The algorithm is meant to be "per session" meaning the client and the server 
negotiate it at the start of a session. This means every secret transmitted 
will use the same algorithm. Note that this does not affect how items are 
stored. (on a sidenote: all of KWallet effectively uses PLAIN right now :)).

> That's all for now. I hope this makes sense :).

Yeah!


I'd probably add a section to the spec regarding client-compatibility 
containing information like that (which is basically what the browser feature 
is about - apart from the extra objectpath alias).

Regards,
Michael

[0] http://library.gnome.org/devel/gnome-keyring/stable/gnome-keyring-gnome-
keyring-password.html#GNOME-KEYRING-NETWORK-PASSWORD--CAPS

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/authentication/attachments/20090715/9b43b6a9/attachment.pgp