| Internet-Draft | MIMI Discovery Reqs | August 2023 |
| Rosenberg | Expires 28 February 2024 | [Page] |
This document defines requirements and use cases for the discovery problem in the More Instant Messaging Interoperability (MIMI) working group. The discovery problem refers to the process by which a message sender can identify the provider associated with a desired messaging recipient, normally identified by an email address or phone number.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 28 February 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The More Instant Messaging Interoperability (MIMI) working group is chartered to enable federated messaging, voice, and video service between application providers, such as WhatsApp, Facebook Messenger, and other vendors. The MIMI protocols cover the exchange of encrypted content [I-D.ietf-mimi-content] through transfer protocols [I-D.ralston-mimi-linearized-matrix]. These protocols allow a user in one provider to initiate 1-1 and group messaging with a user in a second provider. The protocol requires that the originator of the communication know two things about the target user - their messaging provider, and a unique identifier for that user within that provider. The specifications recognize that the originator will not always know the provider for the target user, or the provider-specific identifier for that user on that provider. The problem is further complicated by the fact that a users often make use of multiple messaging applications, in which case the preferences of the target user need to be taken into account as well. These preferences are even less likely to be known by the originator of communications.¶
Rather, in many cases one user will have an email address or phone number for the target user, obtained from their address book on their mobile device. Neither the phone number or email address identify the messaging provider that the target user is using. Unlike email service, the domain portion of a user's email address has no bearing on what messaging provider they use. A user [email protected] might be using WhatsApp or iMessage, neither of which are Gmail. Thus - the core problem is - how to take one of these service independent identifiers and learn the messaging service that user is using, and what their identifier is on that messaging service.¶
The MIMI framework hypothesizes the existence of a discovery or directory service to solve this problem. The discovery service would allow the originator to take a servide independent identifier for a target - such as a mobile phone number or email address - and perform a lookup to determine the preferred service of the target user, along with their identifier within that service.¶
This document describes requirements and use cases for solutions to the discovery problem.¶
Service Independent Identifier (SII): A type of identifier for a user that is unique (such that an SII is associated to only a single user), and independent of any specific communications service. There are two specific identifiers in this case - a phone number (landline or mobile), or an email address.¶
Service Specific Identifier (SSI): A type of identifier for a user that is unique (such that an SSI is associated to only a single user), and achieves its uniqueness by being composed of two parts - a user part, scoped to a provider of communication services, and a unique identifier for the communication service provider. In some services, the user part 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 other services, the user part 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.¶
Personally Identifying Information (PII): Information about a target user that is not unique, but can be used to facilitate a search for the target user. 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.¶
Application Provider (AP): A provider of messaging, voice, video and communications services to end users. An application provider is the entity that would implement the MIMI protocols. Examples of application providers are WhatsApp, Facebook Messenger, iMessage, Wire, Matrix, and so on.¶
Discovery Provider (DP): A provider of discovery services, capable of mapping an SII to an SSI. This entity does not yet exist, and this document defines requirements for the protocols and processes behind it.¶
Number Provider (NP): An entity which has authoritative ownership of the phone number used by a user. In the case of a mobile phone number, this would be their mobile operator (e.g., Verizon or AT&T in the United States). For a landline number, in would be their landline voice provider, which can include incumbent landline providers, but may also include non-traditional providers of voice and SMS services, like CPaaS (Communications Platform as a Service), such as Twilio or Nexmo, CCaaS (Contact Center as a Service), such as Five9 and NICE/InContact, and UCaaS (Unified Communications as a Service) providers, such as RingCentral, Webex and Zoom. We use Number Provider (NP) and not "operator" to keep this general purpose and to emphasize the fact that the key consideration for the discovery service is the assignment of the number to the user, not the provision of communications services against that number.¶
Email Provider (EP): An entity which has authoritative ownership of the domain name portion of the email address used by a user. This would be Google for gmail.com, or Verion/AOL for aol.com as two examples. The EP for an email address can also be an enterprise, such as Cisco for cisco.com email addresses.¶
Cloud Provider (CP): An entity providing services to enterprises for voice, video and messaging services, acting as the Application Provider for employees of its enterprise customers. The CP is the NP for some numbers used by the enterprise, but not always.¶
Discovery services are far from new on the Internet.¶
The whois protocol, originally specified in [RFC0954] and later revised by [RFC3912], was largely focused on the mapping of domain names, to services associated with those domain names, and was one of the first discovery services deployed on the Internet. The DNS SRV record was specified in [RFC2782] and allows a similar discovery process - given a domain name, allows a querier to learn the set of services, such as VOIP based on the Session Initiation Protocol (SIP) [RFC3261] [RFC3263]. Whois and DNS SRV records both assumed that the lookup was keyed by a domain name, and thus they were not that useful for looking up an identifier that is not domain scoped, such as a mobile phone number.¶
This was first addressed through the specification of ENUM [RFC3761] in 2004. ENUM defined the usage of DNS to lookup phone numbers, by convering a phone number to a DNS name by reversing the digits and adding the suffix "e164.arpa". This allowed portions of the namespace to be delegated to telco providers that owned the number prefix in question. Though technically simple to define, its deployment was hampered by the challenges of establishing authority for the prefixes. It also had a network effects challenge - its utility was limited until there was a critical mass of numbers in the system. It thus became hard to justify the investment of contributing numbers to ENUM. It also suffered from an incentive problem - what was the business value for the telcos to participate in the activity? These challenges resulted in a failure of ENUM adoption.¶
Another attempt was made with ViPR (Verification Involving PSTN Reahability) [I-D.rosenberg-dispatch-vipr-overview] [I-D.petithuguenin-vipr-pvp]. VIPR made used of a peer-to-peer network based on RELOAD (Resource Location and Discovery) [RFC6940], running between enterprises. It solved the problem of authority problem by authorizing records based on proof of forward routability. However, it had the same network effects problem as ENUM. It also addressed the incentive problem, by focusing on enterprises for which bypassing the phone network would provide cost savings. However, the network effects problem proved insurmountable (amongst other challenges unrelated to the protocol), and it was never widely deployed.¶
Discovery and lookup services are now common place on the Internet but are scoped entirely within large providers, such as Facebook, Twitter, WhatsApp and other providers.¶
The MIMI discovery service requires a solution that spans across providers.¶
The reference architecture is shown below.¶
+------+ +------+
| Disc | | Disc |
| Prov |--------| Prov |
| 1 | | 2 |
+------+ +------+
| |
| |
+-----+----+ |
| | |
+--------+ +--------+ +--------+
| App | | App | | App |
|Provider| |Provider| |Provider|
| 1 | | 2 | | 3 |
+--------+ +--------+ +--------+
| | | | |
| | | | |
+----+ +----+ +----+ +----+ +----+
|User| |User| |User| |User| |User|
| 1 | | 2 | | 3 | | 4 | | 5 |
+----+ +----+ +----+ +----+ +----+
There are many users in the system, with each user making use of zero or more communication applications, each provided by an Application Protocol (AP). Those application providers, in turn, connect to a Discovery Provider (DP) which is capable of mapping the SII to an SSI. As shown in the diagram, one of the requirements is that there can be more than one DP, in which case there will be a need for some kind of inter-DP communication.¶
There are many variations on who the app provider is, and what their relationship is with the user of the messaging service and the number and email providers for the identities. We can invision the following variants, all of which should be supported by both MIMI and the discovery service.¶
The variations are discussed below in order of decreasing commonality. For each one, we also discuss their cardinality (how many of them there are), how large of a population of users they serve, and how likely they are to participate in MIMI and the discovery service.¶
In this case, the App Provider offers services to consumers. The consumer has an email address and/or phone number, but the EP and NP for those identifiers have no relationship whatsoever with the AP. Examples include Apple's iMessage, Facebook Messenger, Wire and so on. However it does not include Google Messaging (RCS) which is the next category.¶
There are a very small number of these providers today. Many, but not all, are gatekeepers. Most are extremely large, supporting millions or more consumers. It is reasonable to expect the smaller, non-gatekeeper ones, to directly request interop with the gatekeepers as it is core to their business.¶
The smaller consumer OTT providers will be highly incented to participate in MIMI. They may, or may not, be incented to participate in the discovery service. Some of them do not make use of SII's in their services. For those providers, they would require that their users be reached because users in other APs know the SSI instead. Similarly, for their own users to communicate with other consumer OTT providers, they may require their users to know their SSIs.¶
If we were to only consider the consumer OTTs, we might conclude that SII to SSI mapping (discovery) is not needed - users can just use a drop-down menu of providers when reaching out to another user (this is sometimes called a nascar menu). However, it becomes untenable when you consider the additional use cases below.¶
In this case, the app provider offering services to its consumers is affiliated to the Number Provider (NP) for its users, and therefore has authoritative knowledge of the ownership of phone numbers for its users. The primary use case here is Google Messaging, provided through the Rich Communications Service (RCS) providers, which are the mobile operators, or Google who can operate it on their behalf.¶
There are many operators globally, numbering in the hundreds. Today, the only ones offering consumer messaging are the mobile operators.¶
In this case, another entity - the Cloud Provider (CP) is involved - which is a CCaaS, UCaaS or CPaaS provider offering communications services. The enterprise contracts with the Cloud Provider, which acts as the Application Provider (AP). The Cloud Provider is often also the Number Provider for the enterprise numbers used by enterprise employees. However, the Cloud Provider will often instead themselves contract with NPs to obtain numbers for its enterprise customers, which can then route to it over private SIP trunks for voice, and usually some non-SIP APIs for messaging. Examples of enterprise cloud APs are Five9, Cisco Webex, RingCentral, Microsoft Teams, Zoom, and so on.¶
The enterprise use case brings an additional consideration as well - in that many numbers (and email addresses) represent a service rather than a user. THink of the 1-800 number for a business, or an email address for customer support, or a phone number for an enterprise helpdesk. These are all services, behind which one or more users may reside.¶
There are a relatively small number of larger enterprise cloud players, perhaps numbering the few dozen. They tend to each have a smaller number of users than the consumer providers (typically in the hundreds of thousands to millions of users). They also have economic incentive to request interop with the gatekeepers, since it reduces their direct costs for routing messages, voice and video calls. It would also likely increase the appeal of their products, which could offer consumer interconnection as part of their offerings, along with b2b federation between cloud providers.¶
For enterprise clouds to participate in MIMI, the discovery solution is much more important. This is because these companies are often not brands that are not consumer recognizable, there are too many of them to fit in a selector UI, and it is often impossible for a sender of a message to figure out what provider the recipient is on. This is especially problematic for the case where the SII represents a service and not a user.¶
In this case, the app provider offering messaging services is an enterprise, who is doing so through on-premise messaging software they deploy and operate. The enterprise will always be the Email Provider (EP), but they are not the Number Provider (NP). That said, the enterprise connects to the NP via SIP trunks to enable calls to/from those numbers to reach it. One can think of this as the case where the enterprise is its own cloud provider. These cases are less common these days, but still exist. Examples are any enterprises running Cisco Jabber on-prem or Microsoft OCS or LCS on prem.¶
There are of course a large number of enterprises in the world which have historically had some kind of on-prem software, numbering in perhaps the hundreds of thousands. The ones which still do so is much smaller, but still a much larger number than the number of enterprise cloud providers. These enterprises are less likely to request interop with gatekeepers, just because they each serve a much smaller number of users and their incentives for doing so are less.¶
For enterprise on-prem use cases, the discovery service is absolutely required for their users to be reached for inbound communications. There is simply no way that other users will be able to select from a dropdown list of company names.¶
In this last case, the app provider offering messaging services is the consumer themselves, who is running some software in their home network or in a public cloud compute environment, which they deploy and operate. The consumer is neither an NP or an EP. This is a relatively uncommon case these days. It was not uncommon for people to run their own mail services for their home, but since messaging has predominantly been cloud based it is not as common there. That said, it is certainly possible for a consumer to run (for example) their own Matrix server in their home for their family.¶
It is extremely unlikely a consumer on-prem user would ever request interop with a gatekeeper. And, discovery is absolutely needed for the user to be reached for inbound communications.¶
There are four key requirements:¶
Mapping: The service must provide a way to map from a SII to a SSI.¶
Validity: The mappings provided by the service must be represent the wishes of the user associated with the SII, mapping to an application they are a user of, and the mapped SSI must be the one associated with this user. The core issue is one of trust, and how to determine that the mappings provided by the service are accurate.¶
Critical Mass: The network effects problem is perhaps the hardest to solve. But, to be viable, any solution must be able to reach a critical mass of mappings so that it becomes useful to consume, and thus useful to further populate.¶
Incentive Alignment: There must be an incentive structure which motivates the population of mappings into the service, and for the consumption of those mappings.¶
Zero APs: The system should work when a user - and their SIIs - are not associated with any APs. In this case, the discovery operation should indicate a no-match. This would enable an originating user to learn that, they cannot reach that SII.¶
One AP: The system should work in the simple case when a user as a single AP.¶
Multiple APs with Default: The system should enable a user to have multiple APs. The discovery service should enable user preference to be considered, so that a user can choose a default AP to use.¶
Business vs. Consumer AP: It should also be possible for a user to indicate that different APs are used for business purposes vs. consumer purposes. As an example of this case, user Alice might use WhatsApp for friends and family, but use Microsoft Teams at work. Her mobile number is used as an SII in both providers. When a user Bob on Webex Teams searches for that number, Bob would only get the Microsoft Teams SSI because their Webex Teams administrator has specified that messaging is between business APs by default. In another use case, Bob would get both of these back and would have the ability to choose whether to use the business or personal AP.¶
Circle Based APs: It should be possible for a user to specify that different APs are to be used for different contacts. For example, user Alice might use WhatsApp when talking to friends, but use iMessage when talking to family. When Bob, Alice's friend enters her number into his messaging app, the result depends on whether Alice has specified that he is a friend vs. family member [NOTE: I think this is probably more than we need and it adds a lot of complexity. I include it here for completeness to explore how deep this rabbit hole goes].¶
Given the significant volume of inquiries which might be sent, caching is a useful feature of the discovery service.¶
Cacheability of Results: The discovery service should allow for mappings to be cached by the AP. The DP must be able to tell the AP the duration over which the mapping can be cached.¶
Cache Invalidation: To handle changes in preferences or SII releases, it must be possible for the DP to inform the AP when a mapping is no longer valid ahead of its cache expiration.¶
When the SII is a phone number, porting comes into consideration.¶
The requirements depend on whether the users operator - basically their number provider (NP) - is also the Application Provider (AP). When these are intertwined, porting a number also changes providers. Consequently, we can break this down into four distinct use cases and requirements.¶
Donating Operator is not the AP, and neither is the recipient. The number port should change nothing, the discovery service should continue to resolve to the AP.¶
Donating Operator is not the AP, but the recipient operator is an AP. The user now effectively has two APs - the OTT one before the port, and now a second one because their new operator is an AP, in essence enrolling them in the service by virtue of being an AP. In this case, it should be possible for a user to express a preference about where to receive incoming messages.¶
Donating Operator is the AP, but the recipient operator is not an AP. In this case, by porting away from their prior operator who was also an AP, the user has terminating their relationship with the messaging provider, and now has no provider at all, since their new operator is not also an AP. As it relates to the discovery service, once the port is complete, the user should be shown as no longer discoverable, and their prior mapping is deleted.¶
Both Operators are APs: In this case, the user has basically moved providers from one to another. As it relates to the discovery service, once the port is complete, the discovery service should indicate that their SSI is now on the new operator/AP.¶
If a user is associated with a phone number by virtue of being a customer of an NP that is providing them that number, their association with that number will end once the user terminates their relationship with their NP. It is typical in telephony systems for that number to go into a waiting pool for several months before it can be reassigned to a different user.¶
For email addresses, it is also possible for a user to lose their association with an email address when they end service with that provider. Although reclamation of email addresses is possible, it is less common. Nontheless, it is technically possible.¶
This release process adds requirements for the discovery service.¶
When a user starts their association to a number or email address, we can think of this as a "claim". Their claim is rooted in the start of services from the Number Provider (NP), Cloud Provider (CP) or Email Provider (EP) towards the user. This introduces a timeliness requirement.¶
A key consideration is - who runs, or can run, the discovery service?¶
Multiple Providers are Possible: One can imagine a design for the discovery service in which there is a single, worldwide global provider of the discovery service. This would certainly simplify the protocol and its security properties. There are some precedents for a singleton provider of service in the Internet - see ICANN and IANA. However, neither of these run operational services. Even the Internet's primary global service - the DNS - is in practice distributed amongst many different entities that run and operate the top level domain name servers. As a result, the discovery service should follow a similar pattern and allow for multiple providers of the discovery service.¶
Organizational Principles deliver trust: Once we accept that there can be many such providers of discovery services, how would an application provider (AP) know whether to trust the mappings that it provides? One answer is - this is just left to the market to decide, and the IETF has nothing to say on the matter. The alternative is that - the IETF defines the solution in such a way that there are ways for trust to be established. As one such example, the solution could be specified such that the solution for phone numbers makes use of existing number ownership structures that support STIR/SHAKEN [RFC8224] [RFC8225]. Or, it could define the solution in such a way that entities which already hold this routing information for messaging apps (i.e. using the Pathfinder service from Neustar which provides this mapping today for the GSMA) expose APIs for it.¶
PII Residency within Geopolitical Boundaries: There are increasingly regulations being passed, like GDPR, which require that personal data remain within certain geopolitical boundaries. Since the discovery service contains such information, it must be possible for the DPs to sit within a geopolitical boundary and hold data for users within those geopolitical boundaries.¶
Invisible to Consumers: There are a class of solutions wherein a DP is directly visible to consumers, who would sign up, verify their number with it, and configure their preferences with it. However, this is unlikely to work in practice. It suffers from a significant network effects problem, such that signing up for the service would provide no value to its users until critical mass is reached. This would disincent users from signing up in the first place. As a result, the only solutions which can really work are those which are invisible to users.¶
Numerous App Providers: This is as much a requirement in MIMI, as it is for the discovery protocol. But, the goal is that we want a system wherein there can be a lot of app providers, many of which are smaller in size. This becomes even more obvious when we consider enterprise use cases, where a business might be its own provider for its own employees, and want them to be able to message consumers as well as other businesses using business numbers or business email addresses. In such a scenario, the number of APs can be in the thousands or more.¶
DP Federation: Because there are multiple DPs, run by different entities, it must be possible for some kind of federation so that an AP can request for a mapping from its own DP, and the mapping can be provided even if it resides within a different DP. Note that - this requirement could be contested. There is an alternative world view, wherein each AP needs to connect to every DP, with each DP holding a subset of the mapings. The drawback of such a system is, if we think DPs are aligned against geopolitical or organizational boundaries, it may be impossible or impractical for such a full-mesh configuration.¶
DP Federation Policy: Due to geopolitical considerations, it must be possible for a DP to decide to federate, or not federate, with other DPs.¶
If we accept the requirement above that there can be a large number of app providers, including enterprises themselves, there is a large risk that one of them is malicious. The main attack we wish to prevent, is for an AP to claim it has a user associated with a given SII, when it in fact does not. Though MLS would (to the degree e2e identity works against that SII) prevent the recipient from reading messages sent to that SII, it is certainly possible that they can "blackhole" them. This is an attack wherein the malicious AP causes the SII to map to its own SSI, rather than the legitimate SSI for the user. This would deny receipt of messages at the legimiate SSI, and thus is a form of denial of service.¶
The concern over blackhole attacks introduces several key requirements.¶
Malicious AP cannot blackhole against a legitimate AP: A critical security requirement for the discovery service, is that is not possible for a malicious AP to create a blackhole.¶
Malciious AP cannot make a user appear discoverable even though they are not: In this case, a user Bob is not a user of any AP. In a functioning system, they would show as not-discoverable to users searching for them based on their SII. In this attack, a malicious AP tries to convince the discovery service that they are in fact a user of the malicious AP. Even though the malicious AP cannot decrypt the incoming messages, they will cause other users to now view user Bob as discoverable. This is a less severe version of the above attack, but is still an attack. It would potentially fool senders into thinking they have reached a target that is ignoring them, which can cause unintended consequences.¶
Spam is a significant concern in the system, and its risk grows exponentially with the number of APs connected to the system. As noted above, many use cases have a large number of APs, which can pose a serious risk. Spam prevention needs to be considered at both the MIMI layer (using techniques like connection requests and reputation safeguards), but can also be addressed at the discovery service.¶
No Enumeration: The system must protect against an enumeration attack. An enumeration attack is one wherein a malicious AP attempts to look up a large number of SIIs - especially phone numbers which can easily be enumerated as they are finite - in order to learn the SSI assocaited with each. Once an SSI is known, the malicious AP has an address it can add to its spam list. Today, many people avoid listing their email addresses or phone numbers on public websites to prevent spam sites from scraping those identifiers to add them to target lists. We dont want the discovery service to be a nice, convenient and easily farmable source of identifiers for sending spam.¶
Rate Limits: The system must provide rate limit capabilities to restrict an AP from sending too many discovery requests. There must be a way for the Discovery Provider (DP) to assess what a reasonable rate limit might be for that AP.¶
At the risk of stating the obvious, but:¶
Also obvious, but:¶