MSC4348: Portable and serverless accounts in rooms#4348
MSC4348: Portable and serverless accounts in rooms#4348Gnuxie wants to merge 4 commits intomatrix-org:mainfrom
Conversation
Gnuxie
changed the title
Gnuxie
changed the title
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Server
- Complement tests
| - Unlike | ||
| [MSC4243](https://github.com/matrix-org/matrix-spec-proposals/4243), | ||
| no endpoint or network requests are needed for servers or clients to | ||
| verify server ownership over an account, as all events are co-signed | ||
| by the room scoped server key. This is both a security and | ||
| consistency enhancement. |
There was a problem hiding this comment.
We need to be clear about whether servers do own accounts or whether participating in the room from multiple servers at the same time is possible.
There was a problem hiding this comment.
It seems like there would be no way to enforce this other than through a change in membership otherwise
|
|
||
| The domain can be found from MSC4345's `unsigned.server_domain`. | ||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
I'd like someone to talk to me about E2EE in the context of this MSC because I actually have no idea how tf E2EE already works on Matrix.
| - Within the context of MSC4345, the server key can be rotated without | ||
| effecting users or the room. | ||
|
|
||
| ## Proposal |
There was a problem hiding this comment.
We need to specify how precisely the server co-signs the event that has first been signed by the account key. And how this interacts with authorization rules, event creation, and room creation.
| - Portable snd serverless accounts accounts are now native to this new room model. | ||
| - Pseudo identity is supported in the room model for servers and room | ||
| admins that wish to immediately implement it. | ||
| - Servers can immediately be implemented as relays for P2P clients. |
There was a problem hiding this comment.
This isn't necessarily true. There are situations where MSC4345 would require cooperation from an account key.
| ### User accounts can move servers | ||
|
|
||
| Users that were resident to denied servers can migrate their account | ||
| to servers that are participating in the room. We assess this is | ||
| acceptable because we expect completing the same registration | ||
| requirements on the new server as they would with a brand new user | ||
| account will be required to migrate an account. | ||
|
|
||
| We expect servers with weak registration requirements or setup for the | ||
| use of ban evasion will be identified and removed as they are | ||
| currently. However, with the security enhancements of MSC4345, such | ||
| servers can no longer join rooms unanticipated. So we have an | ||
| advantage. |
There was a problem hiding this comment.
This implies that the membership event of a user needs explicitly tying to the co-sigining server's participation, and if either the co-singing server key or the account key are revoked, then the membership event cannot be used to authorize events.
I think that it is ok for a new membership event to be created with the same account key co-signed by a new server.
| We use the same `POST /_matrix/federation/v1/query/accounts` endpoint | ||
| from MSC4243, with the exception that the requested server must verify | ||
| that the requesting server is participating in common rooms to those | ||
| of the queried account key. |
There was a problem hiding this comment.
Forgive me if I've simply missed where this is expanded upon, but in MSC4243, the server is meant to query the origin that is in the user ID.
Given this proposal then removes that server name, where is the remote server supposed to query? I don't see a source of origin in events anymore, since the room ID no longer has an origin, the event ID no longer has an origin, and now the sender no longer has an origin.
Should the signing servers be queried instead? What if the event is only signed by the origin, and the origin is no longer responding to requests?
There was a problem hiding this comment.
That comes from what is currently called the unverified_domain in the parent MSC4345 which is annotated on the m.server.participation event for the co-signing server key (that can be found by looking for the public key as the state key).
If the server is no longer responding then profile information cannot be obtained
3 participants
Rendered
Signed-off-by: Gnuxie [email protected]