From 1be4019a6267a2963cd8a689da310efbefa49998 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Mon, 28 Jun 2021 09:02:19 -0400 Subject: [PATCH] Clarify implications of signing events. --- proposals/3083-restricted-rooms.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/proposals/3083-restricted-rooms.md b/proposals/3083-restricted-rooms.md index a77c36383..bd6b0a7e3 100644 --- a/proposals/3083-restricted-rooms.md +++ b/proposals/3083-restricted-rooms.md @@ -69,7 +69,18 @@ caveat that servers must ensure that: * The user's previous membership was `invite` or `join`, or * The `m.room.member` event with a `membership` of `join` has a valid signature - from a homeserver whose users have the power to issue invites. + from a homeserver whose users have the power to issue invites. This implies + that: + + * A join event issued via `/make_join` & `/send_join` is signed by the not + just the requesting server, but also the resident server. (This seems like + an improvement regardless since the resident server is accepting the event + on behalf of the joining server and ideally this should be verifiable after + the fact, even for current room versions.) + * 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. As normal, the above check is also performed against the current room state during [soft-failure](https://matrix.org/docs/spec/server_server/r0.1.4#soft-failure),