canmove, Confirmed users
725
edits
Services/Sync/Developer/StorageFormat: Difference between revisions
Jump to navigation
Jump to search
Services/Sync/Developer/StorageFormat (view source)
Revision as of 19:22, 12 December 2010
, 12 December 2010no edit summary
No edit summary |
|||
| Line 7: | Line 7: | ||
All records from the server come back as a JSON string that represent a JS-object with some attributes. The whole object is described by the [[Labs/Weave/API|Sync Server API]], but for a given client storage version, only a subset may be used. | All records from the server come back as a JSON string that represent a JS-object with some attributes. The whole object is described by the [[Labs/Weave/API|Sync Server API]], but for a given client storage version, only a subset may be used. | ||
== Versions 2, 3, and | == Versions 2, 3, and 5 == | ||
The following describes the JS-object represented by the JSON-string record: | The following describes the JS-object represented by the JSON-string record: | ||
| Line 84: | Line 84: | ||
Individual data engines, e.g., bookmarks, encrypt their [[Labs/Weave/Developer/BrowserObjects|Browser Objects]] payloads before packing it into the <tt>payload</tt> field of a Weave Basic Object. There is additional metadata about the encryption to help decrypt the BrowserObject payload. | Individual data engines, e.g., bookmarks, encrypt their [[Labs/Weave/Developer/BrowserObjects|Browser Objects]] payloads before packing it into the <tt>payload</tt> field of a Weave Basic Object. There is additional metadata about the encryption to help decrypt the BrowserObject payload. | ||
== Version | == Version 5 == | ||
Version | Version 5 is similar to Version 2 and 3, except '''encryption''' has been dropped and the HMAC is now calculated with a separate key which is no longer used in its base64 representation but in its raw byte form. | ||
The keys with which to verify and decrypt a WBO are now determined based on the collection name. If collection-specific keys do not exist, the default key bundle should be used. | The keys with which to verify and decrypt a WBO are now determined based on the collection name. If collection-specific keys do not exist, the default key bundle should be used. | ||
| Line 193: | Line 193: | ||
The payload of the <tt>meta/global</tt> record contains general metadata to describe data like versions and syncID. | The payload of the <tt>meta/global</tt> record contains general metadata to describe data like versions and syncID. | ||
== Version 2, 3 and | == Version 2, 3 and 5 == | ||
The following describes the JS-object represented by the JSON-string payload: | The following describes the JS-object represented by the JSON-string payload: | ||
| Line 249: | Line 249: | ||
= Payload: crypto/keys = | = Payload: crypto/keys = | ||
In storage Version | In storage Version 5, the public/private key layer has been dropped. All bulk keys are now stored in this one WBO. Encryption and HMAC keys are separate keys and kept in key pairs. | ||
The '''keys''' WBO is encrypted and verified just like any other WBO, except a different key bundle is used. The key bundle for the '''keys''' WBO is derived from the Sync Key using an HKDF with HMAC-SHA256 as the HMAC function (see [http://tools.ietf.org/html/rfc5869 RFC 5869]): | The '''keys''' WBO is encrypted and verified just like any other WBO, except a different key bundle is used. The key bundle for the '''keys''' WBO is derived from the Sync Key using an HKDF with HMAC-SHA256 as the HMAC function (see [http://tools.ietf.org/html/rfc5869 RFC 5869]): | ||
| Line 265: | Line 265: | ||
== Version | == Version 5 == | ||
{| cellpadding=5 | {| cellpadding=5 | ||