Re: Sub-origins

I absolutely think that the generation should be standardized so it can be
reproduced identically by servers and across-browsers (think WebRTC, as
well).

I worry that adding additional internal structure will produce the same
failure modes in legacy components unaware of the structure that adding a
second value would.

There is also some smalle value for external components that use a
fixed-size representation of an origin (granted that's not completely
possible due to unknown size of scheme, but say they assume it will only be
either http, https, etc) to have suborigins fit within that buffer.



On Mon, Aug 26, 2013 at 3:54 PM, Devdatta Akhawe <dev.akhawe@gmail.com>wrote:

> One problem I see is that this identifier (may it be origin +
> suborigin-label, or the HMAC as you suggest) needs to be shared by the
> server (for CORS) as well as the client (for postMessage). Helper
> functions would work if this was only a client-side trait.
>
> But, since we want CORS APIs to also use this, the server has to
> understand (and possibly generate) these identifiers. That means we
> would need to standardize on the HMAC function (at least the hash
> function). I am not sure we want to head down that path.
>
> If we really really want a single string for the origin (instead of
> two), then figuring out a way to include the sub-origin in the URI
> seems better than trying to standardize an HMAC.
>
> thanks
> dev
>
>
>
>
>
> On 26 August 2013 15:42, Brad Hill <hillbrad@gmail.com> wrote:
> > I imagine that there might be a helper function defined, or that
> developers
> > could do it themselves, or that you could have API sugar that helps out.
> >
> > -Brad
> >
> >
> > On Mon, Aug 26, 2013 at 3:39 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
> > wrote:
> >>
> >> > Content-Security-Policy: sandbox suborigin:'isolateme'
> >> >
> >> > Where the result of this is to set the origin representation to an
> >> > HMAC_SHA256 of the origin with "isolateme" as the key.
> >> >
> >> > This gives the ability to developers to create convenient names for
> >> > arbitrary groupings of site functionality, makes it extraordinarily
> >>
> >> I imagine that this is what an implementation might do. I am curious
> >> about how developers would use it. For example, in an API like
> >> postMessage where the developer has to name and use the origin (or in
> >> CORS), the current proposal requires the developer to say
> >> "{origin.com, isolateme}". Do you envision the developer writing this
> >> HMAC value in the target origin field?
> >>
> >> thanks
> >> Dev
> >
> >
>