MSC2787: Portable Identities

[neilalexander]

Rendered.

Supersedes #1228, matrix-org/matrix-spec#246, matrix-org/matrix-spec#220 (and #3793?). Relevant to #2783.

[ShadowJonathan]

Might want to italicise this part, especially because UPK is a concept that is introduced later on

[neilalexander]

This section is more of a TODO list to remind me to address those things :-) It won't stay in the final draft most likely.

[ShadowJonathan]

2 questions:

1. 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 expires key), signed with UDK B and the UPK?

2. 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?

[ShadowJonathan]

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)

[ara4n]

Suggested change

	- How to handle multiple homeservers joining the same room, since they will have
	- How to handle the same user on multiple homeservers joining the same room, since they will have

i assume?

How about we have a separate UDK and membership event for every device in the room (whether it's on the same server or not)? That way we can kill device lists.

[ara4n]

KILL WITH 🔥

[ara4n]

The ability for a server admin to unilaterally migrate their users between domains is Very Desirable™️ (so you can rebrand vector.im to riot.im to element.io without the users having to opt into it, or for that matter move users from uk.example.com to us.example.com - or add backup.example.com or cluster2.example.com as a valid home for the users, etc.)

[kevincox]

It would be interesting if the user could override this using their keys. For example the server admin can say "also forward messages here" or "stop forwarding messages to me". But the user can sign an attestation saying "I no longer trust this server, do not send messages there and they may no longer redirect my messages".

Of course this simple solution is prone to "fork bomb" tactics. But something like "Servers A and B are my only trusted servers at this point" could be used to be more robust.

I guess what I am saying is that it would make sense to have temporary (but indefinite) delegated consent. The homeservers can then manage these mappings but the user can reset and revoke this at any time.

[ara4n]

line 28: undefined concept error: delegated & permanent user identities are not defined concepts

[ara4n]

as per above, i'm pretty sure we need servers to be able to move users around without the users consenting to it (at least for the non-p2p world)

[ara4n]

hum, shouldn't this be the same as their Secret Storage key from 4S? Last thing we need is to maintain separate cryptographic login passphrase from the recovery passphrase. Also, this means this supersedes #1699

[ara4n]

also, we'll need to figure out how to rotate this key (i.e. how password reset works)

[ara4n]

hm, do we not get a different UDK per room? avoiding correlation of users between different rooms if they blow away their UPK->UDK mappings feels very desirable (and is an expectation i've set to many VIPs to expect in the future, much to their happiness, based on #1228's precedent)

[kevincox]

If all of the UDKs are signed with the same UPK how will this provide anonymity?

Furthermore I am struggling to identify what the point of all this is if you want to be anonymous. It seems that the point of this signing is allowing the server to join the room on behalf of you. If you want to join anonymously why not just let the server join without any signature?

I guess the reason is that if you want to then move the chat somewhere else you need to prove that it is the "same you". In that case we still don't want to link it to the UPK. But you could generate effectively a new UPK for each ID you want to have and join the room with that. Of course managing these is a mess but you could just make it a KDF of your "primary" UPK. Then if you want to prove that it is actually "you" you can sign your new UPK with your primary UPK.

Or to make better terms: UPK user primary key. URK user room key. SRK server room key. To join a room anonymously the server generates a SRK, you generate a URK and sign the server's SRK. That is then logged to the room. In the future you can migrate server by signing the new server's SRK. If you want to de-anonymize yourself you can sign your URK with your UPK to prove that it is you.

But there isn't really a difference between the UPK and URK in this picture. You can view them both as different identities. And by cross-signing you can "join" them.

So to loop around to the start if you want anonymity I think you need a new UPK per room, not a new UDK. Unless I am missing something.

[ara4n]

hm, we seem to have lost all the room_id fun that MSC1228 provides, which is Really Important because it means we can kill off signing keys (i think?) and thus massively speeds up room joins, and fixes matrix-org/synapse#3121 and stuff. If this MSC completely replaces #1228, then we should merge it in.

[ara4n]

it'd be good to justify we we need an expiry time here (especially if it means that non-NTP-synced hosts are going to get horribly confused)

[ara4n]

Suggested change

	"~udk_that_is_being_attested": {
	"^udk_that_is_being_attested": {

i think?

[ara4n]

hum. can't the server just emit events with an origin_server_ts before the expires ts?

[ara4n]

Suggested change

	"~udk_that_is_being_attested": {
	"^udk_that_is_being_attested": {

[ara4n]

I"m not completely convinced that we need all this expiration stuff. We trust the server to do many things on our behalf, but we can rely on e2ee to stop them spoofing messages.

[ara4n]

agreed - being able to map @matthew:matrix.org to the right UPK is super important for compatibility. Could we put the mxid in the attestation rather than server_name to achieve this?

[kevincox]

This could also be solved via the comment above: https://github.com/matrix-org/matrix-doc/pull/2787/files#r563198856

The client would look up the URL and get the associated UPK and signed proof.

[ara4n]

Hm, why bury the version byte within the base64 rather than the ~1:..... approach from MSC1228, ooi?

[ara4n]

@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 #2787 (comment) 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 #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?

[ara4n]

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 :)

[kevincox]

It would be interesting if the user could override this using their keys. For example the server admin can say "also forward messages here" or "stop forwarding messages to me". But the user can sign an attestation saying "I no longer trust this server, do not send messages there and they may no longer redirect my messages".

Of course this simple solution is prone to "fork bomb" tactics. But something like "Servers A and B are my only trusted servers at this point" could be used to be more robust.

I guess what I am saying is that it would make sense to have temporary (but indefinite) delegated consent. The homeservers can then manage these mappings but the user can reset and revoke this at any time.

[kevincox]

The order of this is awkward because it is reversed. Why not say "The UDK is a tidle sigil then the base64 of both a version byte and the public key".

I also agree that keeping the version byte outside is much more flexible for future changes. How about this:

The UDK is the ~ sigil, followed by the version as a base-10 ascii number. Followed by a : and the URL-safe base64-encoded public key.
prefixed with the ~ sigil. The version byte for ed25519 is 0x01.

[kevincox]

What is the point of expiry if we can issue new attestations that invalidate the old ones? It seems that this just means that if I go on vacation for a month my sever stops being able to effectively handle my messages.

It seems to me that there is no expiry that is both short enough to be useful and long enough to avoid timing out when someone is offline.

What is the threat model if the latest attestation is trusted forever? As a user I can send new attestations to other servers in the room and they will trust me because it is newer. The only server I can't convince is the malicious one, but even if its attestation expired what difference would that make. Would other users of that server be warned that the attestation is out of date? Assuming that e2ee is enabled the only benefit to doing this should be getting metadata, but the server gets metadata from its users anyways.

[kevincox]

Presumably this needs to be signed by the UPK or it can be spoofed?

[kevincox]

This could also be solved by signing the UPK with the associated private key. So https://chat.example/.well-known/matrix/id/%40kevincox:chat.example would contain a signed attestation that kevincox:chat.example is a MXID for the signing UPK. This can be trusted beacuse

• The domain is validated by the https cert.
• The UPK is validated by the signature.

It should also be possible/required to provide an expiry so that a malicious domain owner can't host that attestation forever and pretend to be you.

[kevincox]

This could also be solved via the comment above: https://github.com/matrix-org/matrix-doc/pull/2787/files#r563198856

The client would look up the URL and get the associated UPK and signed proof.

[kevincox]

I think this will be required if only for key rotation for future algorithm upgrades.

[LecrisUT]

Actually, this might be more important than it seems. What if your UPK private key is compromised, how can you retrieve back your identity. Currently the homeserver can reset your credentials, so at the very least something similar has to be included.

Some considerations

• If we detach the mxid from the UPK, then there is an ambiguity when the UPK private key is compromised, i.e. is the old key stolen and the user made a new UPK to link the mxid identity, or did the user give up on that mxid. Which is the true identity of the user, the UPK or the mxid?
• The identity is better verified via a x509 certificate cross-signed by all authorized servers (in case one of them is compromised). Then if the UPK is compromised, the user can use their 3pid to reauthenticate and create a new certificate and UPK. Cross verification between servers needs more thought though.
• For an x509 certificate, the main CA should be either the identity server (s) where you registered your 3pid (cross confirming the identity and having at least a common subset of 3pids) or your homeserver(s). For the former it would be more straightforward to reset one's identity even if one of the identity servers is comprised, but for the latter, you should make sure all servers should simultaneously agree with the identity, e.g. if a redaction is requested, it should be announced to the other servers which contact the user and confirm the validity.
• The UPK should be occasionally checked against other authorized servers to make sure it was not flagged as compromised.
• Having the UPK have a finite lifetime seems useful, but what if the user did not log in in a long time? How do we know it is not comprised in the meantime?

[kevincox]

If all of the UDKs are signed with the same UPK how will this provide anonymity?

Furthermore I am struggling to identify what the point of all this is if you want to be anonymous. It seems that the point of this signing is allowing the server to join the room on behalf of you. If you want to join anonymously why not just let the server join without any signature?

I guess the reason is that if you want to then move the chat somewhere else you need to prove that it is the "same you". In that case we still don't want to link it to the UPK. But you could generate effectively a new UPK for each ID you want to have and join the room with that. Of course managing these is a mess but you could just make it a KDF of your "primary" UPK. Then if you want to prove that it is actually "you" you can sign your new UPK with your primary UPK.

Or to make better terms: UPK user primary key. URK user room key. SRK server room key. To join a room anonymously the server generates a SRK, you generate a URK and sign the server's SRK. That is then logged to the room. In the future you can migrate server by signing the new server's SRK. If you want to de-anonymize yourself you can sign your URK with your UPK to prove that it is you.

But there isn't really a difference between the UPK and URK in this picture. You can view them both as different identities. And by cross-signing you can "join" them.

So to loop around to the start if you want anonymity I think you need a new UPK per room, not a new UDK. Unless I am missing something.

[kevincox]

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.

[LecrisUT]

Overall I think the UPK is too strong of an identifier and a target for identity theft. There should also be more metadata associated with it that should specify who/what attest to that identity. It should be more of a profile that the user manages and shares with each device.

[LecrisUT]

I think this is not an appropriate usage of the UDK/UPK.

When Alice wants to invite, message, etc. Bob, than she needs to know where to find Bob, either through a mxid or 3pid+identity server. She then contact's a server (or all of them) where Bob is registered, Charlie's for example, and sends the requests there to be redirected to Bob's devices. Then Bob responds with whichever identity he prefers to use with Alice and the UPK/UDK for that server.

If for example the server identity at that server is decommissioned, Bob is responsible to give the appropriate redirect to the server where to be found next. If the server is not accessible at all, Bob should have prepared a separate identity before and sent a request to decommission that identity to all the rooms he is in. This could also be sent and tracked by the servers themselves, doing the necessary re-routing and announcing the identity change for future usages as well.

[LecrisUT]

Instead of the UPK representing the whole user's entity, it should be more of a profile. There is a security issue if the UPK is a single point of failure and identity. Instead, the matrix server should continuously attest the validity of the UPK, not just the UDK.

The idea of a profile, makes it possible to have multiple UPK to be associated with specific sets of identities with controllable knowledge of one another, e.g. Alice has an account on her homeserver and Bob's server, and Alice's server knows about the relation between those 2, but Bob's doesn't. So on Alice's server she links 2 UPKs to her account, while on Bob, just one. This makes more sense in a context of work/family/internet profiles each managed by different servers. Similarly the devices can have a subset of profiles that can be accessible.

As for the security, it depends on the model that the user has. If the user has a UPK registered at a single server, than that server should be in change of the sole identification and attestation of that user. If it's distributed, than all servers should agree to the new identity, and individually confirm the new identity, from a registered 3pid etc.

For that reason, I think an additional User Identity Certificate (UIC) should be added and tracked by all relevant servers. The UPK creates and signs the UIC with the servers that co-manage this user/profile, and the servers co-sign the certificate and save a copy. Optionally a global 3pid or an identity server can be included in it, that all servers can reference, otherwise the user has to register specific identification for each server. Then, in the event of a UPK update/rollover, the server can announce this event to all relevant servers if the user cannot access one of the servers when updating.

In the event of requesting a UPK reset or cancellation, the server confirms their identity and forwards the request to all relevant servers to confirm as well, and if all agree the event passes and a new identity is made. If someone else tries to impersonate, than it has to have access to all the identities registered for each server. This should be independent of client stored information, because presumably that is the source of the account being compromised.

[mildred]

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.

[minecraftchest1]

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.

[mildred]

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.org that it wishes to move over to bob.example.net, it creates an empty account at @bob:bob.example.net and instructs the new homeserver that the account should link with @bob:example.org
• @bob:example.org instructs its homeserver example.org that it wishes to port his identity to @bob:bob.example.net
• example.org asks bob.example.net if this is true and gets the confirmation
• example.org on behalf of Bob would then send an event to all the rooms bob is part of telling in essence that @bob:bob.example.net is now an alias of @bob:example.org. it means that events from bob could be signed by both homeservers
• example.org would also tell bob.example.net the state of all the rooms subscriptions
• bob.example.net would 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.

[mildred]

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)

[orpheuslummis]

Decentralized Identifiers (DIDs) https://www.w3.org/TR/did-core/ became a W3C recommendation last month (July 2022).

[izN8nu6RyeneG5XnBoBgyRMVGH6H43WF]

@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:

• [WIP] MSC1762: Support user-owned identifiers as new 3PID type #1762
• [WIP] MSC1768: Proposal to authenticate with public keys #1768
• [WIP] MSC1781: Proposal for associations for DIDs and DID names #1781
• MSC3839: primary-identity-as-key #3839
• Decentralised identity (SPEC-458) matrix-spec#203
• Decentralised user accounts 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.

[olanod]

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.

[RokeJulianLockhart]

As a layman, would implementation of this proposed specification allow me to change the username for any of my matrix accounts?

[lepras]

As a layman, would implementation of this proposed specification allow me to change the username for any of my matrix accounts?

Yes

[acerspyro]

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.

[UnConundrum]

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.

[mpeter50]

@UnConundrum

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.

Did she change the display name? Do you think the username should be changed too?
Asking because the lots of thumbs ups make me feel a lot of users may not know about it.

[AlexRFox]

Can't speak to that scenario, but I've personally changed my last name and I really hate having my old name pop up in usernames. I changed my name for a reason, and I don't want to have to keep track of where I haven't been able to change my name yet.