On 8/9/13 3:15 PM, Lloyd Hilaiel wrote:
Chris and I talked about this a bit this afternoon. Some thoughts:
> 4. what is the extent of the content's responsibility? More than just
> auth gets sucky.
> A: It's just auth. More than just auth gets sucky. Preferences and
> mgmt are "native".
* if we go with the "doughnut" approach (BTW I love this name), we need
to clearly define the boundary. Signin-in-content means the FF
home-page "Sign-In To Sync!" button leads to a content page that gets:
- an API for local crypto implementations (scrypt), but it falls back
to the scrypt-helper if not available / too slow
- an API to give a sessionToken and the kA/kB keys to the sync engine
- maybe an API to detect if sync is already set up
* An account portal web page (usable from non-FF) could behave the same
way, but get a different kind of token that represents a non-device
session. This session lets you do account things (maybe change
password, maybe delete account, maybe do non-Sync things).
We have to decide what to bake in and what to leave in web. A while ago,
Ben had a proposal ("BCP" if anyone remembers) in which the entire sync
mechanism (including encryption) would be delivered in one of these "JS
ambassador"/doughnut frames, just like we do with BrowserID IdP pages.
We probably can't go that far. The sync hardware needs to live close to
the internals. But the auth and UI could probably afford to be loaded in
web content.
A good distinction might be "relates to Sync" vs "relates to the FF
Account".
cheers,
-Brian
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
