Confirm
1,136
edits
Changes
Creating Unverified Email from Ben's notes
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.
=== 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.
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.
=== 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.
