> 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 might need to be some things that need to change in order to make token-invalidating events (like password resets) safe; this came up today. We need to discuss this. > 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). Last time this came up when I was in the room, I pointed out that migration pain later is the price we pay for shipping in 29, and not spending the up-front time on, e.g., version negotiation and a meta server. We can't stick with the existing Sync protocol and storage schema forever (it's too limiting and is cramping client features), and we're electing not to use *this* shift to make the next one easier, so we should simply accept that at some point we'll have another transition. It might be bumpy, or we might be able to make it pretty smooth (as we're aiming to with the FxA switchover, by using migration sentinels and pre-populating email address fields), but I don't see us still struggling within the confines of Weave in 2015 or 2016. _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
