CloudServices/Roadmaps/Identity

	Mozilla Identity Roadmap
	Owner: Dan Mills	Updated: 2011-03-3
	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 their ID provider and use their preferred provider on 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

We'll have a mailing list set up soon. In the meantime you can reach us on IRC:

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

Requirements

Service

• Service shares user DB with Firefox Sync
• Supports multiple email addresses per account
• Email addresses must be verified before they can be used for sign-in
• Service implements verified email protocol [todo: link to protocol spec]

HTML Client-side Implementation

• Implements verified email protocol JS API with a library
• Supports IE 8+, Chrome, Firefox 4+, Safari 5
• JS library must disable itself if the browser natively implements the API
• Allows user to sign-in to Mozilla service, using an email and password
• Allows user to register a new Mozilla account
• Implements email disclosure flow once signed in
• Communication with the user is done via pop-ups (to prevent clickjacking)

Admin Interface

• List and manage email addresses (verified and unverified)
  • Add, remove address
  • Re-send verification mail
• List sites where Mozilla ID has been used to sign in
  • Include a timestamp for the last time a sign-in occurred

Operational Requirements

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

Releases / Roadmap

[to be updated - requirements have changed]

Schedule of Deliverables

Milestone 1

Overview

• Sites implement OpenID 2 RP support
• Sites use a JS library to build a sign-in button on their pages
• Users can sign in using their Sync password using any web browser

Timing

tbd

Details

Priority	Item	Bug	Status
P1	OpenId 2.0 Provider endpoint	-	code complete
P1	Sign in page takes email and password	-	code complete
P1	Sign in matches against Sync user DB	-	code complete
P1	JS API & Library to create a button and initiate login	-	not started
P1	Claimed IDs are unique per each user/site combination	-	not started
P2	Temp artwork	-	not started

Milestone 2

Overview

• Sites add attribute exchange support to get email
• Sites can get different button options
• Users can sign up for a Mozilla Account using any browser
• User will be prompted when a site requests their email address

Timing

tbd

Details

Priority	Item	Bug	Status
P1	Attr. exchange support; email only, content disclosure form	-	not started
P1	In-content account creation flow	-	not started
P2	Single Sign on pilot program	-	not started
P2	Martell artwork v1	-	not started
P2	Various display options for buttons (e.g. sizes)	-	not started

Milestone 3

Overview

• Firefox users will see chrome
  • prompting them to sign in, disclose their email, or create a Mozilla account
  • displaying their current signed in state on the current site
• Users can sign into Mozilla ID using an OpenID or GoogleID
• Users can alias a GoogleID or OpenID into their Sync account
• Sites can request account strength details (captcha'd, last profile change, etc.)

Timing

tbd

Details

Priority	Item	Bug	Status
P1	Account Manger integration (sign-in, email disclosure, active identity)	-	not started
P2	Attr. exchange for other account metadata (e.g., captcha'd, etc.)	-	not started
P1	CAS server integration (SSO)	-	not started
P1	Google sign-in, linked to an existing account	-	not started
P1	OpenID sign-in, linked to an existing account	-	not started
P2	Stand-alone Google ID / OpenID sign-in	-	not started

Milestone 4

Overview

Timing

Details

Priority	Item	Bug	Status
P1	Admin API & Dashboard	-	not started
P2	Dashboard: transaction log	-	not started
P1	Dashboard: connected accounts (OPs)	-	not started
P1	Dashboard: RPs & granted permissions	-	not started
P1	Dashboard: Change email/password	-	not started
P2	Admin API meets Account Manager needs for site prefs/acct details	-	not started

Design Documents / Dev Notes

• OpenID documentation
• Server protocol notes

M1

Things to think about in the M1 time-frame:

• Abuse mitigation
• JS API needs to allow for sites to customize the button they embed
• Need to sketch out what admin API will look like

Open Questions

M1

• Who will create the js api?
  • what actions will the js api need to provide?
  • how will the library be invoked?
• Where will sign-in page be hosted?
• How will claimed id's be hashed & associations stored?
• Is site customization of the login button compatible with restricting introspection of the inserted page elements?

M2

• Will we be accepting Google sign-ins (iow. are we proxying google or are we accepting Google as a OP?)

OpenID has no concept of proxying. Sites will be RPs to us, and we will be RP to Google (as well as other OpenID providers).

• Is there an api for sync account creation flow?
• Can we create Sync accounts in this way and still allow the Sync UI in the browser to connect to that account? Sync UI currently expects you to either (a) create a new account, or (b) know the details, including the sync key.
• Captcha mechanism to use?

Accounts created on our service directly (i.e., not federated OpenID/GoogleID accounts) will be regular accounts like the Sync service makes, and should use the same CAPTCHA service (ReCaptcha at the moment).

• Is content disclosure per partner or global?

Disclosure is for each RP.

• • where will this preference be stored?
  • Will user be able to modify/revoke access?

Yes, the admin API and the dashboard will provide this functionality.

M3

• Who will be doing chrome work?
• Where/how will meta data be stored?
• Who will be the PoC for CAS?
• How will user be polled for additional attribute exchange?
• Do we determine signed in state without actively polling remote site (cookies lie)?

UX Mockups

Iteration 1

Iteration 2: Single email

Iteration 2: Multi email

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?)