Confirm
471
edits
Changes
m
→Using the Account Token
== Using the Account Token ==
The single-use Account Token can be traded in for either a Signing Token or a Reset Token. Once used, the Account Token becomes invalid. The Account Token will also expire after a while (probably a few minutes to an hour). Each account will have just one Account Token valid at any given time. (We do not expect two devices to access the account so simultaneously that this becomes a problem).
=== Getting the Signing Token ===
The Account Token is used to derive a "tokenID" and an intermediate value called "getSignToken". Then getSignToken is used to derive three keys:
* request HMAC key
* response HMAC key
* response XOR key
The requestHMACkey is used in a HAWK (https://github.com/hueniverse/hawk/) request to provide integrity over the "getSignToken" request. It is used as credentials.key, while tokenID is used as credentials.id . HAWK includes the URL and the HTTP method ("POST") in the HMAC-protected data, and will optionally include the HTTP request body (payload) if requested (this is not used for getSignToken or getResetToken, but is used for "sign" itself).
HAWK provides one thing: integrity/authentication for the request contents (URL, method, and optionally the body). It does not provide confidentiality of the request, or integrity of the response, or confidentiality of the response. We must provide these three other properties ourselves.
For getSignToken and getResetToken, we don't need request confidentiality. We *do* need response confidentiality and integrity. To achieve these, the HAWK response is defined to be HMAC'ed (using responseHMACkey) and encrypted (XORed with the responseXORkey). XOR is safe and appropriate because the key is single-use and the data we're protecting is short and fixed-length.
=== Getting the Reset Token ===
The "getResetToken" request looks just like "getSignToken", but it uses a different HTTP endpoint and a different set of keys.
== Signing Certificates ==
== Resetting the Account ==
