Identity/BrowserID/TransitioningSites: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 15: Line 15:
==== Safe migration from legacy auth to BrowserID ====
==== Safe migration from legacy auth to BrowserID ====
* Never trust that the email address currently associated with a profile is valid or usable
* Never trust that the email address currently associated with a profile is valid or usable
** User could have lost control in the time since the user verified it
** Stale data; user could have lost control in the time since first signed up and verified it
** Another person could have claimed that email address out from under (unlikely, but possible)
* Require legacy username / password auth followed by subsequent BrowserID signin
* Require legacy username / password auth followed by subsequent BrowserID signin
** Ensures verified hand-off from legacy auth to BrowserID
** Ensures verified hand-off from legacy auth to BrowserID

Revision as of 04:38, 6 December 2011

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.

Proposed notions

BrowserID flow with legacy migration

  • The goldenish lines are the "golden path", which should be the most common cases.

BrowserID flow with legacy migration

Mockup source

Safe migration from legacy auth to BrowserID

  • Never trust that the email address currently associated with a profile is valid or usable
    • Stale data; user could have lost control in the time since first signed up and verified it
  • 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

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?
    • Retain legacy user/pass auth for last-ditch recovery

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?