anchor.diff:  field, the decrypted `recovery_token` value is used as the signing key (in
   conjunction with some HMAC mechanism).
   
  -If the request fails the authentication requests, a 401 Unauthorized error
  +Instead of HTTP Signature auth using the SSH key, HMAC signature using the
  +`recovery_token` as value will be used.
  +
  +If the lost token does not exists in KBMAPI we should reject the request with
  +a `404 Not Found` response.
  +
  +If the request fails the authentication requests, a `401 Unauthorized` error
   is returned.
   
   If all the checks succeed, the information from the old token (`:guid`) is
  -moved to a history entry for that token.
  +moved to a history entry for that token. Any subsequent requests to
  +`/pivtokens/:guid` should either return a `404 Not found` reply or, in case
  +we add some kind of `replaced_by: :new_guid` attribute to the archived token,
  +we could also return `301 Moved Permanently` with the new pivtoken location.
  +
  +The newly created token will then be returned, together with the proper
  +`Location` header (`/pivtokens/:new_guid`). In case of network/retry issues,
  +additional attempts to retrieve the new pivtoken information should be made
  +through `CreateToken` end-point for the new token, and these requests should
  +be signed by the new token 9e key, instead of using HMAC with the old token
  +`recovery_token`.
  +
   
   An example request:
   
  
positive.code: Response-Time: 42
  
  {
      "recovery_token": "ShCopwm8QUWsujJQHV7igNxVaWx4ZzmU5SpQtaOC+TY="
  }
  ----
  
  Note that the location contains the guid of the _new_ token.
  
negative.code: }
  ----
  
  In order to make the request/response retry-able w/o generating and saving a new
  `recovery_token` each time (to prevent a single recovery configuration update
  from creating multiple `recovery_tokens` due to network/retry issues), any
  requests made after the initial token creation to the same `Location` (i.e.
  `POST /pivtokens/:guid`) will result into the same pivtoken object being
  retrieved.
  
  This can be used too in order to generate new recovery tokens when a request is
  made at a given time after `recovery_token` creation. This time interval will
  be configurable in SAPI through the variable `KBMAPI_RECOVERY_TOKEN_DURATION`.
  By default, this value will be set to 1 day.
  
  When the `POST` request is received for an existing pivtoken, KBMAPI will
  verify the antiquity of the newest member of `recovery_tokens` and in case it
  exceeds the aforementioned `KBMAPI_RECOVERY_TOKEN_DURATION` value, it will
  generate a new `recovery_token`.
  
  On all of these cases, the status code will be `200 Ok` instead of the
  `201 Created` used for the initial pivtoken creation.
  
  
  ### UpdateToken (PUT /pivtokens/:guid)
  
  Update the current fields of a token.  Currently, the only field that can be
  