anchor.diff:  | Yes
   | The pin of the provisioned token.
   
  -| recovery_token
  +| recovery_tokens
   | Yes
  -| The recovery token used to recover the encryption keys of a zpool protected
  -by this token.  Also used when replacing a token.
  +| An array of recovery tokens.  Used to recover the encryption keys of a zpool protected by this token.  Also used when replacing a token.  When the recovery configuration is updated, a new recovery token is generated and added to the list.
   
   | pubkeys
   | Yes
  
positive.code: etc.), a recovery must be performed.  This allows a new token to replace the
  unavailable token.  When a recovery is required, an operator initiates the
  recovery process on the CN.  This recovery process on the CN will decrypt the
  `recovery_token` value for the lost token that was created during the lost
  token's CreateToken request.  The CN then submits a RecoverToken request to
  replace the unavailable token with a new token.  The `:guid` parameter is the
  guid of the unavailable token.  The data included in the request is identical
  to that of a CreateToken request.  The major difference is that instead of
  using a token's 9e key to sign the date field, the decrypted `recovery_token`
  value is used as the signing key.
  
  **QUESTION**: Should we also include an additional header with the date signed
  by the new token's 9e key?  Or is it sufficient to trust the data if signed by
  
negative.code: 
  #### Interaction: ZFS
  
  After setup has completed kbmd will manage the `rfd77:config` ZFS property on
  the pool itself directly. This will be read during boot and written during
  recovery or rekeying. kbmd itself will also make the libzfs call to provide
  key material to the pool during the unlock process (since it needs to do this
  