Labs/Weave/Developer/SecureDataSharing

An ultimate goal of the Weave project is to support secure private sharing of data with users and services across the internet. This is a very complex problem, so we're taking it in pieces.

The Weave Sync API uses a fairly complex cryptographic process to protect user data. (You can read about the cryptographic details here). The cryptography that we employ today is entirely used to allow a user to recover their data at a second machine, and has no mechanism to support securely sharing with a third party.

The system described here does not assume that users will share their data with us. Our goal is to keep the service ignorant of private details whenever possible.

In our vision, a secure sharing scenario would unfold like this:

A user visits a site, which asks permission to see some of his data (say, his web browsing history). The user grants permission to the site, and a secure relationship is created between the user and the site. The site is then able to access the user's web browsing history, but the information on Mozilla's servers is still encrypted. At some later date, the user is able to revoke access to their browsing history, and the site is unable to retrieve, or read, any new data. Other sites that the user may have shared with continue to work normally.

There are four pieces that we need to implement to support that story:

Access Control

The user must be able to grant read or write privileges to subsets of his or her data. We want users to be able to grant these privileges to both organizations and individual people. This will require some additional server work. We would probably also forbid some sharing by default, e.g. of the user's passwords.

Once this is done, the third party service will be able to retrieve the encrypted data.

Delegated authentication and authorization

The user must have a way of proving to a third-party service that they really are who they claim, and for the Mozilla service to provide information back to the third-party service that access has been granted. The OpenID and OAuth protocols provide what we need here, and the OpenID/OAuth hybrid flow has been described.

Once this is done, the third party service will be able to establish a relationship with the Weave Sync service for a user, without the user disclosing his or her password.

Key exchange and generation

The user's software will need to obtain a public key for the third-party service or remote user, and use it to put an entry on their keyring (that is, to encrypt a symmetric key by using the third party's public key). This keyring entry will need to be made available to the third party.

Once this is done, the third party service will be able to access the bulk key for the data that it has access to, allowing it to read (and write) entries to that collection.

Data segmentation

Currently, the data in the Sync service is encrypted with one key per collection type. That means there's no way to share (say) only some of your bookmarks.

Once this is done, users can share just what they want to share instead of following an arbitrary data-type-based separation.

Weave-data Access Tokens (WATs)

One idea for sharing data, and potentially for single-user use as well, is to implement a system of specialized bearer tokens. The tokens would look somewhat like this:

<bearer token>:<key ID>:<key unlock token>

That is, a long string of hashes and data, which could be stored as-is, or encapsulated in a file for example.

Deconstructing the token:

bearer token

The bearer token portion of the Weave token would act as a "standard" bearer token. It would provide access to some subset (or all) of the user's resources stored on the server. This would need to include of course the relevant key and keyrings.

key ID

Which key to use.

key unlock token

Could be a passphrase, or perhaps some sort of digest (Tahoe-style?) that could be used to unlock the key or the data.

Using the Weave token:

The token could be given as-is to a Weave-enabled application, which would split it up into its component parts, and:

1. use the bearer token to retrieve keys, keyrings, and data from the Weave service
2. use the key unlock token to unlock the private key, and that way access the keyring, and ultimately the data

Alternatives/ideas

The tokens could be hashed to get the "bearer token" portion, instead of splitting it into component pieces. This is more similar to what Tahoe does.