]> Phoenix R&D

konrad@ratchet.ing

Phoenix R&D

ietf@raphaelrobert.com

Applications and Real-Time More Instant Messaging Interoperability identity TODO Abstract About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the More Instant Messaging Interoperability Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction

• MIMI currently doesn't make assumptions about names beyond the URI format introduced in
• Different messaging applications use different schemes
• MIMI should be able to support at least the most widely used ones

Identifier types

Identifiers for connection establishment

• Globally unique
• User-facing
• Often chosen by user
• Multiple identifiers per user possible
• User can add/delete identifiers dynamically
• Examples:
  • Phone numbers
  • Signal-style usernames
  • Matrix-style usernames
  • Administrative identifiers

Administrative identifiers

• Globally unique
• Generally not user-facing
• Generally not chosen-facing
• Can be provider-generated
• Server might not be able to link admin to connection establishment identifiers
• Immutable
• Examples
  • UUIDs
  • Matrix-style usernames

Display names (decorative identifiers)

• Not globally unique
• Not necessarily visible to provider
• User-facing
• User-chosen

Proposal for MIMI

Connection establishment

• Multiple options for connection establishment identifiers
  • Phone numbers (draft WIP)
  • Usernames (user chosen names, potentially with format restrictions)
• No requirement for providers to be able to link connection establishment identifiers with administrative identifiers
• Ephemeral identifiers should be allowed

Administrative identifiers

• Should be unique within domain of provider
• Should be immutable
• No other requirement w.r.t. format, i.e. both Matrix-style and UUIDs allowed
• No requirement for user-readability
• These are used for authentication and are included in MLS credentials

Display names

• No strict requirement for hub/provider to have access to display names, may be subject to policy

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

Normative References Cisco The Matrix.org Foundation C.I.C. Phoenix R&D Rohan Mahy Consulting Services The Matrix.org Foundation C.I.C. Phoenix R&D This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room.

Acknowledgments TODO acknowledge.