FxA timelines and you
lloyd at mozilla.com
Sat Oct 19 06:02:59 PDT 2013
Fernando, thanks for the creativity and working so hard to find a solution - I realize you're trying to find a compromise that works for your peers and the gaia and gecko teams - and I really appreciate all the energy and thought you're putting into this. I wish I could take you out for a beer next week (jed will be there, is a better human than I, and will do so in my absence).
Generally though, this still makes me uncomfortable. The initial goal that I had going into this was to keep as much of the Firefox Accounts code as possible in one place, and modular. Minimal code landing in platform to start, and a clear and minimalistic contract between Firefox Accounts and the rest of the system.
I know that the identity team (specifically jedp, shane, sam, and zaach) will be (at least partially) tasked with maintaining this code. So I'm favoring bright lines around the fxa implementation. We've learned a lot from maintaining persona on firefoxos.
Finally, this is an account system we're integrating. Other people have account systems. This phone is customizable. It feels a little bit unnatural to bake our own account system in deeply - that doesn't really fit with our stated goals for firefoxos.
First question: Do others see value in these goals? (I obviously do)
Now I feel like we're proposing to land code all over the system - Gecko, Gaia:Settings, Gaia:Preferences, Gaia:FTU, maybe new DOM bindings.
I feel like there is a graceful path forward once we have firefox accounts implemented in a certified app to move more and more of the appropriate bits into platform (crypto that's useful to the whole web, but not our own account system). We can even explore using platform provided jwcrypto in the first pass (which is, as far as I know, landed but untested).
And again, replacing marketplace sign-in (which is OOP, long lived, and remoted), with Firefox accounts (which is OOP, short lived, and local) - seems like a significant win from a performance perspective.
Second Question: Do folks agree that the certified app approach is a significant performance improvement over Persona in FirefoxOS as it is today? (I do)
Are we trying to boil the ocean here and optimizing, jeopardizing our chances of landing in 1.3, before we've even understood whether we can get the simplest integration done in the 1.3 timeframe?
Third Question: Do folks believe the certified app proposal is less work than any other? (because I still do)
Sorry for pushing so hard here folks, but I really want to make sure we deliver the thing that has user value first.
On Oct 18, 2013, at 4:30 PM, Fernando Jiménez Moreno <ferjmoreno at gmail.com> wrote:
> On 17/10/2013, at 17:48, Fabrice Desré <fabrice at mozilla.com> wrote:
>> On 10/17/2013 05:34 AM, Fernando Jiménez Moreno wrote:
>>> On 17/10/2013, at 06:28, Fabrice Desré <fabrice at mozilla.com> wrote:
>>>> 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 (eg.
>>>> looks very nice, but will likely not work well). This thing will blow up
>>>> with no rescue team on target devices currently deployed.
>>> I think there might be a general confusion about Persona vs FxA implementations in FxOS.
>>> You are describing the implementation of a Persona flow. The FxA flow, even if it will use the same API (with a few tweaks) it's going to be a bit different and it won't open the Trusted UI or use any remotely hosted content.
>> The diagram at
>> is not about persona, it shows the FxA app as a standalone app using IAC.
> Indeed. And it says nothing about the Trusted UI or any loaded network resources :)
>>> Lloyd wrote a few words about the proposed architecture at  and . But basically, in a few words, the big picture of the FxA flow would be something like:
>>> 1- A RP with a FxA <meta> or a FxA manifest field (still to be discussed) requests a login via nav.id.request() API.
>>> 2- The nsIDOMIdentity component handle this request and notice the <meta> or manifest bits, so it takes the FxA path.
>>> 3- A "fxacct-login" or similar system message is sent to content and handled by the FxA app (OOP certified app).
>>> 4- The FxA app communicates with the FxA service via its own REST API and does all the Persona magic to finally get a Persona assertion that is delivered to the RP via the usual nav.id callbacks.
>> How does that magic part work? Is this still using the current setup
>> with a dedicated process? If so, you have : the FxA app, the nav.id oop
>> frame, and probably the oop keyboard at some point (oh, and the
>> homescreen and cost control apps are still trying to not be killed also).
> With the current setup, there will be a dedicated process for the FxA app but there won't be any nav.id OOP frame. As I previously mentioned the current FxOS Persona implementation (Trusted UI loading the remotely hosted Persona flow from the network) will *not* be involved in the proposed FxA flow.
> In any case, I agree with your previous comment about the potential benefits of placing as much code as possible into the platform for this flow. I had a couple of IRC conversations with Jed and Lloyd about this and this is what I know so far:
> 1. The FxA app is a must to have cause we need to show an UI for the sign-up process. Unless we build this UI in the System app. but I'll assume that the independent app option is the preferred one.
> 2. For doing all of this Persona magic, about which I am mostly ignorant but Lloyd and/or Jed can probably explain (please do :) ), the FxA app has two dependencies: jwcrypto  and  gherkin.
> 2.1 jwcrypto is already in Gecko  \o/.
> 2.2 gherkin is a complete new thing to me but seems to be the JS client for this API  and it seems to be pending some minification work if it is intended to be loaded within the FxA app. It would be great to know if the entire lib is needed or only a few specific parts (Jed, Lloyd?).
> So given the above, I was wondering if we could have an alternative architecture like this one:
> 1. Move all the Persona magic client side work that is supposed to be done by the FxA app to the platform (that might be mostly what gherkin currently does I guess).
> 2. Build and expose a FxA DOM API for certified apps only.
> 3. Turn the FxA app into UI related stuff only and make it consume the FxA DOM API.
> 4. Make FTU and Settings also consume the FxA DOM API.
> What I think are Benefits of this approach:
> 1. We get rid of the IAC API dependency, which means:
> 1.1. Simplicity.
> 1.2. A shorter messaging path. We won't need the System app as a proxy or direct communication between FTU <-> FxA app or Settings <-> FxA app.
> 1.3. No instances of MozInterAppMessagePort.
> 1.4. no  issue.
> 2. We don't duplicate the jwcrypto dependency in the content side as we already have it in Gecko.
> 3. We don't need to launch a new process for the sign-up flow from FTU and Settings or for the consumption of an already signed in account from a RP.
> 4. We make the FxA process lighter as it would only host the UI for the sign-up process and the FxA DOM API consumer parts.
> A couple of random clarifications:
> 1. I still don't know how this FxA DOM API would look like. I have a remote idea about it, but I'll need to check with Lloyd, Jed and others before.
> 2. RPs will still use the Persona API (plus the <meta> or manifest thing already mentioned). The FxA DOM API is intended only to allow certified apps to do the required account management work.
> Let me know if this makes sense, please.
> / Fernando
>  https://github.com/mozilla/jwcrypto
>  https://github.com/mozilla/picl-gherkin
>  https://mxr.mozilla.org/mozilla-central/source/toolkit/identity/jwcrypto.jsm
>  https://github.com/mozilla/picl-idp/blob/master/docs/api.md
>  https://www.w3.org/Bugs/Public/show_bug.cgi?id=23327
> Sync-dev mailing list
> Sync-dev at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sync-dev