On Oct 10, 2013, at 6:00 PM, Zachary Carter <[email protected]> wrote:
> >> From: "Dirkjan Ochtman" <[email protected]> >> To: "Lloyd Hilaiel" <[email protected]> >> Cc: [email protected] >> Sent: Thursday, October 10, 2013 3:56:56 AM >> Subject: Re: Firefox Accounts on Firefox OS > >> On Thu, Oct 10, 2013 at 11:56 AM, Lloyd Hilaiel <[email protected]> wrote: >>> https://id.etherpad.mozilla.org/fxa-on-fxos >>> >>> Curious to hear thoughts and constructive criticism. > >> Trying to make sense of this, after reading three times, but still >> struggling a bit. > >> For the FTU experience, step 4, is that "normal" Persona >> authentication + provisioning? > > Correct me if I'm wrong Lloyd, but this will be the special FxA flow, which > is similar to how the fallback currently operates. It may not need the normal > Persona authentication + provisioning phases, but the output is compatible > with the normal Persona flow. Yes, as a first step I think this is exactly right. I do think we need to allow jgruen and rfeely to explore and optimize. One key thing is that having to check your email at unboxing is a near killer. federation might solve this. delayed verification might mitigate this (I notice the FxA apis already have this notion of delayed verification and tiered permissions). Not enough uncertainty that we can't plow forward, but enough that we need to be ready for the specifics of how you prove your identity while you're doing first time setup to change. >> For applications where FxA is the only way to sign in: why is FxA >> required for WheresMyFox and Marketplace? For WMF, I presume it's >> because you need to access a cloud service to wipe/find your device, >> but I don't really see the need for more than authentication. For >> Marketplace, is it because we're syncing application ownership data? >> Again, do we need more than authentication? > > I assume Marketplace wants to associate app purchases with a stable Firefox > Account ID, so that the user could log in to a new device and have their apps > available (hand waiving over UX here). Retrieving the FxA ID would require an > additional API request or bundling it with the Persona assertion (or maybe > they will key by email after all). > > I'm not sure of WheresMyFox's requirements, but the FxA server has a devices > API that may be useful. > >> I guess what I really don't understand is what FxA provides beyond >> secure storage. I thought FxA was email address + password (which is >> being challenged, I think, which is a good thing in my book, in favor >> of first time authn through Persona?) + key storage (stretched from >> password) + sync content storage. It seems like it's now being used in >> a much wider context ("Cloud Services"!), but it's very unclear to me >> what it's actually providing in that context. > > FxA does not encompass data storage for sync, but does store encryption keys > for use by authenticated sync clients. > > It also provides SSO for apps that opt-in. Per Lloyd's doc there's a flag for > services that require FxA and a permission for apps where it's optional. > Marketplace's feature (installing apps) has a strong coupling with the > device, so it's reasonable to have that tied to the identity signed into the > device. Presumably other apps that require FxA will also have a strong > coupling with the device (or perhaps they're connected to other apps > associated with a user's FxA, or some other constraint requiring an FxA). > > It'd be nice to have a list of all the apps that are looking into using FxA > and why. Is it for the buttery smooth SSO or what? from summit, it's basically an exuberant ever-expanding set of services. It's contacts. It's sharing. It's communication / webrtc. It's remote wipe. My thinking is that because FxA gives us a way to request a new assertion for a specific domain (service), we have the authentication architecture we need. The question becomes one of per-app authorization, and we can iteratively figure that out on a per-app basis. The first two are probably: 1. marketplace wants to queue applications for installation on firefoxos (they could host that queue on their side, or they could use fxa cassandra (big question mark), or they could stand up a new service to host the queue. One that you auth to with fxa. 2. remote location of your device and eventually device wipe in WheresMyFox. we have an outstanding question to dougt for the particular requirements. Then an aside, but the other large meta feature that fxa provides us is a single database, where a user's presence in that database indicates they've been displayed a clear privacy & tos disclosure, and fulfilled whatever legal requirements are present to use services we host. While that is not strictly utilizing features of fxa, that is a very important way that we could reduce friction of services that are part of this loosely coupled cloud… … So services may *require* fxa not to use it via apis, but simply so that we have a single central place where we handle things that all users must understand and consent to use mozilla services. lloyd > > -z > >> Cheers, > >> Dirkjan _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
