Identity/Features/Sign into the browser

From MozillaWiki
< Identity
Revision as of 03:55, 12 January 2012 by Thunder (talk | contribs) (Created page with "{{FeatureStatus |Feature name=Sign into the browser |Feature stage=Draft |Feature version=Firefox 13 |Feature health=OK |Feature status note=Needs UX input }} {{FeatureTeam |Feat...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Please use "Edit with form" above to edit this page.

Status

Sign into the browser
Stage Draft
Status `
Release target Firefox 13
Health OK
Status note Needs UX input

{{#set:Feature name=Sign into the browser

|Feature stage=Draft |Feature status=` |Feature version=Firefox 13 |Feature health=OK |Feature status note=Needs UX input }}

Team

Product manager Dan Mills
Directly Responsible Individual Dan Mills
Lead engineer Ben Adida
Security lead `
Privacy lead Sid Stamm
Localization lead `
Accessibility lead `
QA lead `
UX lead Zhenshuo Fang
Product marketing lead `
Operations lead `
Additional members `

{{#set:Feature product manager=Dan Mills

|Feature feature manager=Dan Mills |Feature lead engineer=Ben Adida |Feature security lead=` |Feature privacy lead=Sid Stamm |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=Zhenshuo Fang |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}

Open issues/risks

Requires coordination with services infrastructure to support BrowserID-based authentication, as well as a key-wrapping feature in BrowserID.

Stage 1: Definition

1. Feature overview

Being able to sign into the browser is a key feature in our identity roadmap. It allows us to hang other features and services off of the user's identity. Examples of this include signing into websites (via the navigator.id.get() API that BrowserID provides), using the Sync feature, encrypting locally stored browser data (i.e., "master password"), and more. It also sets up a framework to think about user profiles, enabling better support for multi-user (shared device) scenarios.

Note that while the sign into the browser feature enables these other features, it isn't the same as those, merely a prerequisite to them. Sign into the browser is simply:

  • the ability to sign in using browserid.org credentials
  • the ability to seamlessly create a browserid.org account if necessary

2. Users & use cases

Since sign into the browser enables numerous browser features, the target audience is quite large. However, users most likely to benefit from the feature are users who:

  • use the Sync feature
  • use BrowserID to sign into websites
  • share a device/browser with other users on a regular basis (assuming later implementation of a user-switch feature)

A use-case of a user setting up sync:

Joe has never used Firefox or BrowserID before. He downloads it to check it out, and after browsing for a while he stumbles upon and decides to try the sync feature. Firefox prompts him for his email address and Joe types it in, at which point Firefox checks if he's a BrowserID user. Joe isn't, so Firefox prompts him to make a new account by typing and verifying a password. Since Joe has never set up sync before, there are a couple of extra steps he is automatically taken to next. Joe fills out a captcha, and given a chance to learn what is going to be synced. Finally, Joe is told that everything is ready to go, and than an email has been sent to the address he specified for verification. Once Joe has verified his email, he can connect any other device/browser simply by signing in with the same email+password.

3. Dependencies

  • Services (sync) support for BrowserID-based authentication.
  • BrowserID key-wrapping feature

4. Requirements

  • Ability for user to sign in via UI option somewhere (e.g., menu)
  • Ability for other Firefox features (e.g. sync) to trigger sign-in flow
  • Email-based authentication using browserid.org accounts
  • Should match BrowserID flow except where absolutely necessary (e.g., ask for email first, decide what to do based on the email)
  • Ability to create browserid.org accounts
    • Ask for password up-front, but allow deferred verification (see: BrowserID "unverified" flow/feature)
  • UI should be unambiguous that the user is interacting with the *browser* (not content)

Non-goals

  • master password integration / modal sign-in screen on browser startup
  • multi-user support or profile switching

Stage 2: Design

5. Functional specification

`

6. User experience design

`

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=Requires coordination with services infrastructure to support BrowserID-based authentication, as well as a key-wrapping feature in BrowserID. |Feature overview=Being able to sign into the browser is a key feature in our identity roadmap. It allows us to hang other features and services off of the user's identity. Examples of this include signing into websites (via the navigator.id.get() API that BrowserID provides), using the Sync feature, encrypting locally stored browser data (i.e., "master password"), and more. It also sets up a framework to think about user profiles, enabling better support for multi-user (shared device) scenarios.

Note that while the sign into the browser feature enables these other features, it isn't the same as those, merely a prerequisite to them. Sign into the browser is simply:

  • the ability to sign in using browserid.org credentials
  • the ability to seamlessly create a browserid.org account if necessary

|Feature users and use cases=Since sign into the browser enables numerous browser features, the target audience is quite large. However, users most likely to benefit from the feature are users who:

  • use the Sync feature
  • use BrowserID to sign into websites
  • share a device/browser with other users on a regular basis (assuming later implementation of a user-switch feature)

A use-case of a user setting up sync:

Joe has never used Firefox or BrowserID before. He downloads it to check it out, and after browsing for a while he stumbles upon and decides to try the sync feature. Firefox prompts him for his email address and Joe types it in, at which point Firefox checks if he's a BrowserID user. Joe isn't, so Firefox prompts him to make a new account by typing and verifying a password. Since Joe has never set up sync before, there are a couple of extra steps he is automatically taken to next. Joe fills out a captcha, and given a chance to learn what is going to be synced. Finally, Joe is told that everything is ready to go, and than an email has been sent to the address he specified for verification. Once Joe has verified his email, he can connect any other device/browser simply by signing in with the same email+password. |Feature dependencies=* Services (sync) support for BrowserID-based authentication.

  • BrowserID key-wrapping feature

|Feature requirements=* Ability for user to sign in via UI option somewhere (e.g., menu)

  • Ability for other Firefox features (e.g. sync) to trigger sign-in flow
  • Email-based authentication using browserid.org accounts
  • Should match BrowserID flow except where absolutely necessary (e.g., ask for email first, decide what to do based on the email)
  • Ability to create browserid.org accounts
    • Ask for password up-front, but allow deferred verification (see: BrowserID "unverified" flow/feature)
  • UI should be unambiguous that the user is interacting with the *browser* (not content)

|Feature non-goals=* master password integration / modal sign-in screen on browser startup

  • multi-user support or profile switching

|Feature functional spec=` |Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

Priority P1
Rank 999
Theme / Goal `
Roadmap `
Secondary roadmap `
Feature list `
Project `
Engineering team `

{{#set:Feature priority=P1

|Feature rank=999 |Feature theme=` |Feature roadmap=` |Feature secondary roadmap=` |Feature list=` |Feature project=` |Feature engineering team=` }}

Team status notes

  status notes
Products ` `
Engineering ` `
Security ` `
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}