matrix-spec-proposals
matrix-spec-proposals copied to clipboard
matrix-org
MSC2787: Portable Identities
Supersedes matrix-org/matrix-spec-proposals#1228, matrix-org/matrix-spec#246, matrix-org/matrix-spec#220 (and matrix-org/matrix-spec-proposals#3793?). Relevant to matrix-org/matrix-spec-proposals#2783.
2 questions:
-
Lets say server A creates an attestation for UDK A (in a room), and server B creates an attestation for UDK B. Now, the user wants to insta-expire UDK A (lets say trust reasons with the admin of that server), but they are unable to access server A for any reason (downtime, deliberate malice, etc.), would it be reasonable to allow Server B to create an attestation event for UDK A (with shortened
expireskey), signed with UDK B and the UPK? -
Lets say server A has joined a room via UDK A attestation, that server goes down before the user is able to do anything, will the user be able to join the room (without an invite, or invite authorisation) with server B and UDK B simply by saying "hey, this identity (UPK) was in this room before, let me in with this UDK (B), please.", would that pass? Would UDK A need to not be expired, or is the unredacted attestation event (ignoring kicks, bans, and other control events) enough for the room logic to allow the new UDK into the room?
One idea I came up with is the following;
Construct and add an additional "identity" called the "OTI" (one true identity) for every room, this OTI holds all information regarding powerlevels, auth, membership information, and everything a "user" has, this is keyed to an opaque string that's generated when users first join a room.
The OTI generation event is keyed to the OTI string, but internally (in the content) it's signed and linked to the UPK, this cannot be changed from therein out, the OTI is linked to the UPK until it's redacted.
Every additional UDK attestation is then linked to the OTI by including the OTI string in the attestauon
By doing it this way, the OTI effectively becomes "the user" for a room, with every UDK acting as an "agent" for that user. An UDK-signed event (if valid/not expired) can use the powerlevels and control given to the OTI key.
Additional to this, there could be additional schenanigans where a user could "revive" their room membership (after every UDK is inaccessible or expired) by "knocking" on a server that has access to that room, by asking to engage in an exchange with another server to attest another UDK (signed and validated by the UPK), and effectively rejoin the room.
One other thing could be this: an UPK-signed event can (from any other UDK) extend or belittle the expiry key on a UDK-keyed event.
All of this is possible while still having deniability: redact all UDK attestation events, redact the OTI-to-UDK linkage events, and then finally redact the OTI creation event, this way the UPK key is effectively forgotten in a room, and an identity is dead.
(The only problem I see is historical verifiability of any now-dead-UDK-signed auth event, if this is "just allowed", an attack can take place in a fork by forging a UDK attestation event, then creating an auth/control event keyed to the OTI, and then creating a redaction event redacting the attestation, this requires some more thought.)
Regarding profiles and MXIDs;
I think profiles should be an internal room that's federated by all servers that have an UDK to corresponding UPK mapping, all state events in that room can be signed by both UDKs and UPKs for validity, any and all auth and control events can be signed by UPKs only.
MXIDs could be an agreement between users and servers (after any authenticity and approval flow), this bond of trust creating a MXID key that users and servers can use to retract mxid mappings, these mappings are effectively embedded in that internal profile room's state, and retrievable by anyone over federation by UPK or MXID (though maybe some MXIDs can be "hidden", deniability for UPK-to-MXID, but confirmation on MXID-to-UPK)
These are my thoughts and ideas on this MSC.
(Btw @ara4n, you may be pleased to know that I think this model would very well work with a p2p model, as long as the underlying matrix Infrastructure is able to effectively route and federate events in the hybrid (p2p and conventional servers) fashion, I'd like to hear your thoughts on it :D)
@ShadowJonathan thanks for perusing this. one important convention when commenting on MSCs is to comment on the diff (using the title if it's a generic comment) rather than on the PR itself, as it's sadly the only way to get threaded comments on PRs - and makes it much easier to track and resolve and respond to specific comments.
That said, I'll let @neilalexander respond to the ability to override attestation expirations via other servers. Agreed that it's desirable to have a revocation mechanism... assuming we have expiration at all. As per https://github.com/matrix-org/matrix-doc/pull/2787#discussion_r495498219 i'm slightly dubious that we need that complexity at all, though, given you can attest your identity on a per-message basis via E2EE (especially if/when MSC matrix-org/matrix-spec-proposals#2757 lands).
In terms of the OTI idea... I'm completely failing to understand the benefit it brings beyond a UPK, i'm afraid.
Please can we continue the discussion split into comment threads on the diff itself?
oh, and in terms of
you may be pleased to know that I think this model would very well work with a p2p model, as long as the underlying matrix Infrastructure is able to effectively route and federate events in the hybrid (p2p and conventional servers) fashion, I'd like to hear your thoughts on it :D
yes, i'm reassured that this model should work well for p2p (which is hopefully not that surprising, given @neilalexander is one of the leads for p2p matrix :)
In terms of the OTI idea... I'm completely failing to understand the benefit it brings beyond a UPK, i'm afraid.
@ara4n It allows for a logically-centralised user identity in a room, and resolves the problem of powerlevels and the like for individual UDKs (even after they're redacted), and provides an optimised path for homeservers to serve up a user in C-S, while allowing S-S to become decoupled from origin server, and allow redactions to follow privacy laws.
A redaction would strip the identity from the UPK, but still allow it to stand as "a user" inside the room, allowing stateres to be more robust in the light of it existing. Instead of juggling multiple distinct UDK IDs that acted upon the room as if it were one, but are now functionally distinct, their links broken, and the stateres retroactively unsure about the eventual control state of the room, allowing for (security) bugs.
Please can we continue the discussion split into comment threads on the diff itself?
My apologies, I'll do so now, I just think it's hard to convey a completely different new angle into this MSC other than putting it into a generic comment.
I've already propose this as a dendrite feature (https://github.com/matrix-org/dendrite/issues/1699) but it seems to be a good place also. I am convinced that solid WebID (https://github.com/solid/solid-spec#webid-profile-documents) can be a solution on portable and multiple session.
As a user, I'd like to switch to a new homeserver, which supports specific experimental features (Cerulean via Dendrite). If I have to create a new account on a Dendrite server, I would like to take my contact lists and my conversations with me. I'd like to show that @dagguh:matrix.org and @dagguh:dendrite.matrix.org are both me. So if you get messages from both, they could be shown within the same room.
I hope my use case helps motivate some aspects of Portable Identities. Sorry if I'm overstepping here. I can delete my comment if this is not the right place.
Another use case that I have is having fallback servers. If my own homeserver is down, it would be nice if I could temporarily use a friend's server in the meantime.
I believe that it would be very useful to people wanting to host servers locally rather than renting VPS/dedicated servers, as there can be more risks of downtime there. It would be very reassuring to know that a power outage won't completely kill your communications, especially when traveling (for example).
Like @dagguh said, I'll delete this comment if this isn't the right place to suggest use cases.
Another use case that I have is having fallback servers. If my own homeserver is down, it would be nice if I could temporarily use a friend's server in the meantime.
I believe that it would be very useful to people wanting to host servers locally rather than renting VPS/dedicated servers, as there can be more risks of downtime there. It would be very reassuring to know that a power outage won't completely kill your communications, especially when traveling (for example).
Like @dagguh said, I'll delete this comment if this isn't the right place to suggest use cases.
No, this is absolutely the best place for suggesting this, and when you just described this usecase, i realised how beautifully right you are with this specific use-case, e.g. a group of friend-servers allowing eachother to be fallbacks, which ups the redundancy and resiliency of matrix, damn.
Another way to look at it, which is probably even more relevant, is that this should facilitate decentralization.
Some of the main reasons why people chose matrix.org over other public homeservers is that it is very likely to last for a long time and to have very good uptime. So why settle for one that might be taken down at any time without notice?
As a regular user who doesn't selfhost, I'd rather pick a few local homeservers that aren't as overcrowded as matrix.org and have more peace of mind knowing that it doesn't matter too much if one of them is down for a while or forever. I'd also probably get better performance this way!
Using this feature for "fallback" servers probably also needs some way of adding a new fallback server and replicating to the new server the history that the user already has access to.
An interesting note is that this is actually a very big leap towards moving away from Web PKI. If you can change your homeserver address easily and reliably you can then start using IP addresses (maybe a handful in case one goes down) and avoiding DNS. The only missing gap is TLS using the Web PKI which could be replaced by embedding a cert into the announcement messages discussed in this MSC. Once that is done there is no longer a fixed trust anchor (just relying on the availability of IP routing). Of course IP addresses and certs could also be replaced with libp2p, but either way we move forward this is a big step.
We probably don't want to take these steps in the context of this MSC but I think it is worth thinking about this possible future while we discuss.
Instead of implementing something complex for portable identities, could it not be simpler to have a way to tell contacts and rooms that @bob:matrix.org is the same person as @hello:bob.name for example. Then, the information is stored in the room and both identities appear as single in clients that supports it.
Hi there. I shared an idea earlier today (!jxlRxnrZCsjpjDubDX:matrix.org/$Tv0LuCtYfxj5DeaONBpNqMenHQ6RNEumnA-n8JLDkzY) before finding this that I through might be interesting. The description I showed really showed one specific usecase, but is easily extended beyond what I described. Skimming through the proposal, I didn't see anything talking about how to sync the info (though I could have easillly missed it), and it seemed to me like these could go hand in hand.
I didn't get my wording quite right so if you need some clarification on it, feel free to ask.
I believe that it is possible to have portable identities without having to remove the need for servers to have a single static signing key, as they do today. This is I believe a bit out of scope, and I don't think we need to replace the MXID with a UPK to achieve portability.
Instead of removing MXID and replace it by a public key that needs to be protected (significantly more difficult for the end-user, requiring delegated keys and risking the master private key being stolen), a user could be identified by multiple MXID.
Say we have a user @bob:example.org that wants to have a portable identity with @bob:bob.example.net, what could happen is as follows:
- Bob has an account
@bob:example.orgthat it wishes to move over tobob.example.net, it creates an empty account at@bob:bob.example.netand instructs the new homeserver that the account should link with@bob:example.org -
@bob:example.orginstructs its homeserverexample.orgthat it wishes to port his identity to@bob:bob.example.net -
example.orgasksbob.example.netif this is true and gets the confirmation -
example.orgon behalf of Bob would then send an event to all the rooms bob is part of telling in essence that@bob:bob.example.netis now an alias of@bob:example.org. it means that events from bob could be signed by both homeservers -
example.orgwould also tellbob.example.netthe state of all the rooms subscriptions -
bob.example.netwould then subscribe to all the rooms that bob is part of, this would not be a new user joining the rooms, merely a new homeserver joining the room for an existing user
We can imagine the same scenario when bob wants to close its @bob:example.org account, an event would tell that bob no longer wishes to use that account and the example.org server would then unsubscribe and the two MXID would no longer be considered linked as the same user.
What I'm telling here is that there is no need for a single global identifier for a user. The unique identifier for a user could be purely local to the implementation (same pointer in memory, same id in database). There just needs to be a way to tell that at a given time in a room history that a given MXID correspond to a given user, and that the mapping can change over time.
The m.room.member event could gain a new property in the event content:
-
senders([string]) : contains a list of MXID that the sender is also known as. Any event sent by any of these MXID in the room must be treated as being sent by the same member.
The m.room.member event being send and signed by the original homeserver, the homeserver authentifies that the user wishes to grant other servers listed access to the room on behalf of the user itself.
To quote MSC1228:
User IDs currently appear in the following places in a room:
- sender of each event
- state_key of m.room.member events
- users list in m.room.power_levels events
- creatorUserId in the content of m.widget
Except for state_key of m.room.member, the MXID can be mapped through event ordering to a unique member. I can see a few solutions here:
- the state_key is changed to a hash of all the MXID of the member in a canonical ordering of the list, special handling of the room state must happen to remove the old event state
- the state_key will forever contain the fist MXID the room member was known as, even though the first MXID since left. It means that the first MXID cannot be reused. It also means that when sending a m.room.member event, a server must not always put the user MXID in the state_key but must track which MXID the user was first known as for each room
- upon joining the second server will send a second m.room.member event with the second MXID as sender and state_key, and with the senders key coherent with the first m.room.member event, else the second event would be invalid.
(seems the 3rd solution might be better)
Decentralized Identifiers (DIDs) https://www.w3.org/TR/did-core/ became a W3C recommendation last month (July 2022).
@orpheuslummis said: Decentralized Identifiers (DIDs) https://www.w3.org/TR/did-core/ became a W3C recommendation last month (July 2022).
I reviewed this, and I think we should use these. We currently have several outstanding MSCs and other issues related to decentralized identity, including:
- #1762
- #1768
- #1781
- #3839
- matrix-org/matrix-spec#203
- matrix-org/matrix-spec#246
Due to how generic they are, W3C DIDs can (and should) be used as the portable and decentralized identifier mentioned in these GitHub issues.
What this doesn't address, as I noted in #1781, is the distinction between the DIDs proper, and the human-friendly Identifier, which is not in scope for the DID spec, so human-friendly Identifiers should also be out of scope for Matrix portable identities. Under the hood, Matrix should probably consider only the DID proper, regardless of how we present this to the user.
Although we need not and probably should not consider human readability to make identities portable, a solution for mapping human-readable identifiers to a DID is forthcoming, and should be considered as part of Matrix's design. I think #1781 is the right MSC for that discussion.
The other way I ran into a multi-party eddsa implementation and although I'm not very savvy regarding multi-party computation or other related topics like ZKP, I was wondering if something like this could be used to solve the portable identities issue. We can have devices have their own keys or pieces of the one key that don't need to leave the device and they can all be linked into a multi-party set up to generate the one key that identifies the user and signs stuff. This kind of technology seems to be the best option for privacy, unlike DIDs that might not be the best in that matter.
As a layman, would implementation of this proposed specification allow me to change the username for any of my matrix accounts?
As a layman, would implementation of this proposed specification allow me to change the username for any of my matrix accounts?
Yes
I think the ability to change user names on Matrix instances is important.
Having fixed usernames could cause some pain to people who changed their name legally and had their old name in their username. It's very difficult to transfer your online life to another account just to change your username.
Is this still being worked on? As a use case, I have an employee who recently married and wan't her name changed to her husband's last name, but doesn't want to lose all of her old posts.
