CloudServices/Roadmaps/Identity

	Mozilla Identity Roadmap
	Owner: Dan Mills	Updated: 2011-02-28
	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.

Work In Progress

This document, including the project name, has not been finalized

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

Part one

Mark signs in

Mark is a Firefox user. He has a laptop and an iPhone, and he uses Firefox Sync to access his bookmarks from his phone.

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 which is styled with the Mozilla color and logo. Mark hasn't used Mozilla ID before, so when he clicks the button Mark's browser pops up an introduction message that points him to the identity area on the toolbar, and tells him that his Sync ID has been automatically upgraded to a Mozilla ID (so it uses the same password).

After dismissing the introduction dialog, the identity area pops up a doorhanger notification telling him that SaladFans.com is asking for his email address--is it OK to give it to them? Mark says OK and the page refreshes, mark is now signed in!

Summary:

• Easy set-up on Firefox + Sync machines
• Chrome-enhanced experience on Firefox
• Attribute exchange of basic info (email)

Part two

Mark on the go

A few days later, Mark meets George at a party and they start talking about salad bars--it turns out that they are both salad lovers! George hasn't been to SaladFans.com so Mark wants to show it to him. Mark uses Firefox Home to quickly find SaladFans.com from his list of recently visited sites and opens it in Mobile Safari.

Mark wants to sign in to show George one of his draft salad bar reviews he has been working on. He finds the familiar "sign in" button styled with the Mozilla logo, and taps on it. Because he's on Mobile Safari, Mark gets redirected to the Mozilla ID website where he can sign in.

Mark taps in his email address and password, and he gets redirected back to SaladFans.com, where he's now signed in with his Mozilla ID.

Summary:

• Works on any modern browser
• HTML-based baseline experience

Part three (aspirational)

Mark finds his friends online

Note: this last use-case is not reflected in the plan/requirements below - it's food for thought as we think of the future.

Mark wants to share his salad bar reviews with his friends. He knows some of his friends are already using SaladFans.com, but he hasn't connected with them on the site yet.

Mark clicks the "friends" button on SaladFans.com and Firefox prompts him with a doorhanger notification to tell him that SaladFans.com is requesting his friends list--but that unfortunately it's empty! He can connect to another service to add his friends however. Mark decides to do that, Firefox opens up a page that lists possible accounts he can connect to his Mozilla ID. Mark has a lot of friends on his Google address-book, so he clicks the Google button.

Mozilla ID directs him to Google's site where Mark needs to verify that he wants to connect his Google account to his Mozilla ID. After Mark confirms, he goes back to SaladFans.com and Firefox asks him to confirm again that he wants to share his friends list with SaladFans.com. Mark says OK, and Mozilla works with SaladFans.com to disclose his contacts which are already using the site, without disclosing the ones that aren't.

Now SaladFans.com can ask Mozilla ID for updates to his friends list, and that way when Mark adds a new friend to his contact list, they will automatically be connected on SaladFans.com!

Summary:

• Basis for sharing infrastructure
• Mozilla ID remembers auth decisions for ongoing disclosure (app permissions)

Requirements

Service Discovery

• Service is discoverable via a JavaScript-based API
• There is a JavaScript API that constructs a visible button for users to sign in
• Site cannot introspect the JavaScript API or button to discover any user data (including the ID provider), unless the user has opted-into that
• Users who have never used the system automatically default to the Mozilla service
• Users can disable the discovery mechanism and opt out of everything
• Users can opt into a replacement service (assuming another exists)
• Adding a replacement service into the discovery flow uses the Open Web Apps infrastructure [tentative]
• Adding a service does not require any review or approval by Mozilla
• User's choice of Service and provider is persisted server side

ID Discovery

• IDs asserted to sites must be anonymized based on domain
• If user opts in, allow ID discovery and verification without prompting the user (without disclosing other information than the ID)

Account Manager Integration

• Service must meet all Account Manager requirements for a federated ID provider [link to these requirements?] (yes, they don't exist yet)
• On Acct Mgr enabled browsers, users should not see any web-based login pages or disclosure forms, only the sign-in button on the destination site.

Cross-Browser Support

• All major service features must work on other modern browsers without any add-ons or plugins [IE 8+, Chrome, Firefox 4+, Safari ?]

Verification Flow

• Service implements the OpenID 2.0 protocol

Login Flow

• Service accepts Firefox Sync credentials directly (by typing in an email & password)

• Service allows users to register a new Firefox Sync account (in content)
• Accounts created via a content flow should not generate or allude to a sync key
• Service allows users to sign-in using a federated ID from another provider iff that federated ID was previously unknown, or was previously associated with a Firefox Sync account and the user allows sign-in using that ID
• Signing into an account with an associated federated ID does not allow modifying Firefox Sync account data (e.g., password)
• Content login flow should accept Firefox Sync credentials, or attempt email address discovery (webfinger)
• If email discovery fails, the content login flow should present a nascar of supported ID providers

Information Pass-Through

• Service implements OpenID attribute exchange to disclose information we hold (e.g., email address)
• Provide sites with metadata about the strength and properties of the ID:
  • First-party sign-in vs federated
  • Number of associated (verified) federated accounts
  • User has been been subject to a captcha
  • Times since last ID verification or captcha
• Todo: determine if strength data disclosure requires user consent
• Todo: determine if we should pass through data from other services (e.g., user's Twitter username)

SSO requirements

• CAS server integration

Admin Interface

• List sign-ins to sites with Mozilla ID, sorted by time (transaction log)
• Retain N days of logs (TBD)
• Search list of sites
• List connected accounts (identities to which Mozilla ID is an RP)
  • Add account [Facebook, Twitter, Google, Generic OpenID]
  • Remove (disconnect) account
  • Setting to mark a connected account as valid for login into Mozilla ID

Operational Requirements

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

Releases / Roadmap

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

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

OpenID vs. Identity Server

The following outlines a simplified data transfer between two OpenID parties.

It's a bit odd, and the terminology doesn't really seem to help. Here's my understanding of the total OpenID 2 flow (which might explain some of my confusion):

1. Initiation & Normalization: User enters personalized OP URL into RP's identity form. (e.g. http://example.com/foo) which is normalized to a standard URL.

2. Discovery: RP polls http://example.com/foo and finds the OpenID access point declarations:

 openid2.provider => endpoint url for OP
 openid2.local_id  => local /claimed id (for us, it's the unique user+site id hash)

3. Association: RP polls the openid2.provider passing:

 openid.ns = http://specs.openid.net/auth/2.0
 openid.mode = associate
 openid.assoc_type = HMAC_SHA1 (or others)
 openid.session_type = DH_SHA1 (or others)

OP responds with: (_this is where our JS library would start_)

 ns = http://specs.openid.net/auth/2.0
 assoc_handle=255 char or less random string
 session_type = Association::openid.session_type
 assoc_type = Association::openid.assoc_type
 expires_in = {expiration time in seconds}

RP replies with:

 openid.ns = http://specs.openid.net/auth/2.0
 openid.mode = checkid_(immediate|setup)
 openid.claimed_id = Discovery::openid2.local_id
 openid.identity = OP provided local identifier value
 openid.assoc_handle  = Association.response::assoc_handle
 openid.return_to = next URL to respond to
 openid.realm =   Security realm for request (or return_to)

and OP returns to the openid.return_to

 openid.ns = http://specs.openid.net/auth/2.0
 openid.mode = id_res
 openid.op_endpoint = Discovery::openid2.provider
 openid.claimed_id = Association.request::openid.claimed_id
 openid.identity = Association.request::openid.identity
 openid.return_to = Association.request::openid.return_to
 openid.response_nonce = nonce
 openid.assoc_handle = Association.response::assoc_handle
 openid.signed = list of fields used to generate the signature
 openid.sig = signature

We *could* add in the additional user information (like email, etc) into the final association response, since the protocol does allow for it, but we do run the risk of bumping up against max URL length issues with some systems.

Things are a bit fuzzy for mew around the reuse of the association_handle values, and technically, we probably want to do the OpenID2 failure response for checkid_immediate (since we'd be requesting user interaction) but we might be able to skirt that as well.

The additional step to all this is that there is an additional call back to the REAL RP where we pass along the information regarding the blessed user. There are some crypto concerns with Problematic Identity Transfer Agents (PITA) and getting a proper association handle defined.