Identity/BrowserID/TransitioningSites

Overview

We're starting to work through the issues involved in transitioning existing Mozilla web properties over to BrowserID. This page has been created to start collecting thoughts, issues, and solutions.

Edge cases / issues

Localization, or users from locales other than en-US

• BrowserID is not yet localized into all the locales supported by potential relying sites
• Need to retain legacy user/pass auth for those locales, for now

Changing email addresses

• User anticipates losing control of an email address, wants to switch to a different ID
  • Sign-in with address #1, then sign-in again with address #2?
• User lost control of address and only realizes much later.
  • Out of luck unless they verified it in the past with BrowserID?

Lost or inaccessible email accounts

• A user may have lost control of the email address they've used with an existing legacy profile.
  • Maybe allow user/pass auth as last-ditch effort for recovery?

Proposed notions

Safe migration from legacy auth to BrowserID

• Never trust that the email address currently associated with a profile is valid or usable
• Require legacy username / password auth followed by subsequent BrowserID signin
  • Ensures verified hand-off from legacy auth to BrowserID

Many-to-many email to profile relation

• Sign-in
  • On sign-in, BrowserID offers a selection from one of many IDs
  • The relying site should offer a selection from one of many profiles matching the selected BrowserID
  • But, in the simple (and most common?) case where there really is only one email-to-profile, fast track the signin without additional UI.
• ID management
  • On a profile editing page, offer a BrowserID signin button to associate additional IDs with the currently-signed-in profile
  • List currently associated IDs, along with delete buttons
  • No manual email change or edit feature - all email address changes must be associated with pre-verified BrowserIDs