Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-25 04:24:09 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

fixup! e2ee/device verification: move general error handling under framework

Browse source 
Signed-off-by: Sumner Evans <sumner.evans@automattic.com>
This commit is contained in:
Sumner Evans 2024-06-07 10:35:31 -06:00
parent d6c6a0361f
commit 2ea4e13239
No known key found for this signature in database
1 changed files with 24 additions and 23 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

47
content/client-server-api/modules/end_to_end_encryption.md
View file

@ -602,27 +602,27 @@ package naming convention.
At any point the interactive verification can go wrong. The following describes At any point the interactive verification can go wrong. The following describes
what to do when an error happens: what to do when an error happens:
- Alice or Bob can cancel the verification at any time. An - Alice or Bob can cancel the verification at any time. An
[`m.key.verification.cancel`](#mkeyverificationcancel) message must be sent to [`m.key.verification.cancel`](#mkeyverificationcancel) message must be sent
signify the cancellation. to signify the cancellation.
- The verification can time out. Clients should time out a verification that - The verification can time out. Clients should time out a verification that
does not complete within 10 minutes. Additionally, clients should expire a does not complete within 10 minutes. Additionally, clients should expire a
`transaction_id` which goes unused for 10 minutes after having last `transaction_id` which goes unused for 10 minutes after having last
sent/received it. The client should inform the user that the verification sent/received it. The client should inform the user that the verification
timed out, and send an appropriate timed out, and send an appropriate
[`m.key.verification.cancel`](#mkeyverificationcancel) message to the other [`m.key.verification.cancel`](#mkeyverificationcancel) message to the other
device. device.
- When the same device attempts to initiate multiple verification attempts, - When the same device attempts to initiate multiple verification attempts,
the recipient should cancel all attempts with that device. the recipient should cancel all attempts with that device.
- When a device receives an unknown `transaction_id`, it should send an - When a device receives an unknown `transaction_id`, it should send an
appropriate [`m.key.verification.cancel`](#mkeyverificationcancel) message to appropriate [`m.key.verification.cancel`](#mkeyverificationcancel) message
the other device indicating as such. This does not apply for inbound to the other device indicating as such. This does not apply for inbound
[`m.key.verification.request`](#mkeyverificationrequest), [`m.key.verification.request`](#mkeyverificationrequest),
[`m.key.verification.start`](#mkeyverificationstart), or [`m.key.verification.start`](#mkeyverificationstart), or
[`m.key.verification.cancel`](#mkeyverificationcancel) messages. [`m.key.verification.cancel`](#mkeyverificationcancel) messages.
- If the device receives a message out of sequence or that it was not expecting, - If the device receives a message out of sequence or that it was not
it should notify the other device with an appropriate expecting, it should notify the other device with an appropriate
[`m.key.verification.cancel`](#mkeyverificationcancel) message. [`m.key.verification.cancel`](#mkeyverificationcancel) message.
##### Short Authentication String (SAS) verification ##### Short Authentication String (SAS) verification
@ -749,8 +749,9 @@ devices:
###### Error handling during SAS verification ###### Error handling during SAS verification
At any point the interactive verification can go wrong. The following At any point the interactive verification can go wrong. In addition to the
describes what to do when an error happens: [Error handling during key verification](#error-handling-during-key-verification) The following describes
what to do when an error happens:
- If the two devices do not share a common key share, hash, HMAC, or - If the two devices do not share a common key share, hash, HMAC, or
SAS method then the device should notify the other device with an SAS method then the device should notify the other device with an