On 1/02/2015 04:48, Christopher Karlof wrote:
+dev-fxacct, zaach, stomlinson, rfk
Thanks!
Chris or Adam, it would be great if you could add a bit of background on
the feature under discussion here, just so we've got full context for
the list.
From the email thread I get "something loop and encryption and oauth"
but it's not clear what that "something" might be :-)
Cheers,
Ryan
On Fri, Jan 30, 2015 at 5:44 PM, Christopher Karlof <[email protected]
<mailto:[email protected]>> wrote:
On Fri, Jan 30, 2015 at 3:37 PM, Adam Roach <[email protected]
<mailto:[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] <mailto:[email protected]>
+1 650 903 0800 x863 <tel:%2B1%20650%20903%200800%20x863>
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
