On 9/01/2014 10:36 AM, Brian Warner wrote:
>
> * the Sync tokenserver will maintain a table with three columns:
> - FxA Account Identifier
> - FxA generation number
> - Sync account identifier (endpoint? collection-id? I don't know the
> right lingo)
>
> * The Sync account identifier must be a consistent function of (FxA
> account-id, hash-of-encryption-key). Previously it was merely a
> consistent function of the FxA account-id.
An alternative could be to pass the hash-of-encryption-key directly to
the sync storage node, which is the thing that actually cares about it.
Off-the-cuff strawman semi-proposal:
* All requests to the sync1.5 API include an "X-Weave-Key-Hash" header
containing the current hash of the encryption key.
* The sync1.5 server remembers the "current key-hash" for each user as
part of their metadata.
* If you show up with a mismatched value for X-Weave-Key-Hash then
you get a 401 and go back to the tokenserver.
* When you DELETE /storage then it resets the current key-hash.
This would be like a storage-wide X-If-Unmodified-Since on the
encryption key. It would increase the size of each sync storage request
and maybe add some extra db reads on the storage nodes, but keeps this
concern localized to the sync system.
Hmmm...dunno if that's really any better. It depends on where you draw
the boundaries around these systems and what other services you think
might pop up downstream of tokensever in the future.
Cheers,
Ryan
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
