<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 23, 2014 at 8:05 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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Dec 23, 2014 at 1:42 AM, Tarek Ziade <span dir="ltr"><<a href="mailto:tarek@mozilla.com" target="_blank">tarek@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"><div><div><div>Ryan, Chris,<br><br></div>I am using PyFxa to prototype the encryption flow here, by directly connecting to FxA : <br><br><a href="https://github.com/tarekziade/share/blob/master/share.py#L66" target="_blank">https://github.com/tarekziade/share/blob/master/share.py#L66</a><br><br></div>Can you tell me if that's the flow you had in mind ?<br><br></div></div></blockquote><div><br></div></span><div>I don’t know the best way to do this yet.</div><div><br></div><div>You suggestion gets the job done, but the idea would be that reliers would integrate with a “public facing component” to get the keys, e.g., the OAuth and Profile server. </div></div></div></div></blockquote><div><br></div><div>Yes, as noted in my code, this direct access is temporary. It's done just because for now we can't get the keys back as an oauth relier. I used a direct Auth just to show how the kB key can be used.<br><br></div><div>So the final version would replace this part with an oauth relier part to get the keys.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The Auth server isn’t the recommended way to interface with FxA (it’s internal plumbing), but it is indeed open, and we’re not doing anything to prevent developers from using it directly. </div><div><br></div><div>-chris </div><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div>Thanks<br><div><div><br><br></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 23, 2014 at 9:05 AM, Tarek Ziade <span dir="ltr"><<a href="mailto:tarek@mozilla.com" target="_blank">tarek@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"><br><div class="gmail_extra"><div class="gmail_quote"><span>On Tue, Dec 23, 2014 at 1:07 AM, 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">Explicit revocation is different from “revocation as a surprising side of effect of doing something else that’s not obviously going to trigger revocation”. <div class="gmail_extra"><div class="gmail_quote"><div><div><br></div><div>Ryan’s point is that password reset could easily fall into the latter type if we’re not careful.</div></div></div></div></div></blockquote><div><br></div></span><div>I don't see how this is avoidable though, without storing the old keys on the server, which seems like a bad idea.<br><br><br></div><div>Did you have a solution in mind ?<br><br></div><div>Cheers<span><font color="#888888"><br>Tarek<br></font></span></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>