On 18/10/2013 17:45, Fabrice Desré wrote:
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.
Welcome to my world :P. I call dibs to corner Fernando into a room with
a blackboard and getting some painted diagrams from him :)
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
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra política de envío y recepción de correo electrónico en el enlace
situado más abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
