Identity/BrowserIDSync

We propose a mechanism for accessing Firefox Sync via BrowserID credentials. The goal is to provide a template for other REST services to integrate with BrowserID.

High-Level Architecture

The REST API for Sync remains the same, only the authorization header changes, as per BrowserID+REST below. The nature of Sync data remains the same: nondurable. The main difference is that access to the data is authorized by a BrowserID Assertion.

Of course, this yields only encrypted data. We also propose a mechanism to use BrowserID (specifically its password) for key-wrapping purposes, so that logging into BrowserID can become sufficient to reclaim one's data from Sync.

BrowserID + REST

We standardize a point of authentication, /auth, which exchanges an assertion for a MAC HTTP Auth token and secret, valid for some session duration (30 minutes?). Then, subsequent API calls are made with an HTTP MAC Auth signature header (HTTP MAC) using that token and secret. (This is similar to OAuth in 2-legged mode, but is now being standardized as its own HTTP Auth method.) Thus, apart from the new API call to /auth, a REST API does not need to change. Only its authorization header is affected.

In order to make it easier for clients to discover our authentication mechanism, unauthenticated API calls should return

  401 Unauthorized 
  WWW-Authenticate: BrowserID+MAC url="/auth"

Other potential approaches:

• use the assertion as a proper assertion on the first call, then as a cookie on subsequent calls, valid for 30 minutes. This is not as secure, since API calls aren't signed, but it is easier to implement.

• don't standardize the exact approach. Let each service do authentication via BrowserID assertion any way it wishes. Exchange for a cookie, OAuth, etc, it can depend from one service to the other. Pro: sites do what they want. Con: writing common libraries is now impossible.

Key Wrapping

BrowserID Key Wrapping