Compare commits

...

5 commits

Author SHA1 Message Date
Kévin Commaille ae79ea7abc
Merge 2fca4789ca into bb3daafe96 2026-02-16 16:34:37 +00:00
Kévin Commaille bb3daafe96
Spec User suspension & locking endpoints (#2278)
Some checks failed
Spec / 🔎 Validate OpenAPI specifications (push) Has been cancelled
Spec / 🔎 Check Event schema examples (push) Has been cancelled
Spec / 🔎 Check OpenAPI definitions examples (push) Has been cancelled
Spec / 🔎 Check JSON Schemas inline examples (push) Has been cancelled
Spec / ⚙️ Calculate baseURL for later jobs (push) Has been cancelled
Spec / 📢 Run towncrier for changelog (push) Has been cancelled
Spell Check / Spell Check with Typos (push) Has been cancelled
Spec / 🐍 Build OpenAPI definitions (push) Has been cancelled
Spec / 📖 Build the spec (push) Has been cancelled
Spec / 🔎 Validate generated HTML (push) Has been cancelled
Spec / 📖 Build the historical backup spec (push) Has been cancelled
Spec / Create release (push) Has been cancelled
2026-02-16 13:08:04 +00:00
Kévin Commaille 2fca4789ca
Apply suggestions
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
2026-01-27 18:05:46 +01:00
Kévin Commaille 3ff21c357d
Add changelog
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
2026-01-27 11:59:53 +01:00
Kévin Commaille d6716305b1
Spec for MSC4153: Exclude non-cross-signed devices
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
2026-01-27 11:57:17 +01:00
10 changed files with 525 additions and 13 deletions

View file

@ -0,0 +1 @@
Add administrator endpoints to lock and suspend server-local users and add the `m.account_management` capability, as per [MSC4323](https://github.com/matrix-org/matrix-spec-proposals/pull/4323).

View file

@ -0,0 +1 @@
Add `GET /_matrix/client/v1/admin/suspend/{userId}`, as per [MSC4323](https://github.com/matrix-org/matrix-spec-proposals/pull/4323).

View file

@ -0,0 +1 @@
Add `PUT /_matrix/client/v1/admin/suspend/{userId}`, as per [MSC4323](https://github.com/matrix-org/matrix-spec-proposals/pull/4323).

View file

@ -0,0 +1 @@
Add `GET /_matrix/client/v1/admin/lock/{userId}`, as per [MSC4323](https://github.com/matrix-org/matrix-spec-proposals/pull/4323).

View file

@ -0,0 +1 @@
Add `PUT /_matrix/client/v1/admin/lock/{userId}`, as per [MSC4323](https://github.com/matrix-org/matrix-spec-proposals/pull/4323).

View file

@ -0,0 +1 @@
Add recommendation about excluding non-cross-signed devices from encrypted conversations, as per [MSC4153](https://github.com/matrix-org/matrix-spec-proposals/pull/4153).

View file

@ -2394,9 +2394,12 @@ where feasible. The Matrix-specific actions are:
Server administrators may apply locks to prevent users from usefully
using their accounts, for instance, due to safety or security concerns.
In contrast to account deactivation, locking is a non-destructive action
that can be reversed. This specification describes the behaviour of clients
and servers when an account is locked. It deliberately leaves the methods
for locking and unlocking accounts as a server implementation detail.
that can be reversed.
{{% added-in v="1.18" %}} To lock or unlock an account, administrators
SHOULD use the [`PUT /admin/lock/{userId}`](#put_matrixclientv1adminlockuserid)
endpoint. They MAY also use [`GET /admin/lock/{userId}`](#get_matrixclientv1adminlockuserid)
to check whether a user's account is locked.
When an account is locked, servers MUST return a `401 Unauthorized` error
response with an `M_USER_LOCKED` error code and [`soft_logout`](#soft-logout)
@ -2445,6 +2448,11 @@ from that account. The effect is similar to [locking](#account-locking), though
without risk of the client losing state from a logout. Suspensions are reversible,
like locks and unlike deactivations.
{{% added-in v="1.18" %}} To suspend or unsuspend an account, administrators
SHOULD use the [`PUT /admin/suspend/{userId}`](#put_matrixclientv1adminsuspenduserid)
endpoint. They MAY also use [`GET /admin/suspend/{userId}`](#get_matrixclientv1adminsuspenduserid)
to check whether a user's account is suspended.
The actions a user can perform while suspended is deliberately left as an
implementation detail. Servers SHOULD permit the user to perform at least the
following, however:
@ -2500,9 +2508,6 @@ Content-Type: application/json
}
```
APIs for initiating suspension or unsuspension are not included in this version
of the specification, and left as an implementation detail.
### Adding Account Administrative Contact Information
A homeserver may keep some contact information for administrative use.

View file

@ -5,6 +5,91 @@ Matrix optionally supports end-to-end encryption, allowing rooms to be
created whose conversation contents are not decryptable or interceptable
on any of the participating homeservers.
#### Recommended client behaviour
{{% added-in v="1.18" %}}
While clients are able to choose what encryption features they implement based
on their threat model, this section recommends behaviours that will improve the
overall user experience and security of encrypted conversations.
While a user may be unable to [verify](#device-verification) every other user
that they communicate with, or may be unaware of the need to verify other users,
[cross-signing](#cross-signing) gives some measure of protection and so SHOULD
be used where possible. In particular, clients SHOULD implement the following
recommendations.
* Clients SHOULD create new [cross-signing keys](#cross-signing) for users who
do not yet have cross-signing keys.
* Clients SHOULD encourage users to set up their [Secret Storage](#storage) to
avoid needing to reset their cryptographic identity in case the user does not
have an existing device that can [share the secrets](#sharing) with the new
device. The user's Secret Storage SHOULD contain the user's cross-signing
private keys and the [key backup](#server-side-key-backups) decryption key
(if the user is using key backup). The user's Secret Storage SHOULD have a
[default key](#key-storage) (a key referred to by
`m.secret_storage.default_key`) that encrypts the private cross-signing keys
and key backup decryption key (if available).
* Clients SHOULD encourage users to [cross-sign](#cross-signing) their devices.
This includes both when logging in a new device, and for existing devices.
Clients MAY even go so far as to require cross-signing of devices by
preventing the user from using the client until the device is cross-signed.
If the user cannot cross-sign their device (for example, if they have
forgotten their Secret Storage key), the client can allow users to reset their
[Secret Storage](#storage), cross-signing keys, and [key backup](#server-side-key-backups).
* When Alice [verifies](#device-verification) Bob, the verification SHOULD
verify their [cross-signing keys](#cross-signing). Any flow between different
users that does not verify the users' cross-signing keys (it verifies only the
device keys) is deprecated.
* Clients SHOULD flag when [cross-signing keys](#cross-signing) change. If
Alice's cross-signing keys change, Alice's own devices MUST alert her to this
fact, and prompt her to re-cross-sign those devices. If Bob is in an
encrypted room with Alice, Bob's devices SHOULD inform him of Alice's key
change and SHOULD prevent him from sending an encrypted message to Alice
without acknowledging the change. Bob's clients may behave differently
depending on whether Bob had previously [verified](#device-verification)
Alice or not. For example, if Bob had previously verified Alice, and Alice's
keys change, Bob's client may require Bob to re-verify, or may display a more
aggressive warning.
* Clients SHOULD NOT send encrypted [to-device](#send-to-device-messaging)
messages, such as [room keys](#sharing-keys-between-devices) or [secrets](#secrets)
(via [Secret Sharing](#sharing)), to [non-cross-signed](#cross-signing)
devices by default. Non-cross-signed devices don't provide any assurance that
the device belongs to the user, and server admins can trivially create new
devices for users. When sending room keys, clients can use a
[`m.room_key.withheld`](#mroom_keywithheld) message with a code of
`m.unverified` to indicate to the non-cross-signed device why it is not
receiving the room key.
Note that clients cannot selectively send room events only to cross-signed
devices. The only way to exclude non-cross-signed devices from encrypted
conversations is to not send the room keys so those devices won't be able to
decrypt the messages.
* Similarly, messages sent from [non-cross-signed](#cross-signing) devices
cannot be trusted and SHOULD NOT be displayed to the user. Clients have no
assurance that encrypted messages sent from non-cross-signed devices were sent
by the user, rather than an impersonator.
* Matrix clients MUST NOT consider non-cryptographic devices (devices which do
not have [device identity keys](#device-keys) uploaded to the homeserver) to
be equivalent to [non-cross-signed](#cross-signing) cryptographic devices for
purposes of enforcing E2EE policy. For example, clients SHOULD NOT warn nor
refuse to send messages due to the presence of non-cryptographic devices. For
all intents and purposes, non-cryptographic devices are a completely separate
concept and do not exist from the perspective of the cryptography layer since
they do not have identity keys, so it is impossible to send them decryption
keys.
* Clients MAY make provisions for encrypted bridges. Some bridges are structured
in a way such that only one user controlled by the bridge (often called the
bridge bot) participates in encryption, and encrypted messages from other
bridge users are encrypted by the bridge bot. Thus encrypted messages sent by
one user could be encrypted by a [Megolm](#mmegolmv1aes-sha2) session sent by
a different user. Clients MAY accept such messages, provided the session
creator's device is [cross-signed](#cross-signing). However, the client MUST
annotate the message with a warning, unless the client has a way to check that
the bridge bot is permitted to encrypt messages on behalf of the user. Future
MSCs such as [MSC4350](https://github.com/matrix-org/matrix-spec-proposals/pull/4350)
may provide a secure way to allow such impersonation.
#### Key Distribution
Encryption and Authentication in Matrix is based around public-key
@ -674,8 +759,11 @@ The process between Alice and Bob verifying each other would be:
their devices if they match or not.
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).
* {{% changed-in v="1.18" %}} Each of the keys that they wish the other user
to verify (usually their device ed25519 key and their master cross-signing
key). The master cross-signing key SHOULD be included when two different
users are verifying each other. Verifying individual devices of other
users is deprecated.
* The complete list of key IDs that they wish the other user to verify.
The MAC calculation is defined [below](#mac-calculation).

View file

@ -16,7 +16,7 @@ info:
title: Matrix Client-Server Administration API
version: 1.0.0
paths:
"/admin/whois/{userId}":
"/v3/admin/whois/{userId}":
get:
summary: Gets information about a particular user.
description: |-
@ -107,6 +107,391 @@ paths:
}
tags:
- Server administration
"/v1/admin/suspend/{userId}":
get:
summary: Gets information about the suspended status of a particular user.
x-addedInMatrixVersion: "1.18"
description: |-
Gets information about the suspended status of a particular server-local user.
The user calling this endpoint MUST be a server admin.
In order to prevent user enumeration, servers MUST ensure that authorization is checked
prior to trying to do account lookups.
operationId: getAdminSuspendUser
security:
- accessTokenQuery: []
- accessTokenBearer: []
parameters:
- in: path
name: userId
description: The user to look up.
required: true
example: "@peter:rabbit.rocks"
schema:
type: string
format: mx-user-id
pattern: "^@"
responses:
"200":
description: The lookup was successful.
content:
application/json:
schema:
type: object
properties:
suspended:
type: boolean
description: Whether the target account is suspended.
example: true
required:
- suspended
examples:
response:
value: {
"suspended": true,
}
"400":
description: |-
The user ID does not belong to the local server. The errcode is `M_INVALID_PARAM`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_INVALID_PARAM",
"error": "User does not belong to the local server."
}
"403":
description: |-
The requesting user is not a server administrator, or the target user is another
administrator. The errcode is `M_FORBIDDEN`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_FORBIDDEN",
"error": "Requesting user is not a server administrator."
}
"404":
description: |-
The user ID is not found, or is deactivated. The errcode is `M_NOT_FOUND`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_NOT_FOUND",
"error": "User not found."
}
tags:
- Server administration
put:
summary: Set the suspended status of a particular user.
x-addedInMatrixVersion: "1.18"
description: |-
Sets the suspended status of a particular server-local user.
The user calling this endpoint MUST be a server admin. The client SHOULD check that the user
is allowed to suspend other users at the [`GET /capabilities`](/client-server-api/#get_matrixclientv3capabilities)
endpoint prior to using this endpoint.
In order to prevent user enumeration, servers MUST ensure that authorization is checked
prior to trying to do account lookups.
operationId: setAdminSuspendUser
security:
- accessTokenQuery: []
- accessTokenBearer: []
parameters:
- in: path
name: userId
description: The user to change the suspended status of.
required: true
example: "@peter:rabbit.rocks"
schema:
type: string
format: mx-user-id
pattern: "^@"
requestBody:
content:
application/json:
schema:
type: object
properties:
suspended:
type: boolean
description: Whether to suspend the target account.
example: true
required:
- suspended
examples:
request:
value: {
"suspended": true,
}
required: true
responses:
"200":
description: The action was successful.
content:
application/json:
schema:
type: object
properties:
suspended:
type: boolean
description: Whether the target account is suspended.
example: true
required:
- suspended
examples:
response:
value: {
"suspended": true,
}
"400":
description: |-
The user ID does not belong to the local server. The errcode is `M_INVALID_PARAM`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_INVALID_PARAM",
"error": "User does not belong to the local server."
}
"403":
description: |-
The requesting user is not a server administrator, is trying to suspend their own
account, or the target user is another administrator. The errcode is `M_FORBIDDEN`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_FORBIDDEN",
"error": "Requesting user is not a server administrator."
}
"404":
description: |-
The user ID is not found, or is deactivated. The errcode is `M_NOT_FOUND`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_NOT_FOUND",
"error": "User not found."
}
tags:
- Server administration
"/v1/admin/lock/{userId}":
get:
summary: Gets information about the locked status of a particular user.
x-addedInMatrixVersion: "1.18"
description: |-
Gets information about the locked status of a particular server-local user.
The user calling this endpoint MUST be a server admin.
In order to prevent user enumeration, servers MUST ensure that authorization is checked
prior to trying to do account lookups.
operationId: getAdminLockUser
security:
- accessTokenQuery: []
- accessTokenBearer: []
parameters:
- in: path
name: userId
description: The user to look up.
required: true
example: "@peter:rabbit.rocks"
schema:
type: string
format: mx-user-id
pattern: "^@"
responses:
"200":
description: The lookup was successful.
content:
application/json:
schema:
type: object
properties:
locked:
type: boolean
description: Whether the target account is locked.
required:
- locked
examples:
response:
value: {
"locked": true,
}
"400":
description: |-
The user ID does not belong to the local server. The errcode is `M_INVALID_PARAM`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_INVALID_PARAM",
"error": "User does not belong to the local server."
}
"403":
description: |-
The requesting user is not a server administrator, or the target user is another
administrator. The errcode is `M_FORBIDDEN`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_FORBIDDEN",
"error": "Requesting user is not a server administrator."
}
"404":
description: |-
The user ID is not found, or is deactivated. The errcode is `M_NOT_FOUND`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_NOT_FOUND",
"error": "User not found."
}
tags:
- Server administration
put:
summary: Set the locked status of a particular user.
x-addedInMatrixVersion: "1.18"
description: |-
Sets the locked status of a particular server-local user.
The user calling this endpoint MUST be a server admin. The client SHOULD check that the user
is allowed to lock other users at the [`GET /capabilities`](/client-server-api/#get_matrixclientv3capabilities)
endpoint prior to using this endpoint.
In order to prevent user enumeration, servers MUST ensure that authorization is checked
prior to trying to do account lookups.
operationId: setAdminLockUser
security:
- accessTokenQuery: []
- accessTokenBearer: []
parameters:
- in: path
name: userId
description: The user to change the locked status of.
required: true
example: "@peter:rabbit.rocks"
schema:
type: string
format: mx-user-id
pattern: "^@"
requestBody:
content:
application/json:
schema:
type: object
properties:
locked:
type: boolean
description: Whether to lock the target account.
example: true
required:
- locked
examples:
request:
value: {
"locked": true,
}
required: true
responses:
"200":
description: The action was successful.
content:
application/json:
schema:
type: object
properties:
locked:
type: boolean
description: Whether the target account is locked.
example: true
required:
- locked
examples:
response:
value: {
"locked": true,
}
"400":
description: |-
The user ID does not belong to the local server. The errcode is `M_INVALID_PARAM`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_INVALID_PARAM",
"error": "User does not belong to the local server."
}
"403":
description: |-
The requesting user is not a server administrator, is trying to lock their own
account, or the target user is another administrator. The errcode is `M_FORBIDDEN`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_FORBIDDEN",
"error": "Requesting user is not a server administrator."
}
"404":
description: |-
The user ID is not found, or is deactivated. The errcode is `M_NOT_FOUND`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_NOT_FOUND",
"error": "User not found."
}
tags:
- Server administration
servers:
- url: "{protocol}://{hostname}{basePath}"
variables:
@ -118,7 +503,7 @@ servers:
hostname:
default: localhost:8008
basePath:
default: /_matrix/client/v3
default: /_matrix/client
components:
securitySchemes:
accessTokenQuery:

View file

@ -84,7 +84,7 @@ paths:
description: |
**Deprecated:** Capability to indicate if the user can change their display name.
Refer to `m.profile_fields` for extended profile management.
For backwards compatibility, servers that directly or indirectly include the
`displayname` profile field in the `m.profile_fields` capability MUST also
set this capability accordingly.
@ -121,7 +121,7 @@ paths:
description: |
If present, a list of profile fields that clients are allowed to create, modify or delete,
provided `enabled` is `true`; no other profile fields may be changed.
If absent, clients may set all profile fields except those forbidden by the `disallowed`
list, where present.
items:
@ -133,7 +133,7 @@ paths:
type: array
description: |
This property has no meaning if `allowed` is also specified.
Otherwise, if present, a list of profile fields that clients are _not_ allowed to create, modify or delete.
Provided `enabled` is `true`, clients MAY assume that they can set any profile field which is not
included in this list.
@ -147,6 +147,34 @@ paths:
example: true
required:
- enabled
m.account_moderation:
x-addedInMatrixVersion: "1.18"
type: object
title: AccountModerationCapability
description: |-
Capability to indicate if the user can perform account moderation actions
via [server administration](/client-server-api/#server-administration)
endpoints.
This property should be omitted altogether if `suspend` and `lock` would
be `false`.
properties:
suspend:
type: boolean
description: |-
`true` if the user can suspend a user via [`PUT /admin/suspend/{userId}`](/client-server-api/#put_matrixclientv1adminsuspenduserid),
`false` otherwise.
Defaults to `false`.
example: true
lock:
type: boolean
description: |-
`true` if the user can lock a user via [`PUT /admin/lock/{userId}`](/client-server-api/#put_matrixclientv1adminlockuserid),
`false` otherwise.
Defaults to `false`.
example: true
examples:
response:
value: {