Identity/Features/Web-based Verified Email Client

Please use "Edit with form" above to edit this page.

Status

Web-based Verified Email Client
Stage Complete
Status `
Release target `
Health `
Status note Scoping new work after VEP changes.

{{#set:Feature name=Web-based Verified Email Client

|Feature stage=Complete |Feature status=` |Feature version=` |Feature health=` |Feature status note=Scoping new work after VEP changes. }}

Team

Product manager Dan Mills
Directly Responsible Individual Dan Mills
Lead engineer Rob Miller
Security lead Michael Coates
Privacy lead Sid Stamm
Localization lead `
Accessibility lead `
QA lead James Bonacci
UX lead Chris Howse
Product marketing lead `
Operations lead `
Additional members `

{{#set:Feature product manager=Dan Mills

|Feature feature manager=Dan Mills |Feature lead engineer=Rob Miller |Feature security lead=Michael Coates |Feature privacy lead=Sid Stamm |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=James Bonacci |Feature ux lead=Chris Howse |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}

Open issues/risks

`

Stage 1: Definition

1. Feature overview

Pure HTML client of the Verified Email Service.

Related features:

Goals:

  • Implement the JS API for sites to support Verified Email
  • Not to interfere when native browser support is present
  • Directly interface with the Mozilla Verified Email service for all functionality
  • Support Verified Email on current-generation browsers: Firefox 4, IE 8, Chrome 10, Safari 5, Opera

2. Users & use cases

Mark gets a tip from a friend about SaladFans.com, a place to review and share your favorite salad bars. Mark visits the site and is eager to contribute his own reviews as well as connecting with friends to find out which salad bars they like.

Mark sees a "sign in" button on the SaladFans site, and when he clicks on it a Mozilla ID pop-up dialog comes up telling him that the site is asking for a verified email address to sign-in. Mark hasn't used Mozilla ID before, so he clicks the "register" button.

Mark now types in his email address, and chooses a password for his account. After he's done, Mozilla ID tells him that a verification message has been sent to his email, and he needs to click on a link there before proceeding. Mark checks his email and clicks on the link in the message Mozilla ID sent him. The link opens up a new pop-up replacing the previous one, which welcomes him to Mozilla ID and asks him if it's OK to disclose the email address to SaladFans.com. Mark clicks OK, the dialog closes, SaladFans.com reloads, and Mark is now signed into SaladFans.com!

Key Points:

  • Easy set-up from scratch
  • All HTML flow, works on a variety of browsers
  • Flow centered around verified email disclosure

3. Dependencies

`

4. Requirements

Item Bug Status
Core VEP client implementation (can handshake w/ server register an email, generate keys, receive a cert, generate assertion; no UI, no cert refresh) 664598 -
Relying party wrapper implementation (can handle getVerifiedEmail call and interact w/ core VEP client in a popup window; still no UI nor cert refresh) 664597 -
Identity authority wrapper implementation (can handler registerVerifiedEmail and registerVerifiedEmailCertificate calls and can interact w/ core VEP client in parent window, still no UI nor cert refresh) 669455 -
UI interaction through account creation / login / release of one email address (most UI will be generated by the server) 664594 -
Email selection UI (mostly generated by UA) and integration into VEP process 664599 -
Certificate refresh, successful only 668620 -
Certificate refresh w/ failure 668625 -
========= OLDER (OBSOLETE?) MILESTONES BELOW ==========
Relying party API - -
Sign-in pop-up - -
Email disclosure pop-up - -
Email verification pop-up - -
Account creation pop-up - -
Account creation UX polish[1] - -
HTML client popups support multiple emails - -
HTML client allows adding a new email to an existing account - -

[1] e.g., password strength meter, pop-up auto-closes upon email verification

Non-goals

  • Integrating with/implementing non-Verified Email auth protocols
    • including HTTP Auth, forms-based sign-in, OpenID, OAuth, etc.
  • Support for other profile information

Stage 2: Design

5. Functional specification

API Docs

Obsolete?

6. User experience design

 
Registration (i2)
 
Single email (i2)
 
Multi email (i2)


Older mockups:

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

Basic Identity items test plan

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=` |Feature overview=Pure HTML client of the Verified Email Service.

Related features:

Goals:

  • Implement the JS API for sites to support Verified Email
  • Not to interfere when native browser support is present
  • Directly interface with the Mozilla Verified Email service for all functionality
  • Support Verified Email on current-generation browsers: Firefox 4, IE 8, Chrome 10, Safari 5, Opera

|Feature users and use cases=Mark gets a tip from a friend about SaladFans.com, a place to review and share your favorite salad bars. Mark visits the site and is eager to contribute his own reviews as well as connecting with friends to find out which salad bars they like.

Mark sees a "sign in" button on the SaladFans site, and when he clicks on it a Mozilla ID pop-up dialog comes up telling him that the site is asking for a verified email address to sign-in. Mark hasn't used Mozilla ID before, so he clicks the "register" button.

Mark now types in his email address, and chooses a password for his account. After he's done, Mozilla ID tells him that a verification message has been sent to his email, and he needs to click on a link there before proceeding. Mark checks his email and clicks on the link in the message Mozilla ID sent him. The link opens up a new pop-up replacing the previous one, which welcomes him to Mozilla ID and asks him if it's OK to disclose the email address to SaladFans.com. Mark clicks OK, the dialog closes, SaladFans.com reloads, and Mark is now signed into SaladFans.com!

Key Points:

  • Easy set-up from scratch
  • All HTML flow, works on a variety of browsers
  • Flow centered around verified email disclosure

|Feature dependencies=`

|Feature requirements=

Item Bug Status
Core VEP client implementation (can handshake w/ server register an email, generate keys, receive a cert, generate assertion; no UI, no cert refresh) 664598 -
Relying party wrapper implementation (can handle getVerifiedEmail call and interact w/ core VEP client in a popup window; still no UI nor cert refresh) 664597 -
Identity authority wrapper implementation (can handler registerVerifiedEmail and registerVerifiedEmailCertificate calls and can interact w/ core VEP client in parent window, still no UI nor cert refresh) 669455 -
UI interaction through account creation / login / release of one email address (most UI will be generated by the server) 664594 -
Email selection UI (mostly generated by UA) and integration into VEP process 664599 -
Certificate refresh, successful only 668620 -
Certificate refresh w/ failure 668625 -
========= OLDER (OBSOLETE?) MILESTONES BELOW ==========
Relying party API - -
Sign-in pop-up - -
Email disclosure pop-up - -
Email verification pop-up - -
Account creation pop-up - -
Account creation UX polish[1] - -
HTML client popups support multiple emails - -
HTML client allows adding a new email to an existing account - -

[1] e.g., password strength meter, pop-up auto-closes upon email verification |Feature non-goals=* Integrating with/implementing non-Verified Email auth protocols

    • including HTTP Auth, forms-based sign-in, OpenID, OAuth, etc.
  • Support for other profile information

|Feature functional spec==== API Docs ===

Obsolete?

|Feature ux design=

 
Registration (i2)
 
Single email (i2)
 
Multi email (i2)


Older mockups:

|Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=Basic Identity items test plan |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

Priority P1
Rank 999
Theme / Goal `
Roadmap Mozilla Identity
Secondary roadmap `
Feature list Services
Project `
Engineering team Services

{{#set:Feature priority=P1

|Feature rank=999 |Feature theme=` |Feature roadmap=Mozilla Identity |Feature secondary roadmap=` |Feature list=Services |Feature project=` |Feature engineering team=Services }}

Team status notes

  status notes
Products ` `
Engineering ` `
Security sec-review-unnecessary 2-Dec-2011: notified project canceled/shelved, removing security tags and closing out feature page per discussion with Rob Miller. Project superseded by BrowserID
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=sec-review-unnecessary |Feature security health=` |Feature security notes=2-Dec-2011: notified project canceled/shelved, removing security tags and closing out feature page per discussion with Rob Miller. Project superseded by BrowserID |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}