- From: Arun Ranganathan <arun@mozilla.com>
- Date: Mon, 13 May 2013 14:38:51 -0400
- To: Aymeric Vitte <vitteaymeric@gmail.com>
- Cc: Anders Rundgren <anders.rundgren@telia.com>, Ryan Sleevi <sleevi@google.com>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
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 :-( > 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. > 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 -- A*
Received on Monday, 13 May 2013 18:39:21 UTC