Open sandysage opened 6 years ago
Per emails with FxA:
Users can install the webextension and start using it locally without linking their Firefox Account. It will store their data locally but not attempt to put it in The Cloud.
Once they're using the product, users may be prompted to connect their Firefox Account to get backup and/or syncing of their passwords.
This will launch the FxA OAuth flow in a popup window, and we expect a significant number of users to have to create an account at this point.
This will use the new scoped-keys flow to obtain a Lockbox-specific encryption key, to be used for encrypting data locally.
This will obtain an OAuth token for access to a storage backend running Kinto, into which Lockbox will sync the encrypted data from its local storage.
When the user closes Firefox, Lockbox will discard its encryption keys, but keep some of the othe state around from the OAuth dance in order to make re-authenticating easier.
When the user re-opens Firefox and tries to access their Lockbox data gain, Lockbox will do another FxA login flow to re-authenticate the user
This will use the new scoped-keys flow to obtain the same Lockbox-specific encryption key as before, so the user can decrypt their locally-stored data.
It's preferred that this flow appear in a doorhanger UI rather than a pop-up window.
It's strongly preferred that this flow does not force the user through an email confirmation loop, since this is just "re-authenticating" to an existing device.
If the user happens to try to access their Lockbox data while they're offline, they'll get a connection error when loading the FxA OAuth flow.
Having to click a link in the email confirmation flow, means users can get derailed from the signup process. FxA experimenting with having the user type in a code rather than click on a link.
If the user is signed in to Lockbox on a device, and then does a password reset on their Firefox Account, then Lockbox will discover this when it next tries to sync and finds that its OAuth tokens have been revoked. It will enter some sort of "needs re-auth" state and prompt the user to sign in again.
If there was a password reset user encounters another email-confirmation loop on this device
@sandysage to help drop in designed/desired flow here
may need separate tasks here real quick..
@sandysage @changecourse Is there a design for this? I'm working on recommendations and it would be helpful to understand how the current master password creation will change. My understanding is that creating a master password will be replaced by the FxA creation flow, is that right?
Is there a design for this? I'm working on recommendations and it would be helpful to understand how the current master password creation will change
@hmcgaw just to close the loop, I know you have this, but the planned design is in the Invision doc: https://mozilla.invisionapp.com/share/54E2A6ZKF#/259383381_0-0_Add_Lockbox
This will launch the FxA OAuth flow in a popup window, and we expect a significant number of users to have to create an account at this point.
@linuxwolf @sashei do you two have corresponding sub-tasks or issues opened for the extension (datastore?) and iOS app to track the exploration and OAuth work yet so we can add it to the epic list above?
@linuxwolf @sashei do you two have corresponding sub-tasks or issues opened for the extension (datastore?) and iOS app to track the exploration and OAuth work yet so we can add it to the epic list above?
@changecourse I think the workflow articulated here is as defined as we're expecting for now, right? If so, let's remove the "needs-ux" label, knowing that other tasks may need your involvement.
@sandysage I think that's true... Removing the label...
As a Firefox Account user, I find the password manager is optimized for me such that I can set it up in 5 clicks or less, and retrieve and fill my credentials in 3 clicks or less.
Acceptance Criteria
Expected behavior
Visual Design
https://mozilla.invisionapp.com/share/54E2A6ZKF#/screens/
Context
The concept of a master password as one password that would give access to many more passwords is generally understood by users. But it's unclear if that's just as understood when a user needs to have an account to sync their data to different devices. Do users accept creating and managing both an account (with a password) AND a master password?
The hypothesis here is that users want less to manage and understand that their data is secured by their Firefox account access. And that this proposed flow matches already existing workflows around using a federated identity to access other accounts (ie can log into an account using Google or Facebook sign-in).
Extension (Alpha) Tasks
Sync
Mobile
Future?