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

As I mentioned earlier, one use case I can think of is of sister sites. Many TV stations are owned by a single entity (Turner, for example, owns CNN, Cartoon Network, so on). So, regardless of whether the key is symmetric or otherwise, it would be great to share across sites (domains). [Again, synchronization of the keys on the back-ends is not our problem.]

I know that we can do this today through some SSO mechanism (SAML/OpenID). That, however, only meets the 'login' problem. If we want to use that key as a source for other trust related operations (signatures, non-repudiability, encryption, etc.) then it will be good to have access to that key across domains.

Would love to hear others' thoughts as well.

On 8/22/12 7:46 PM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote:

On Wed, Aug 22, 2012 at 6:28 PM, Wan-Teh Chang <wtc@google.com<mailto: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.