W3C home > Mailing lists > Public > public-web-security@w3.org > June 2011

Re: Request for feedback: DOMCrypt API proposal

From: David Dahl <ddahl@mozilla.com>
Date: Sun, 5 Jun 2011 19:30:46 -0700 (PDT)
To: Adam Barth <w3c@adambarth.com>
Cc: Anders Rundgren <anders.rundgren@telia.com>, public-web-security@w3.org
Message-ID: <303731295.122222.1307327446797.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>


----- Original Message -----
From: "Adam Barth" <w3c@adambarth.com>
To: "David Dahl" <ddahl@mozilla.com>
Cc: "Anders Rundgren" <anders.rundgren@telia.com>, public-web-security@w3.org
Sent: Sunday, June 5, 2011 8:14:50 PM
Subject: Re: Request for feedback: DOMCrypt API proposal

On Sun, Jun 5, 2011 at 7:36 AM, David Dahl <ddahl@mozilla.com> wrote:
>> This is a somewhat un-answered question if you look at the spec, which is undergoing a lot of editing right now. There absolutely must be some kind of UI that governs access to every method in this API. I imagine it will be much like the prompts that ask for user approval in GeoLocation.

> I'm not sure I understand.  Why must there be UI?

I guess this was one of the fuzzy parts of how all of this works (to me, anyway). My implementation does not care what origin is using the API, so I thought there would have to be a geolocation style prompt before first use per origin. However, the idea of per-origin keypairs kind of trumps this, correct?

>> Another idea is treat keypairs similar to the data in localStorage where a script cannot use the API unless it has been granted access and it is with the keypair generated by the current origin only.

> Right.  All state should be per-origin.  We don't want to repeat the mistakes of SSL client certs!

Can you point me to some discussion about the SSL client cert issues?

Cheers,

David
Received on Monday, 6 June 2011 02:31:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:19 UTC