anchor.diff:  ## KBMAPI
   
   As mentioned in <<overview>>, a trusted node service will be needed in a
  -datacenter to store the pins and recovery data for all of the pivtokens in the
  +datacenter to store the pins and recovery data for all of the PIV tokens in the
   datacenter.  This service is the Key Backup and Management API (KBMAPI).
   
   KBMAPI will be a fairly simple and minimal REST service.  API endpoints
  
positive.code: 
  | guid
  | Yes
  | The GUID of the provisioned pivtoken
  
  | cn_uuid
  | Yes
  | The UUID if the CN that contains this pivtoken
  
  | pin
  | Yes
  | The pin for the pivtoken generated during provisioning
  
  | model
  | No
  | The model of the pivtoken (if known)
  
  | serial
  | No
  | The serial number of the pivtoken (if known)
  
  | pubkeys
  | Yes
  | The public keys of the pivtoken generated during provisioning
  
  | pubkeys.9a
  | Yes
  | The `9a` public key of the pivtoken
  
  | pubkeys.9d
  | Yes
  | The `9d` public key of the pivtoken
  
  | pubkeys.9e
  | Yes
  | The `9e` public key of the pivtoken
  
  | attestation
  | No
  
negative.code: a second authentication token used only when replacing a PIV token.
  
  [[kbmapi-history]]
  When PIV tokens are deleted or reinitialized, the old PIV token data should be kept in a
  KBMAPI-maintained history.  This history maintains the PIV 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 PIV token deletion.
  
  ### Attestation
  
  :yubi-attest: https://developers.yubico.com/PIV/Introduction/PIV_attestation.html
  
  Some PIV tokens have extensions that allow for attestation -- that is a method
  to show that a given key was created by the device and was not imported onto
  the PIV token. For YubiKeys, this is done by creating a special x509 certificate
  as detailed {yubi-attest}[here].
  