MSC2212: Third party user power levels #2212
Conversation
turt2live
changed the title
turt2live
added
the
unassigned-room-version
|
This is a prerequisite for Canonical DMs and hasn't received a lot of traffic. We intend to make Canonical DMs a thing very soon, so in the interest of moving the ball forward: @mscbot fcp merge |
|
This FCP proposal has been cancelled by #2212 (comment). Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people: Concerns:
Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for information about what commands tagged team members can give me. |
mscbot
added
proposed-final-comment-period
| stripped except for `key_validity_url` and `public_key`. | ||
| 2. Redacting a `m.room.member` event must additionally preserve `third_party_invite` under | ||
| `content`. All fields are stripped from the `third_party_invite` object with the exception | ||
| of `signed`, which additionally has all fields stripped with the exception of `mxid`, |
There was a problem hiding this comment.
Won't stripping the fields out of signed cause the signature in signatures to be invalid? Looking at the synapse code, it looks like it is verifying the signature on the whole object, not just the mxid and token fields.
(As an aside, the spec for the signed field in m.room.member seems a bit confusing, since I think it should be referring to the Signing JSON section, rather than Signing Events )
There was a problem hiding this comment.
It's not stripped? signed contains signatures, which are both preserved by this sentence.
There was a problem hiding this comment.
If you strip all fields other than mxid, signatures, and token, then the signature will no longer be valid, since the signature covers all fields under signed, and not just mxid and token. E.g., if someone sends a m.room.member event with the fields mxid, signatures, token, and foo, then if you strip out foo, then the signature will no longer be valid. So you need to retain the entirety of signed. (From an abuse mitigation standpoint, I don't think that this should be much of an issue since clients don't display the contents of signed.)
There was a problem hiding this comment.
right, that's irritating. We should probably ensure things that make sense only get signed and not random keys, however making that rule future proof is difficult :(
| # Third party user power levels | ||
|
|
||
| This MSC is a requirement for [MSC2199](https://github.com/matrix-org/matrix-doc/pull/2199) | ||
| to work in Matrix. It serves little value outside of MSC2199 due to the ability of users |
There was a problem hiding this comment.
It does allow for users who were invited via a third-party ID to claim their power level immediately rather than waiting for someone else to promote them.
|
Since this is the only issue I have with the proposal and the rest looks fine, I'll check my box and log a concern. @mscbot concern redacting things from |
| The new field has auth rules very similar to `users`: | ||
| 1. Taking place immediately after 10a (requiring `users` to be a specific shape): If the | ||
| `third_party_users` in `content` is not a dictionary with keys that are known tokens | ||
| for `m.room.third_party_invite` events in current room state with values that are |
There was a problem hiding this comment.
Hum. For state resolution, I think we need to be able to auth PL events without reference to the rest of the room state. @erikjohnston might be able to correct me on this?
We can probably just remove that restriction?
| 1. Taking place immediately after 10a (requiring `users` to be a specific shape): If the | ||
| `third_party_users` in `content` is not a dictionary with keys that are known tokens | ||
| for `m.room.third_party_invite` events in current room state with values that are | ||
| integers (or a string that is an integer), reject. |
There was a problem hiding this comment.
because the auth rules already do
There was a problem hiding this comment.
oh. yes. would it be plausible to fix that while we're here?
+1 to making the rule for third_party_users match that for users, anyway.
There was a problem hiding this comment.
it's a bit scope creepy but one line never hurt anyone - will convert both rules to be just ints.
|
Cancelling FCP proposal as this proposal lacks an implementation. @mscbot fcp cancel |
mscbot
removed
the
proposed-final-comment-period
turt2live
added
requires-room-version
turt2live
added
the
needs-implementation
Rendered
For MSC2199. Related to https://github.com/vector-im/riot-web/issues/6093