Questions about using FirefoxAccount information

Lloyd Hilaiel lhilaiel at
Thu Nov 14 11:27:06 PST 2013

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?

> 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!



More information about the Dev-fxacct mailing list