Re: crypto-ISSUE-17: Define the scope and API for custom key attributes [Web Cryptography API]

On Mon, Aug 27, 2012 at 2:58 AM, Vijay Bharadwaj
<Vijay.Bharadwaj@microsoft.com> wrote:
> I think we agree at least partly - my intention was that attributes created by a given origin should only be visible to that origin. Essentially I'm advocating for the following:
>
> There are two kinds of keys, those created by an origin (origin-specific) and those provisioned out of band (origin-authorized)
> - Origin-specific keys (and all their attributes) are only available to the creating origin. If it is desirable to share these with a different origin, then the two origins need to cooperate by providing an export-import flow.
> - Origin-authorized keys may be authorized to any origin by an implementation-specific method (requiring user interaction is encouraged). Each such authorized origin can see the key and use it in the same way.
>
> For origin-authorized keys, there are two kinds of attributes:
> - Origin-specific attributes are those created by a specific origin. They are only visible to that origin.
> - Origin-authorized attributes are those that are provisioned out-of-band (presumably in the same way as the key was). They cannot be modified through the API and are visible to all origins.
>
> In fact, I'm not even sure that origin-specific attributes are valuable on origin-authorized keys. I can't think of a use case for them - this is one case in which it seems to me that it should be okay to require the app to store such attributes in localStorage or indexedDB, since the origin-authorized key is presumably managed out of band and is liable to disappear at any time.

That sounds reasonable to me. It resolves the primary concern, which
was two origins sharing the same key and using custom attributes as a
way to smuggle data beyond the SOP (essentially, using the Key as a
replacement for the deprecated GlobalStorage spec of WebStorage)

I suspect the resolution of this issue, at least using what you
described, is partially tied to the resolution of ISSUE-26
(multi-origin shared access).

Received on Tuesday, 28 August 2012 00:54:41 UTC