4.7 KiB
MSC4009: Expanding the Matrix ID grammar to enable E.164 IDs
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 common1 for social networks or messaging applications to use phone numbers as identifiers instead of relying on users remembering separate usernames (and needing to tell other users how to find them).
Matrix user identifiers are almost compatible with E.164:
The
localpartof a user ID is an opaque identifier for that user. It MUST NOT be empty, and MUST contain only the charactersa-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 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.
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
Homeservers and clients must already be more tolerant of Matrix 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.
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
identity service /lookup endpoint
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, but only applies to the localpart of the Matrix ID, not the entire domain. The solution remains the same: using portable identifiers (MSC1228 or MSC4014).
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
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.
Although E.164 limits the + character to the initial character there seems to
be no reason to limit that for Matrix identifiers.
Security considerations
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:
- 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.
- 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
N/A
Dependencies
N/A
-
E.g. Signal, WhatsApp, etc. ↩︎