wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Review feedback.

Browse source
This commit is contained in:
Patrick Cloke 2021-07-20 13:23:17 -04:00 • committed by Richard van der Hoff
parent 27bee1bad8
commit 67e558da52
1 changed files with 40 additions and 34 deletions
Download patch file Download diff file Expand all files Collapse all files

74
proposals/3083-restricted-rooms.md
View file

@ -63,6 +63,46 @@ if the user is invited to this room, or is joined to one of the listed rooms. If
the user is not a member of at least one of the rooms, the homeserver should return the user is not a member of at least one of the rooms, the homeserver should return
an error response with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`. an error response with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`.
From the perspective of the [auth rules](https://spec.matrix.org/unstable/rooms/v1/#authorization-rules),
the `restricted` join rule has the same behavior as `public`, with the additional
caveat that servers must ensure that:
* The user's previous membership was `invite` or `join`, or
* The join event has a valid signature from a homeserver whose users have the
power to issue invites.
When generating a join event the server should include the MXID of a local user
who could issue an invite in the content with the key
`join_authorised_via_users_server`. The actual user chosen is arbitrary.
This implies that:
* A join event issued via `/send_join` is signed by not just the requesting
server, but also the resident server.<sup id="a3">[3](#f3)</sup>
In order for the joining server to receive the proper signatures the join
event will be returned via `/send_join` in the `event` field.
* The auth chain of the join event needs to include events which prove
the homeserver can be issuing the join. This can be done by including:
* The `m.room.power_levels` event
* The `m.room.member` event (with `membership` equal to `join`) the user
specified in `join_authorised_via_users_server`.
It should be confirmed that the authorising user is in the room. (This
prevents situations where any homeserver could process the join, even if
they weren't in the room, under certain power level conditions.)
This creates a new restriction on the relationship between the resident
servers used for `/make_join` and `/send_join` -- they must now both go to
the same server (since the `join_authorised_via_users_server` is added in
the call to `/make_join`, while the final signature is added during
the call to `/send_join`).
Note that the homeservers whose users can issue invites are trusted to confirm
that the `allow` rules were properly checked (since this cannot easily be
enforced over federation by event authorisation).<sup id="a4">[4](#f4)</sup>
It is possible for a resident homeserver (one which receives a `/make_join` / It is possible for a resident homeserver (one which receives a `/make_join` /
`/send_join` request) to not know if the user is in some of the allowed rooms (due `/send_join` request) to not know if the user is in some of the allowed rooms (due
to not participating in them). If the user is not in any of the allowed rooms that to not participating in them). If the user is not in any of the allowed rooms that
@ -79,40 +119,6 @@ it should return an error response with HTTP status code of 400 and an `errcode`
of `M_CANNOT_ALLOW`. The joining server should attempt to join via another of `M_CANNOT_ALLOW`. The joining server should attempt to join via another
resident homeserver. resident homeserver.
From the perspective of the [auth rules](https://spec.matrix.org/unstable/rooms/v1/#authorization-rules),
the `restricted` join rule has the same behavior as `public`, with the additional
caveat that servers must ensure that:
* The user's previous membership was `invite` or `join`, or
* The join event has a valid signature
from a homeserver whose users have the power to issue invites. This implies
that:
* A join event issued via `/send_join` is signed by not just the requesting
server, but also the resident server.<sup id="a3">[3](#f3)</sup>
In order for the joining server to receive the proper signatures the join
event will be returned via `/send_join` in the `event` field.
* The auth chain of the join event needs to include an event which proves
the homeserver can be issuing the join. This can be done by including the
`m.room.power_levels` event and an `m.room.member` event with `membership`
equal to `join` for a member who could issue invites from that server.
In order to find a corresponding event quickly for verification, the
content of the join event should include the chosen user's MXID in the
content with the key `join_authorised_via_users_server`. The actual user
chosen is arbitrary.
This creates a new restriction on the relationship between the resident
servers used for `/make_join` and `/send_join` -- they must now both go to
the same server (since the `join_authorised_via_users_server` is added in
the call to `/make_join`, while the final signature is added during
the call to `/send_join`).
Note that the homeservers whose users can issue invites are trusted to confirm
that the `allow` rules were properly checked (since this cannot easily be
enforced over federation by event authorisation).<sup id="a4">[4](#f4)</sup>
To better cope with joining via aliases, homeservers should use the list of To better cope with joining via aliases, homeservers should use the list of
authorised servers (not the list of candidate servers) when a user attempts to authorised servers (not the list of candidate servers) when a user attempts to
join a room. join a room.