clarifications, fix formatting
@@ -470,11 +470,18 @@ On success, returns the empty JSON object.
##### `auth_data` for backup versions
The `auth_data` property for the backup versions endpoints for
-`m.megolm_backup.v1.curve25519-aes-sha2` is a signedjson object with the
+`m.megolm_backup.v1.curve25519-aes-sha2` is a [signed
+json](https://matrix.org/docs/spec/appendices#signing-json) object with the
following keys:
- `public_key` (string): the curve25519 public key used to encrypt the backups
-- `signatures` (object): signatures of the public key
+- `signatures` (object): signatures of the `auth_data`.
+
+The `auth_data` should be signed by the user's [master cross-signing
+key](https://github.com/matrix-org/matrix-doc/pull/1756), and may also be
+signed by the user's device key. The allows clients to ensure that the public
+key is valid, and prevents an attacker from being able to change the backup to
+use a public key that have the private key for.
##### `session_data` for key backups
@@ -516,10 +523,10 @@ key backup. This proposal does not attempt to protect against that.
An attacker who gains access to a user's account can create a new backup
version using a key that they control. For this reason, clients SHOULD confirm
with users before sending keys to a new backup version or verify that it was
-created by a trusted device by checking the signature. One way to confirm the
-new backup version if the signature cannot be checked is by asking the user to
-enter the recovery key, and confirming that the backup's public key matches
-what is expected.
+created by a trusted device by checking the signature. Alternatively, if the
+signature cannot be verified, the backup can be validated by prompting the user
+to enter the recovery key, and confirming that the backup's public key
+corresponds to the recovery key.
Other Issues
------------
