On 1/3/14 4:42 PM, Toby Elliott wrote: > It also raises the question of what FxA Sync is under this model. > Simply the same Sync backend, with FxA auth and key stretching > replacing the secret key?
Yup. The FxA process ends with a (Persona) certificate, which gets submitted to the tokenserver to get the token that the Sync servers will consume. The Sync master key is derived from FxA's "kB" key. No changes to the Sync protocol (either the encryption or the schema / poll / merge / data-formatting aspects). There are certainly things we'd like to fix in that space, but none of them are on the table for the 29-Jan deadline. I don't know as much about the tokenserver (design or deployment) as I should, but if current-Sync is using it, then I imagine that we could run a single tokenserver that understands both old and new/FxA schemes, it will have a DB with accounts that are either tied to an (old-sync) email address or a (new-FxA) account GUID, and then the rest of the Sync infrastructure can be shared without it even knowing what sort of client is talking to it. We could also run a new tokenserver that only speaks FxA, dispatching to a new batch of Sync servers, which run the same code as the old ones but otherwise not overlapping at all. > Will there ever be a window to make improvements to the backend > protocol? That's the big question. By spending our user-visible flag day on the pairing -> FxA transition, we'll be hard pressed to have a second one for any huge breaking protocol change. So I think we'll be limited by whatever we can do without user interaction (although we can probably get away with forcing people to re-log-in if necessary). My hunch is that we can make most of the backend protocol improvements we want within that constraint, but I don't know for sure. cheers, -Brian _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
