Changes

<div style= MozillaID ="border: thin dotted #aaa; padding-left: 10px;">;Work In Progress

The concept of a MozillaID is a single user identity:This document, including the project name, has '''not been finalized'''</auth credentials that can be used across all Mozilla properties.div>

=Project Overview = Technology survey ==* What technologies are available? What fits our requirements?** OpenID?** LDAP?** Something else?

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. 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.* Give users the ability to choose their ID provider, and use their preferred provider on any Web site. Even if that provider is not Mozilla!* 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: Mark finds his friends online 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 =[https://intranet.mozilla.org/Projects/MozillaID/Schedule 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 {| width="100%" cellpadding="3"|-| style="background-color: #efefef; width: 20px"| '''Priority'''| style="background-color: #efefef;"| '''Item'''| style="background-color: #efefef;"| '''Bug'''| style="background-color: #efefef;"| '''Status'''|-| P1 || OpenId 2.0 Provider endpoint || - || not started|-| P1 || Sign in page takes email and password || - || not started|-| P1 || Sign in matches against Sync user DB || - || not started|-| P1 || JS API &amp; 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 {| width="100%" cellpadding="3"|-| style="background-color: #efefef; width: 20px"| '''Priority'''| style="background-color: #efefef;"| '''Item'''| style="background-color: #efefef;"| '''Bug'''| style="background-color: #efefef;"| '''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|} == Timeline Milestone 3 == ;Overview * Firefox users will see chrome * Implementation planning* 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 {| width="100%" cellpadding="3"|-| style="background-color: #efefef; width: 20px"| '''Priority'''| style="background-color: #efefef;"| '''Item'''| style="background-color: #efefef;"| '''Bug'''| style="background-color: #efefef;"| '''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 {| width="100%" cellpadding="3"|-| style="background-color: #efefef; width: 20px"| '''Priority'''| style="background-color: #efefef;"| '''Item'''| style="background-color: #efefef;"| '''Bug'''| style="background-color: #efefef;"| '''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 = * [https://wiki.mozilla.org/Services/OpenId OpenID documentation]* [[Projects/MozillaID/ServerProtocol|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 &amp; associations stored? ;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?* 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 = <br clear="all"/> = Security & Privacy = = Legal Considerations = = Other Notes / Whiteboards = * [https://rpxnow.com/ RPX/Janrain Engage] is similar; we should consider how what we does relates to that (and to their API) ;Roadmap whiteboard (2011.01.21):[[Image:idw_DSCN1684.JPG|300x200px]][[Image:DSCN1687.JPG|300x200px]]  ;Bits of -love- frustration:[https://twitter.com/chrismessina/status/30123267528331264 @ChrisMessina]: "OpenID:OAuth::FireWire:USB" [http://www.quora.com/What-s-wrong-with-OpenID Quora] What's wrong with OpenID [http://productblog.37signals.com/products/2011/01/well-be-retiring-our-support-of-openid-on-may-1.html 37Signals] "We'll be retiring support for Open ID on May 1, 2011 [http://tim-gregory.com/2009/07/federated-identity-and-why-openid-sucks/ Tim Gregory]Federated identity and why OpenID sucks [http://www.25hoursaday.com/weblog/2011/01/30/LearningFromOurMistakesTheFailureOfOpenIDAtomPubAndXMLOnTheWeb.aspx 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?) <br clear="all"/>