FxA timelines and you

Jed Parsons jparsons at mozilla.com
Thu Oct 17 05:27:16 PDT 2013

Hi, Fabrice,

We actually do intend to build fxa sign-in and services natively on device, with no hosted UI.

> De: "Fabrice Desré" <fabrice at mozilla.com>
> Enviados: Jueves, 17 de Octubre 2013 7:28:55
> The nav.id implementation is "kind of" remoted, in the sense that it
> works oop, but it relies on the security UI in b2g that spawns a new
> process to load network resources. That's very suboptimal, and in no way
> can we add yet another process for FxA 

So what we're actually proposing for fxa is not to rely on either remote hosted UI or on the trusted UI for presentation.

We want to have the fxa ui and core code completely native and client-side.

When an RP uses navigator.id.* to request an identity from fxa, we are catching this at the nsDOM level and handing control over to fxa on the device.  fxa will return a browserid assertion, but it will be issued by firefox.com, not persona.org.

There will of course be a firefox accounts service that the native app needs to interact with (via restful apis), but if the user is signed in, we can generate the assertion on device with no calls to pull UI and no calls to the remote service for authentication.

> https://docs.google.com/file/d/0B0Az-aXpSyQJZ2xCdWRwWTNoRDQ/edit?usp=sharing&pli=1
> looks very nice, but will likely not work well). This thing will blow up
> with no rescue team on target devices currently deployed.

In light of my attempt to explain this above, do you still think this is the case?  Can you help us understand what is wrong and what we could do better?

> The way forward is to move back into the platform as much as code as
> possible, deal with protocol changes in a backward compatible way and
> burn the tree once in a while like we all do ;)

So yes, this will all be code on the platform.  We have a related quarterly goal in our group to solidify apis and data models in a way that will maintain compatibility and make sign-in on native and mobile devices a simpler process.  We are going forward on fxa with those api modifications in mind.

> Oh, and you still have almost two months. That's a lot in b2g land!

Well, I don't know :)  Time seems to move at a different pace in b2g land.  But we're working on it!


> 	Fabrice
> On 10/16/2013 07:04 PM, Doug Turner wrote:
> > Have you guys figured out how FxA is going to work between processes?
> > That is, suppose the FTU sets up a user.  Now, I run my application and
> > I call navigator.id <http://navigator.id>.  What happens?  Am I going to
> > be hitting the network, or are you going to save this info in the parent
> > process and just share it with the application?
> > 
> > // Doug Turner
> > 
> > 
> > On Wed, Oct 16, 2013 at 6:58 PM, Jared Hirsch <6a68 at mozilla.com
> > <mailto:6a68 at mozilla.com>> wrote:
> > 
> >     TL;DR - If you want to help danny and rfk, you should really
> >     consider doing it right away.
> > 
> >     Hey all,
> > 
> >     Here are some things I've learned from chatting with Rob Lord in #picl:
> > 
> >     * FXOS 1.3 is feature complete Dec 9, to be released in March
> >     * As of now, FxA is scheduled to be code complete & riding that train.
> >     * As of now, I think UX is working on mocks/flows, but I don't think
> >     they have clarity yet on the final feature set or any of the
> >     interactions.
> >     * Next week (Oct 21-25) there is a Madrid work week, in which
> >     FxA-Persona integration details will be worked out. Jed and Lloyd
> >     (and others?) will be there.
> > 
> >     Any of these things may be incorrect now, or become inaccurate in
> >     the immediate future. But, thought I'd share what I've learned, to
> >     try to give signin folks a sense of the ludicrous speed at which FxA
> >     needs to build. Signin devs, if you want to lend a hand, it's
> >     probably a good idea to do it soon (just some friendly advice).
> > 
> >     Sync devs, CCing you to be ridiculously overcommunicative, also in
> >     case timelines have changed in the past 24 hours, you can correct me
> >     here ;-)
> > 
> >     Yours in well-intentioned mailing list overloading,
> > 
> >     Jared
> >     _______________________________________________
> >     dev-identity mailing list
> >     dev-identity at lists.mozilla.org <mailto:dev-identity at lists.mozilla.org>
> >     https://lists.mozilla.org/listinfo/dev-identity
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Sync-dev mailing list
> > Sync-dev at mozilla.org
> > https://mail.mozilla.org/listinfo/sync-dev
> > 
> --
> Fabrice Desré
> b2g team
> Mozilla Corporation
> _______________________________________________
> Sync-dev mailing list
> Sync-dev at mozilla.org
> https://mail.mozilla.org/listinfo/sync-dev

More information about the Sync-dev mailing list