Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-02-02 20:43:42 +01:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

s/accept/ready/ because we already have an m.key.verification.accept

Browse source
This commit is contained in:
Hubert Chathi 2019-11-29 09:22:09 -05:00
parent 5f5f99fcc1
commit 5742c30a96
1 changed files with 6 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
proposals/2366-key-verification-accept.md
View file

@ -1,4 +1,4 @@
# Key verification flow addition: `m.key.verification.accept` # Key verification flow addition: `m.key.verification.ready`
The current key verification framework is asymmetrical in that the user who The current key verification framework is asymmetrical in that the user who
requests the verification is unable to select the key verification method. requests the verification is unable to select the key verification method.
@ -10,11 +10,11 @@ verifying in-person, but are using a trusted but remote channel of verification
## Proposal ## Proposal
A new event type is added to the key verification framework: A new event type is added to the key verification framework:
`m.key.verification.accept`, which may be sent by the target of the `m.key.verification.ready`, which may be sent by the target of the
`m.key.verification.request` message, upon receipt of the `m.key.verification.request` message, upon receipt of the
`m.key.verification.request` event. It has the fields: `m.key.verification.request` event. It has the fields:
- `from_device`: the ID of the device that sent the `m.key.verification.accept` - `from_device`: the ID of the device that sent the `m.key.verification.ready`
message message
- `methods`: an array of verification methods that the device supports - `methods`: an array of verification methods that the device supports
@ -22,7 +22,7 @@ It also has the usual `transaction_id` or `m.relates_to` fields for key
verification events, depending on whether it is sent as a to-device event verification events, depending on whether it is sent as a to-device event
or an in-room event. or an in-room event.
After the `m.key.verification.accept` event is sent, either party can send an After the `m.key.verification.ready` event is sent, either party can send an
`m.key.verification.start` event to begin the verification. If both parties `m.key.verification.start` event to begin the verification. If both parties
send an `m.key.verification.start` event, and they both specify the same send an `m.key.verification.start` event, and they both specify the same
verification method, then the event sent by the user whose user ID is the verification method, then the event sent by the user whose user ID is the
@ -32,7 +32,7 @@ compared instead. If both parties send an `m.key.verification.start` event,
but they specify different verification methods, the verification should be but they specify different verification methods, the verification should be
cancelled with a `code` of `m.unexpected_message`. cancelled with a `code` of `m.unexpected_message`.
The `m.key.verification.accept` event is optional; the recipient of the The `m.key.verification.ready` event is optional; the recipient of the
`m.key.verification.request` event may respond directly with a `m.key.verification.request` event may respond directly with a
`m.key.verification.start` event instead. This is for compatibility with the `m.key.verification.start` event instead. This is for compatibility with the
current version of the spec. current version of the spec.
@ -46,7 +46,7 @@ There are now three possible ways that a key verification can be performed:
2. A device sends an `m.key.verification.request` event and the recipient 2. A device sends an `m.key.verification.request` event and the recipient
replies with an `m.key.verification.start` event. replies with an `m.key.verification.start` event.
3. A device sends an `m.key.verification.request` event and the recipient 3. A device sends an `m.key.verification.request` event and the recipient
replies with an `m.key.verification.accept` event, and which point, either replies with an `m.key.verification.ready` event, and which point, either
device can send an `m.key.verification.start` event to begin the device can send an `m.key.verification.start` event to begin the
verification. verification.