Re: Follow-up. Re: Use case: Authenticate using eID

To state this example in a little more detail: 

1. Origin B loads Origin A in an iframe
2. Origin B creates the message to be signed
3. Origin B sends the message to Origin A using postMessage
4. Origin A signs the message
5. Origin A sends the signature to Origin B using postMessage

As Ryan notes, the "send" in steps 3 and 5 is between browser windows, not over the network.

--Richard




On Wednesday, May 15, 2013 at 9:14 AM, Ryan Sleevi wrote:

> Have origin B load Origin A in an iframe, postMessage the message to be signed to via the iframe Origin A, have Origin A perform the signature, and postMessage it back to origin B via parent.
> The actual message is never sent remotely - postMessage is entirely within the UA. As long as you trust Origin A, this remains true.
> This is the exact same security assumption when you deploy native middleware apps - you trust the middleware vendor to not include back doors.
> On May 15, 2013 12:53 AM, "Mountie Lee" <mountie@paygate.net (mailto:mountie@paygate.net)> wrote:
> > Hi.
> > let me rewrite my understanding for postMessage.
> > 
> > let's assume
> > Key-A has origin-A and no Key is associated with origin-B.
> > 
> > if an user visit origin-A
> > user is able to generate signature with Key-A
> > and send it to origin-B via postMessage.
> > 
> > if an user visit origin-B 
> > user is unable to generate signature with Key-A
> > and has nothing to send via postMessage.
> > 
> > normally original text for signature will be prepared by origin-B. 
> > 
> > I'm not trying to be negative attitude.
> > just I'm trying to find acceptable solution for my use case.
> > 
> > still I need help.
> > 
> > regards
> > mountie.
> > 
> > 
> > 
> > On Wed, May 15, 2013 at 5:00 AM, Arun Ranganathan <arun@mozilla.com (mailto:arun@mozilla.com)> wrote:
> > > On May 13, 2013, at 4:38 PM, Aymeric Vitte wrote:
> > > > In another email, you wrote "2. The key can be shared with origin 2 via cross-origin messaging." (http://lists.w3.org/Archives/Public/public-webcrypto/2013May/0036.html), I don't see how CORS could apply here, withCredentials or not, CORS is only about sending/receiving things to/from other origins and sharing some stringyfiable things or cookies uses, you can not share keys, the best you can do is to send some information to allow another origin to find the keys.
> > > > 
> > > > Maybe I am missing something but what is the idea here?
> > > 
> > > 
> > > (I was responding to your point about IndexedDB being a "mega-Cookie" and unwisely elected to discuss differences in how Cookies can be used vs. client-side stores.  I'm sorry if this was confusing.  These technologies are unrelated to our discussion of Crypto and cross-origin messaging.) 
> > 
> > 
> > 
> > -- 
> > Mountie Lee
> > 
> > PayGate
> > CTO, CISSP
> > Tel : +82 2 2140 2700 (tel:%2B82%202%202140%202700)
> > E-Mail : mountie@paygate.net (mailto:mountie@paygate.net)
> > 
> > ======================================= PayGate Inc. THE STANDARD FOR ONLINE PAYMENT for Korea, Japan, China, and the World