User Discovery Requirements
draft-interop-mimi-discovery-requirements-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Giles Hogben , Femi Olumofin , Jon Peterson , Jonathan Rosenberg | ||
| Last updated | 2024-11-27 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-interop-mimi-discovery-requirements-02
More Instant Messaging Interoperability (mimi) G. Hogben
Internet-Draft F. Olumofin
Intended status: Informational Google
Expires: 1 June 2025 J. Peterson
TransUnion
J. Rosenberg
Five9
28 November 2024
User Discovery Requirements
draft-interop-mimi-discovery-requirements-02
Abstract
This document defines requirements for the user discovery problem
within the More Instant Messaging Interoperability (MIMI) working
group. User discovery is essential for interoperability, allowing
message senders to locate recipients across diverse platforms using
globally unique, cross-service identifiers (e.g., email addresses,
phone numbers). The core challenge involves reliably mapping these
identifiers to messaging service providers and determining the
reachability of a recipient's identifier across multiple providers.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://datatracker.ietf.org/doc/draft-interop-mimi-discovery-
requirements/. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-interop-mimi-discovery-
requirements/.
Discussion of this document takes place on the mimi Working Group
mailing list (mailto:mimi@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/mimi/. Subscribe at
https://www.ietf.org/mailman/listinfo/mimi/.
Source for this draft and an issue tracker can be found at
https://github.com/femigolu/user-discovery.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Hogben, et al. Expires 1 June 2025 [Page 1]
Internet-Draft Discovery Requirements November 2024
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 1 June 2025.
Copyright Notice
Copyright (c) 2024 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. User Discovery Problem Statement . . . . . . . . . . . . . . 4
4. Prior Efforts . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Summary of Requirements . . . . . . . . . . . . . . . . . . . 5
6. Recipient Authorization of Mappings . . . . . . . . . . . . . 7
7. Recipient Preferences in Mappings . . . . . . . . . . . . . . 7
8. Sender Retrieval of Mappings . . . . . . . . . . . . . . . . 8
9. Mapping Authenticity Verification . . . . . . . . . . . . . . 8
10. Support for Varying Mapping Results . . . . . . . . . . . . . 8
11. Protecting Sender and Recipient Privacy . . . . . . . . . . . 9
12. In-Transit Encryption . . . . . . . . . . . . . . . . . . . . 10
13. Protection Against Enumeration Attacks . . . . . . . . . . . 10
14. Mapping Removal . . . . . . . . . . . . . . . . . . . . . . . 10
15. Security Considerations . . . . . . . . . . . . . . . . . . . 11
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
17. Normative References . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Architectural Models . . . . . . . . . . . . . . . . 13
A.1. Centralized DP (Monolithic Service) . . . . . . . . . . . 13
A.1.1. Advantages . . . . . . . . . . . . . . . . . . . . . 13
Hogben, et al. Expires 1 June 2025 [Page 2]
Internet-Draft Discovery Requirements November 2024
A.1.2. Drawbacks . . . . . . . . . . . . . . . . . . . . . . 14
A.2. Hierarchical DPs (Discovery Resolvers) . . . . . . . . . 14
A.2.1. Advantages . . . . . . . . . . . . . . . . . . . . . 14
A.2.2. Drawbacks . . . . . . . . . . . . . . . . . . . . . . 14
A.3. Federated DPs (Distributed Peer Service) . . . . . . . . 15
A.3.1. Advantages . . . . . . . . . . . . . . . . . . . . . 15
A.3.2. Drawbacks . . . . . . . . . . . . . . . . . . . . . . 15
A.4. Additional Considerations on Architectural Models . . . . 15
A.4.1. Telephone Number CSIs . . . . . . . . . . . . . . . . 15
A.4.2. Bias Mitigation . . . . . . . . . . . . . . . . . . . 16
Appendix B. Recipient's Critical User Journeys . . . . . . . . . 16
Appendix C. Protecting Sender-Recipient Social Graph Edge . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
MIMI user discovery enables a message sender to locate messaging
service providers on which a particular recipient can be reached.
Currently, users often need to ask contacts what service they are on
out-of-band or try multiple services, which creates friction.
Specifically, discovery helps a user on one messaging service (Alice
on Service A) to find another user on a potentially different or the
same service (Bob on Service B) without prior knowledge of Bob's
provider, and in a provider-neutral manner.
Discovery is necessary because the identifiers we commonly have for
contacts (phone numbers, email addresses, etc.) do not necessarily
tell us which messaging service they are using. Someone with the
email alice@gmail.com might use iMessage, Signal, or another service
entirely. Thus, the core problem is how to take one of these cross-
service identifiers and learn the messaging service provider that the
user is using and how to communicate with them on that service.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1. _Cross-Service Identifier (CSI)_: A globally unique identifier
for a user across multiple services (e.g., E.164 phone number,
email address).
2. _Cross-Service Identifier Provider (CSIP)_: An entity that issues
and manages CSIs (e.g., telecom providers, email providers).
Hogben, et al. Expires 1 June 2025 [Page 3]
Internet-Draft Discovery Requirements November 2024
3. _Messaging Service Provider (MSP)_: An entity offering messaging
services to end users (e.g., WhatsApp, Signal, iMessage).
4. _Service Specific Identifier (SSI)_: A unique identifier for a
user within a single MSP (e.g., a Twitter handle).
5. _Discovery Provider (DP)_: An entity that stores and facilitates
the discovery of MSPs for a given CSI. A DP may be operated by
an MSP or a third party.
6. _Verifiable Mapping_: A representation of the cryptographic
binding of a CSI and the set of MSPs where the CSI is reachable.
7. _Recipient_: A user who possesses a CSI that has been assigned by
a CSIP and authorizes verifiable mapping of that CSI to an MSP
set.
8. _Sender_: A user who queries a DP to discover the MSPs for a
given CSI.
3. User Discovery Problem Statement
User discovery involves two key aspects:
1. _Authorization_: Recipients must be able to authorize verifiable
mappings between their CSIs and their chosen MSPs.
2. _Lookup_: Senders must be able to query these mappings to
determine where a recipient can be reached.
To authorize verifiable mappings, the recipient must:
* Possess a valid, CSIP-issued CSI.
* Have active accounts with each MSP to be mapped.
* Associate the CSI with each of those accounts.
Discovered mappings must be verifiable to ensure they are accurate.
Crucially, discovery must prioritize user privacy, allowing users to
control their discoverability, and it must integrate well with end-
to-end encryption and other MIMI protocols.
*Note:* This document focuses on discovering _which_ MSPs a user is
on. Retrieving SSIs and cryptographic keys can be a separate,
subsequent step.
Hogben, et al. Expires 1 June 2025 [Page 4]
Internet-Draft Discovery Requirements November 2024
The rest of this document describes a series of requirements for the
discovery problem.
4. Prior Efforts
Discovery services are far from new on the Internet. The whois
protocol [RFC3912], largely focused on mapping domain names to
associated services, was one of the earliest discovery services
deployed on the Internet. DNS SRV records, specified in [RFC2782],
allow a similar process - given a domain name, a user can discover
available services, such as VoIP based on the Session Initiation
Protocol (SIP) [RFC3261] [RFC3263]. SRV records were adapted
specifically for messaging in [RFC3861]. However, both whois and DNS
SRV records rely on domain names as lookup keys, making them
unsuitable for identifiers like mobile phone numbers, which don't
have inherent domain associations.
ENUM [RFC6117] addressed this limitation. It used DNS to look up
phone numbers by reversing the digits and adding the "e164.arpa"
suffix. This allowed delegation of portions of the namespace to
telecom providers who owned specific number prefixes. While
technically straightforward, public deployment of ENUM was hampered
by challenges in establishing authority for prefixes. However,
private ENUM [RFC6116] services have become relatively common,
facilitating functions like MMS routing within messaging.
Another attempt was ViPR (Verification Involving PSTN Reachability)
[I-D.rosenberg-dispatch-vipr-overview] [I-D.petithuguenin-vipr-pvp].
ViPR utilized a peer-to-peer network based on RELOAD (Resource
Location and Discovery) [RFC6940] to operate between enterprises. It
addressed the authority problem by authorizing records based on proof
of forward routability but faced the same network effects issue as
ENUM. ViPR attempted to address incentive problems by focusing on
enterprises seeking cost savings by bypassing the phone network.
Ultimately, network effects challenges (among other protocol-
unrelated issues) prevented widespread deployment.
Discovery and lookup services are now commonplace on the Internet but
are largely scoped within large providers such as Facebook, Twitter,
WhatsApp, and others.
The MIMI discovery service requires a solution that works across
providers.
5. Summary of Requirements
This section provides a summary of the requirements for MIMI user
discovery.
Hogben, et al. Expires 1 June 2025 [Page 5]
Internet-Draft Discovery Requirements November 2024
+=====+==============================+===========+==========+
| # | Requirement | Mandatory | Optional |
+=====+==============================+===========+==========+
| | *Recipients* | | |
+-----+------------------------------+-----------+----------+
| R1 | Only the recipient MUST be | x | |
| | able to authorize verifiable | | |
| | mapping of the recipient's | | |
| | CSI to an MSP set | | |
+-----+------------------------------+-----------+----------+
| R2 | A mapping MUST allow for the | x | |
| | inclusion of tags or similar | | |
| | constructs to indicate the | | |
| | recipient's preferences for | | |
| | using each included MSP | | |
+-----+------------------------------+-----------+----------+
| | *Senders* | | |
+-----+------------------------------+-----------+----------+
| R3 | Senders MUST be able to | x | |
| | retrieve all verifiable | | |
| | mappings for a CSI | | |
+-----+------------------------------+-----------+----------+
| R4 | Senders MUST be able to | x | |
| | verify the authenticity of | | |
| | mappings | | |
+-----+------------------------------+-----------+----------+
| | *Discovery Provider* | | |
+-----+------------------------------+-----------+----------+
| R5 | Discovery MUST support | x | |
| | results with zero, one, or | | |
| | multiple mappings | | |
+-----+------------------------------+-----------+----------+
| R6 | DPs MUST NOT be able to | x | |
| | learn both the sender's | | |
| | identity and the recipient's | | |
| | CSI | | |
+-----+------------------------------+-----------+----------+
| R7 | All data exchanged in the | x | |
| | processing of a discovery | | |
| | request MUST be encrypted in | | |
| | transit | | |
+-----+------------------------------+-----------+----------+
| R8 | DPs SHOULD be protected | | x |
| | against enumeration attacks | | |
+-----+------------------------------+-----------+----------+
| R9 | DPs MUST provide a way to | x | |
| | remove mappings | | |
+-----+------------------------------+-----------+----------+
Hogben, et al. Expires 1 June 2025 [Page 6]
Internet-Draft Discovery Requirements November 2024
| R10 | Only the recipient or the | | x |
| | CSIP SHOULD be able to | | |
| | remove mappings | | |
+-----+------------------------------+-----------+----------+
Table 1
6. Recipient Authorization of Mappings
_R1: Only the recipient MUST be able to authorize verifiable mapping
of the recipient's CSI to an MSP set._
This requirement prevents unauthorized mapping and potential
impersonation attacks. The integrity of mappings requires the
recipient to be the sole party to authorize mappings of the
recipient's CSI to the designated MSP set. Allowing any other user
besides the recipient to authorize the creation of verifiable
mappings could open the recipient to impersonation attacks, where the
MSP set will include MSPs where the attacker controls the accounts.
It is expected that the recipient has active accounts with each MSP
in the set and has already linked the CSI with each of those MSP
accounts. If a recipient includes MSPs that do not meet these
preconditions, the recipient will not be reachable on the incorrect
MSPs. While this problem can be resolved if each MSP participates in
creating verifiable mappings to confirm the recipient's account
exists, mapping creation will be more involved. Hence, this issue is
deferred as a post-discovery problem to address.
7. Recipient Preferences in Mappings
_R2: A mapping MUST allow for the inclusion of tags or similar
constructs to indicate the recipient's preferences for using each
included MSP._
This requirement allows recipients to guide how senders contact them
on different MSPs. For example, a preference tag may be formulated
as closed or open-ended strings (e.g., "Business", "Personal",
"BasketballFriends", "WhatsApp") or a list (e.g., "Business,
WhatsApp"). A recipient might want senders to utilize a specific
"Business" mapping for business messaging and a different one for
other types of messaging.
Hogben, et al. Expires 1 June 2025 [Page 7]
Internet-Draft Discovery Requirements November 2024
This requirement prioritizes recipient preferences because senders
already have flexibility in choosing their MSP (and potentially DP)
when initiating requests. Further considerations regarding sender
and DP preferences, as well as more complex recipient preferences,
are deemed to be implementation issues. See Appendix B: Recipient's
Critical User Journeys for some more examples for recipients.
8. Sender Retrieval of Mappings
_R3: Senders MUST be able to retrieve all verifiable mappings for a
CSI._
This requirement ensures senders have complete information for
reaching a recipient. When a sender queries for mappings established
for a given recipient's CSI, all available verifiable mappings that
exist must be returned as a response.
9. Mapping Authenticity Verification
_R4: Senders MUST be able to verify the authenticity of mappings._
This requirement enables senders to trust the mapping information.
On receipt of the mappings that exist for a recipient's CSI, the
sender should have a means to verify the authenticity of the mappings
by learning that the recipient authorized that mapping. The
verification process may leverage all or parts of the mapping content
and may involve network calls to an oracle to help with the
verification, provided the oracle query process is consistent with
Requirement 6.
10. Support for Varying Mapping Results
_R5: Discovery MUST support results with zero, one, or multiple
mappings._
This requirement covers cases where a user has no mappings, has opted
out of discovery, or uses multiple MSPs. Regardless of how the
verifiable mapping structure is represented (e.g., one CSI to a set
of MSPs, or one CSI to one MSP repeated for each MSP), senders must
be able to determine the following from a user discovery response for
a given CSI:
* No mapping exists, e.g., the recipient has not created any
mapping.
* One or more mappings exist, but without listed MSPs, e.g., the
recipient has intentionally configured discovery to return no
mappings.
Hogben, et al. Expires 1 June 2025 [Page 8]
Internet-Draft Discovery Requirements November 2024
* One mapping exists with one listed MSP.
* One mapping exists with multiple listed MSPs.
* Multiple mappings exist, each potentially with a different number
of MSPs.
In situations where the recipient who authorized mappings using a
CSI, such as an email address, becomes unreachable (e.g., due to the
user's death), implementations can rely on the MSPs included in the
mapping to resolve non-reachability issues outside user discovery.
11. Protecting Sender and Recipient Privacy
_R6: DPs MUST NOT be able to learn both the sender's identity and the
recipient's CSI._
This requirement prevents the DP from building a complete social
graph of users across MSPs. This protects user privacy by limiting
the information the DP can gather about relationships between senders
and recipients.
User discovery lookups inherently create a connection point (an edge)
on the social graph between the sender and the recipient. To protect
the privacy of both parties, the DP must be prevented from learning
this connection consisting of the sender's identity and the
recipient's CSI/mapping. Specifically, the DP can learn at most one
of the following:
1. Identifying information about the sender, such as their source IP
address, username, etc.
2. The recipient's CSI and any associated response mappings.
While the DP might be able to infer this edge or connection later if
both users communicate through the same MSP, this requirement focuses
on preventing the DP from directly learning this during discovery.
To understand the importance of this, it's helpful to distinguish
between two types of social graphs:
* Messaging social graph: Reflects actual communication between
users.
* Discovery social graph: Encompasses all attempted user discovery
lookups, which can be significantly larger than the messaging
social graph, as it includes searches for users the sender may not
ultimately contact.
Hogben, et al. Expires 1 June 2025 [Page 9]
Internet-Draft Discovery Requirements November 2024
Protecting user privacy during discovery is crucial because, without
it, a sender's entire discovery social graph could be revealed during
bulk discovery that requires the lookup of all contacts on the
sender's address book, which exposes a much broader range of
potential connections than their actual messaging activity.
Appendix C Protecting Sender-Recipient Social Graph Edge has some
recommendations for implementation.
12. In-Transit Encryption
_R7: All data exchanged in the processing of a discovery request MUST
be encrypted in transit._
This requirement ensures the confidentiality of discovery requests
and responses.
13. Protection Against Enumeration Attacks
_R8: DPs SHOULD be protected against enumeration attacks._
This requirement ensures there is a security defense against attacks
aimed at scraping mapping data. Discovery providers should implement
mechanisms to defend against large-scale scraping of mappings from
their database, which can be used to compile spam targeting lists.
One potential implementation approach is to utilize time-bound blind
signatures. This method limits the number of user discovery lookups
a sender can perform within a given timeframe. Each lookup request
must include a unique, unblinded signature that cannot be linked to
the sender's identity. To facilitate rate-limiting across different
server entities (e.g., DPs and MSPs), this unique signature should be
passed along during communication.
14. Mapping Removal
_R9: DPs MUST provide a way to remove mappings._
_R10: Only the recipient or the CSIP SHOULD be able to remove
mappings_
These requirements allow recipients to manage their discoverability
and remove outdated mappings. Authorization to remove verifiable
mappings for a given CSI should be limited to only the recipient who
authorized the mapping or the CSIP managing that CSI (for cases where
a CSI is no longer assigned to any recipient).
Hogben, et al. Expires 1 June 2025 [Page 10]
Internet-Draft Discovery Requirements November 2024
Recipients can change their minds and decide to make a prior mapping
not discoverable; they may want to update mappings or start all over.
Thus, a DP should provide a means to remove verifiable mappings.
Once removed, a mapping should no longer be returned for senders'
requests.
A recipient that authorized the creation of a verifiable mapping
should also be able to authorize its removal from the backend of DPs.
Similarly, a CSIP may request the removal of mappings for a CSI that
has become unassigned.
A possible implementation approach is for verifiable mapping
authorization to include a bit that the recipient can use to indicate
if a mapping is new. When that bit is set, a DP may proactively de-
list any existing mapping for that CSI (after asking the user to re-
confirm). Note that the CSIP does not need to be aware of or be
involved with the de-listing of mappings with such an approach.
There are other approaches to ensure mappings are fresh and are not
impacted when the same CSI is transferred between two recipients.
15. Security Considerations
Security considerations are addressed throughout the document,
particularly in requirements R1, R4, R6, R7, and R8. These
requirements focus on preventing unauthorized mapping, ensuring the
authenticity of mappings, protecting user privacy, and securing data
in transit and at rest.
16. IANA Considerations
This document has no IANA actions.
17. Normative References
[I-D.petithuguenin-vipr-pvp]
Petit-Huguenin, M., Rosenberg, J., and C. F. Jennings,
"The Public Switched Telephone Network (PSTN) Validation
Protocol (PVP)", Work in Progress, Internet-Draft, draft-
petithuguenin-vipr-pvp-04, 12 March 2012,
<https://datatracker.ietf.org/doc/html/draft-
petithuguenin-vipr-pvp-04>.
Hogben, et al. Expires 1 June 2025 [Page 11]
Internet-Draft Discovery Requirements November 2024
[I-D.rosenberg-dispatch-vipr-overview]
Rosenberg, J., Jennings, C. F., and M. Petit-Huguenin,
"Verification Involving PSTN Reachability: Requirements
and Architecture Overview", Work in Progress, Internet-
Draft, draft-rosenberg-dispatch-vipr-overview-04, 25
October 2010, <https://datatracker.ietf.org/doc/html/
draft-rosenberg-dispatch-vipr-overview-04>.
[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/rfc/rfc2119>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/rfc/rfc2782>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/rfc/rfc3261>.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
DOI 10.17487/RFC3263, June 2002,
<https://www.rfc-editor.org/rfc/rfc3263>.
[RFC3861] Peterson, J., "Address Resolution for Instant Messaging
and Presence", RFC 3861, DOI 10.17487/RFC3861, August
2004, <https://www.rfc-editor.org/rfc/rfc3861>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/rfc/rfc3912>.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
<https://www.rfc-editor.org/rfc/rfc5222>.
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)", RFC 6116,
DOI 10.17487/RFC6116, March 2011,
<https://www.rfc-editor.org/rfc/rfc6116>.
Hogben, et al. Expires 1 June 2025 [Page 12]
Internet-Draft Discovery Requirements November 2024
[RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
Registration of Enumservices: Guide, Template, and IANA
Considerations", RFC 6117, DOI 10.17487/RFC6117, March
2011, <https://www.rfc-editor.org/rfc/rfc6117>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/rfc/rfc6376>.
[RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S.,
and H. Schulzrinne, "REsource LOcation And Discovery
(RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940,
January 2014, <https://www.rfc-editor.org/rfc/rfc6940>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8616] Levine, J., "Email Authentication for Internationalized
Mail", RFC 8616, DOI 10.17487/RFC8616, June 2019,
<https://www.rfc-editor.org/rfc/rfc8616>.
Appendix A. Architectural Models
This appendix explores various architectural models for MIMI DP to
provide an overview and address practical implementation
considerations. The working group observed these requirements are
similar among these models and opted to maintain architectural
neutrality for the discovery protocol. However, we will outline
requirements for the roles of DPs, how they interact with each other,
MSPs in a federated model, and how DPs accommodate queries from both
MSPs and users.
A.1. Centralized DP (Monolithic Service)
A globally accessible, authoritative database (potentially sharded/
replicated) stores all authenticated CSI mappings. This monolithic
service, implemented across synchronized global nodes, handles all
CSI queries from messaging platforms and acts as the single source of
truth for mapping data, even if certain mappings may be restricted in
specific regions due to geopolitical considerations.
A.1.1. Advantages
* Standardization and uniform control over mapping creation,
updates, and data formats.
Hogben, et al. Expires 1 June 2025 [Page 13]
Internet-Draft Discovery Requirements November 2024
* Promotes fair and unbiased CSI mapping discovery.
* Single source of truth for mapping simplifies data management and
ensures consistency.
* Sharding/replication can address geographical distribution and
performance needs.
A.1.2. Drawbacks
* Centralization of sensitive user data raises privacy risks.
* May conflict with data localization regulations.
* Single point of failure vulnerability from outages affecting the
entire system.
* Potential difficulty with immediate global updates for rapidly
changing mappings.
A.2. Hierarchical DPs (Discovery Resolvers)
A global root Discovery Provider (DP) directs mapping requests to
authoritative DPs based on CSI structure (e.g., country codes for
E.164 phone numbers) or sharding mechanisms. The root DP, similar to
hierarchical DNS, acts as a directory service, holding pointers to
authoritative DPs rather than mappings themselves. Alternatives to
hierarchical resolution, like the LoST protocol [RFC5222], or
distributed hash tables (DHTs), can achieve similar outcomes.
A.2.1. Advantages
* Scalability from distributed load and mapping management across
multiple DPs.
* Flexibility that allows different DPs to specialize in specific
CSI ranges for regions.
* Better alignment with data localization requirements.
A.2.2. Drawbacks
* Requires coordination and maintenance of hierarchy.
* Root DP failure could disrupt the entire system.
* Potential delays due to additional hops in the discovery process.
Hogben, et al. Expires 1 June 2025 [Page 14]
Internet-Draft Discovery Requirements November 2024
A.3. Federated DPs (Distributed Peer Service)
In a federated model, multiple independent DPs collaborate to provide
CSI mapping discovery. Each DP holds a subset of mappings and
pointers to other DPs, with no central authority dictating mapping
locations. Discovering all mappings for a CSI may involve querying
multiple DPs. DPs can exchange CSI information or recursively query
each other. The specifics of DP federation are determined by
business agreements, not technical requirements. A variation of this
model involves messaging platforms acting as their own DPs, managing
mappings for their users.
A.3.1. Advantages
* Decentralization ensures there is no single point of control or
failure. The system can continue functioning even if some DPs are
unavailable.
* Mappings can be distributed according to local regulations.
A.3.2. Drawbacks
* Discovery process may involve querying multiple DPs, increasing
network load.
* Potential for bias as DPs may prioritize their own mappings,
leading to uneven results.
* Requires robust mechanisms to prevent CSI impersonation and ensure
trust between DPs.
* Pairwise relationships in a federated DP model could create a
barrier to entry for smaller MSP/DPs, similar to the trust
requirements in the DKIM [RFC6376] and DMARC [RFC8616] ecosystems.
A.4. Additional Considerations on Architectural Models
A.4.1. Telephone Number CSIs
Telephone number portability is complex due to its reliance on real-
time queries to proprietary and legacy systems. Overall, the
authenticated mappings proposed for MIMI may necessitate additional
platform measures to assess mapping freshness and ensure up-to-date
reachability responses.
Hogben, et al. Expires 1 June 2025 [Page 15]
Internet-Draft Discovery Requirements November 2024
A.4.2. Bias Mitigation
Bias occurs when a DP prioritizes mappings to its affiliated MSP
without consideration of what is best for end users. Mitigating bias
is essential to ensure fair and equitable discovery of authenticated
mappings across different services. The working group has decided to
defer such mitigation to policies and regulations, excluding it from
the discovery protocol.
Appendix B. Recipient's Critical User Journeys
Here are some Critical User Journeys (CUJs) that are the most
important to discovery recipients.
In the CUJs below, Bob is the recipient that creates verifiable
mappings, and Alice is the sender or user performing discovery:
1. Sender mapping preferences: Bob only wants to be found by Alice
and other users on WhatsApp, not his other messaging apps.
2. Same-app preferences: Bob prefers that Alice can find him on the
same messaging service that she is using. In other words, Bob
does not want cross-app discovery and messaging.
3. No-random mapping preferences: Bob does not want to go through
multiple apps to find a message from Alice when discovery returns
one of 10 mappings that Bob has established with discovery
providers.
4. No-duplication preferences: Bob does not want Alice's messages to
be broadcasted to all or a subset of his apps based on the result
of discovery.
5. Per-sender preferences: Bob wants to control which app messages
from Alice go to and do the same for other users (e.g., Carol's
messages may go to a different app than Alice's).
6. Closed group preferences: Bob only wants his soccer parents to
discover and contact him on WhatsApp, not his Wire app. That is,
a group of senders has the same mapping results based on Bob's
preferences.
7. Open-ended group preferences: Bob wants his business contacts to
discover and reach him on Wire, not WhatsApp. That is, an open-
ended list of senders (i.e., including leads) are provided with a
designated mapping.
Hogben, et al. Expires 1 June 2025 [Page 16]
Internet-Draft Discovery Requirements November 2024
Appendix C. Protecting Sender-Recipient Social Graph Edge
To protect user privacy, implementations should consider:
1. Sender Identity Protection: This approach focuses on concealing
the sender's identity from the Discovery Provider (DP).
Techniques like IP blinding (e.g., using a Private Relay) can be
employed to achieve this, ensuring the DP only learns the
recipient's CSI.
2. Recipient Identity Protection: This approach aims to hide the
recipient's CSI from the DP. Methods like Private Information
Retrieval (PIR) or Private Set Membership (PSM) allow the sender
to perform the lookup without revealing the recipient's
information to the DP, effectively limiting the DP's knowledge to
the sender's identity.
Acknowledgments
We gratefully acknowledge the valuable feedback and constructive
discussions received within the working group, in individual
conversations, and during the MIMI interim meetings, as well as IETF
119, 120, and 121.
Authors' Addresses
Giles Hogben
Google
United States of America
Email: gih@google.com
Femi Olumofin
Google
United States of America
Email: fgolu@google.com
Jon Peterson
TransUnion
United States of America
Email: jon.peterson@transunion.com
Jonathan Rosenberg
Five9
United States of America
Email: jdrosen@jdrosen.net
Hogben, et al. Expires 1 June 2025 [Page 17]