Merge pull request #1271 from uhoreg/add_verification_request_msgtype

add in-room m.key.verification.request msgtype
pull/1319/head
Hubert Chathi 2 years ago committed by GitHub
commit 830f80f56a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -0,0 +1 @@
Add missing documentation for `m.key.verification.request` msgtype for in-room verification.

@ -434,19 +434,22 @@ shared by the other messages of that session.
In general, verification operates as follows:
- Alice requests a key verification with Bob by sending an
`m.key.verification.request` event. This event indicates the verification
methods that Alice's client supports. (Note that "Alice" and "Bob" may in
fact be the same user, in the case where a user is verifying their own
devices.)
- Alice requests a key verification with Bob by sending a key verification
request event. If the verification is being requested in a room, this will
be an event with type [`m.room.message` and `msgtype:
m.key.verification.request`](#mroommessagemkeyverificationrequest); if the verification is being requested using
to-device messaging, this will be an event with type
[`m.key.verification.request`](#mkeyverificationrequest). This event indicates the verification methods
that Alice's client supports. (Note that "Alice" and "Bob" may in fact be the
same user, in the case where a user is verifying their own devices.)
- Bob's client prompts Bob to accept the key verification. When Bob accepts
the verification, Bob's client sends an `m.key.verification.ready` event.
the verification, Bob's client sends an [`m.key.verification.ready`](#mkeyverificationready) event.
This event indicates the verification methods, corresponding to the
verification methods supported by Alice's client, that Bob's client supports.
- Alice's or Bob's devices allow their users to select one of the verification
methods supported by both devices to use for verification. When Alice or Bob
selects a verification method, their device begins the verification by
sending an `m.key.verification.start` event, indicating the selected
sending an [`m.key.verification.start`](#mkeyverificationstart) event, indicating the selected
verification method. Note that if there is only one verification method in
common between the devices then the receiver's device (Bob) can auto-select
it.
@ -454,11 +457,11 @@ In general, verification operates as follows:
verification method. This could involve their clients exchanging messages,
Alice and Bob exchanging information out-of-band, and/or Alice and Bob
interacting with their devices.
- Alice's and Bob's clients send `m.key.verification.done` events to indicate
- Alice's and Bob's clients send [`m.key.verification.done`](#mkeyverificationdone) events to indicate
that the verification was successful.
Verifications can be cancelled by either device at any time by sending an
`m.key.verification.cancel` event with a `code` field that indicates the reason
[`m.key.verification.cancel`](#mkeyverificationcancel) event with a `code` field that indicates the reason
it was cancelled.
When using to-device messages, Alice may not know which of Bob's devices to
@ -562,6 +565,8 @@ in this specification must be under the `m.key.verification` namespace
and any other event types must be namespaced according to the Java
package naming convention.
{{% event event="m.room.message$m.key.verification.request" title="`m.room.message` with `msgtype: m.key.verification.request`" %}}
{{% event event="m.key.verification.request" %}}
{{% event event="m.key.verification.ready" %}}

@ -29,8 +29,8 @@ optional keys, as outlined below. If a client cannot display the given
instead.
Some message types support HTML in the event content that clients should
prefer to display if available. Currently `m.text`, `m.emote`, and
`m.notice` support an additional `format` parameter of
prefer to display if available. Currently `m.text`, `m.emote`, `m.notice`,
and `m.key.verification.request` support an additional `format` parameter of
`org.matrix.custom.html`. When this field is present, a `formatted_body`
with the HTML must be provided. The plain text version of the HTML
should be provided in the `body`.

@ -0,0 +1,19 @@
{
"event_id": "$143273582443PhrSn:example.org",
"origin_server_ts": 1432735824653,
"room_id": "!jEsUZKDJdhlrceRyVU:example.org",
"sender": "@alice:example.org",
"type": "m.room.message",
"unsigned": {
"age": 1234
},
"content": {
"body": "Alice is requesting to verify your device, but your client does not support verification, so you may need to use a different verification method.",
"from_device": "AliceDevice2",
"methods": [
"m.sas.v1"
],
"to": "@bob:example.org",
"msgtype": "m.key.verification.request"
}
}

@ -3,7 +3,9 @@ allOf:
- $ref: core-event-schema/event.yaml
description: |-
Requests a key verification with another user's devices.
Requests a key verification using to-device messaging. When requesting a key
verification in a room, a `m.room.message` should be used, with
[`m.key.verification.request`](#mroommessagemkeyverificationrequest) as msgtype.
properties:
content:
properties:

@ -0,0 +1,68 @@
---
allOf:
- $ref: core-event-schema/room_event.yaml
description:
Requests a key verification in a room. When requesting a key verification
using to-device messaging, an event with type [`m.key.verification.request`](#mkeyverificationrequest)
should be used.
properties:
content:
properties:
body:
type: string
description: |-
A fallback message to alert users that their client does not support
the key verification framework, and that they should use a different method
to verify keys. For example, "Alice is requesting to verify keys with you.
However, your client does not support this method, so you will need to use
the legacy method of key verification."
Clients that do support the key verification framework should hide the body
and instead present the user with an interface to accept or reject the key
verification.
format:
description: |-
The format used in the `formatted_body`. Currently only
`org.matrix.custom.html` is supported.
type: string
formatted_body:
description: |-
The formatted version of the `body`. This is required if `format` is
specified. As with the `body`, clients that do support the key
verification framework should hide the formatted body and instead
present the user with an interface to accept or reject the key
verification.
type: string
from_device:
type: string
description: |-
The device ID which is initiating the request.
methods:
type: array
description: |-
The verification methods supported by the sender.
items:
type: string
to:
description: |-
The user that the verification request is intended for. Users who
are not named in this field and who did not send this event should
ignore all other events that have an `m.reference` relationship with
this event.
type: string
msgtype:
enum:
- m.key.verification.request
type: string
required:
- from_device
- methods
- msgtype
- to
type: object
type:
enum:
- m.room.message
type: string
title: KeyVerification
type: object

@ -16,9 +16,10 @@
{{ $msgtypes := (slice "m.room.message$m.text" "m.room.message$m.emote" "m.room.message$m.notice" "m.room.message$m.image" "m.room.message$m.file") }}
{{/*
It excludes `m.room.message$m.server_notice`
It excludes `m.room.message$m.server_notice` and `m.room.message$m.key.verification.request`
since they are in their own modules.
*/}}
{{ $excluded := slice "m.room.message$m.server_notice" }}
{{ $excluded := slice "m.room.message$m.server_notice" "m.room.message$m.key.verification.request" }}
{{/*
It then adds any other events that start with `m.room.message`.

Loading…
Cancel
Save