Identity/UnverifiedEmail

The BrowserID protocol allows websites to get a verified email address from a user. It's verified in that they have been sent an email in the past and clicked a link, proving they control that email address.

To support FirefoxOS, we will provide a second type of identity, an Un-verified Email.

Many websites and applications are okay with a graduated progression from un-trusted to more trusted accounts. They may restrict what the user can do, until they have proved various aspects of their identity.

Users can "level-up"

                 __________________
                 |                |
                 | Verified Email |
   ______________|                |
   |                              |
   | Un-verified                  |
   |                              |
   --------------------------------

Additions to the BrowserID protocol

navigtor.id.request

navigtor.id.request now takes an optional parameter allowUnverified which is a boolean. If set to true, then the Un-verified Email flow is allowed. Defaults to false.

Changes to verifier service

Currently a fallback verifier lives at https://verifier.login.persona.org/verify.

Marketplace and other RPs can POST to https://verifier.login.persona.org/verify?allow_unverified=true. The response from this service will include either an email property or a new unverified-email property.

Un-verified Email

   {
     "status": "okay",
     "unverified-email": "sita@example.com",
     "audience": "https://marketplace.mozilla.org",
     "issuer": "login.persona.org",
     "expires": ...
   }

Verified Email

   {
     "status": "okay",
     "email": "sita@example.com",
     "audience": "https://marketplace.mozilla.org",
     "issuer": "login.persona.org",
     "expires": ...
   }

Once the user goes through the email verification loop, they will have a verified email. The response will stop showing the unverified-email property and start showing the email property.

Passwords

Just like today, an un-verified email flow will collect a password from the user up front. We'll use the password to allow them to log in to their un-verified account.

Question & Answers

• Q: Why do I need to verify an assertion, if it's for an un-verified email?
• A: These terms are confusing, but consider:
  • Although the user hasn't verified that they own that email address yet, you do get the assurance that this is the person who has started the account creation flow.
  • Additionally once the user does verify the email address, your code will automatically start getting the feedback that the user has shown that they own the address. Only minimal conditional code is needed to support the two states.

Other Requirements

Once an email is verified, it won't go back in to an un-verified state.

We'll need to look at this from a security POV and make sure an attacker can't squat on email addresses. We may need a way to expire the password/verification email for un-verified accounts.

Flows should handle the case where the user mis-types their password or forgets it by the time they verify their address.

Flows should handle a malicious user claiming an email address, using it on several sites that support unverified, and then the actual owner attempting to claim and verify their email address for the first time.