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

pull/977/head
Hubert Chathi 5 years ago
parent 5f5f99fcc1
commit 5742c30a96

@ -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
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
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` 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
- `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
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
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
@ -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
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.start` event instead. This is for compatibility with the
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
replies with an `m.key.verification.start` event.
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
verification.

Loading…
Cancel
Save