<div dir="ltr">+dev-fxacct, zaach, stomlinson, rfk<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 30, 2015 at 5:44 PM, Christopher Karlof <span dir="ltr"><<a href="mailto:ckarlof@mozilla.com" target="_blank">ckarlof@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">On Fri, Jan 30, 2015 at 3:37 PM, Adam Roach <span dir="ltr"><<a href="mailto:abr@mozilla.com" target="_blank">abr@mozilla.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span>
    <div>On 1/30/15 16:14, Christopher Karlof
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>Some considerations:<br>
        </div>
        <div>* kBr (and kB) are not recoverable if the user forgets and
          resets her password. After reset, the kB will change to
          something based on the new password. If you want a recoverable
          key (which Mozilla essentially escrows) we also have kA.</div>
      </div>
    </blockquote>
    <br></span>
    Recovery is an anti-goal. If we were willing to give Mozilla a path
    to access the information, we would store it in clear text on the
    server. :)<span><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>* This isn’t straightforward on FxOS, mainly because the
          FxA code ships with the devices and we have no way to update
          it.</div>
      </div>
    </blockquote>
    <br></span>
    For the moment, we're kind of soft-pedaling the mobile client. I
    think we're willing to move forward with a plan that leaves them
    unable to view/modify this data, as long as it can be manipulated on
    the desktop. From your "isn't straightfoward" phrasing, I assume
    that we could (e.g.) run through the OAUth procedure independent of
    the platform FxA code in order to acquire a key, right?<span><br>
    <br></span></div></blockquote><div><br></div></span><div>No. Part of what makes it relatively straightforward on Desktop is there’s infrastructure for our OAuth flow to talk directly in a trusted way to Desktop Firefox. There is no such facility on FxOS or in the Web in general (e.g., on other browsers). This is what I meant by "If you’re just focusing on Desktop OAuth services, that’s a simpler case of what Tarek is after, which is providing the keys to OAuth reliers in general.” Supporting it “independent of the platform” might currently involve sending the keys over a HTTP redirect or something more complex we haven’t invented yet, which probably requires a bit more head scratching.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span>
    <blockquote type="cite">
      <div dir="ltr">
        <div>This is feasible for Loop Desktop logins today. We could
          bubble up kBr to the Loop Desktop code during the login
          process, but I’d need to think about it more and have the
          implementation approach reviewed before proceeding. <br>
        </div>
        <div><br>
        </div>
        <div>If you’re just focusing on Desktop OAuth services, that’s a
          simpler case of what Tarek is after, which is providing the
          keys to OAuth reliers in general.</div>
      </div>
    </blockquote>
    <br></span>
    Right; this would be just for the Loop Desktop client, at least for
    the foreseeable future.<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>Timeline?</div>
        <br>
      </div>
    </blockquote>
    <br>
    The related feature is slated for Firefox 39.<br>
    <br>
    Ideally, we'd like to be able to work with this during the Firefox
    39 development cycle, so we'd need a dev environment enough in
    advance of March 30th that we could integrate and make use of it. If
    we can't hit that window, we can deal with having it later, although
    there would be some user-visible impacts and we'd have to do some
    rearchitecting to do things one way, and then pivot once the
    capability became possible.<br>
    <br>
    I fully understand if this isn't a reasonable timeframe for your
    team, which is why I opened by asking when you think you could have
    this kind of thing implemented rather than asking if you could have
    it ready for us in the 39 dev cycle. :)<span><br>
    <br></span></div></blockquote><div><br></div></span><div>I need to think about that more, but if you’re just targeting the narrow Desktop Hello case, it’s likely pretty straightforward.</div><div><br></div><div>-chris</div><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span>
    <div>-- <br>
      <div style="font-family:sans-serif"> <span>Adam Roach</span><br>
        <span style="font-size:12">Principal Platform Engineer</span><br>
        <span style="font-size:12"><a href="mailto:abr@mozilla.com" target="_blank">abr@mozilla.com</a></span><br>
        <span style="font-size:12"><a href="tel:%2B1%20650%20903%200800%20x863" value="+16509030800" target="_blank">+1 650 903 0800 x863</a></span><br>
      </div>
    </div>
  </span></div>

</blockquote></span></div><br></div></div>
</blockquote></div><br></div>