<div dir="ltr"><div>My head is spinning, though I'm sure it'll become more clear as I re-read the threads. One comment from rfk's email [1] from December:<br><br>> Chris also suggested that the encryption keys may not need to transit 
the server at all, but could instead be communicated from content-server 
to relier via a client-side postMessage API.  I don't know much about 
postMessage but it sounds worth exploring.<br><br></div>This is only possible if an iframe is involved somehow. Either the relier embeds the content server into its page (e.g., the lightbox flow[2]), or the relier embeds a hidden content server iframe in its page. <br><br>The hidden iframe solution would involve the content server creating keys and storing them into localStorage when the user signs in. When the user redirects back to the relier, the relier would embed a hidden iframe hosted by the content server that can access the keys and postMessage them out. Not terrible, but it means the keys are stored in the user's localStorage (as well as their filesystem). A bad actor who has access to the user's computer and knows their away around the filesystem could extract the keys from the filesystem and go to town.<br><br>Shane<br><br>-----------------------<br><div><br><br>[1] - <a href="https://mail.mozilla.org/pipermail/dev-fxacct/2014-December/001260.html">https://mail.mozilla.org/pipermail/dev-fxacct/2014-December/001260.html</a><br>[2] - <a href="https://123done-stomlinson.dev.lcip.org/iframe">https://123done-stomlinson.dev.lcip.org/iframe</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 2, 2015 at 12:21 AM, Ryan Kelly <span dir="ltr"><<a href="mailto:rfkelly@mozilla.com" target="_blank">rfkelly@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 1/02/2015 10:03, Adam Roach wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 1/31/15 15:50, Ryan Kelly wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 1/02/2015 04:48, Christopher Karlof wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+dev-fxacct, zaach, stomlinson, rfk<br>
</blockquote>
<br>
Thanks!<br>
<br>
Chris or Adam, it would be great if you could add a bit of background<br>
on the feature under discussion here, just so we've got full context<br>
for the list.<br>
<br>
>From the email thread I get "something loop and encryption and oauth"<br>
but it's not clear what that "something" might be :-)<br>
</blockquote>
<br>
We need to be able to encrypt "context information", as described here:<br>
<a href="https://wiki.mozilla.org/Loop/Architecture/Context" target="_blank">https://wiki.mozilla.org/Loop/<u></u>Architecture/Context</a><br>
</blockquote>
<br></span>
Thanks.  It's cool to see additional applications springing up for these account-linked encryption keys!<br>
<br>
I agree with Chris's assessment that this will be much simpler to do inside desktop firefox than on the open web.<br>
<br>
We need to be careful when defining the data model, so that we can eventually add equivalent functionality to the public oauth flow.  This means locking down what keys the relier can access, what they are called, and how are they derived from the master key material on the account.<br>
<br>
A brief sanity-check: are you working from the terminology proposed in the following thread?<br>
<br>
  <a href="https://mail.mozilla.org/pipermail/dev-fxacct/2014-December/001260.html" target="_blank">https://mail.mozilla.org/<u></u>pipermail/dev-fxacct/2014-<u></u>December/001260.html</a><br>
<br>
<br>
Also, a small suggestion for the proposed encryption flow on <a href="https://wiki.mozilla.org/Loop/Architecture/Context" target="_blank">https://wiki.mozilla.org/Loop/<u></u>Architecture/Context</a>, where you say:<br>
<br>
  """<br>
  The room context information is serialized as a JSON object, and<br>
  encrypted using kR<br>
  """<br>
<br>
The key kR is likely the only key material your relier will be able to get.  I recommend treating it like a master key and deriving purpose-specific keys from it via HKDF, rather than using it directly.<br>
<br>
<br>
 Cheers,<br>
<br>
    Ryan<br>
</blockquote></div><br></div>