- From: Mike Hanson <mhanson@mozilla.com>
- Date: Thu, 27 Oct 2011 09:22:54 -0700
- To: Anders Rundgren <anders.rundgren@telia.com>
- Cc: "public-identity@w3.org" <public-identity@w3.org>
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 Thursday, 27 October 2011 16:23:35 UTC