- From: Ryan Sleevi <sleevi@google.com>
- Date: Mon, 13 May 2013 13:43:11 -0700
- To: Aymeric Vitte <vitteaymeric@gmail.com>
- Cc: Arun Ranganathan <arun@mozilla.com>, Anders Rundgren <anders.rundgren@telia.com>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
On Mon, May 13, 2013 at 1:38 PM, Aymeric Vitte <vitteaymeric@gmail.com> wrote: > > Le 13/05/2013 20:38, Arun Ranganathan a écrit : > >> On May 13, 2013, at 1:49 PM, Aymeric Vitte wrote: >> >>> I have suggested too : >>> http://lists.w3.org/Archives/Public/public-webcrypto/2013May/0070.html >>> >>> To be more clear, only a combination of link above and links below is >>> feasible, and that's not a hack, neither a hook, that's the web. >> >> >> +1, but bookmarklet use here cannot possibly be good and so shouldn't be >> considered a viable answer to Mountie's question :-( > > > Mountie's, Karen's or others, I am not saying that's a fantastic solution > (as well as iframes uses), but I don't see another one. > > >> >> >>> And I believe "super cookie" is not the web, but you can consider >>> indexedDB as a mega cookie. >>> >> Any client-side storage mechanism can be invoked by colluding origins for >> different purposes, but the difference is that you don't get HTTP behavior >> or XHR in withCredentials mode (but you knew that). If they aren't in >> collusion, then it's likely to be a hack. > > > 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? Cross-origin messaging != CORS Cross-origin messaging = postMessage, which takes structured clonable objects (eg: including keys) > > >> >> >>> I have not thought a lot to eID case, maybe a more detailed example >>> including requirements/restrictions could help to try writing it and see if >>> it's feasible as such. >>> >> Depending if the eID use case can work within a "cooperating origins" >> model (to be contrasted with collusion), we may have something here. If >> not, I defer to Nick VDB: >> http://lists.w3.org/Archives/Public/public-webcrypto/2013May/0046.html > > > What is unclear for me in the eID example is what is secret and what is not. > > I have read several time Nick's description, maybe something a little bit > more detailed could help. > > >> >> -- A* >> > > -- > 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 Monday, 13 May 2013 20:43:38 UTC