Session Date/Time: 23 Apr 2024 19:00

MIMI

Summary

The second MIMI interim since IETF 119 focused primarily on user discovery, continuing discussions initiated in Brisbane. Key topics included various Discovery Provider (DP) models (monolithic singleton, hierarchical resolvers, federation), the implications of these models for potential bias and fairness in routing, and the different ways users might interact with the discovery process. The group explored when discovery should occur (message sending vs. contact management) and how to handle multiple authenticated mappings. A significant discussion point was user preferences and capabilities, where it was decided that Discovery's role is not to find common applications between sender and receiver, but rather to facilitate interoperability. Privacy considerations related to social graph exposure and IP blinding were also touched upon.

Key Discussion Points

Administrative Items:
- John Peterson volunteered as note taker.
- The chairs committed to running MIMI interims every two weeks until at least IETF 120 (late July).
Review of Previous Consensus (from IETF 119 in Brisbane):
- The working group assumes a multiplicity of message service providers (MSPs).
- MSPs wish to assert mappings from Service Independent Identifiers (SIIs) (e.g., telephone numbers, email addresses) to their services.
- Message senders need to discover which MSPs map to an SII, with a significant security concern regarding the authenticity of these mappings.
- The discovery problem is twofold: an authentication function (MSP asserting mappings) and a distribution function (DP for authenticated mappings). These may be decoupled.
- The need for clearer terminology than SSI/SII was noted.
- Discovery acts on SIIs; if a Service Specific Identifier (SSI) is already known, discovery is not needed.
- The scope of SIIs for discovery should continue to incorporate both telephone numbers and email addresses (majority support).
- Early discussions suggested DPs might be a logical singleton, but geopolitical sharding is a recognized reality.
Discovery Provider (DP) Models:
- Monolithic Singleton: A logically single, potentially distributed, point where all participating providers provision authenticated mapping data. Similar to traditional numbering databases.
- Hierarchical Resolvers: A "golden root" points to DPs, which may be operated by MSPs or other entities. Similar to DNS delegation. Every requester aims to receive pointers to all eligible DPs for an SII.
- Federation: MSPs run their own DPs and establish business/policy arrangements to share or point to each other's mappings. This model lacks a central "golden root."
Considerations on DP Models (Bias, Fairness, Scope):
- Potential Bias and Fairness: A core question was whether the discovery architecture should eliminate potential bias (e.g., a gatekeeper MSP preferentially routing traffic to its own network).
  - While some argue that fairness is a policy layer enforced by regulators, others believe the design can support or hinder it.
  - The DMA perspective highlights the need for smaller providers to compete fairly, suggesting users should receive consistent mapping sets regardless of the DP consulted.
  - It was noted that even with technical measures, UI design could introduce bias.
  - The group agreed that providing consistent, approximately same responses to the same query, while acknowledging geopolitical and policy constraints, is a sane objective.
- Authenticated TN Mappings: The complexity of real-time databases and commercial implications for telephone number (TN) routing was highlighted, posing challenges for a comprehensive "hoovering up" of all data.
Discovery Invocation and Result Handling:
- When Discovery Happens:
  - Immediately before a message is sent (real-time).
  - At contact registration or continuously for presence/social graph management.
  - Conclusion: The protocol's building blocks should support both scenarios; the specific implementation is up to providers/applications.
- Handling Multiple Mappings: What happens if discovery yields multiple authenticated mappings for an SII?
  - Suggestions included using a consent mechanism where the recipient approves communication on a specific platform.
  - The goal is to enable cryptographic context establishment (e.g., MLS), regardless of whether the first application message is a text or a contact card.
  - It was emphasized that users should be able to opt out of automatic discovery for specific SIIs or contexts (e.g., work vs. personal) or provide hints for manual selection.
  - The authentication of "preferred service" bits by the user (rather than MSP) was suggested to prevent gaming.
User Interaction with Discovery Providers (DPs):
- Three straw-man models were presented, assuming some entities other than MSPs can operate DPs:
  - Platform Driven: Only MSPs talk to DPs; the process is entirely invisible to users. The MSP handles all routing decisions.
  - User Triggered: Users interact with their MSP client, which then performs discovery. Results (e.g., multiple options) may be presented to the user.
  - User Driven: Users directly query DPs, receive authenticated mappings, and then provide their chosen mapping to their MSP for routing. Users have maximum control.
- Discussion on User Interaction Models:
  - Scalability and load on DPs were raised as concerns for user-driven models (billions of devices directly querying DPs).
  - The choice between user-triggered and user-driven might be an application-level decision, though protocol implications (e.g., security associations, access restrictions, geopolitical constraints) exist.
  - Privacy Trade-offs:
    - User-direct-to-DP might reveal more of the social graph to DPs.
    - MSP-proxied queries might offer more privacy, as the DP only sees queries from the MSP, though the MSP itself knows the sender's intent.
    - Conclusion: IP blinding for queries is a desirable feature. Whatever design is chosen must be consistent with MIMI's overall metadata privacy goals and not worsen user privacy.
User Preferences and Capabilities:
- Lessons from SIP Offer/Answer: The experience with SIP's capability negotiation highlights the potential for extreme complexity and pitfalls.
- Protocol Requirements: Any protocol must allow users to express authenticated capabilities/preferences.
- Sender Preferences: A sender might have preferences (e.g., "only use Session app"), which could be client-driven or configured via the MSP.
- Receiver Preferences: The choice of client/provider is crucial for the receiver, as it isn't dictated by the message's origin. Context (work, home, hobby) adds complexity to preference expression.
- Capability Negotiation (Finding Overlap): A specific question was posed: Is Discovery's job to find the intersection of services/applications supported by both sender and receiver (e.g., if both support "C", use "C")?
  - Strong Consensus: No, this is explicitly not the job of Discovery. Such a function would incentivize the use of common "gatekeeper" applications, contrary to the goals of interoperability.
- Simplicity and Abuse: The group emphasized the need for a simple mechanism for preferences, avoiding arbitrary content in records to prevent abuse (harassment, illegal content) and excessive complexity.

Decisions and Action Items

Decision: MIMI will continue bi-weekly interims until at least IETF 120.
Decision: The scope of Service Independent Identifiers (SIIs) for Discovery continues to include both telephone numbers and email addresses.
Decision: It is not the job of the discovery process to find the intersection of messaging services/applications supported by both the sender and receiver for the purpose of capability negotiation. This approach is deemed to disincentivize true interoperability.
Action Item: Participants are encouraged to send concrete requirements to the mailing list derived from the discussions on DP models, user interaction, and preferences.
Action Item: Rowan will follow up with the chairs to schedule a presentation slot for his content format document at the May 8th interim.
Action Item: Participants should review the Mimi meetings page for upcoming interim schedules and agenda updates.

Next Steps

The next MIMI interim is scheduled for May 8th at 9:00 AM Pacific (12:00 PM Eastern), focusing on the content format document.
The discussion on user preferences, privacy considerations, and further refinement of requirements for Discovery Providers and user interaction models is expected to continue at subsequent interims, likely on May 22nd.
Anyone wishing to propose agenda items for future interims should contact the chairs at mimi-chairs@ietf.org.