+dev-fxacct, zaach, stomlinson, rfk On Fri, Jan 30, 2015 at 5:44 PM, Christopher Karlof <[email protected]> wrote:
> On Fri, Jan 30, 2015 at 3:37 PM, Adam Roach <[email protected]> wrote: > >> On 1/30/15 16:14, Christopher Karlof wrote: >> >> Some considerations: >> * 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. >> >> >> 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. :) >> >> * This isn’t straightforward on FxOS, mainly because the FxA code ships >> with the devices and we have no way to update it. >> >> >> 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? >> >> > 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. > > 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. >> >> 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. >> >> >> Right; this would be just for the Loop Desktop client, at least for the >> foreseeable future. >> >> >> Timeline? >> >> >> The related feature is slated for Firefox 39. >> >> 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. >> >> 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. :) >> >> > I need to think about that more, but if you’re just targeting the narrow > Desktop Hello case, it’s likely pretty straightforward. > > -chris > > > >> -- >> Adam Roach >> Principal Platform Engineer >> [email protected] >> +1 650 903 0800 x863 >> > >
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
