Changes

Jump to: navigation, search

Identity/AttachedServices/KeyServerProtocol

247 bytes removed, 02:21, 28 June 2013
Signing Certificates
(TBD, future protocol)
The Sign Token is used to derive a "tokenID" and four additional keystwo values:
* request XOR keytokenID
* request HMAC key
* response HMAC key
* response XOR key
[[File:PICL-IdPAuth-signRequest.png|Signing the Request]]
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.
We might not need request confidentiality for For signCertificate(). We do need it for resetAccount(). And , we do not need request confidentiality or response confidentiality and integrity for both. To achieve these, since the HAWK response is defined to be HMACclient'ed (using responseHMACkey) s pubkey and encrypted (XORed with the responseXORkey)resulting certificate will both be exposed over a similar SSL connection to the storage server later. XOR And it is safe and appropriate because sufficient to rely on the response integrity provided by SSL, since the key is single-use and client can the data we're protecting is short and fixed-lengthreturned certificate for itself[[File:PICL-IdPAuth-decryptResponse.png|Decrypting the Response]]
= Resetting the Account =
Confirm
471
edits

Navigation menu