<div dir="ltr"><div><div><div><div><div><div><div><div>Hi folks,<br><br></div>Me, rfkelly, zaach, and markh had a discussion about keeping a device's FxA login state in sync with the fxa-content-server.  By "device", I mean a Firefox -- Desktop, iOS, Android.<br><br></div>We discussed two main use cases, both after a user signs in to Sync in the browser.  The first case is that they use a third party oauth relier (like Pocket): we want to give a smooth, password-less flow when possible.  The device knows that the user is signed in, even if browser state (cookies, localStorage) that might tell <a href="http://accounts.firefox.com">accounts.firefox.com</a> that the user is signed in is not present.  The second case is that a user is signed in and wants to go to <a href="http://accounts.firefox.com/settings">accounts.firefox.com/settings</a> and interact, but again the browser state is missing.<br><br></div>We discussed a number of aspects of this; sorry, I didn't take notes.  We ended up with the following avenue to pursue:<br><br>* a message exchange from fxa-content-server to device and back.  This exchange can target WebChannels only, since older devices won't participate.  This exchange cannot be dependent on the context query parameter, since an oauth relier (like Pocket) will not produce that parameter.<br><br></div>* the exchange should be as brief as possible, and ideally should complete before the fxa-content-server produces the 'loaded' message for the device to consume.<br><br></div>* tentatively, the exchange will include {email, uid, sessionToken}, where sessionToken will be non-null.  The exchange needs to include sessionToken in order for the fxa-content-server to take certain actions (like changing the avatar, I think).  It should be noted that the sessionToken doesn't allow some actions (like changing the password). <br><br></div><div>* we are considering adding some opt-in-to-feature flags to the exchange.  For example, a device might ask for "choose what to Sync" options to be hidden.<br></div><div><br></div>The next action is for zaach, who will be doing most of the fxa-content-server work, to evaluate how this messaging might fit with our existing context query parameter matrix.<br><br></div><div>Others in attendance: kindly correct my mis-conceptions, add what I dropped, and fill in the full richness of our shared experience.<br></div><div><br></div>Best,<br></div>Nick<br></div>