anchor.diff:  So instead, the soft-token keys' backup comes in the form of a single
   large box (keyed only to the backup keys) which unlocks all of them.
   Every time we need to add or remove something from that box, we have to
  -regenerate it from scratch using the individual boxes targetted to the
  -primary Yubikey. So we keep a plaintext record next to it of the
  -locations of all of the primary Yubikey boxes on disk. We call this
  +regenerate it from scratch using the individual boxes targeted to the
  +primary YubiKey. So we keep a plaintext record next to it of the
  +locations of all of the primary YubiKey boxes on disk. We call this
   whole structure together the "recovery registry".
   
   This implies that the storage of these keys is somewhat managed by the
  
positive.code: | recovery_tokens
  | Yes
  | An array of recovery tokens. Used as an alternate authentication key when
  replacing a PIV token on a machine (usually due to loss or damange of the
  original PIV token). They also serve as proof to KBMAPI that a recovery
  operation was performed. When the recovery configuration is updated, a new
  recovery token is generated and added to the list. A history of previous
  
negative.code: KBMAPI-maintained history.  This history maintains the token data for an
  amount of time defined by the `KBMAPI_HISTORY_DURATION` SAPI variable.  The
  default shall be 15 days.  The purpose is to provide a time-limited backup
  against accidental token deletion.
  
  ### Attestation
  
  