1015423 - Get FxA user's email to FMD

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: FxA, defect, P3)

Description

[Sam Penrose]

navigator.mozId returns a concatenated, byte-encoded blob to onlogin(). Provide a method to extract the underlying JSON.

Comment 1

[Sam Penrose]

Attachment: 1015423-decodeAssertion.patch

Jed, this gets stringified JSON to the RP. Do you remember if there is a way to send an object?

Comment 2

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

Comment on attachment 8428169 [details] [diff] [review]
1015423-decodeAssertion.patch

I understand that it's useful to extract the underlying JSON for debugging, but I think we want to be careful about putting the methods to do this in our API, since we don't want people working with assertions in the client; verification and inspection should be done on the server.

So my personal feedback is that we don't want to do this because I think it could encourage bad habits in client-side programming that could have dangerous consequences.

If it helps, the code is pretty straightforward:
https://mxr.mozilla.org/mozilla-central/source/dom/identity/tests/mochitest/test_declareAudience.html?force=1#229

Also, François has a nice set of tools for debugging with BrowserID:
https://github.com/fmarier/browserid-tools

Comment 3

[Sam Penrose]

Jed, this is great feedback, thank you. I had neglected the very important question of verification. Here our old friend, the awkward question "to what extent is the device the user-agent, and to what extent is the app the user-agent?" rears its head. Insofar as the app is the user-agent, you are absolutely correct that FMD should simply send the assertion to its server and receive the email in return *if* the assertion is verified. But ...

... does it make really make sense to distrust the device's vouching for a *firefox account* ...
... in the context of this certified app?
... in general?

I am changing the title of this bug to reflect FMD's actual request. Guilherme, given that FMD does send the assertion to the server:

  https://github.com/mozilla-b2g/gaia/blob/master/apps/findmydevice/js/findmydevice.js#L194

Can FMD simply get the email back from it? If not, is that a short term problem of deadlines, or something deeper?

Comment 4

[Guilherme Gonçalves [:ggp]]

(In reply to Sam Penrose from comment #3)
> Can FMD simply get the email back from it?

Yes, we're going to do that.

Comment 5

[Guilherme Gonçalves [:ggp]]

Actually, sorry, I got ahead of myself there. There are two moments in which we need the logged in user's email:

1) When a user, logged into FxA, enables FMD. This is the client-server communication Sam linked to, and yes, it would be feasible to have the server unpack the assertion and return the email.

2) When someone attempts to disable FMD, so we can compare that email address to the one that had initially enabled it. We currently do not contact the server when FMD is being disabled, so the solution here is not as straightforward.

In 2), it would be possible for the client to verify the assertion itself, for example. Or maybe even hit the server once again, just to get it to return the email address. However, I'd rather not do any network activity there if I can, as that would greatly increase the complexity of the disabling procedure.

In light of this, perhaps we can reconsider making FxA provide this information to us somehow instead?

Comment 6

[Sam Penrose]

Hhmm. I believe the state machine for your case 2) looks like this:

1) Manual disable triggers refreshAuth with same email: FMD verifies, no problem. Note that refreshAuth hits FxA server (or fails if offline).
2) FxA logout while enabled leaves enabled: FMD needs to have stored enabling email previously.
3) FxA login after 2): FMD verifies assertion, then:
  i. same email: no problem
  ii. different email: FMD is "locked on"

In case 3)ii. FMD should surface language to the effect of "FMD has been enabled by user [e-mail]. To disable FMD, log out of FxA and have a@example log back in to FxA and disable FMD."

Is that the correct state machine?

Comment 7

[Guilherme Gonçalves [:ggp]]

Yes. Of course, step 3) takes place upon a disable attempt (just pointing it out for clarity). So, on a disable attempt, FMD should:

1- Trigger a refreshAuth
2- Get an assertion back, <hand wave>get it verified and extract the email from it</hand wave>
3- Compare the email to the one that was previously stored ([e-mail])
  i. If they match, disable FMD
  ii. If they don't, display an error message and keep FMD enabled

We may want to skip the refreshAuth if we know beforehand that the currently logged-in user is not [e-mail], since we know that disabling will fail even if the assertion verifies, but that's outside the scope of this bug I think.

Comment 8

[Sam Penrose]

Hhmm. In the case where the person holding the phone asks to disable, there are two possibilities:

I. There has not been an FxA logout/login since FMD was first enabled.
II. There has been, *in which case both of your callbacks to watch should have fired*

Therefore, while your step 3. is possible, it will only occur rarely, and you will know when it occurs. Mostly when you get a refreshAuth you will be in my case I, and you will know that the emails will be the same (though of course it's worth checking).

(In reply to Guilherme Gonçalves [:ggp] from comment #7)
> Yes. Of course, step 3) takes place upon a disable attempt (just pointing it
> out for clarity). So, on a disable attempt, FMD should:
> 
> 1- Trigger a refreshAuth
> 2- Get an assertion back, <hand wave>get it verified and extract the email
> from it</hand wave>
> 3- Compare the email to the one that was previously stored ([e-mail])
>   i. If they match, disable FMD
>   ii. If they don't, display an error message and keep FMD enabled
> 
> We may want to skip the refreshAuth if we know beforehand that the currently
> logged-in user is not [e-mail], since we know that disabling will fail
> even if the assertion verifies, but that's outside the scope of this bug I
> think.

Comment 9

[Sam Penrose]

Guilherme, can you let me know what the status of this bug should be? Thanks very much.

Comment 10

[bhavana bajaj [:bajaj]]

Vishy will get privacy input here

Comment 11

[Guilherme Gonçalves [:ggp]]

RESOLVED WONTFIX, since decodeAssertion is not going to be added to mozId after all? I think we'll just resort to verifying the assertion in the client in FMD.

Comment 12

[Sam Penrose]

Thanks ggp, and sorry we couldn't do more.