**Session Date/Time:** 18 Sep 2024 16:00

# [MIMI](../wg/mimi.html)

## Summary

The MIMI Working Group held an interim meeting to discuss updates to the Discovery requirements document (draft-ietf-mimi-discovery-requirements). FEI presented the changes made since IETF 120, focusing on clarifications regarding verifiable mapping distribution, recipient preference handling, and security considerations. The chair indicated that the working group is preparing for an adoption call for this document.

## Key Discussion Points

*   **Discovery Requirements Document Update**: FEI presented changes to the `draft-ietf-mimi-discovery-requirements` document, incorporating feedback from IETF 120.
*   **Verifiable Mapping Distribution**:
    *   Clarification was added that a representation of a computed mapping (CSI to MSP) can be distributed by Discovery Providers (DPs) other than the one that computed it.
    *   The mapping must include metadata allowing any party to cryptographically verify that the client, MSP, and DP were jointly involved in its computation.
    *   Users do not need to trust the DP distributing the mapping, as verification is based on cryptographic proofs (e.g., signatures).
*   **Recipient Preference Handling**:
    *   The draft now proposes using "tags" (string values) instead of a "preference index or string" for recipient preferences.
    *   Users can tag their mappings (e.g., "WhatsApp," "friend," "personal").
    *   One mapping can be marked with a "default" tag to indicate a preferred way to reach the user.
    *   If multiple mappings are returned with equal preference (e.g., all default), implementations are encouraged to pick one consistently and save the state to avoid message bouncing.
    *   **Privacy Concerns with Tags**: Rowan raised a privacy concern that broad tag disclosure (e.g., a "kinky fetish group" tag) could inadvertently reveal sensitive information when a general query returns all tags.
    *   **Proposed Solutions**:
        *   FEI suggested using code names for sensitive tags.
        *   Rowan suggested an attribute for tags indicating if an exact match is required, or if it should be omitted from general queries.
        *   A URI-based tag space was later suggested, allowing for registered and user-defined portions.
*   **Handling Reissued Phone Numbers**:
    *   A requirement was clarified for new owners of a reissued phone number: their first mapping for that CSI should signal to DPs to invalidate any existing mappings associated with the previous owner of that number.
*   **Security and Abuse Prevention**:
    *   Standard security requirements are included (e.g., all data exchange over encrypted channels).
    *   **Black-Box Prevention/Rate Limiting**: Discussion on preventing enumeration of mappings by attackers (e.g., learning all phone numbers mapped to a DP).
    *   The chair questioned the feasibility of rate limiting for distinguishing legitimate bootstrapping (e.g., uploading an entire address book) from malicious attacks, given the expected volume.
    *   FEI explained that rate limiting is straightforward for identifiable users. For anonymous users, techniques like blind signatures with limited, time-bound tokens could be used (e.g., a budget of 50 queries within a 24-hour window, with tokens renewed after expiry). The sense of those present was that stating the requirement at this level is acceptable if such mechanisms are broadly considered feasible.
*   **High-Level Considerations (not immediate protocol requirements)**:
    *   The draft highlights the need for a protocol for inter-DP communication (e.g., exchanging mappings, serving queries).
    *   Data sovereignty concerns (e.g., data residency within specific regions like the EU) need to be addressed in practical implementations.
    *   A registry for DPs is needed to enable DPs to discover and communicate with each other when a query response is not locally available.
    *   **Scale of DPs**: Rowan inquired about the expected number of DPs, with FEI suggesting potentially hundreds or even thousands over time to allow for small players to participate.

## Decisions and Action Items

*   **Decision**: The Working Group will prepare for an adoption call for `draft-ietf-mimi-discovery-requirements`.
*   **Action Item**: The Working Group Chair will initiate the call for adoption for `draft-ietf-mimi-discovery-requirements` on the mailing list.
*   **Action Item**: All participants are encouraged to perform a close review of the latest draft and provide feedback on the mailing list in response to the adoption call.

## Next Steps

*   Following a successful adoption call, `draft-ietf-mimi-discovery-requirements` will be moved to the Working Group's GitHub repository for issue and pull request tracking.
*   The next interim meeting is tentatively scheduled for two weeks from now, with a focus on protocols and privacy metadata. The meeting may be canceled if there are no significant updates.
*   Rowan indicated plans to work on rule-based access control, selective disclosure of information, and anti-abuse topics, hoping to discuss at least one or two of these at the next interim.
*   The document editors will review and reply to recent feedback on the content format.