On 10/18/2013 06:30 AM, Fernando Jiménez Moreno wrote:
>> The diagram at
>> https://docs.google.com/file/d/0B0Az-aXpSyQJZ2xCdWRwWTNoRDQ/edit?usp=sharing&pli=1
>> 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 :)
Ok. So I guess I don't understand *at all* what we are trying to achieve
with FxA. Specifically:
- When I create my FxA account, do I reuse my existing persona identities?
- Once I have a FxA account, does that change anything for web sites
that currently use Persona? Do I get a simplified login flow? Do sites
need to do something special?
>>> Lloyd wrote a few words about the proposed architecture at [1] and [2]. 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 [1] and [2] gherkin.
> 2.1 jwcrypto is already in Gecko [3] \o/.
> 2.2 gherkin is a complete new thing to me but seems to be the JS client for
> this API [4] 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 [5] 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.
If you want to go fast, I would do gecko --mozChromeEvent--> system app
--IAC--> settings|ftu
Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
