Compare commits

..

No commits in common. "b1fd2af72cd41f79a89fe6ff1fffc5a3f21be402" and "a2027a398541552b31572c948e7b6bdd2a802adf" have entirely different histories.

4 changed files with 1 additions and 5 deletions

View file

@ -1 +0,0 @@
Clarify that servers may choose not to use `M_USER_DEACTIVATED` at login time, for example for privacy reasons when they can't authenticate deactivated users.

View file

@ -1 +0,0 @@
Minor grammatical fix in the Secrets module description.

View file

@ -59,7 +59,7 @@ clients will try to use the default key to decrypt secrets.
Clients that want to present a simplified interface to users by not supporting Clients that want to present a simplified interface to users by not supporting
multiple keys should use the default key if one is specified. If no default multiple keys should use the default key if one is specified. If no default
key is specified, the client may behave as if no key is present at key is specified, the client may behave as if there is no key is present at
all. When such a client creates a key, it should mark that key as being the all. When such a client creates a key, it should mark that key as being the
default key. default key.

View file

@ -262,8 +262,6 @@ paths:
or the requested device ID is the same as a cross-signing key or the requested device ID is the same as a cross-signing key
ID. ID.
* `M_USER_DEACTIVATED`: The user has been deactivated. * `M_USER_DEACTIVATED`: The user has been deactivated.
Servers MAY instead use `M_FORBIDDEN` when they can no longer authenticate
the deactivated user (e.g. their password has been wiped).
content: content:
application/json: application/json:
schema: schema: