W3C home > Mailing lists > Public > public-identity@w3.org > November 2011

Re: BrowserID - Key Storage

From: Anders Rundgren <anders.rundgren@telia.com>
Date: Tue, 01 Nov 2011 12:16:13 +0100
Message-ID: <4EAFD4FD.60905@telia.com>
To: Mike Hanson <mhanson@mozilla.com>
CC: "public-identity@w3.org" <public-identity@w3.org>
Thanx Mike,
Now it became a bit clearer :-)

That BrowserID will move the world away from TLS-client-certificate-authentication is IMO good because it is (as I have said a million times before...) not particularly compatible with the rest of the
web, like the web session concept.

What's a little bit sad with BrowserID is that it doesn't (at least for now) include support for existing PKIs.  There are already tens of million users of proprietary browser plugins that more or
less do what BrowserID does during authentication.

Although (in retrospect...) unnecessary complex the following is an example of such a scheme:

http://code.google.com/p/openkeystore/source/browse/trunk/library/src/org/webpki/wasp/webauth.xsd

I intend to simplify it a bit based on the SKS/KeyGen2 scheme.

Anders

On 2011-10-27 18:22, Mike Hanson wrote:
> Anders -
>
> For the current "bootstrapping" implementation of BrowserID, the keys are stored in the localStorage of a trusted domain, and cross-document JavaScript techniques are used to create inter-domain APIs inside the browser.  
>
> The approach we're using is designed to gracefully evolve into a browser-provided API.  I blogged about the technique here: www.open-mike.org/entry/lifding-the-web.  
>
> This technique (which was termed "LIFD" at the most recent IIW) is being used for a number of identity and security protocol experiments, including Google's Belay project.
>
> Note that the BrowserID protocol is not asserting that the primary authentication keys of the user live in this domain, or in the browser.  The current focus of the protocol is on federating an identity outwards from a server.  In the fully-distributed world we hope to get to, the keys have a short-to-medium lifespan, and are generated dynamically in response to a request from a web domain (typically, a succesful login to an email provider).  The web domain certifies the keypair for as long as it is comfortable doing so, and a mechanism is proposed to enable refresh.
>
> -mh
>
> On Oct 27, 2011, at 1:10 AM, Anders Rundgren wrote:
>
>> Hi,
>> I may have read the specification in too much haste but I can't see how
>> you can store keys for arbitrary RPs using an unmodified browser and JS.
>>
>> Could someone enlighten me?
>>
>> Anders
>>
>
Received on Tuesday, 1 November 2011 11:16:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 1 November 2011 11:16:55 GMT