- From: Ryan Sleevi <sleevi@google.com>
- Date: Wed, 22 Aug 2012 18:46:19 -0700
- To: Wan-Teh Chang <wtc@google.com>
- Cc: Mountie Lee <mountie.lee@mw2.or.kr>, Seetharama Rao Durbha <S.Durbha@cablelabs.com>, David Dahl <ddahl@mozilla.com>, Web Cryptography Working Group <public-webcrypto@w3.org>
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.
Received on Thursday, 23 August 2012 01:46:49 UTC