You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
matrix-spec/data/event-schemas/schema/m.key.verification.cancel.yaml

71 lines
2.7 KiB
YAML

---
allOf:
- $ref: core-event-schema/event.yaml
description: |-
Cancels a key verification process/request.
properties:
content:
properties:
transaction_id:
type: string
description: |-
Required when sent as a to-device message. The opaque identifier for
the verification process/request.
reason:
type: string
description: |-
A human readable description of the `code`. The client should only rely on this
string if it does not understand the `code`.
code:
type: string
# Note: this is not an enum because we go into detail about the different
# error codes. If we made this an enum, we'd be repeating information.
# Also, we can't put a real bulleted list in here because the HTML2RST parser
# cuts the text at weird points, breaking the list completely.
description: |-
The error code for why the process/request was cancelled by the user. Error
codes should use the Java package naming convention if not in the following
list:
* `m.user`: The user cancelled the verification.
* `m.timeout`: The verification process timed out. Verification processes
can define their own timeout parameters.
* `m.unknown_transaction`: The device does not know about the given transaction
ID.
* `m.unknown_method`: The device does not know how to handle the requested
method. This should be sent for `m.key.verification.start` messages and
messages defined by individual verification processes.
* `m.unexpected_message`: The device received an unexpected message. Typically
raised when one of the parties is handling the verification out of order.
* `m.key_mismatch`: The key was not verified.
* `m.user_mismatch`: The expected user did not match the user verified.
* `m.invalid_message`: The message received was invalid.
* `m.accepted`: A `m.key.verification.request` was accepted by a different
device. The device receiving this error can ignore the verification request.
Clients should be careful to avoid error loops. For example, if a device sends
an incorrect message and the client returns `m.invalid_message` to which it
gets an unexpected response with `m.unexpected_message`, the client should not
respond again with `m.unexpected_message` to avoid the other device potentially
sending another error response.
m.relates_to:
$ref: m.key.verification.m.relates_to.yaml
required:
- code
- reason
type: object
type:
enum:
- m.key.verification.cancel
type: string
type: object