Questions about using FirefoxAccount information

JR Conlin jrconlin at
Thu Nov 14 12:02:54 PST 2013

On 2013/11/14 11:27 AM, Lloyd Hilaiel wrote:
> On Nov 14, 2013, at 6:46 PM, JR Conlin <jrconlin at> wrote:
>> On 2013/11/14 12:42 AM, Lloyd Hilaiel wrote:
>>> On Nov 14, 2013, at 12:30 AM, JR Conlin <jrconlin at> wrote:
>>>> On 2013/11/13 2:14 PM, Ryan Kelly wrote:
>>>>> On 14/11/2013 6:51 AM, JR Conlin wrote:
>>>>>> As I understand it, login is performed by a gherkin script on the
>>>>>> browser that returns a certificate. The server I'm building is not
>>>>>> node.js, so I have a few questions about certificate management:
>>>>> At a high level, the login flow from the server's perspective is
>>>>> completely identical to the exiting BrowserID login flow (which probably
>>>>> explains why we haven't documented it separately):
>>>>> * Client talks to FxA server to obtain an identity certificate
>>>>> * Client uses certificate to sign an identity assertion
>>>>> * Client delivers identity assertion to the server to login
>>>>> * Server verifies the identity assertion and exchanges it for
>>>>>   e.g. a session cookie
>>>> As noted, I am working on the Where's My Fox server portion.
>>>> Just so I'm clear, the current design has two aspects to it:
>>>> * A FxOS client
>>>> * A server with it's own UI.
>>>> The device and server need to coordinate and agree upon the fact that
>>>> the user is the correct individual. As I understand, the device could
>>>> send the verified certificate UUID (and store it for future use).
>>>> Likewise the server could authenticate the cert and fetch the same UUID,
>>>> only allowing if the two match. This would prevent the need to exchange
>>>> the certificate between the two, correct?
>>> The user’s email and UUID will be embedded in an identity assertion.  You should verify the validity of the assertion and extract both.
>>>>>> 1) Is the certificate sensitive information (should I protect it from
>>>>>> inadvertent exposure or is it encrypted such that it's not an issue)?
>>>>> Yes it is, but the certificate itself should never leave the client
>>>>> device, so the server shouldn't need to worry about it.  Only signed
>>>>> identity assertions are seen by the server.
>>>> Ah, so possibly a confusion in terminology on my part. I thought that
>>>> "certificate" was the new name for the old BrowserID "assertion". If the
>>>> previous understanding is correct, however, I need not send the signed
>>>> assertion to the server at all.
>>> I think you do need to send assertions to your server to establish a
>>> session. The assertion identifies and authenticates the user to your
>>> service. Allowing authentication to occur via the assertion means you
>>> don’t need any other mechanism for authing the user.
>> Ah, I'm not really authing the user in this case. It's more a question
>> of providing a globally unique identifier for a given individual so that
>> the device and web site can coordinate. I can also easily hash the GUID
>> if disclosure of that info might be potentially damaging.
> I’m not nearly as concerned about disclosing a user’s identifier or email address as I am about disclosing their location.
> If I can generate an assertion which asserts I am the owner of the identifier in question, then can I also see the location of the phone of the user associated with that identifier?

The device only reports it's location to the server. In order for you to
discover this information you would need to:

1) spoof the carrier DNS information for the device to point to the
malicious server.
2) spoof the TLS cert for the malicious server to be the same as our
legit server.
3) trigger a device registration call in order to get the user's ID number
4) essentially replicate our server in order to handle location updates
associated with the device ID.

Honestly, if you're doing steps 1 & 2 already, it's pretty much a wash
for the user and they're probably already tracking your device from
carrier records since that's easier, more discrete, and less likely to
raise suspicion.

>> Authorization would be contained on the mobile device and the web
>> control panel, where sessioning makes more sense.
>>> From an “RP” (your server's) perspective, support of FxOS with FxA
>>> inside (tm) is almost completely analogous to how persona works today.
>>> You get an assertion, validate the assertion, get the user’s email
>>> address (and uuid with fxa), and create a session.
>>> is this confusing, or clarifying?
>> It's very clarifying, thanks!
> yay!
> lloyd

More information about the Dev-fxacct mailing list