mirror of
https://github.com/matrix-org/matrix-spec
synced 2026-04-24 19:44:09 +02:00
Compare commits
6 commits
056b61ab84
...
678b6b8eb4
| Author | SHA1 | Date | |
|---|---|---|---|
|
678b6b8eb4 | ||
|
|
2a8c0bc7b8 | ||
|
|
81a864545f | ||
|
|
671bc674cd | ||
|
|
72a2ebc7ad | ||
|
|
f42ce28bfe |
|
|
@ -1 +0,0 @@
|
|||
Room IDs can now appear without a domain component in [room version 12](/rooms/v12), as per [MSC4291](https://github.com/matrix-org/matrix-spec-proposals/pull/4291).
|
||||
|
|
@ -1 +0,0 @@
|
|||
Declare the Application Service Registration schema to follow JSON Schema spec 2020-12.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Minor fixes to JSON schemas.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Deprecate `m.set_avatar_url` and `m.set_displayname` capabilities, as per [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133).
|
||||
|
|
@ -1 +0,0 @@
|
|||
Update user profile endpoints to handle custom fields, and add a new `m.profile_fields` capability, as per [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133).
|
||||
|
|
@ -1 +0,0 @@
|
|||
Declare the event schemas to follow JSON Schema spec 2020-12.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Clarify that `format` is required if `formatted_body` is specified.
|
||||
|
|
@ -1 +0,0 @@
|
|||
The `latest_event` in an aggregated set of thread events uses the same format as the event itself.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Fix various typos throughout the specification.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Add `format` query parameter to `GET /state/{eventType}/{stateKey}` to allow fetching metadata of a specific state event.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Fix various typos throughout the specification.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Fix various typos throughout the specification.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Minor fixes to JSON schemas.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Add the `use_state_after` query parameter and `state_after` response property to `GET /sync`, as per [MSC4222](https://github.com/matrix-org/matrix-spec-proposals/issues/4222).
|
||||
|
|
@ -0,0 +1 @@
|
|||
Clarify terminology for keys in cross-signing module.
|
||||
|
|
@ -1 +0,0 @@
|
|||
When upgrading rooms to [room version 12](/rooms/v12), `additional_creators` may be specified on the [`POST /_matrix/client/v3/rooms/{roomId}/upgrade`](/client-server-api/#post_matrixclientv3roomsroomidupgrade) endpoint, as per [MSC4289](https://github.com/matrix-org/matrix-spec-proposals/pull/4289).
|
||||
|
|
@ -1 +0,0 @@
|
|||
When creating rooms with [room version 12](/rooms/v12), the `trusted_private_chat` preset should merge the invitees into the supplied `content.additional_creators` in the resulting room, as per [MSC4289](https://github.com/matrix-org/matrix-spec-proposals/pull/4289).
|
||||
|
|
@ -1 +0,0 @@
|
|||
In [room version 12](/rooms/v12), the power level of room creators is now infinitely high as per [MSC4289](https://github.com/matrix-org/matrix-spec-proposals/pull/4289).
|
||||
|
|
@ -1 +0,0 @@
|
|||
In [room version 12](/rooms/v12), room IDs no longer have a domain component as per [MSC4291](https://github.com/matrix-org/matrix-spec-proposals/pull/4291).
|
||||
|
|
@ -1 +0,0 @@
|
|||
When creating rooms with [room version 12](/rooms/v12), the initial power levels will restrict the ability to upgrade rooms by default, as per [MSC4289](https://github.com/matrix-org/matrix-spec-proposals/pull/4289).
|
||||
|
|
@ -1 +0,0 @@
|
|||
Fix `/sync` flow referencing incorrect parameter to use with `/messages`.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Clarify wording around the `world_readable` history visibility setting. Contributed by @HarHarLinks.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Add a profile field for a user's time zone, per [MSC4175](https://github.com/matrix-org/matrix-spec-proposals/pull/4175).
|
||||
|
|
@ -1 +0,0 @@
|
|||
Invites and knocks are now expected to contain the `m.room.create` event in their stripped state entries, as per [MSC4311](https://github.com/matrix-org/matrix-spec-proposals/pull/4311).
|
||||
|
|
@ -1 +0,0 @@
|
|||
Add "placeholder MSC" process definition.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Upgrade the docsy theme to version 0.12.0.
|
||||
|
|
@ -1 +0,0 @@
|
|||
GitHub actions are now building the OpenAPI `spec/identity-service-api/api.json` file.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Specify a correct spelling for "display name".
|
||||
|
|
@ -1 +0,0 @@
|
|||
Clarify that clients should replace events with the most recent replacement by origin_server_ts.
|
||||
|
|
@ -1 +0,0 @@
|
|||
TODO: Placeholder
|
||||
|
|
@ -1 +0,0 @@
|
|||
Fix a grammatical typo on the Matrix Spec Process documentation page.
|
||||
|
|
@ -1 +0,0 @@
|
|||
In room versions 1 through 12, an event's `auth_events` have always needed to belong to the same room as per [MSC4307](https://github.com/matrix-org/matrix-spec-proposals/pull/4307).
|
||||
|
|
@ -1 +0,0 @@
|
|||
Add [room version 12](/rooms/v12) as per [MSC4304](https://github.com/matrix-org/matrix-spec-proposals/pull/4304).
|
||||
|
|
@ -1 +0,0 @@
|
|||
Room IDs in room version 12 are now the event ID of the create event with the normal room ID sigil (`!`), as per [MSC4291](https://github.com/matrix-org/matrix-spec-proposals/pull/4291).
|
||||
|
|
@ -1 +0,0 @@
|
|||
Room creators are formalized in room version 12 and have infinitely high power level, as per [MSC4289](https://github.com/matrix-org/matrix-spec-proposals/pull/4289).
|
||||
|
|
@ -1 +0,0 @@
|
|||
State Resolution is updated in room version 12 to reduce the opportunity for "state resets", as per [MSC4297](https://github.com/matrix-org/matrix-spec-proposals/pull/4297).
|
||||
|
|
@ -1 +0,0 @@
|
|||
The default room version is now room version 12, though servers SHOULD keep using room version 11 for a little while, as per [MSC4304](https://github.com/matrix-org/matrix-spec-proposals/pull/4304).
|
||||
|
|
@ -1 +0,0 @@
|
|||
Add [room version 12](/rooms/v12) as per [MSC4304](https://github.com/matrix-org/matrix-spec-proposals/pull/4304).
|
||||
|
|
@ -1 +0,0 @@
|
|||
`invite_room_state` and `knock_room_state` now have additional requirements and validation depending on the room version, as per [MSC4311](https://github.com/matrix-org/matrix-spec-proposals/pull/4311).
|
||||
|
|
@ -67,7 +67,7 @@ current_version_url = "https://spec.matrix.org/latest"
|
|||
# The following is used when status = "stable", and is displayed in various UI elements on a released version
|
||||
# of the spec.
|
||||
# major = "1"
|
||||
# minor = "15"
|
||||
# minor = "16"
|
||||
|
||||
# User interface configuration
|
||||
[params.ui]
|
||||
|
|
|
|||
103
content/changelog/v1.16.md
Normal file
103
content/changelog/v1.16.md
Normal file
|
|
@ -0,0 +1,103 @@
|
|||
---
|
||||
title: v1.16 Changelog
|
||||
linkTitle: v1.16
|
||||
type: docs
|
||||
layout: changelog
|
||||
outputs:
|
||||
- html
|
||||
- checklist
|
||||
date: 2025-09-17
|
||||
---
|
||||
|
||||
## Client-Server API
|
||||
|
||||
**Deprecations**
|
||||
|
||||
- Deprecate `m.set_avatar_url` and `m.set_displayname` capabilities, as per [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133). ([#2071](https://github.com/matrix-org/matrix-spec/issues/2071))
|
||||
|
||||
**Removed Endpoints**
|
||||
|
||||
- Remove unintentional intentional mentions in replies, as per [MSC4142](https://github.com/matrix-org/matrix-spec-proposals/pull/4142). ([#2210](https://github.com/matrix-org/matrix-spec/issues/2210))
|
||||
|
||||
**Backwards Compatible Changes**
|
||||
|
||||
- Update user profile endpoints to handle custom fields, and add a new `m.profile_fields` capability, as per [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133). ([#2071](https://github.com/matrix-org/matrix-spec/issues/2071))
|
||||
- Add `format` query parameter to `GET /state/{eventType}/{stateKey}` to allow fetching metadata of a specific state event. ([#2175](https://github.com/matrix-org/matrix-spec/issues/2175))
|
||||
- Add the `use_state_after` query parameter and `state_after` response property to `GET /sync`, as per [MSC4222](https://github.com/matrix-org/matrix-spec-proposals/issues/4222). ([#2187](https://github.com/matrix-org/matrix-spec/issues/2187))
|
||||
- When upgrading rooms to [room version 12](/rooms/v12), `additional_creators` may be specified on the [`POST /_matrix/client/v3/rooms/{roomId}/upgrade`](/client-server-api/#post_matrixclientv3roomsroomidupgrade) endpoint, as per [MSC4289](https://github.com/matrix-org/matrix-spec-proposals/pull/4289). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
|
||||
- When creating rooms with [room version 12](/rooms/v12), the `trusted_private_chat` preset should merge the invitees into the supplied `content.additional_creators` in the resulting room, as per [MSC4289](https://github.com/matrix-org/matrix-spec-proposals/pull/4289). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
|
||||
- In [room version 12](/rooms/v12), the power level of room creators is now infinitely high as per [MSC4289](https://github.com/matrix-org/matrix-spec-proposals/pull/4289). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
|
||||
- In [room version 12](/rooms/v12), room IDs no longer have a domain component as per [MSC4291](https://github.com/matrix-org/matrix-spec-proposals/pull/4291). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
|
||||
- When creating rooms with [room version 12](/rooms/v12), the initial power levels will restrict the ability to upgrade rooms by default, as per [MSC4289](https://github.com/matrix-org/matrix-spec-proposals/pull/4289). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
|
||||
- Add a profile field for a user's time zone, as per [MSC4175](https://github.com/matrix-org/matrix-spec-proposals/pull/4175). ([#2206](https://github.com/matrix-org/matrix-spec/issues/2206))
|
||||
- Invites and knocks are now expected to contain the `m.room.create` event in their stripped state entries, as per [MSC4311](https://github.com/matrix-org/matrix-spec-proposals/pull/4311). ([#2207](https://github.com/matrix-org/matrix-spec/issues/2207))
|
||||
|
||||
**Spec Clarifications**
|
||||
|
||||
- Clarify that `format` is required if `formatted_body` is specified. ([#2167](https://github.com/matrix-org/matrix-spec/issues/2167))
|
||||
- The `latest_event` in an aggregated set of thread events uses the same format as the event itself. ([#2169](https://github.com/matrix-org/matrix-spec/issues/2169))
|
||||
- Fix various typos throughout the specification. ([#2171](https://github.com/matrix-org/matrix-spec/issues/2171), [#2177](https://github.com/matrix-org/matrix-spec/issues/2177), [#2179](https://github.com/matrix-org/matrix-spec/issues/2179))
|
||||
- Clarify that clients should replace events with the most recent replacement by `origin_server_ts`. ([#2190](https://github.com/matrix-org/matrix-spec/issues/2190))
|
||||
- Fix `/sync` flow referencing incorrect parameter to use with `/messages`. ([#2195](https://github.com/matrix-org/matrix-spec/issues/2195))
|
||||
- Clarify wording around the `world_readable` history visibility setting. Contributed by @HarHarLinks. ([#2204](https://github.com/matrix-org/matrix-spec/issues/2204))
|
||||
|
||||
|
||||
## Server-Server API
|
||||
|
||||
**Backwards Compatible Changes**
|
||||
|
||||
- `invite_room_state` and `knock_room_state` now have additional requirements and validation depending on the room version, as per [MSC4311](https://github.com/matrix-org/matrix-spec-proposals/pull/4311). ([#2207](https://github.com/matrix-org/matrix-spec/issues/2207))
|
||||
|
||||
|
||||
## Application Service API
|
||||
|
||||
No significant changes.
|
||||
|
||||
|
||||
## Identity Service API
|
||||
|
||||
No significant changes.
|
||||
|
||||
|
||||
## Push Gateway API
|
||||
|
||||
No significant changes.
|
||||
|
||||
|
||||
## Room Versions
|
||||
|
||||
**Backwards Compatible Changes**
|
||||
|
||||
- Room IDs in room version 12 are now the event ID of the create event with the normal room ID sigil (`!`), as per [MSC4291](https://github.com/matrix-org/matrix-spec-proposals/pull/4291). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
|
||||
- Room creators are formalized in room version 12 and have infinitely high power level, as per [MSC4289](https://github.com/matrix-org/matrix-spec-proposals/pull/4289). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
|
||||
- State Resolution is updated in room version 12 to reduce the opportunity for "state resets", as per [MSC4297](https://github.com/matrix-org/matrix-spec-proposals/pull/4297). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
|
||||
- The default room version is now room version 12, though servers SHOULD keep using room version 11 for a little while, as per [MSC4304](https://github.com/matrix-org/matrix-spec-proposals/pull/4304). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
|
||||
- Add [room version 12](/rooms/v12) as per [MSC4304](https://github.com/matrix-org/matrix-spec-proposals/pull/4304). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193), [#2199](https://github.com/matrix-org/matrix-spec/issues/2199))
|
||||
|
||||
**Spec Clarifications**
|
||||
|
||||
- In room versions 1 through 12, an event's `auth_events` have always needed to belong to the same room as per [MSC4307](https://github.com/matrix-org/matrix-spec-proposals/pull/4307). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
|
||||
|
||||
|
||||
## Appendices
|
||||
|
||||
**Backwards Compatible Changes**
|
||||
|
||||
- Room IDs can now appear without a domain component in [room version 12](/rooms/v12), as per [MSC4291](https://github.com/matrix-org/matrix-spec-proposals/pull/4291). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
|
||||
|
||||
|
||||
## Internal Changes/Tooling
|
||||
|
||||
**Backwards Compatible Changes**
|
||||
|
||||
- Add "placeholder MSC" process definition. ([#2157](https://github.com/matrix-org/matrix-spec/issues/2157))
|
||||
|
||||
**Spec Clarifications**
|
||||
|
||||
- Declare the Application Service Registration schema to follow JSON Schema spec 2020-12. ([#2132](https://github.com/matrix-org/matrix-spec/issues/2132))
|
||||
- Declare the event schemas to follow JSON Schema spec 2020-12. ([#2132](https://github.com/matrix-org/matrix-spec/issues/2132))
|
||||
- Upgrade the docsy theme to version 0.12.0. ([#2160](https://github.com/matrix-org/matrix-spec/issues/2160))
|
||||
- GitHub actions are now building the OpenAPI `spec/identity-service-api/api.json` file. ([#2172](https://github.com/matrix-org/matrix-spec/issues/2172))
|
||||
- Minor fixes to JSON schemas. ([#2182](https://github.com/matrix-org/matrix-spec/issues/2182))
|
||||
- Specify a correct spelling for "display name". ([#2189](https://github.com/matrix-org/matrix-spec/issues/2189))
|
||||
- Fix a grammatical typo on the Matrix Spec Process documentation page. ([#2205](https://github.com/matrix-org/matrix-spec/issues/2205))
|
||||
|
|
@ -93,7 +93,7 @@ Example:
|
|||
```
|
||||
|
||||
`ed25519` and `curve25519` keys are used for [device keys](#device-keys).
|
||||
Additionally, `ed25519` keys are used for [cross-signing keys](#cross-signing).
|
||||
Additionally, `ed25519` keys are keys used for [cross-signing](#cross-signing).
|
||||
|
||||
`signed_curve25519` keys are used for [one-time and fallback keys](#one-time-and-fallback-keys).
|
||||
|
||||
|
|
@ -675,7 +675,7 @@ The process between Alice and Bob verifying each other would be:
|
|||
15. Assuming they match, Alice and Bob's devices each calculate Message
|
||||
Authentication Codes (MACs) for:
|
||||
* Each of the keys that they wish the other user to verify (usually their
|
||||
device ed25519 key and their master cross-signing key).
|
||||
device ed25519 key and their master key, see below).
|
||||
* The complete list of key IDs that they wish the other user to verify.
|
||||
|
||||
The MAC calculation is defined [below](#mac-calculation).
|
||||
|
|
@ -931,16 +931,16 @@ and can be translated online:
|
|||
Rather than requiring Alice to verify each of Bob's devices with each of
|
||||
her own devices and vice versa, the cross-signing feature allows users
|
||||
to sign their device keys such that Alice and Bob only need to verify
|
||||
once. With cross-signing, each user has a set of cross-signing keys that
|
||||
once. With cross-signing, each user has a set of ed25519 key pairs that
|
||||
are used to sign their own device keys and other users' keys, and can be
|
||||
used to trust device keys that were not verified directly.
|
||||
|
||||
Each user has three ed25519 key pairs for cross-signing:
|
||||
Each user has three ed25519 key pairs used for cross-signing:
|
||||
|
||||
- a master key (MSK) that serves as the user's identity in
|
||||
cross-signing and signs their other cross-signing keys;
|
||||
- a master key (MK) that serves as the user's identity in
|
||||
cross-signing and signs their user-signing and self-signing keys;
|
||||
- a user-signing key (USK) -- only visible to the user that it belongs
|
||||
to --that signs other users' master keys; and
|
||||
to -- that signs other users' master keys; and
|
||||
- a self-signing key (SSK) that signs the user's own device keys.
|
||||
|
||||
The master key may also be used to sign other items such as the backup
|
||||
|
|
@ -950,13 +950,15 @@ previously verified Bob's device and Bob's device has signed his master
|
|||
key, then Alice's device can trust Bob's master key, and she can sign it
|
||||
with her user-signing key.
|
||||
|
||||
Users upload their cross-signing keys to the server using [POST
|
||||
Users upload the public part of their master, user-signing and self-signing
|
||||
key to the server using [POST
|
||||
/\_matrix/client/v3/keys/device\_signing/upload](/client-server-api/#post_matrixclientv3keysdevice_signingupload). When Alice uploads
|
||||
new cross-signing keys, her user ID will appear in the `changed`
|
||||
new keys, her user ID will appear in the `changed`
|
||||
property of the `device_lists` field of the `/sync` of response of all
|
||||
users who share an encrypted room with her. When Bob sees Alice's user
|
||||
ID in his `/sync`, he will call [POST /\_matrix/client/v3/keys/query](/client-server-api/#post_matrixclientv3keysquery)
|
||||
to retrieve Alice's device and cross-signing keys.
|
||||
to retrieve Alice's device keys, as well as their master, user-signing and
|
||||
self-signing key.
|
||||
|
||||
If Alice has a device and wishes to send an encrypted message to Bob,
|
||||
she can trust Bob's device if:
|
||||
|
|
@ -971,13 +973,13 @@ The following diagram illustrates how keys are signed:
|
|||
|
||||
```
|
||||
+------------------+ .................. +----------------+
|
||||
| +--------------+ | .................. : | +------------+ |
|
||||
| | v v v : : v v v | |
|
||||
| | +-----------+ : : +-----------+ | |
|
||||
| | | Alice MSK | : : | Bob MSK | | |
|
||||
| | +-----------+ : : +-----------+ | |
|
||||
| | | : : : : | | |
|
||||
| | +--+ :... : : ...: +--+ | |
|
||||
| +--------------+ | ................... : | +------------+ |
|
||||
| | v v v : : v v v | |
|
||||
| | +----------+ : : +----------+ | |
|
||||
| | | Alice MK | : : | Bob MK | | |
|
||||
| | +----------+ : : +----------+ | |
|
||||
| | | : : : : | | |
|
||||
| | +--+ :.... : : ...: +---+ | |
|
||||
| | v v : : v v | |
|
||||
| | +-----------+ ............. : : ............. +-----------+ | |
|
||||
| | | Alice SSK | : Alice USK : : : : Bob USK : | Bob SSK | | |
|
||||
|
|
@ -1004,11 +1006,11 @@ signatures that she cannot see:
|
|||
+------------------+ +----------------+ +----------------+
|
||||
| +--------------+ | | | | +------------+ |
|
||||
| | v v | v v v | |
|
||||
| | +-----------+ | +-----------+ | |
|
||||
| | | Alice MSK | | | Bob MSK | | |
|
||||
| | +-----------+ | +-----------+ | |
|
||||
| | | | | | | |
|
||||
| | +--+ +--+ | +--+ | |
|
||||
| | +----------+ | +----------+ | |
|
||||
| | | Alice MK | | | Bob MK | | |
|
||||
| | +----------+ | +----------+ | |
|
||||
| | | | | | | |
|
||||
| | +--+ +---+ | +---+ | |
|
||||
| | v v | v | |
|
||||
| | +-----------+ +-----------+ | +-----------+ | |
|
||||
| | | Alice SSK | | Alice USK | | | Bob SSK | | |
|
||||
|
|
@ -1024,16 +1026,16 @@ signatures that she cannot see:
|
|||
```
|
||||
|
||||
[Verification methods](#device-verification) can be used to verify a
|
||||
user's master key by using the master public key, encoded using unpadded
|
||||
user's master key by treating the master public key, encoded using unpadded
|
||||
base64, as the device ID, and treating it as a normal device. For
|
||||
example, if Alice and Bob verify each other using SAS, Alice's
|
||||
`m.key.verification.mac` message to Bob may include
|
||||
`"ed25519:alices+master+public+key": "alices+master+public+key"` in the
|
||||
`mac` property. Servers therefore must ensure that device IDs will not
|
||||
collide with cross-signing public keys.
|
||||
collide with public keys used for cross-signing.
|
||||
|
||||
The cross-signing private keys can be stored on the server or shared with other
|
||||
devices using the [Secrets](#secrets) module. When doing so, the master,
|
||||
Using the [Secrets](#secrets) module the private keys used for cross-signing can
|
||||
be stored on the server or shared with other devices. When doing so, the master,
|
||||
user-signing, and self-signing keys are identified using the names
|
||||
`m.cross_signing.master`, `m.cross_signing.user_signing`, and
|
||||
`m.cross_signing.self_signing`, respectively, and the keys are base64-encoded
|
||||
|
|
@ -1052,14 +1054,14 @@ If a user's client sees that any other user has changed their master
|
|||
key, that client must notify the user about the change before allowing
|
||||
communication between the users to continue.
|
||||
|
||||
Since device key IDs (`ed25519:DEVICE_ID`) and cross-signing key IDs
|
||||
(`ed25519:PUBLIC_KEY`) occupy the same namespace, clients must ensure that they
|
||||
use the correct keys when verifying.
|
||||
Since device key IDs (`ed25519:DEVICE_ID`) as well as master, user-signing and
|
||||
self-signing key IDs (`ed25519:PUBLIC_KEY`) occupy the same namespace, clients
|
||||
must ensure that they use the correct keys when verifying.
|
||||
|
||||
While servers MUST not allow devices to have the same IDs as cross-signing
|
||||
keys, a malicious server could construct such a situation, so clients must not
|
||||
rely on the server being well-behaved and should take the following precautions
|
||||
against this.
|
||||
While servers MUST not allow devices to have the same IDs as keys used for
|
||||
cross-signing, a malicious server could construct such a situation, so clients
|
||||
must not rely on the server being well-behaved and should take the following
|
||||
precautions against this:
|
||||
|
||||
1. Clients MUST refer to keys by their public keys during the verification
|
||||
process, rather than only by the key ID.
|
||||
|
|
@ -1067,7 +1069,8 @@ against this.
|
|||
verification process, and ensure that they do not change in the course of
|
||||
verification.
|
||||
3. Clients SHOULD also display a warning and MUST refuse to verify a user when
|
||||
they detect that the user has a device with the same ID as a cross-signing key.
|
||||
they detect that the user has a device with the same ID as a key used for
|
||||
cross-signing.
|
||||
|
||||
A user's user-signing and self-signing keys are intended to be easily
|
||||
replaceable if they are compromised by re-issuing a new key signed by
|
||||
|
|
@ -1104,7 +1107,7 @@ user-signing keys.
|
|||
|
||||
Verifying by QR codes provides a quick way to verify when one of the parties
|
||||
has a device capable of scanning a QR code. The QR code encodes both parties'
|
||||
master signing keys as well as a random shared secret that is used to allow
|
||||
master keys as well as a random shared secret that is used to allow
|
||||
bi-directional verification from a single scan.
|
||||
|
||||
To advertise the ability to show a QR code, clients use the names
|
||||
|
|
@ -1202,15 +1205,14 @@ The binary segment MUST be of the following form:
|
|||
bytes of the ID as a UTF-8 string
|
||||
- the ID encoded as a UTF-8 string
|
||||
- the first key, as 32 bytes. The key to use depends on the mode field:
|
||||
- if `0x00` or `0x01`, then the current user's own master cross-signing public key
|
||||
- if `0x00` or `0x01`, then the current user's own master public key
|
||||
- if `0x02`, then the current device's Ed25519 signing key
|
||||
- the second key, as 32 bytes. The key to use depends on the mode field:
|
||||
- if `0x00`, then what the device thinks the other user's master
|
||||
cross-signing public key is
|
||||
public key is
|
||||
- if `0x01`, then what the device thinks the other device's Ed25519 signing
|
||||
public key is
|
||||
- if `0x02`, then what the device thinks the user's master cross-signing public
|
||||
key is
|
||||
- if `0x02`, then what the device thinks the user's master public key is
|
||||
- a random shared secret, as a sequence of bytes. It is suggested to use a secret
|
||||
that is about 8 bytes long. Note: as we do not share the length of the
|
||||
secret, and it is not a fixed size, clients will just use the remainder of
|
||||
|
|
@ -1221,14 +1223,14 @@ For example, if Alice displays a QR code encoding the following binary data:
|
|||
```
|
||||
"MATRIX" |ver|mode| len | event ID
|
||||
4D 41 54 52 49 58 02 00 00 2D 21 41 42 43 44 ...
|
||||
| user's cross-signing key | other user's cross-signing key | shared secret
|
||||
00 01 02 03 04 05 06 07 ... 10 11 12 13 14 15 16 17 ... 20 21 22 23 24 25 26 27
|
||||
| the first key | the second key | shared secret
|
||||
00 01 02 03 04 05 06 07 ... 10 11 12 13 14 15 16 17 ... 20 21 22 23 24 25 26 27
|
||||
```
|
||||
|
||||
this indicates that Alice is verifying another user (say Bob), in response to
|
||||
the request from event "$ABCD...", her cross-signing key is
|
||||
Mode `0x00` indicates that Alice is verifying another user (say Bob), in
|
||||
response to the request from event "$ABCD...", her master key is
|
||||
`0001020304050607...` (which is "AAECAwQFBg..." in base64), she thinks that
|
||||
Bob's cross-signing key is `1011121314151617...` (which is "EBESExQVFh..." in
|
||||
Bob's master key is `1011121314151617...` (which is "EBESExQVFh..." in
|
||||
base64), and the shared secret is `2021222324252627` (which is "ICEiIyQlJic" in
|
||||
base64).
|
||||
|
||||
|
|
@ -1300,8 +1302,8 @@ one of its variants.
|
|||
Clients must only store keys in backups after they have ensured that the
|
||||
`auth_data` is trusted. This can be done either by:
|
||||
|
||||
- checking that it is signed by the user's [master cross-signing
|
||||
key](#cross-signing) or by a verified device belonging to the same user, or
|
||||
- checking that it is signed by the user's [master key](#cross-signing)
|
||||
or by a verified device belonging to the same user, or
|
||||
- deriving the public key from a private key that it obtained from a trusted
|
||||
source. Trusted sources for the private key include the user entering the
|
||||
key, retrieving the key stored in [secret storage](#secret-storage), or
|
||||
|
|
@ -1786,13 +1788,14 @@ a way to identify the server's support for fallback keys.
|
|||
|
||||
| Parameter | Type | Description |
|
||||
|------------|-----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| changed | [string] | List of users who have updated their device identity or cross-signing keys, or who now share an encrypted room with the client since the previous sync response. |
|
||||
| changed | [string] | List of users who have updated their device identity or their master, self-signing or user-signing keys, or who now share an encrypted room with the client since the previous sync response. |
|
||||
| left | [string] | List of users with whom we do not share any encrypted rooms anymore since the previous sync response. |
|
||||
|
||||
{{% boxes/note %}}
|
||||
For optimal performance, Alice should be added to `changed` in Bob's
|
||||
sync only when she updates her devices or cross-signing keys, or when
|
||||
Alice and Bob now share a room but didn't share any room previously.
|
||||
sync only when she updates her devices or master, self-signing or
|
||||
user-signing keys, or when Alice and Bob now share a room but didn't
|
||||
share any room previously.
|
||||
However, for the sake of simpler logic, a server may add Alice to
|
||||
`changed` when Alice and Bob share a new room, even if they previously
|
||||
already shared a room.
|
||||
|
|
|
|||
|
|
@ -64,11 +64,16 @@ as if it were to be under `m.relates_to` directly instead.
|
|||
|
||||
#### Mentioning the replied to user
|
||||
|
||||
In order to notify users of the reply, it may be desirable to include the `sender`
|
||||
of the replied to event and any users mentioned in that event. See
|
||||
[user and room mentions](#user-and-room-mentions) for additional information.
|
||||
{{% boxes/note %}}
|
||||
{{% changed-in v="1.16" %}}
|
||||
Clients SHOULD no longer propagate mentioned users in the replied to event.
|
||||
{{% /boxes/note %}}
|
||||
|
||||
An example including mentioning the original sender and other users:
|
||||
In order to notify users of the reply, it MAY be desirable to include the `sender`
|
||||
of the replied to event. See [user and room mentions](#user-and-room-mentions) for
|
||||
additional information.
|
||||
|
||||
An example including mentioning the original sender:
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -83,8 +88,6 @@ An example including mentioning the original sender and other users:
|
|||
"user_ids": [
|
||||
// The sender of $another_event.
|
||||
"@alice:example.org",
|
||||
// Another Matrix ID copied from the m.mentions property of $another_event.
|
||||
"@bob:example.org"
|
||||
]
|
||||
}
|
||||
},
|
||||
|
|
|
|||
|
|
@ -21,16 +21,16 @@ paths:
|
|||
x-addedInMatrixVersion: "1.1"
|
||||
x-changedInMatrixVersion:
|
||||
"1.11": UIA is not always required for this endpoint.
|
||||
summary: Upload cross-signing keys.
|
||||
summary: Upload keys used for cross-signing.
|
||||
description: |-
|
||||
Publishes cross-signing keys for the user.
|
||||
Publishes keys used for cross-signing for the user.
|
||||
|
||||
This API endpoint uses the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api).
|
||||
|
||||
User-Interactive Authentication MUST be performed, except in these cases:
|
||||
- there is no existing cross-signing master key uploaded to the homeserver, OR
|
||||
- there is an existing cross-signing master key and it exactly matches the
|
||||
cross-signing master key provided in the request body. If there are any additional
|
||||
- there is no existing master key uploaded to the homeserver, OR
|
||||
- there is an existing master key and it exactly matches the
|
||||
master key provided in the request body. If there are any additional
|
||||
keys provided in the request (self-signing key, user-signing key) they MUST also
|
||||
match the existing keys stored on the server. In other words, the request contains
|
||||
no new keys.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@
|
|||
# limitations under the License.
|
||||
type: object
|
||||
title: CrossSigningKey
|
||||
description: Cross signing key
|
||||
description: Key used for cross signing
|
||||
properties:
|
||||
user_id:
|
||||
type: string
|
||||
|
|
|
|||
|
|
@ -219,7 +219,7 @@ paths:
|
|||
x-addedInMatrixVersion: "1.1"
|
||||
type: object
|
||||
description: |-
|
||||
Information on the master cross-signing keys of the queried users.
|
||||
Information on the master keys of the queried users.
|
||||
A map from user ID, to master key information. For each key, the
|
||||
information returned will be the same as uploaded via
|
||||
`/keys/device_signing/upload`, along with the signatures
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ type: object
|
|||
title: m.signing_key_update
|
||||
description: |-
|
||||
An EDU that lets servers push details to each other when one of their users
|
||||
updates their cross-signing keys.
|
||||
updates their keys used for cross-signing.
|
||||
allOf:
|
||||
- $ref: ../edu.yaml
|
||||
- type: object
|
||||
|
|
@ -34,7 +34,7 @@ allOf:
|
|||
properties:
|
||||
user_id:
|
||||
type: string
|
||||
description: The user ID whose cross-signing keys have changed.
|
||||
description: The user ID whose keys have changed.
|
||||
example: "@alice:example.com"
|
||||
master_key:
|
||||
allOf:
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ paths:
|
|||
- keys
|
||||
master_key:
|
||||
type: object
|
||||
description: The user\'s master cross-signing key.
|
||||
description: The user\'s master key.
|
||||
allOf:
|
||||
- $ref: ../client-server/definitions/cross_signing_key.yaml
|
||||
- example:
|
||||
|
|
|
|||
|
|
@ -194,7 +194,7 @@ paths:
|
|||
x-addedInMatrixVersion: "1.1"
|
||||
type: object
|
||||
description: |-
|
||||
Information on the master cross-signing keys of the queried users.
|
||||
Information on the master keys of the queried users.
|
||||
A map from user ID, to master key information. For each key, the
|
||||
information returned will be the same as uploaded via
|
||||
`/keys/device_signing/upload`, along with the signatures
|
||||
|
|
|
|||
Loading…
Reference in a new issue