Services/Sync/Features/BrowserID Authentication

Please use "Edit with form" above to edit this page.

Status

Sync BrowserID Authentication
Stage	Draft
Status	`
Release target	`
Health	OK
Status note	`

{{#set:Feature name=Sync BrowserID Authentication

|Feature stage=Draft |Feature status=` |Feature version=` |Feature health=OK |Feature status note=` }}

Team

Product manager	`
Directly Responsible Individual	`
Lead engineer	`
Security lead	`
Privacy lead	`
Localization lead	`
Accessibility lead	`
QA lead	`
UX lead	`
Product marketing lead	`
Operations lead	`
Additional members	`

{{#set:Feature product manager=`

|Feature feature manager=` |Feature lead engineer=` |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}

Open issues/risks

`

Stage 1: Definition

1. Feature overview

Sync uses its own authentication database. Authentication of clients to the Sync server is performed via HTTP Basic Auth, sending the account username and password to the server.

Now that BrowserID exists and has momentum, we would like to allow BrowserID to both serve as the account manager (implying that Sync accounts are BrowserID accounts, or vice versa) and be used for HTTP authentication.

The primary purpose of this feature is to design a mechanism whereby BrowserID can be utilized to authenticate Sync requests, replacing the existing use of HTTP Basic Auth.

2. Users & use cases

When new users sign up for Sync, they log in to BrowserID or are presented an opportunity to sign up for BrowserID. Contrast this with the existing method, where users need to log in or create a Mozilla Services account.

3. Dependencies

`

4. Requirements

1. New Sync users do not create a Mozilla Services account, but instead create BrowserID accounts (if they don't have one already).
2. HTTP requests to the Sync server are authenticated via something derived from BrowserID, not by the user's original credentials.
   1. Related: requests should be able to be authenticated without per-request interactions with the BrowserID service. Each sync involves dozens of HTTP requests.
3. The new authentication mechanism should be usable outside of Sync, and outside of Mozilla, by anybody wishing to add BrowserID authentication to her service.
4. The new authentication mechanism cannot simply be raw BrowserID assertions, as these can be quite large and unsuitable for repeated use.

Non-goals

This feature does not involve changing Sync's data encryption model (a cryptographically secure randomly generated private key for client-side encryption): it only involves changing the mechanism by which new user accounts are handled and how Sync HTTP requests are authenticated.

Stage 2: Design

5. Functional specification

Technical details are still being decided.

A rough proposal exists at Identity/BrowserIDSync. Much discussion has occurred on the services-dev mailing list and on IRC. More formal "getting involved" info will follow.

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=` |Feature overview=Sync uses its own authentication database. Authentication of clients to the Sync server is performed via HTTP Basic Auth, sending the account username and password to the server.

Now that BrowserID exists and has momentum, we would like to allow BrowserID to both serve as the account manager (implying that Sync accounts are BrowserID accounts, or vice versa) and be used for HTTP authentication.

The primary purpose of this feature is to design a mechanism whereby BrowserID can be utilized to authenticate Sync requests, replacing the existing use of HTTP Basic Auth. |Feature users and use cases=When new users sign up for Sync, they log in to BrowserID or are presented an opportunity to sign up for BrowserID. Contrast this with the existing method, where users need to log in or create a Mozilla Services account. |Feature dependencies=` |Feature requirements=# New Sync users do not create a Mozilla Services account, but instead create BrowserID accounts (if they don't have one already).

1. HTTP requests to the Sync server are authenticated via something derived from BrowserID, not by the user's original credentials.
   1. Related: requests should be able to be authenticated without per-request interactions with the BrowserID service. Each sync involves dozens of HTTP requests.
2. The new authentication mechanism should be usable outside of Sync, and outside of Mozilla, by anybody wishing to add BrowserID authentication to her service.
3. The new authentication mechanism cannot simply be raw BrowserID assertions, as these can be quite large and unsuitable for repeated use.

|Feature non-goals=This feature does not involve changing Sync's data encryption model (a cryptographically secure randomly generated private key for client-side encryption): it only involves changing the mechanism by which new user accounts are handled and how Sync HTTP requests are authenticated. |Feature functional spec=Technical details are still being decided.

A rough proposal exists at Identity/BrowserIDSync. Much discussion has occurred on the services-dev mailing list and on IRC. More formal "getting involved" info will follow. |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	Unprioritized
Rank	999
Theme / Goal	`
Roadmap	`
Secondary roadmap	`
Feature list	`
Project	`
Engineering team	`

{{#set:Feature priority=Unprioritized

|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=` }}