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 key and its identifier, valid for some session duration (30 minutes?). Then, subsequent API calls are made with an HTTP MAC Auth signature header (HTTP MAC) signed using that key. 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.
