Re: Sub-origins

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

Received on Monday, 26 August 2013 22:55:36 UTC