Add `m.federate` into the auth rules (#1103)

* Add section about `m.federate` into the auth rules

* Add changelog entry

* Update changelog, add to room version 10 event auth rules

changelogs/room_versions/newsfragments/1103.clarification

@@ -0,0 +1 @@
+For all room versions: Add `m.federate` to the authorization rules, as originally intended.

content/rooms/fragments/v1-auth-rules.md

@@ -34,11 +34,14 @@ The rules are as follows:
         algorithm described in the server specification.
 3.  If event does not have a `m.room.create` in its `auth_events`,
     reject.
-4.  If type is `m.room.aliases`:
+4.  If the create event content has the field `m.federate` set to `false`
+    and the sender domain of the event does not match the sender domain of
+    the create event, reject.
+5.  If type is `m.room.aliases`:
     1.  If event has no `state_key`, reject.
     2.  If sender's domain doesn't matches `state_key`, reject.
     3.  Otherwise, allow.
-5.  If type is `m.room.member`:
+6.  If type is `m.room.member`:
     1.  If no `state_key` key or `membership` key in `content`, reject.
     2.  If `membership` is `join`:
         1.  If the only previous event is an `m.room.create` and the
@@ -95,15 +98,15 @@ The rules are as follows:
             than the `sender`'s power level, allow.
         3.  Otherwise, reject.
     6.  Otherwise, the membership is unknown. Reject.
-6.  If the `sender`'s current membership state is not `join`, reject.
-7.  If type is `m.room.third_party_invite`:
+7.  If the `sender`'s current membership state is not `join`, reject.
+8.  If type is `m.room.third_party_invite`:
     1.  Allow if and only if `sender`'s current power level is greater
         than or equal to the *invite level*.
-8.  If the event type's *required power level* is greater than the
+9.  If the event type's *required power level* is greater than the
     `sender`'s power level, reject.
-9.  If the event has a `state_key` that starts with an `@` and does not
+10. If the event has a `state_key` that starts with an `@` and does not
     match the `sender`, reject.
-10. If type is `m.room.power_levels`:
+11. If type is `m.room.power_levels`:
     1.  If `users` key in `content` is not a dictionary with keys that
         are valid user IDs with values that are integers (or a string
         that is an integer), reject.
@@ -127,14 +130,14 @@ The rules are as follows:
         1.  If the current value is equal to the `sender`'s current
             power level, reject.
     6.  Otherwise, allow.
-11. If type is `m.room.redaction`:
+12. If type is `m.room.redaction`:
     1.  If the `sender`'s power level is greater than or equal to the
         *redact level*, allow.
     2.  If the domain of the `event_id` of the event being redacted is
         the same as the domain of the `event_id` of the
         `m.room.redaction`, allow.
     3.  Otherwise, reject.
-12. Otherwise, allow.
+13. Otherwise, allow.
 
 {{% boxes/note %}}
 Some consequences of these rules:

content/rooms/fragments/v3-auth-rules.md

@@ -41,11 +41,14 @@ The complete list of rules, as of room version 3, is as follows:
         algorithm described in the server specification.
 3.  If event does not have a `m.room.create` in its `auth_events`,
     reject.
-4.  If type is `m.room.aliases`:
+4.  If the create event content has the field `m.federate` set to `false`
+    and the sender domain of the event does not match the sender domain of
+    the create event, reject.
+5.  If type is `m.room.aliases`:
     1.  If event has no `state_key`, reject.
     2.  If sender's domain doesn't matches `state_key`, reject.
     3.  Otherwise, allow.
-5.  If type is `m.room.member`:
+6.  If type is `m.room.member`:
     1.  If no `state_key` key or `membership` key in `content`, reject.
     2.  If `membership` is `join`:
         1.  If the only previous event is an `m.room.create` and the
@@ -102,15 +105,15 @@ The complete list of rules, as of room version 3, is as follows:
             than the `sender`'s power level, allow.
         3.  Otherwise, reject.
     6.  Otherwise, the membership is unknown. Reject.
-6.  If the `sender`'s current membership state is not `join`, reject.
-7.  If type is `m.room.third_party_invite`:
+7.  If the `sender`'s current membership state is not `join`, reject.
+8.  If type is `m.room.third_party_invite`:
     1.  Allow if and only if `sender`'s current power level is greater
         than or equal to the *invite level*.
-8.  If the event type's *required power level* is greater than the
+9.  If the event type's *required power level* is greater than the
     `sender`'s power level, reject.
-9.  If the event has a `state_key` that starts with an `@` and does not
+10.  If the event has a `state_key` that starts with an `@` and does not
     match the `sender`, reject.
-10. If type is `m.room.power_levels`:
+11. If type is `m.room.power_levels`:
     1.  If `users` key in `content` is not a dictionary with keys that
         are valid user IDs with values that are integers (or a string
         that is an integer), reject.
@@ -134,7 +137,7 @@ The complete list of rules, as of room version 3, is as follows:
         1.  If the current value is equal to the `sender`'s current
             power level, reject.
     6.  Otherwise, allow.
-11. Otherwise, allow.
+12. Otherwise, allow.
 
 {{% boxes/note %}}
 Some consequences of these rules:

content/rooms/fragments/v8-auth-rules.md

@@ -42,7 +42,10 @@ The rules are as follows:
         algorithm described in the server specification.
 3.  If event does not have a `m.room.create` in its `auth_events`,
     reject.
-4.  If type is `m.room.member`:
+4.  If the create event content has the field `m.federate` set to `false`
+    and the sender domain of the event does not match the sender domain of
+    the create event, reject.
+5.  If type is `m.room.member`:
     1.  If no `state_key` key or `membership` key in `content`, reject.
     2.  If `content` has a `join_authorised_via_users_server`
         key:
@@ -116,15 +119,15 @@ The rules are as follows:
             or `join`, allow.
         4.  Otherwise, reject.
     8.  Otherwise, the membership is unknown. Reject.
-5.  If the `sender`'s current membership state is not `join`, reject.
-6.  If type is `m.room.third_party_invite`:
+6.  If the `sender`'s current membership state is not `join`, reject.
+7.  If type is `m.room.third_party_invite`:
     1.  Allow if and only if `sender`'s current power level is greater
         than or equal to the *invite level*.
-7.  If the event type's *required power level* is greater than the
+8.  If the event type's *required power level* is greater than the
     `sender`'s power level, reject.
-8.  If the event has a `state_key` that starts with an `@` and does not
+9.  If the event has a `state_key` that starts with an `@` and does not
     match the `sender`, reject.
-9. If type is `m.room.power_levels`:
+10. If type is `m.room.power_levels`:
     1.  If `users` key in `content` is not a dictionary with keys that
         are valid user IDs with values that are integers (or a string
         that is an integer), reject.
@@ -148,7 +151,7 @@ The rules are as follows:
         1.  If the current value is equal to the `sender`'s current
             power level, reject.
     6.  Otherwise, allow.
-10. Otherwise, allow.
+11. Otherwise, allow.
 
 {{% boxes/note %}}
 Some consequences of these rules:
@@ -159,4 +162,4 @@ Some consequences of these rules:
 -   To unban somebody, you must have power level greater than or equal
     to both the kick *and* ban levels, *and* greater than the target
     user's power level.
-{{% /boxes/note %}}
+{{% /boxes/note %}}

content/rooms/v10.md

@@ -114,7 +114,10 @@ The rules are as follows:
         algorithm described in the server specification.
 3.  If event does not have a `m.room.create` in its `auth_events`,
     reject.
-4.  If type is `m.room.member`:
+4.  If the create event content has the field `m.federate` set to `false`
+    and the sender domain of the event does not match the sender domain of
+    the create event, reject.
+5.  If type is `m.room.member`:
     1.  If no `state_key` key or `membership` key in `content`, reject.
     2.  If `content` has a `join_authorised_via_users_server`
         key:
@@ -191,15 +194,15 @@ The rules are as follows:
             or `join`, allow.
         4.  Otherwise, reject.
     8.  Otherwise, the membership is unknown. Reject.
-5.  If the `sender`'s current membership state is not `join`, reject.
-6.  If type is `m.room.third_party_invite`:
+6.  If the `sender`'s current membership state is not `join`, reject.
+7.  If type is `m.room.third_party_invite`:
     1.  Allow if and only if `sender`'s current power level is greater
         than or equal to the *invite level*.
-7.  If the event type's *required power level* is greater than the
+8.  If the event type's *required power level* is greater than the
     `sender`'s power level, reject.
-8.  If the event has a `state_key` that starts with an `@` and does not
+9.  If the event has a `state_key` that starts with an `@` and does not
     match the `sender`, reject.
-9. If type is `m.room.power_levels`:
+10. If type is `m.room.power_levels`:
     1.  {{< added-in this="true" >}}
         If any of the keys `users_default`, `events_default`, `state_default`,
         `ban`, `redact`, `kick`, or `invite` in `content` are present and
@@ -230,7 +233,7 @@ The rules are as follows:
         1.  If the current value is equal to the `sender`'s current
             power level, reject.
     6.  Otherwise, allow.
-10. Otherwise, allow.
+11. Otherwise, allow.
 
 {{% boxes/note %}}
 Some consequences of these rules: