- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Wed, 15 May 2013 18:05:27 +0200
- To: Mountie Lee <mountie@paygate.net>
- CC: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>, Arun Ranganathan <arun@mozilla.com>, "public-webcrypto@w3.org Group" <public-webcrypto@w3.org>
- Message-ID: <5193B247.6080407@gmail.com>
Mountie, If I understand your concern, it is about accessing things directly between origins (page and iframes), for security reasons it is very limited, except if you are using postMessage, but the principle in that case is that origins are controling it and allowing it (for example you can not do alert(originB.contentWindow.document.body.outerHTML) but originB can return outerHTML via postMessage if it is willing to do it). I am not a fan of iframes but in that case that's the only way to communicate between origins inside the UA using postMessage, and you can combine with xhr to communicate some results to the servers. Regards, Le 15/05/2013 10:58, Mountie Lee a écrit : > Hi. > > thanks all for examples. > I now completely understand usage. > > in the view of web accessibility for disabilities. > frame or iframe are not recommended (http://webaim.org/techniques/frames/) > > CSS? ... hmm. > > are we sure > iframe and postMessage combination is best practice for all tech > consumers in the world? > > regards > mountie. > > > > > > > > On Wed, May 15, 2013 at 5:25 PM, Nick Van den Bleeken > <Nick.Van.den.Bleeken@inventivegroup.com > <mailto:Nick.Van.den.Bleeken@inventivegroup.com>> wrote: > > Mountie, > > A user 'visiting' a web page from origin-A or origin-B doesn't > mean that the the page can't load resources from another origin > (using iframes for example). > > So when origin-A is responsible for managing the keys, the user > does't has to open a web page on origin-A before he can use keys > managed by origin-A. > > For example: > 1) User opens web page at origin-B > 2) Web page of origin-B loads a web page from origin-A in a 2 > pixel iframe > 3) A script that is loaded by the original web page at origin-B > sends a request to the iframe using postMessage() requesting to > sign a message > 4) If origin-A trusts origin-B it will sign the message and use > postMessage() to send the result back to origin-B > > *Note*: When origin-A receives the sign message message and > doesn't has a key yet it can create the key (if he needs to > register the public key to a server, it can also do this) > > *Note*: If you completely trust origin-B and want to give it full > control origin-A can send back the key to origin-B using > postMessage(). But this is probably not desirable. > > Kind regards, > > Nick Van den Bleeken > > > On 15 May 2013, at 09:51, 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 >> E-Mail : mountie@paygate.net <mailto:mountie@paygate.net> >> >> ======================================= >> PayGate Inc. >> THE STANDARD FOR ONLINE PAYMENT >> for Korea, Japan, China, and the World >> >> > > > ------------------------------------------------------------------------ > > Inventive Designers' Email Disclaimer: > http://www.inventivedesigners.com/email-disclaimer > > > > > -- > Mountie Lee > > PayGate > CTO, CISSP > Tel : +82 2 2140 2700 > E-Mail : mountie@paygate.net <mailto:mountie@paygate.net> > > ======================================= > PayGate Inc. > THE STANDARD FOR ONLINE PAYMENT > for Korea, Japan, China, and the World > > > > -- jCore Email : avitte@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web : www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com
Received on Wednesday, 15 May 2013 16:03:34 UTC