Identity/AttachedServices/StorageServerProtocol: Difference between revisions

Jump to navigation Jump to search

Identity/AttachedServices/StorageServerProtocol (view source)

Revision as of 05:01, 16 May 2013

1,324 bytes removed ,  16 May 2013
no edit summary
No edit summary
Line 5: Line 5:
== Delta-Sync Data Model ==
== Delta-Sync Data Model ==


The storage server hosts a number of independent named '''collections''' for each user.  Each collection is a key-value store whose contents can be atomically modified by the client.
The storage server hosts a number of independent named '''collections''' for each user.  Each collection is a key-value store whose contents can be atomically modified by the client.  Each modification of a collection creates a new '''version''' with corresponding version identifier, which is a signed hash of the contents of the collection at that version.


Each modification of a collection creates a new '''version''' with corresponding version identifier, which is a signed hash of the contents of the collection at that version.  Version identifiers are of the form <seqnum>:<contents-hash>:<mac> and are provided by the client during write.  The server ensures that the version sequences numbers of monotonically increasing.
Each collection has a '''keyid''' which identifies the encryption key used on its contents.  This is of the form <seqnum>:<bytes> is would typically be derived from the master encryption key using HKDF.  The server ensures that keyid updates are given monotonically increasing sequence numbers, so that out-of-date clients can't accidentally roll back a key to a previous version.
Each collection has also have a '''details''' field, a JSON blob that the client can use to store arbitrary metadata on the collection.  If not set by the client, it defaults to null.


More details at [[Identity/CryptoIdeas/04-Delta-Sync]].
More details at [[Identity/CryptoIdeas/04-Delta-Sync]].
Line 17: Line 12:
== Authentication ==
== Authentication ==


To access the storage service, a client device must authenticate by POSTing a BrowserID assertion and a device identifier to a well-known server entry-point.  It will receive in exchange:
To access the storage service, a client device must authenticate by providing a BrowserID assertion and a Device ID.  It will receive in exchange:


* the current version number of each collection
* a short-lived id/key pair that can be used to authenticate subsequent requests with Hawk
* a URL to which further requests should be directed
* a URL to which further requests should be directed
* a short-lived id/key pair that can be used to authenticate subsequent requests with Hawk
* the current metadata info for each collection


You can think of this as establishing a "login session" with the server.  We're also tunneling some basic metadata in order to reduce the number of round-trips.
 
You can think of this as establishing a "login session" with the server, although we're also tunneling some basic metadata in order to reduce the number of round-trips.


Example:
Example:
Line 40: Line 36:
     <  "key": <hawk auth secret key>,
     <  "key": <hawk auth secret key>,
     <  "collections": {
     <  "collections": {
     <    "XXXXX": {
     <    "bookmarks": <version id for bookmarks collection>,
    <      "version": <version id for this collection>,
     <    "passwords": <version id for passwords collection>,
    <      "keyid": <key id for this collection>
    <    },
     <    "YYYYY": {
    <       "version": <version id for this collection>,
    <      "keyid": <key id for this collection>,
    <      "details": <details map for this collection>
    <    },
     <    <...etc...>
     <    <...etc...>
     <  }
     <  }
Line 63: Line 52:
=== GET <base-url> ===
=== GET <base-url> ===


Get the current metadata for all collections.  This is the same data as returned in the session-establishment call above, but it may be useful if the client wants to refresh its view.  Example:
Get the current version id for all collections.  This is the same data as returned in the session-establishment call above, but it may be useful if the client wants to refresh its view.  Example:


     >  GET <base-url>
     >  GET <base-url>
Line 72: Line 61:
     <  {
     <  {
     <  "collections": {
     <  "collections": {
     <    "XXXXX": {
     <    "bookmarks": <version id for bookmarks collection>,
    <      "version": <version id for this collection>,
     <    "passwords": <version id for passwords collection>,
    <      "keyid": <key id for this collection>
    <    },
     <    "YYYYY": {
    <       "version": <version id for this collection>,
    <      "keyid": <key id for this collection>,
    <      "details:" <details map for this collection>
    <    },
     <    <...etc...>
     <    <...etc...>
     <  }
     <  }
Line 87: Line 69:
=== GET <base-url>/<collection> ===
=== GET <base-url>/<collection> ===


Get the current metadata for a specific collection.  Example:
Get the current version id for a specific collection.  Example:


     >  GET <base-url>/<collection>
     >  GET <base-url>/<collection>
Line 95: Line 77:
     <  Content-Type: application/json
     <  Content-Type: application/json
     <  {
     <  {
     <  "version": <version id for this collection>,
     <  "version": <version id for this collection>
    <  "keyid": <key id for this collection>,
    <  "details": <details map for this collection>
     <  }
     <  }


Rfkelly
Confirmed users
358

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/656544"

Navigation menu