Identity/BrowserID/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.

New Fallback verification url

[I don't think we need a second verifier url... we can just enhance the existing verifier, no? -- ozten]

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

Marketplace and other RPs can use https://unverified-verifier.login.persona.org/verify. The response from this service will include a new property:

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

Once the user goes through the email verification loop, the will have a verified email and Marketplace can use either verification service. The repsonse will start showing verified: true.

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.

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.