Re: crypto-ISSUE-26 (multi-origin access): Should key generation be allowed to specify multi-origin shared access [Web Cryptography API]

Hi.
I will try to prepare use cases for this issue.
also I'm checking the alternatives with open mind.

let me have a time.

regards
mountie.


On Thu, Aug 23, 2012 at 10:46 AM, Ryan Sleevi <sleevi@google.com> wrote:

> On Wed, Aug 22, 2012 at 6:28 PM, Wan-Teh Chang <wtc@google.com> wrote:
> > It would be nice for implementations to be able to support two types
> > of key access:
> > - origin-bound keys
> > - shared keys that are associated with certificates
> >
> > The Key object should be specified to have an attribute related to
> > which origins may use the key. We can start with supporting
> > origin-bound keys only.
> >
> > Also, after a signing key has been used, it seems dangerous to broaden
> > the origins. I am worried that an old signature generated when only
> > one origin was allowed may become valid for other origins
> > retroactively. So this key attribute for access control probably
> > should be immutable for signing keys at least.
> >
> > Wan-Teh
>
> Mountie, Wan-Teh, or Seetharama,
>
> Could one of you please write-up a concrete Use Case for multiple
> origin key access? I want to make sure we have a place where we can
> capture:
> 1) Why is it useful/valuable
> 2) What are the security and privacy risks
> 3) Why other alternatives are not suitable
>   3a) script-src , which inherits the SOP of the including domain
>   3b) Web Intents
>   3c) inter-origin communication mechanisms (postMessage, iframe, CORS,
> etc)
>
> I'm deeply concerned about #2 here, so I want to make sure we can
> actually have something concrete to discuss.
>
> I also don't believe we should attempt to reach consensus on this
> issue prior to FPWD. As referenced in previous documents, the state of
> the art and the active encouragement of the web community is not to
> violate the SOP. In order to help reviewers understand why the
> violation is useful or important, I think a strong use case will need
> to be presented.
>

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World