W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2015

Re: JSON representation of CSP policies

From: Jonathan Kingston <jonathan@jooped.com>
Date: Mon, 17 Aug 2015 19:44:17 +0000
Message-ID: <CAKrjaaW9Ljrbx_MLj5=V0gh12GK9rFZebN3xr-obdZb=x+iZhg@mail.gmail.com>
To: Mike West <mkwst@google.com>, "Nottingham, Mark" <mnotting@akamai.com>
Cc: Brad Hill <hillbrad@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
So as much as I thought this had the potential to expand into the headers,
the main rationale for the note I sent was for a serialisation format.

The main motivation is so libraries and services can publish what policy
they adhere to. Then other code can consume and create a composite policy
from many libraries.

If we can provide a tools to output CSP2 style header format from the JSON
the structure isn't massively important. However I thought it was worth
sharing here before all front end libraries run off on a tangent. A format
similar to package.json would be nice for example.

On Mon, Aug 17, 2015 at 2:48 PM Mike West <mkwst@google.com> wrote:

> On Sun, Aug 16, 2015 at 11:13 PM, Nottingham, Mark <mnotting@akamai.com>
> wrote:
>> Just an aside - if we did a new version of CSP, we could use JSON
>> directly for the header syntax:
>>   https://tools.ietf.org/html/draft-reschke-http-jfv-01
>> One of the ideas behind that is that — for headers which use JSON for
>> their data model — we could use an alternative binary representation in
>> HTTP/3.
> Yeah, I was thinking about this as well. It seems more justifiable for CSP
> to use a JSON-based syntax given its complexity, and it might be an
> interesting opportunity for a clean break with the existing CSP behaviors.
> If there are things that we'd like to do in CSP3 that end up being
> backwards incompatible with CSP2 (and I'm not entirely sure there are,
> yet), changing the syntax entirely might be a good way to do it.
> FIled https://github.com/w3c/webappsec/issues/457 to track this.
> -mike
Received on Monday, 17 August 2015 19:44:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:50 UTC