-
Notifications
You must be signed in to change notification settings - Fork 379
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #3122 from uhoreg/deprecate_verification_start
MSC3122: Deprecate starting verifications without requesting first
- Loading branch information
Showing
1 changed file
with
40 additions
and
0 deletions.
There are no files selected for viewing
40 changes: 40 additions & 0 deletions
40
proposals/3122-deprecate-starting-verifications-without-request.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,40 @@ | ||
# MSC3122: Deprecate starting key verifications without requesting first | ||
|
||
Currently, the [Key verification | ||
framework](https://spec.matrix.org/unstable/client-server-api/#key-verification-framework) | ||
allows a device to begin a verification via to-device messages by sending an | ||
`m.key.verification.start` event without first sending or receiving an | ||
`m.key.verification.request` message. (The last sentence of the 5th paragraph | ||
of the Key verification framework in the unstable spec, as of the time of | ||
writing.) However, doing so does not provide a good user experience, and | ||
allowing this adds unnecessary complexity to implementations. | ||
|
||
We propose to deprecate allowing this behaviour. | ||
|
||
Note that verifications in DMs do not allow this behaviour. Currently, Element | ||
Web is the only client known to do this. | ||
|
||
## Proposal | ||
|
||
The ability to begin a key verification by sending an | ||
`m.key.verification.start` event as a to-device event without a prior | ||
`m.key.verification.request` is deprecated. New clients should not begin | ||
verifications in this way, but will still need to accept verifications begun in | ||
this way, until it is removed from the spec. | ||
|
||
## Potential issues | ||
|
||
None. | ||
|
||
## Alternatives | ||
|
||
We could do nothing and leave it in the spec. But we should clean up cruft when | ||
possible. | ||
|
||
## Security considerations | ||
|
||
None. | ||
|
||
## Unstable prefix | ||
|
||
No unstable prefix is required since we are simply deprecating behaviour. |