From 4b3bcefa98648383f2d74b9c4921d5fd037ab005 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Wed, 3 May 2023 14:08:52 -0400 Subject: [PATCH 1/7] E.164 Matrix IDs. --- proposals/4009-e.164-matrix-ids.md | 70 ++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 proposals/4009-e.164-matrix-ids.md diff --git a/proposals/4009-e.164-matrix-ids.md b/proposals/4009-e.164-matrix-ids.md new file mode 100644 index 00000000000..58340ae858d --- /dev/null +++ b/proposals/4009-e.164-matrix-ids.md @@ -0,0 +1,70 @@ +# MSC4009: E.164 Matrix IDs + +[E.164](https://www.itu.int/rec/T-REC-E.164) is a set of international standards +for telephone numbering. This defines a phone number as a `+` followed by a country +code (e.g. `1` for the US, `44` for the UK) followed by a local phone number. +For example, a E.164 phone number would look like: `+15558675309`. + +It is somewhat common[^1] for social networks or messaging applications to use phone +numbers as identifiers instaed of relying on users remembering separate usernames +(and needing to tell other users how to find them). + +[Matrix user identifierss](https://spec.matrix.org/v1.6/appendices/#user-identifiers) +are *almost* compatible with E.164: + +> The `localpart` of a user ID is an opaque identifier for that user. It MUST NOT +> be empty, and MUST contain only the characters `a-z`, `0-9`, `.`, `_`, `=`, `-`, +> and `/`. + +## Proposal + +Add `+` to the list of allowed characters in a Matrix user identifier. This would +allow a full E.164 phone number as the localpart of a Matrix ID: `@+15558675309:example.com`. + +It could additionally lower the impedance mismatch when brdiging if the identifiers +use the full E.164 phone numbers as identifiers. + +## Potential issues + +Homeservers and clients must already be +[more tolerant of Matrix user IDs](https://spec.matrix.org/v1.6/appendices/#historical-user-ids): + +> Older versions of this specification were more tolerant of the characters +> permitted in user ID localparts. [...] clients and servers MUST accept user IDs +> with localparts from the expanded character set: +> +> `extended_user_id_char = %x21-39 / %x3B-7E ; all ASCII printing chars except :` + +Thus it is expected to not cause any issues, although clients will need to identify +that the `+` character is valid for a homeserver. This could be from the supported +Matrix versions which the homeserver advertises. + +## Alternatives + +The `+` could continue to be disallowed and left off the beginning of the Matrix +IDs Note that Synapse reserves digit-only usernames for guest users, although this +seems to be an implementation detail and not mandated by the specification. + +Another option would be to [map from other character sets](https://spec.matrix.org/v1.6/appendices/#mapping-from-other-character-sets). +This would generate a Matrix ID like `@=2b15558675309:example.com`, which would +dramatically impact usability for homeservers which use phone numbers as +identifiers for all users. + +---- + +Although E.164 limits the `+` character to the initial character there seems to +be no reason to limit that for Matrix identifiers. + +## Security considerations + +None noted. + +## Unstable prefix + +N/A + +## Dependencies + +N/A + +[^1]: E.g. Signal, WhatsApp, etc. From 78644ed6cb8e301b36a748e9f3c2922438a73eb9 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Wed, 3 May 2023 14:39:41 -0400 Subject: [PATCH 2/7] Fix typo. --- proposals/4009-e.164-matrix-ids.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4009-e.164-matrix-ids.md b/proposals/4009-e.164-matrix-ids.md index 58340ae858d..b636b3013f9 100644 --- a/proposals/4009-e.164-matrix-ids.md +++ b/proposals/4009-e.164-matrix-ids.md @@ -6,7 +6,7 @@ code (e.g. `1` for the US, `44` for the UK) followed by a local phone number. For example, a E.164 phone number would look like: `+15558675309`. It is somewhat common[^1] for social networks or messaging applications to use phone -numbers as identifiers instaed of relying on users remembering separate usernames +numbers as identifiers instead of relying on users remembering separate usernames (and needing to tell other users how to find them). [Matrix user identifierss](https://spec.matrix.org/v1.6/appendices/#user-identifiers) From a49b587c205ea219a29b8b3f80f7c3757d524c50 Mon Sep 17 00:00:00 2001 From: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> Date: Fri, 5 May 2023 13:34:17 +0100 Subject: [PATCH 3/7] small typo fixes --- proposals/4009-e.164-matrix-ids.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/4009-e.164-matrix-ids.md b/proposals/4009-e.164-matrix-ids.md index b636b3013f9..bcc25c24b87 100644 --- a/proposals/4009-e.164-matrix-ids.md +++ b/proposals/4009-e.164-matrix-ids.md @@ -9,7 +9,7 @@ It is somewhat common[^1] for social networks or messaging applications to use p numbers as identifiers instead of relying on users remembering separate usernames (and needing to tell other users how to find them). -[Matrix user identifierss](https://spec.matrix.org/v1.6/appendices/#user-identifiers) +[Matrix user identifiers](https://spec.matrix.org/v1.6/appendices/#user-identifiers) are *almost* compatible with E.164: > The `localpart` of a user ID is an opaque identifier for that user. It MUST NOT @@ -21,7 +21,7 @@ are *almost* compatible with E.164: Add `+` to the list of allowed characters in a Matrix user identifier. This would allow a full E.164 phone number as the localpart of a Matrix ID: `@+15558675309:example.com`. -It could additionally lower the impedance mismatch when brdiging if the identifiers +It could additionally lower the impedance mismatch when bridging if the identifiers use the full E.164 phone numbers as identifiers. ## Potential issues From cac5eaa2198532b9a986542de5ca0adfdb53d2f8 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Fri, 5 May 2023 13:37:05 -0400 Subject: [PATCH 4/7] Expand examples. Another reasonable way around this is to use a prefix, instead of character mapping. The downsides are essentially the same. --- proposals/4009-e.164-matrix-ids.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/proposals/4009-e.164-matrix-ids.md b/proposals/4009-e.164-matrix-ids.md index bcc25c24b87..973c9f90dde 100644 --- a/proposals/4009-e.164-matrix-ids.md +++ b/proposals/4009-e.164-matrix-ids.md @@ -45,10 +45,11 @@ The `+` could continue to be disallowed and left off the beginning of the Matrix IDs Note that Synapse reserves digit-only usernames for guest users, although this seems to be an implementation detail and not mandated by the specification. -Another option would be to [map from other character sets](https://spec.matrix.org/v1.6/appendices/#mapping-from-other-character-sets). -This would generate a Matrix ID like `@=2b15558675309:example.com`, which would -dramatically impact usability for homeservers which use phone numbers as -identifiers for all users. +Another option would be to [map from other character sets](https://spec.matrix.org/v1.6/appendices/#mapping-from-other-character-sets) +or prefix the Matrix ID with something (e.g. `msisdn`). +This would generate a Matrix ID like `@=2b15558675309:example.com` or +`@msisdn_5558675309:example.com`, which would dramatically impact usability +for the users on homeservers which use phone numbers as identifiers. ---- From 5139eb60df9d35316c383835fc1cdca9892f7bd0 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 9 May 2023 14:49:06 -0400 Subject: [PATCH 5/7] Updates from feedback. --- proposals/4009-e.164-matrix-ids.md | 36 +++++++++++++++++++++++++----- 1 file changed, 30 insertions(+), 6 deletions(-) diff --git a/proposals/4009-e.164-matrix-ids.md b/proposals/4009-e.164-matrix-ids.md index 973c9f90dde..5507d6b1be3 100644 --- a/proposals/4009-e.164-matrix-ids.md +++ b/proposals/4009-e.164-matrix-ids.md @@ -1,4 +1,4 @@ -# MSC4009: E.164 Matrix IDs +# MSC4009: Expanding the Matrix ID grammar to enable E.164 IDs [E.164](https://www.itu.int/rec/T-REC-E.164) is a set of international standards for telephone numbering. This defines a phone number as a `+` followed by a country @@ -19,10 +19,15 @@ are *almost* compatible with E.164: ## Proposal Add `+` to the list of allowed characters in a Matrix user identifier. This would -allow a full E.164 phone number as the localpart of a Matrix ID: `@+15558675309:example.com`. +allow a full E.164 phone number as a user's username on a server, which is common +practice for many applications. This should hopefully ease bridging of those +services to Matrix or help them natively speak Matrix in the future. Users would +not need to learn a new Matrix ID, but can continue using their phone number, as +today. -It could additionally lower the impedance mismatch when bridging if the identifiers -use the full E.164 phone numbers as identifiers. +Although E.164 IDs are meant to be globally unique they are still namespaced under +a domain under this proposal, e.g. `@+15558675309:example.com`, as the same user may +already be registered on multiple service providers. ## Potential issues @@ -35,10 +40,19 @@ Homeservers and clients must already be > > `extended_user_id_char = %x21-39 / %x3B-7E ; all ASCII printing chars except :` -Thus it is expected to not cause any issues, although clients will need to identify +Thus, it is expected to not cause any issues, although clients will need to identify that the `+` character is valid for a homeserver. This could be from the supported Matrix versions which the homeserver advertises. +---- + +A user have two account with the same identifier on different services is not +ideal, but is not different than today where a user may log into both WhatsApp +and Signal with their phone number. This MSC does *not* attempt to help with mapping +of an E.164 identifier to an actual Matrix ID, that's best left to the current +[identity service `/lookup` endpoint](https://spec.matrix.org/v1.6/identity-service-api/#post_matrixidentityv2lookup) +or future discovery services. + ## Alternatives The `+` could continue to be disallowed and left off the beginning of the Matrix @@ -58,7 +72,17 @@ be no reason to limit that for Matrix identifiers. ## Security considerations -None noted. +E.164 IDs are globally unique, but the proposed change only enforces per-homeserver +uniqueness. If a homeserver does not diligently check that the phone number belongs +to a user then this may allow additional spoofing attacks. The author does not consider +this to be much worse than today's situation: + +1. Many current applications need to verify that a phone number truly is owned + by an account. Any current best practices should be followed by a service + taking advantage of this MSC. +2. It is already quite easy today to spoof a user's ID by registering the same + user localpart on a different homeserver. The same issue occurs with email or + other distributed system (Mastodon, etc.). ## Unstable prefix From ba06fb90253cd1d90f918b3198b988dfe642e627 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Wed, 10 May 2023 08:47:24 -0400 Subject: [PATCH 6/7] Fix typos. Co-authored-by: Hubert Chathi --- proposals/4009-e.164-matrix-ids.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/4009-e.164-matrix-ids.md b/proposals/4009-e.164-matrix-ids.md index 5507d6b1be3..d79d52f9c3b 100644 --- a/proposals/4009-e.164-matrix-ids.md +++ b/proposals/4009-e.164-matrix-ids.md @@ -46,7 +46,7 @@ Matrix versions which the homeserver advertises. ---- -A user have two account with the same identifier on different services is not +A user having two accounts with the same identifier on different services is not ideal, but is not different than today where a user may log into both WhatsApp and Signal with their phone number. This MSC does *not* attempt to help with mapping of an E.164 identifier to an actual Matrix ID, that's best left to the current @@ -56,7 +56,7 @@ or future discovery services. ## Alternatives The `+` could continue to be disallowed and left off the beginning of the Matrix -IDs Note that Synapse reserves digit-only usernames for guest users, although this +IDs. Note that Synapse reserves digit-only usernames for guest users, although this seems to be an implementation detail and not mandated by the specification. Another option would be to [map from other character sets](https://spec.matrix.org/v1.6/appendices/#mapping-from-other-character-sets) From a9278819779b90807e23a5012badfd6518da919b Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Wed, 24 May 2023 07:42:58 -0400 Subject: [PATCH 7/7] Add note about re-using IDs. --- proposals/4009-e.164-matrix-ids.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/proposals/4009-e.164-matrix-ids.md b/proposals/4009-e.164-matrix-ids.md index d79d52f9c3b..ca86a8cd266 100644 --- a/proposals/4009-e.164-matrix-ids.md +++ b/proposals/4009-e.164-matrix-ids.md @@ -53,6 +53,14 @@ of an E.164 identifier to an actual Matrix ID, that's best left to the current [identity service `/lookup` endpoint](https://spec.matrix.org/v1.6/identity-service-api/#post_matrixidentityv2lookup) or future discovery services. +---- + +If a service uses E.164 identifiers as Matrix IDs then it must be careful to avoid +leaking history when reassigning IDs to new users. This is related to [#234](https://github.com/matrix-org/matrix-spec/issues/234), +but only applies to the localpart of the Matrix ID, not the entire domain. The +solution remains the same: using portable identifiers ([MSC1228](https://github.com/matrix-org/matrix-spec-proposals/pull/1228) +or [MSC4014](https://github.com/matrix-org/matrix-spec-proposals/pull/4014)). + ## Alternatives The `+` could continue to be disallowed and left off the beginning of the Matrix