Services/Sync/Features/BrowserID Authentication
Status
| Sync BrowserID Authentication | |
| Stage | Draft |
| Status | ` |
| Release target | ` |
| Health | OK |
| 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 | ` |
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
- New Sync users do not create a Mozilla Services account, but instead create BrowserID accounts (if they don't have one already).
- HTTP requests to the Sync server are authenticated via something derived from BrowserID, not by the user's original credentials.
- Related: requests should be able to be authenticated without per-request interactions with the BrowserID service. Each sync involves dozens of HTTP requests.
- The new authentication mechanism should be usable outside of Sync, and outside of Mozilla, by anybody wishing to add BrowserID authentication to her service.
- 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
| Priority | Unprioritized |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | ` |
| Secondary roadmap | ` |
| Feature list | ` |
| Project | ` |
| Engineering team | ` |
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
