CloudServices/Roadmaps/Identity

NOTE: This page is defunct and retained for historical purposes only. See the current Identity page for actively-maintained info on the current Identity team and project status.

	Mozilla Identity Roadmap
	Owner: Dan Mills	Updated: 2013-11-19
	Mozilla ID (final name TBD) will be a Mozilla-operated service that provides a safe and simple to use federated ID system for Web developers and users. Signing into sites is a common pain point on Web sites today, and this service will be one piece of a larger effort to fix that pain. We've made an effort to bring a 'single sign-on'-like experience to the Web, to provide hooks for browser integration, to make sure the system works on current-generation browsers, to give users the ability to choose what identity they choose to disclose to any Web site, and to protect user privacy while at the same time facilitating an exchange of profile data with sites.

Project Overview

Mozilla ID (final name TBD) will be a Mozilla-operated service that provides a safe and simple to use ID system based on email addresses to Web developers and users.

Signing into sites is a common pain point on Web sites today, and this service will be one piece of a larger effort to fix that pain. What Mozilla ID does is allow users to easily sign into Web sites with just an email address, without any extra passwords.

We've made an effort to:

• Bring a 'single sign-on'-like experience to the Web. Users don't have to worry about how they signed into a site--even across browsers or devices.
• Provide hooks for browser integration, for maximum convenience and protection from phishing attacks.
• Make sure the system works on current-generation browsers, no special add-ons required.
• Provide on-ramps towards a fully decentralized system (with the browser as ID mediator).
• Protect user privacy while at the same time facilitating an exchange of profile data with sites.

Get Involved

Subscribe to our mailing list / Google group / newsgroup:

• Our Google group
• Our mailing list
• Our newsgroup (nntp):

Server: news.mozilla.org
Group: mozilla.dev.identity

Reach us on IRC here:

irc.mozilla.org, #identity

Use Cases

First-run experience

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!

Summary:

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

Enhanced Firefox experience

Note: This use-case is not part of the requirements below. It's here to help guide our API design choices, since it's critical that sites don't need to do anything special to trigger the enhanced chrome flow.

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 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!

Summary:

• Same site API triggers enhanced chrome dialogs in Firefox
• Firefox reuses Sync credentials
• Firefox can verify the email proactively before first-use

Operational Requirements

• Uptime
• Security & privacy / info leakage
• Policies
• Log retention policy
• Number of transactions/sec to support

Releases / Roadmap

• Calendar

Design Documents / Dev Notes

• Verified Email Protocol
• Client API
• Pure HTML Client

Other Notes / Whiteboards

• RPX/Janrain Engage is similar; we should consider how what we does relates to that (and to their API)

• OpenID on Wikipedia, as some basic background

• OAuth vs OpenID

Roadmap whiteboard (2011.01.21)

Bits of -love- frustration

@ChrisMessina: "OpenID:OAuth::FireWire:USB"

Quora What's wrong with OpenID

37Signals "We'll be retiring support for Open ID on May 1, 2011

Tim GregoryFederated identity and why OpenID sucks

Dare Obasanjo Learning from our Mistakes: The Failure of OpenID, AtomPub and XML on the Web

takeaways/things to avoid

• For everyone else, OpenID sucks because it's:
  • hard
  • yet another login (instead of the one true login)
  • doesn't provide enough information to RPs (e.g. name, photo, etc.)
  • confusing (I'm a URL?)