Internet DRAFT - draft-rosenberg-mimi-taxonomy
draft-rosenberg-mimi-taxonomy
Mimi J. Rosenberg
Internet-Draft Five9
Intended status: Standards Track 23 October 2022
Expires: 26 April 2023
A Taxonomy for More Messaging Interop (MIMI)
draft-rosenberg-mimi-taxonomy-00
Abstract
This document introduces a taxonomy and use cases for More Messaging
Interop (mimi). This taxonomy includes how users initiate messaging,
how recipients receive initial messages, and so on.
Status of This Memo
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 26 April 2023.
Copyright Notice
Copyright (c) 2022 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.
Rosenberg Expires 26 April 2023 [Page 1]
Internet-Draft MIMI Taxonomy October 2022
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Initiator Knowledge . . . . . . . . . . . . . . . . . . . . . 2
3. Recipient Approval . . . . . . . . . . . . . . . . . . . . . 4
4. Identity Conveyance . . . . . . . . . . . . . . . . . . . . . 5
5. Federation Model . . . . . . . . . . . . . . . . . . . . . . 6
6. SII Type . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. 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.
2. 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.
Rosenberg Expires 26 April 2023 [Page 2]
Internet-Draft MIMI Taxonomy October 2022
* 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.
Rosenberg Expires 26 April 2023 [Page 3]
Internet-Draft MIMI Taxonomy October 2022
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:
Service Initiator Knowledge
iMessage SII (mobile number, email)
RCS/SMS SII (mobile number)
WhatsApp SII (mobile number)
Facebook Messenger PII (Facebook graph search)
Twitter DM SSI (twitter handle)
KaokaoTalk SSI (KaokaoTalk) and SII (mobile number)
3. 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.
Rosenberg Expires 26 April 2023 [Page 4]
Internet-Draft MIMI Taxonomy October 2022
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.
4. 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.
Rosenberg Expires 26 April 2023 [Page 5]
Internet-Draft MIMI Taxonomy October 2022
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.
5. 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.
6. 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.
Rosenberg Expires 26 April 2023 [Page 6]
Internet-Draft MIMI Taxonomy October 2022
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.
7. Normative References
[I-D.ietf-mls-architecture]
Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., Kwon,
A., and A. Duric, "The Messaging Layer Security (MLS)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-mls-architecture-09, 19 August 2022,
<https://www.ietf.org/archive/id/draft-ietf-mls-
architecture-09.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Author's Address
Jonathan Rosenberg
Five9
Email: jdrosen@jdrosen.net
Rosenberg Expires 26 April 2023 [Page 7]
