A Taxonomy for More Messaging Interop (MIMI)

Introduction The More Instant Messaging Interoperability (MIMI) working group will specify the minimal set of mechanisms required to make modern Internet messaging applications interoperable. Over time, messaging applications have achieved widespread use, their feature sets have broadened, and their adoption of end-to-end encryption (E2EE) has grown, but the lack of interoperability between these services continues to create a suboptimal user experience. The standards produced by the MIMI working group will allow for E2EE messaging applications for both consumer and enterprise to interoperate without undermining the security guarantees that they provide. There are many decisions that need to be made about how such interoperability will be provided. These include how users initiating communications will find and/or identify users they wish to communicate with, how recipients will receive initial communications, whether the communications services envisioned by MIMI are bilateral or multilateral, and so on. This document provides a taxonomy and outlines the solution space of decisions that will need to be taken. It is meant as an informative document to aid in discussions and decision making.

Initiator Knowledge In the most basic case for mimi, there is one user (the initiator) that wishes to send a message to another user (the recipient). This can be a basic 1-1 messaging session, or it can be that the initiator is part of a group chat, and wishes to add the recipient to the group chat. Initiating communications requires the initiator to know something about the recipient, which is used to target the communications to that recipient. There are a finite set of things that the initiator is required to know in order to initiate communications, and this forms one dimension of taxonomization for mimi - initiator knowledge.

Unique, Service Independent Identifier (SII): In this case, the initiator has an identifier for the recipient, but that identifier is independent of any specific communications service. There are two specific identifiers in this case - a mobile phone number, or an email address. For this use case to function, the recipient must be using a communications service that links users to this SII. This would be the case for communications services which require users to verify their mobile numbers or email addresses during the sign up process, even if those services don't actually use them for communications.
Unique, Service Specific Identifier (SSI): In this case, the intitiator has two linked pieces of knowledge - they know the communications service used by the recipient, and they also know an identifier for the recipient on that service. In some services, the identifier is not globally unique across services. Examples of this case are Wire, Twitter and Skype, where user handles are flat - @jdrosen2 on Twitter, for example. In some services, the identifier is globally unique, and corresponds to the email address or mobile phone number for the recipient. Examples of this case are WhatsApp, iMessage, and Facetime.
Non-Unique, Personally Identifying Information (PII): In this case, the initiator doesnt have a specific identity for the recipient, but they know something about them and use that information to perform a search. Typically this would be the first name and/or last name of the recipient. The search would provide a list of possible matches, along with additional information, such as display names and avatars, which help the initiator find the specific person to which communications is desired.

Mimi support for these different use cases comes with different pros and cons. The SSI case has the benefit that it enables interop with communications services, such as Wire, that dont retain email address or mobile phone numbers for users. However, it has a drawback that is requires the user to know, in advance, what communications service the recipient is using. In cases where the identifier is a phone number or email address, it is unlikely that the initiator will know this information. A common use case is for the initiator to be on their mobile phone, using their mobile phone's native messaging function - iMessage on iPhone, Android Messages on Android - and wish to send a message to another user. In this case, today this use cases requires the initiator to only know the mobile number of the recipient. In other words, today's native mobile messaging experiences are SII based. If we want the mimi solution to work seamlessly with the user experiences mobile users already have, then SII is required. The PII solution has the obvious benefit of enabling user's to find each other with limited information, without requiring knowledge of an identifier. However, inter-domain search is fraught with privacy and security problems. It is helpful to understand which of these modes are used in some of the more popular consumer messaging applications:

Recipient Approval Another aspect of the solution considers the experience of the recipient. Does the recipient need to approve the communications, or do they just receive it? The solution space for this is finite:

No Approvals: The recipient doesnt need to approve anything. For a 1-1 message, the message will show up. For group communications, the recipient would be added to the group.
Approval, no User Content: The recipient needs to approve the initiator communications. To reduce the likelihood of becoming a spam vector, no user generated content is shown to the recipient. For 1-1 messages, the recipient would see something like, "Alice Alexander wishes to send you a message, do you approve?". For group messages, the recipient would see something like, "Alice Alexander wishes to add you to group chat. Do you approve?". Only after approving, the recipient receives the message, or is added to the group. Note that group names count as user generated content, so when approving group addition, the user would not be shown the group name.
Approval, with User Content: The recipient needs to approve the initiator communications, but to help them make a decision, initiator-generated content is shared. This would include some or all of the message content for a 1-1 message, and for addition to a group chat, would contain the name of the group.

The choice for recipient approval is somewhat intertwined with the question on identity conveyance, as discussed in the next section.

Identity Conveyance When the recipient receives the message or group chat addition from the initiatior, they will see some information about the identity of the initiator. There are many options for what can be done:

SII Only: In this case, the only thing seen by the recipient is the SII - the mobile number or email address. Whether the recipient can trust this information is a separate matter, and is yet another dimension of the solution. Independently of trust, using SII as an identifier means that the identifier can be matched against the recipient address book, and use any matches to render a trusted display name.
SSI Only: In this case, the recipient sees the name of the service provider of the initiatior, along with their handle within that service. This identity will not generally be matchable against the local address book of the recipient.
SSI (or SII) with Display Name: In this case, the recipient sees the identifier of the sender, but also sees a display name that is provided by the originating provider. This assumes that the originating provider can be trusted to ascertain and provide this display name. If the display name is entered by the user and never verified, it doesnt count as a display name and instead is considered user generated content per the "recipient approval" dimension described above.

Identity conveyance is intertwined with the question of recipient approval. If the system is based on Approval, no User Content - the safest choice to reduce spam - then the only way in which the recipient can make a decision is based on the identity of the sender. If there is no useful information about the sender, it is difficult for the recipient to make a decision. SSI Only provides the least information. SII is a significant improvement, largely due to the possible match against the address book. SII with display name is better still, but depends on the ability of the display name to be trusted.

Federation Model The mimi solution can be built on one of several federation models:

Open: In the open model, service provider interconnection is open. Any provider can communicate with any other provider. No prior arrangements are needed, and mimi facilitates any discovery or bootstrapping needed. This is how email works today.
Bilateral: On the opposite end of the spectrum is bilateral communications. In this model, each provider makes an independent decision about which other providers it interconnects with. A new provider must approach each and every other provider, requesting interconnection. The overall interconnection is the union of the bilateral arrangements.
Multilateral: Halfway between the extremes of bilateral and open, is multilateral. In this model, there is some kind of forum the providers can elect to join, or not join. The forum imposes community defined standards for entry - perhaps on size of user base, adherance to spam standards, and so on. Once a provider is a member of the forum, they can interconnect with any other member. This is how the telephone network works today.

SII Type There are only two SII types - email addresses and phone numbers. The choice about whether to support one, the other, or both, has many considerations. Phone numbers have the property that they are finite, whereas email addresses are infinite in supply. This is relevant when considering spam. When an identifier space is finite, it is much easier to introduce blacklists for blocking communications. When the identifier space is infinite, bad actors can mint new addresses, bypassing blacklists. Whitelist-based systems are unaffected by this. Email addresses contain user-identifying information within their structure. An email address like "joesmith23@aol.com" indicates that this user might be named Joe Smith. When recipient approval is without user content, and there is no display name in the identity conveyance, the only information present is the SII itself. If the SII is not matched to the address book, the email address can provide some clue about who the user is. Phone numbers, on the other hand, do not provide any such information. This is a dual-edged sword. While it may help users in making decisions on whether to approve communications, it can also be used as a source of spam. Consider a malicious initiator that knows that the recipient has a friend named "Joe Smith". The malicious initiator could mint email addresses like "joesmith4@gmail.com", and attempt communications. If rejected, they can try again with yet another email address - "joesmith87@gmail.com", and try again. Phone numbers have the property that they are not free to obtain. Email addresses are free to obtain. Identifiers which cost money, increase the expense required to use them as a source of spam. This argues in favor of mobile numbers. Of course, these costs continue to decline, but they remain non-zero. The finite supply of numbers also means that they are unlikely to ever go to zero.