[[File:PICL-IdPAuth-encrypt-resetAccount.png|Deriving the Client encrypts resetAccount Keysrequest]]
The request data will contain wrap(kB), a new (randomly-generated) SRP salt, and the new SRP verifier, all concatenated together. Since we always pad the SRP verifier to the full (256-byte) group length, all four pieces are fixed-length. We generate enough reqXORkey bytes to cover all four values.
The request data is XORed with requestXORkey, then delivered in the body of a HAWK request that uses tokenID as credentials.id and requestHMACkey as credentials.key . Note: it is critical to include the request body in the HAWK integrity check (options.payload=true, on both client and server), otherwise a man-in-the-middle could substitute their own SRP verifier, giving them control over the account (access to the user's class-A data, and a brute-force attack on their password).
[[File:PICL-IdPAuth-encryptResetAccount.png|Encrypting the resetAccount Request]]
Clients might use resetAccount for two reasons: