-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC2787: Portable Identities #2787
base: old_master
Are you sure you want to change the base?
Conversation
It is still a work-in-progress—some things that need attention include: | ||
|
||
- How to handle multiple homeservers joining the same room, all with attestations | ||
from the same UPK, and how they synchronise state amongst themselves; | ||
- How to handle invites, given that you won't know a UDK until after the user has | ||
joined the room; | ||
- How to adequately disconnect UDKs from UPKs as a part of a data removal request | ||
for GDPR compliance; | ||
- Whether UPKs should really be a "one true identity" for a user or whether a user | ||
may actually have multiple UPKs if they want; | ||
- How to handle device list syncing and send-to-device messages; | ||
- The extent to which users should be involved in attesting MXID-to-UPK mappings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might want to italicise this part, especially because UPK
is a concept that is introduced later on
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
… as events will still have those signatures
2 questions:
|
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) |
|
||
It is still a work-in-progress—some things that need attention include: | ||
|
||
- How to handle multiple homeservers joining the same room, since they will have |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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.
for GDPR compliance; | ||
- Whether UPKs should really be a "one true identity" for a user or whether a user | ||
may actually have multiple UPKs if they want; | ||
- How to handle device list syncing and send-to-device messages; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
KILL WITH 🔥
- Whether UPKs should really be a "one true identity" for a user or whether a user | ||
may actually have multiple UPKs if they want; | ||
- How to handle device list syncing and send-to-device messages; | ||
- The extent to which users should be involved in attesting MXID-to-UPK mappings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
|
||
- To enable account portability by breaking the link between a user identity and a | ||
specific homeserver; | ||
- To allow breaking the link between delegated and permanent user identities at a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
line 28: undefined concept error: delegated & permanent user identities are not defined concepts
specific homeserver; | ||
- To allow breaking the link between delegated and permanent user identities at a | ||
later date, e.g. as a part of a data deletion request; | ||
- To allow a user to grant permission to one or more homeservers to act on behalf of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
This proposal includes specifications to: | ||
|
||
- To give a user a single cryptographic User Permanent Key (herein referred to as | ||
a "UPK"), which they will use as part of a cryptographic challenge login; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, we'll need to figure out how to rotate this key (i.e. how password reset works)
- To give a user a single cryptographic User Permanent Key (herein referred to as | ||
a "UPK"), which they will use as part of a cryptographic challenge login; | ||
- To give a server a set of User Delegated Keys (herein referred to as a "UDK"), | ||
which will represent servers acting on behalf of users within rooms; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
- To give a server a set of User Delegated Keys (herein referred to as a "UDK"), | ||
which will represent servers acting on behalf of users within rooms; | ||
- To allow users to attest one or more UDKs using their UPK; | ||
- To remove Matrix IDs (MXIDs) and server names from events, similar to MSC1228; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
|
||
### Membership UDK Attestation | ||
|
||
An attestation will include the UDK that is being attested to, and an expiry time. The |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
"~upk_that_is_attesting": { | ||
"ed25519": "upk_signature" | ||
}, | ||
"~udk_that_is_being_attested": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"~udk_that_is_being_attested": { | |
"^udk_that_is_being_attested": { |
i think?
|
||
This prevents servers from continuing to impersonate the user with new events after | ||
the attestation has expired - necessary as the server owns and maintains the UDK | ||
keypair. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hum. can't the server just emit events with an origin_server_ts
before the expires
ts?
"~upk_that_is_attesting": { | ||
"ed25519": "upk_signature" | ||
}, | ||
"~udk_that_is_being_attested": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"~udk_that_is_being_attested": { | |
"^udk_that_is_being_attested": { |
historical attestations too. | ||
|
||
TODO: Doing this may mean that other servers that try to backfill may not be able to | ||
verify that the events were allowed to be sent? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
|
||
Public keys as identifiers may enable some portability but they aren't user-friendly | ||
and somewhat difficult to put on a business card. For this, it is necessary to be | ||
able to allow users to maintain MXID mappings much as they have today. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
#### UPK Format | ||
|
||
The UDK is prefixed with a version byte, then URL-safe base64-encoded, and then | ||
prefixed with the `~` sigil. The version byte for ed25519 is `0x01`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, why bury the version byte within the base64 rather than the ~1:.....
approach from MSC1228, ooi?
@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? |
oh, and in terms of
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 :) |
The UDK signature will remain in the event, but without the attestation, it will not | ||
be possible to link it to a UPK. | ||
|
||
### Matrix ID to UPK mapping |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity, would it be strictly necessary to operate a homeserver to map an MXID to a UPK? If a UPK is static (which is my understanding?), I would be interested in a discovery endpoint that could be handled by any webserver, for instance https://example.com/.well-known/matrix/id/jonah
for @jonah:example.com
could return a response containing a UPK and a resident homeserver of my choosing.
I envision a use-case where it is trivial to create many MXID aliases pointing to a single account, and making it easy for organizations and individuals on budget/shared hosting platforms to use "branded domain" MXIDs. Multiple discovery methods could extend to non-HTTP methods as well, perhaps a number are implemented in some prioritized order:
- Query homeserver at server_name for MXID in database
- Query
.well-known
endpoint for MXID mapping - Query DNS TXT record for MXID mapping
- ...?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So far I have worked on the assumption that the user-homeserver attestations would need to remain up-to-date to maintain an alias, and that other homeservers would verify those attestations, otherwise it creates a big social problem in that someone can just buy a domain and start assigning unwanted aliases to users (I'm envisaging things like @unknowing_user:supportsthenazis.net
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed that in the next section here, but I don't think I am as convinced this is an issue personally. I don't see what is currently stopping me now from operating that supportsthenazis.net
homeserver and creating users named anything I want, just as nothing is stopping me from operating an email server that forwards unknowing_user@supportsthenazis.net
to unknowing_user@gmail.com
.
I don't think there is a societal expectation that such a username is always someone's canonical ID online for this reason. If I've never included a certain username on my websites/business cards/etc., I don't think someone would immediately assume it belongs to me if I just so happened to receive it.
Invitations in Matrix could also display both a "From" and a "To" field, and I could judge invitations based on that.
My other assumption is that in this proposal, MXIDs will only be used to identify a user's UPK, but are not actually a part of the user's canonical profile, so after the initial invite to a room the MXID would be irrelevant anyways.
If you do want to include MXIDs in user profiles, I still don't see why this wouldn't be possible. If Bob wants to verify @alice:example.com
belongs to Alice:
- Bob's homeserver checks
example.com
for an MXID mapping - That mapping is followed to Alice's (presumed) actual resident homeserver
- Alice's homeserver returns a profile object signed with her user key that includes
@alice:example.com
as a known alias.
That should function as two-way verification without requiring any special software on example.com
itself. In this case, profiles could even have define multiple aliases and set one as a canonical alias if it is desired to have a displayed MXID in user profiles.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
- Whether UPKs should really be a "one true identity" for a user or whether a user | ||
may actually have multiple UPKs if they want; | ||
- How to handle device list syncing and send-to-device messages; | ||
- The extent to which users should be involved in attesting MXID-to-UPK mappings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
#### UPK Format | ||
|
||
The UDK is prefixed with a version byte, then URL-safe base64-encoded, and then | ||
prefixed with the `~` sigil. The version byte for ed25519 is `0x01`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 is0x01
.
validity of the previous attestation has expired. | ||
|
||
The previous membership event with the previous attestation must appear in the | ||
`auth_events` of the new membership event with the new attestation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
#### Removing an attestation | ||
|
||
To remove an attestation, the membership event should be replaced with a new | ||
membership event that no longer includes an attestation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Presumably this needs to be signed by the UPK or it can be spoofed?
The UDK signature will remain in the event, but without the attestation, it will not | ||
be possible to link it to a UPK. | ||
|
||
### Matrix ID to UPK mapping |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
|
||
Public keys as identifiers may enable some portability but they aren't user-friendly | ||
and somewhat difficult to put on a business card. For this, it is necessary to be | ||
able to allow users to maintain MXID mappings much as they have today. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
- How to adequately disconnect UDKs from UPKs as a part of a data removal request | ||
for GDPR compliance; | ||
- Whether UPKs should really be a "one true identity" for a user or whether a user | ||
may actually have multiple UPKs if they want; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this will be required if only for key rotation for future algorithm upgrades.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
- To give a user a single cryptographic User Permanent Key (herein referred to as | ||
a "UPK"), which they will use as part of a cryptographic challenge login; | ||
- To give a server a set of User Delegated Keys (herein referred to as a "UDK"), | ||
which will represent servers acting on behalf of users within rooms; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
- A UPK in combination with a previously-known resident server name; | ||
- A MXID, from which a response will contain the UPK and a resident server name. | ||
|
||
In these instances, you are addressing "the user" rather than a UDK. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
|
||
### User Permanent Key (UPK) | ||
|
||
The UPK is an ed25519 public key which represents a user entity. The initial |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Instead of implementing something complex for portable identities, could it not be simpler to have a way to tell contacts and rooms that |
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
We can imagine the same scenario when bob wants to close its 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
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:
Except for
(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). |
I reviewed this, and I think we should use these. We currently have several outstanding MSCs and other issues related to decentralized identity, including:
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? |
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. |
Rendered.
Supersedes #1228, matrix-org/matrix-spec#246, matrix-org/matrix-spec#220 (and #3793?). Relevant to #2783.