|
|
| Line 40: |
Line 40: |
|
| |
|
| = Use Cases = | | = Use Cases = |
| | |
| | note: these use-cases are out of date, will be updated soon. |
|
| |
|
| ;Part one: Mark signs in | | ;Part one: Mark signs in |
| Line 86: |
Line 88: |
| = Requirements = | | = Requirements = |
|
| |
|
| ;Service Discovery | | ;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] |
|
| |
|
| * Service is discoverable via a JavaScript-based API
| | ;HTML Client-side Implementation |
| * There is a JavaScript API that constructs a visible button for users to sign in | | * Implements verified email protocol JS API with a library |
| * Site cannot introspect the JavaScript API or button to discover any user data (including the ID provider), unless the user has opted-into that
| | * Supports IE 8+, Chrome, Firefox 4+, Safari 5 |
| * Users who have never used the system automatically default to the Mozilla service
| | * JS library must disable itself if the browser natively implements the API |
| * Users can disable the discovery mechanism and opt out of everything
| | * Allows user to sign-in to Mozilla service, using an email and password |
| * Users can opt into a replacement service (assuming another exists)
| | * Allows user to register a new Mozilla account |
| * Adding a replacement service into the discovery flow uses the Open Web Apps infrastructure [tentative]
| | * Implements email disclosure flow once signed in |
| * Adding a service does not require any review or approval by Mozilla
| | * Communication with the user is done via pop-ups (to prevent clickjacking) |
| * 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 | | ;Admin Interface |
| * List sign-ins to sites with Mozilla ID, sorted by time (transaction log) | | * List and manage email addresses (verified and unverified) |
| * Retain N days of logs (TBD) | | ** Add, remove address |
| * Search list of sites | | ** Re-send verification mail |
| * List connected accounts (identities to which Mozilla ID is an RP) | | * List sites where Mozilla ID has been used to sign in |
| ** Add account [Facebook, Twitter, Google, Generic OpenID]
| | ** Include a timestamp for the last time a sign-in occurred |
| ** Remove (disconnect) account
| |
| ** Setting to mark a connected account as valid for login into Mozilla ID | |
|
| |
|
| = Operational Requirements = | | = Operational Requirements = |
| Line 159: |
Line 119: |
|
| |
|
| = Releases / Roadmap = | | = Releases / Roadmap = |
| | |
| | [to be updated - requirements have changed] |
| | |
| [https://intranet.mozilla.org/Projects/MozillaID/Schedule Schedule of Deliverables] | | [https://intranet.mozilla.org/Projects/MozillaID/Schedule Schedule of Deliverables] |
|
| |
|