Services/Sync/Features/BrowserID Authentication

Status

Team

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

`

Feature details

Team status notes