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

Re: Request for feedback: DOMCrypt API proposal

From: Adam Barth <w3c@adambarth.com>
Date: Sun, 5 Jun 2011 20:07:40 -0700
Message-ID: <BANLkTimHoR1oTxnPugDBjmT9na6V-YMukg@mail.gmail.com>
To: David Dahl <ddahl@mozilla.com>
Cc: Anders Rundgren <anders.rundgren@telia.com>, public-web-security@w3.org
On Sun, Jun 5, 2011 at 7:30 PM, David Dahl <ddahl@mozilla.com> wrote:
> ----- 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?

Yeah, sharing state between origins needs to be done extremely
carefully.  One approach that can work well is to have the state be
local to an origin by default but then provide a way for one origin to
share the state with another origin using postMessage.

>>> 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?

I'm not sure there's a great place to read up on this topic, but
generally speaking, one reason web sites avoid using SSL client certs
is because SSL client certs are global to the Internet.  That's both a
privacy problem (because sites can track users between sites because
the user has the same client cert) and a UI problem because using
client certs triggers browser-UI, which sites generally want to avoid.

Received on Monday, 6 June 2011 03:08:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:26 UTC