Identity/Features/Firefox-native Verified Email Client

Feature	Status	ETA	Owner
Firefox-native Verified Email Client	Scoping new work after VEP changes	TBD	David Dahl

Summary

Ability to sign into web sites using Verified Email, integrated with our (secondary authority) ID service.

Related features:

• Verified Email Service
• Web-based Verified Email Client
• Verified Email Service Admin Interface

Team

Who's working on this?

• Feature Manager: Dan Mills
• Lead Developer: David Dahl
• Product Manager: Dan Mills
• QA: Tracy Walker
• UX: Alex Faaborg
• Security: Curtis Koenig
• Privacy: Sid Stamm
• User Research: Diane Loviglio

Release Requirements

Content APIs in place for web sites to:

• Request a verified email from the browser
  • Support for signing new identity assertions in-browser
• Be proactively given a verified email
• Advertise active/passive sign-in user sessions and sign-out method
• Register a verified email certificate (primary/secondary authority API)
  • Support for keeping certificates in the browser
  • Support for refreshing certificates as needed

Browser UI in place to:

• Create a Firefox Account
• Sign into a Firefox Account
• Add an email address to a Firefox Account, and verify it
• Sign into a site by disclosing an email, whether the process is started from chrome or content
• Display active session(s) with the site, and sign-out

Next Steps

• Scope engineering work [David Dahl]
• UX Research [Diane Loviglio]
• Session API Draft [Dan Mills]
• Create test plan [Tracy Walker]
• Security review [?]
• Engineering work [David Dahl]

Related Bugs & Dependencies

• Tracking bug
  • Tracking bug: email disclosure APIs
  • Tracking bug: Firefox account & email verification UI
  • Tracking bug: Session discovery & chrome UI

Designs

API docs:

• Verified Email Protocol
• Client API (obsolete?)

Mockups:

• Verified Email (various)
• Firefox Account
• HTML client mockups (for reference)

Use Cases

Note: you may wish to read the use-case for the Web-based Verified Email Client as well

Anne is a Firefox user. She has an iPhone too, and uses Firefox Sync to get to her bookmarks from her phone.

While browsing the Web, Anne sees a notification bar in Firefox asking her to verify the email address she uses to sign into Firefox Sync. Anne decides to go ahead, clicks a button to send a verification message, and is told to check her inbox for a message.

Anne finds the message in her inbox and clicks the link. She is taken back to Firefox and a message thanks her for verifying the email address. Firefox also tells her that she can now use her verified email address to sign into any supported Web site without any extra passwords.

While talking to her friend Mark, Anne learns about a site called SaladFans.com. Excited to try it out, she browses to the site on her desktop, and when she clicks the "sign in" button, Firefox asks her if it's OK to disclose her verified email address with SaladFans.com. Anne clicks OK, SaladFans.com refreshes and she is now signed in!

Key points:

• Site API triggers enhanced chrome dialogs in Firefox
• The same API triggers HTML pop-ups on other browsers (see Web-based Verified Email Client)
• Firefox reuses Sync credentials for Verified Email
• Firefox can verify the email proactively before first-use

Test Plans

Any and all test plans and strategies. Either inline or linked to.

Goals

• Provide a convenient way for users to sign-in and sign-out of web sites by using their verified email address
• Anchor signed-in status & functionality to a consistent location in browser chrome
• Integrate with the Firefox Account, the same account used for Firefox Sync

Non-Goals

• Integrating with/implementing non-Verified Email auth protocols
  • including HTTP Auth, forms-based sign-in, OpenID, OAuth, etc.
• Multiple accounts per-site (plus fast-user switching)
• Expanding "sign into the browser" role to allow multiple user support, profile switching support, master password support
• Integrating account information into site-prefs

Legend (remove if you like)

	Healthy: feature is progressing as expected.
	Blocked: feature is currently blocked.
	At Risk: feature is at risk of missing its targeted release.
ETA	Estimated date for completion of the current feature task. Overall ETA for the feature is the product release date.