[Authentication] Proposal for a common secrets handling in web browsers
lemma at confuego.org
Wed Jul 15 09:14:28 PDT 2009
On Wednesday 15 July 2009 17:23:55 Guillaume Martres wrote:
> Hi all,
> As an Arora 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
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
> - Forms handling:
> * Use the attribute "URL" to indicate the page where the form lies.
For transport related passwords I'd use a scheme similar to what gnome-keyring
currently uses .
@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 :).
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/authentication/attachments/20090715/9b43b6a9/attachment.pgp
More information about the Authentication