More Instant Messaging Interoperability (MIMI) using HTTPS and MLS

1.1. Known Gaps

In this version of the document, we have tried to capture enough concrete functionality to enable basic application functionality, while defining enough of a protocol framework to indicate how to add other necessary functionality. The following functions are likely to be needed by the complete protocol, but are not covered here:¶

Authorization policy:

In this document, we introduce a notional concept of roles for participants, and permissions for roles. Concrete authorization policies are defined in [I-D.ietf-mimi-room-policy].¶

Knock and invite flows:

This document describes how user can be added, or how authorized users can add themselves to a group based on the policy of the room. It does not include flows where a user can "knock" to ask to enter a room, nor does it include "invitations", where a user offers information to another user about how to be added to a room.¶

Identifiers:

Certain entities in the MIMI system need to be identified in the protocol. In this document, we define a notional syntax for identifiers, but a more concrete one should be defined.¶

Authentication

While MLS provides basic message authentication, users should also be able to (cryptographically) tie the identity of other users to their respective providers. Further authentication such as tying clients to their users (or the user's other clients) may also be desirable.¶

3.1. Alice Creates a Room

The first step in the lifetime of a MIMI room is its creation on the hub server. This operation is local to the service provider, and does not entail any MIMI protocol operations. However, it must establish the initial state of the room, which is then the basis for protocol operations related to the room.¶

For authorization purposes, MIMI uses permissions based on room-defined roles. For example, a room might have a role named "admin", which has canAddUser, canRemoveUser, and canSetUserRole permisions.¶

Here, we assume that Alice uses ClientA1 to create a room with the following base policy properties:¶

• Room Identifier: mimi://a.example/r/clubhouse¶

• Roles: admin = [canAddUser, canRemoveUser, canSetUserRole]¶

And the following participant list:¶

• Participants: [[mimi://a.example/u/alice, "admin"]]¶

ClientA1 also creates an MLS group with group ID mimi://a.example/g/clubhouse and ensures via provider-local operations that Alice's other clients are members of this MLS group.¶

3.2. Alice adds Bob to the Room

Adding Bob to the room entails operations at two levels. First, Bob's user identity must be added to the room's participant list. Second, Bob's clients must be added to the room's MLS group.¶

The process of adding Bob to the room thus begins by Alice fetching key material for Bob's clients. Alice then updates the room by sending an MLS Commit over the following proposals:¶

• An AppSync proposal updating the room state by adding Bob to the participant list¶

• Add proposals for Bob's clients¶

The MIMI protocol interactions are between Alice's server ServerA and Bob's server ServerB. ServerB stores KeyPackages on behalf of Bob's devices. ServerA performs the key material fetch on Alice's behalf, and delivers the resulting KeyPackages to Alice's clients. Both ServerA and ServerB remember the sources of the KeyPackages they handle, so that they can route a Welcome message for those KeyPackages to the proper recipients -- ServerA to ServerB, and ServerB to Bob's clients.¶

• NOTE: In the protocol, it is necessary to have consent (see Section 8) and access control on these operations. We have elided that step here in the interest of simplicity.¶

3.3. Bob adds Cathy to the Room

The process of adding Bob was a bit abbreviated because Alice is a user of the hub service provider. When Bob adds Cathy, we see the full process, involving the same two steps (KeyPackage fetch followed by Add), but this time indirected via the hub server ServerA. Also, now that there are users on ServerB involved in the room, the hub ServerA will have to distribute the Commit adding Cathy and Cathy's clients to ServerB as well as forwarding the Welcome to ServerC.¶

3.4. Cathy Sends a Message

Now that Alice, Bob, and Cathy are all in the room, Cathy wants to say hello to everyone. Cathy's client encapsulates the message in an MLS PrivateMessage and sends it to ServerC, who forwards it to the hub ServerA on Cathy's behalf. Assuming Cathy is allowed to speak in the room, ServerA will forward Cathy's message to the other servers involved in the room, who distribute it to their clients.¶

3.5. Bob Leaves the Room

A user removing another user follows the same flow as adding the user. The user performing the removal creates an MLS commit covering Remove proposals for all of the removed user's devices, and an AppSync proposal updating the room state to remove the removed user from the room's participant list.¶

One's own user leaving is slightly more complicated than removing another user, because the leaving user cannot remove all of their devices from the MLS group. Instead, the leave happens in three steps:¶

1. The leaving client constructs MLS Remove proposals for all of the user's devices (including the leaving client), and an AppSync proposal that removes its user from the participant list.¶

2. The leaving client sends these proposals to the hub. The hub caches the proposals.¶

3. The next time a client attempts to commit, the hub requires the client to include the cached proposals.¶

The hub thus guarantees the leaving client that they will be removed as soon as possible.¶

3.6. Cathy adds a new device

Many users have multiple clients often running on different devices (for example a phone, a tablet, and a computer). When a user creates a new client, that client needs to be able to join all the MLS groups associated with the rooms in which the user is a participant.¶

In MLS in order to initiate joining a group the joining client needs to get the current GroupInfo and ratchet_tree, and then send an External Commit to the hub. In MIMI, the hub keeps or reconstructs a copy of the GroupInfo, assuming that other clients may not be available to assist the client with joining.¶

For Cathy's new client (ClientC3) to join the MLS group and therefore fully participate in the room with Alice, ClientC3 needs to fetch the MLS GroupInfo, and then generate an External Commit adding ClientC3.¶

Cathy's new client sends the External Commit to the room's MLS group by sending an /update to the room.¶

4.1. Transport layer

MIMI servers communicate using HTTPS. The HTTP request MUST identify the source and target providers for the request, in the following way:¶

• The target provider is indicated using a Host header [RFC9110]. If the provider is using a non-standard port, then the port component of the Host header is ignored.¶

• The source provider is indicated using a From header [RFC9110]. The mailbox production in the From header MUST use the addr-spec variant, and the local-part of the address MUST contain the fixed string mimi. Thus, the content of the From header will be mimi@a.example, where a.example is the domain name of the source provider.¶

• NOTE: The use of the From header field here is not really well-aligned with its intended use. The WG should consider whether this is correct, or whether a new header field would be better. Perhaps something like "From-Host" to match Host?¶

The TLS connection underlying the HTTPS connection MUST be mutually authenticated. The certificates presented in the TLS handshake MUST authenticate the source and target provider domains, according to [RFC6125].¶

The bodies of HTTP requests and responses are defined by the individual endpoints defined in Section 4.3.¶

4.2. End-to-End Security Layer

Every MIMI room has an MLS group associated to it, which provides end-to-end security guarantees. The clients participating in the room manage the MLS-level membership by sending Commit messages covering Add and Remove proposals.¶

Every application message sent within a room is authenticated and confidentiality-protected by virtue of being encapsulated in an MLS PrivateMessage object.¶

MIMI uses the MLS application state synchronization mechanism ([I-D.barnes-mls-appsync]) to ensure that the clients involved in a MIMI room agree on the state of the room. Each MIMI message that changes the state of the room is encapsulated in an AppSync proposal and transmitted inside an MLS PublicMessage object.¶

The PublicMessage encapsulation provides sender authentication, including the ability for actors outside the group (e.g., servers involved in the room) to originate AppSync proposals. Encoding room state changes in MLS proposals ensures that a client will not process a commit that confirms a state change before processing the state change itself.¶

• TODO: A little more needs to be said here about how MLS is used. For example: What types of credential are required / allowed? If servers are going to be allowed to introduce room changes, how are their keys provisioned as external signers? Need to maintain the membership and the list of queued proposals.¶

4.3. Application Layer

Servers in MIMI provide a few functions that enable messaging applications. All servers act as publication points for key material used to add their users to rooms. The hub server for a room tracks the state of the room, and controls how the room's state evolves, e.g., by ensuring that changes are compliant with the room's policy. Non-hub servers facilitate interactions between their clients and the hub server.¶

In this section, we describe the state that servers keep. The following top level section describes the HTTP endpoints exposed to enable these functions.¶

Add: ["mimi://d.example/u/diana", role: 4 (admin)],
     ["mimi://e.example/u/eric", role: 3 (moderator)],
Remove: ["mimi://b.example/u/bob"],
SetRole: [["mimi://c.example/u/cathy", role: 1 (banned)]]

5.1. Directory

Like the ACME protocol (See Section 7.1.1 of [RFC8555]), the MIMI protocol uses a directory document to convey the HTTPS URLs used to reach certain endpoints (as opposed to hard coding the endpoints).¶

The directory URL is discovered using the mimi-protocol-directory well-known URI. The response is a JSON document with URIs for each type of endpoint.¶

GET /.well-known/mimi-protocol-directory

{
  "keyMaterial":
     "https://mimi.example.com/v1/keyMaterial/{targetUser}",
  "update": "https://mimi.example.com/v1/update{roomId}",
  "notify": "https://mimi.example.com/v1/notify/{roomId}",
  "submitMessage":
     "https://mimi.example.com/v1/submitMessage/{roomId}",
  "groupInfo":
     "https://mimi.example.com/v1/groupInfo/{roomId}",
  "requestConsent":
     "https://mimi.example.com/v1/requestConsent/{targetUser}",
  "updateConsent":
     "https://mimi.example.com/v1/updateConsent/{requesterUser}",
  "identifierQuery":
     "https://mimi.example.com/v1/identifierQuery/{domain}",
  "reportAbuse":
     "https://mimi.example.com/v1/reportAbuse/{roomId}"
}

5.2. Fetch Key Material

This action attempts to claim initial keying material for all the clients of a single user at a specific provider. The keying material is designed for use in a single room and may not be reused. It uses the HTTP POST method.¶

POST /keyMaterial/{targetUser}

The target user's URI is listed in the request path. KeyPackages requested using this primitive MUST be sent via the hub provider of whatever room they will be used in. (If this is not the case, the hub provider will be unable to forward a Welcome message to the target provider).¶

The path includes the target user. The request body includes the protocol (currently just MLS 1.0), and the requesting user. When the request is being made in the context of adding the target user to a room, the request MUST include the room ID for which the KeyPackage is intended, as the target may have only granted consent for a specific room.¶

For MLS, the request includes a non-empty list of acceptable MLS ciphersuites, and an MLS RequiredCapabilities object (which contains credential types, non-default proposal types, and extensions) required by the requesting provider (these lists can be an empty).¶

The request body has the following form.¶

struct {
    opaque uri<V>;
} IdentifierUri;

struct {
    Protocol protocol;
    IdentifierUri requestingUser;
    IdentifierUri targetUser;
    IdentifierUri roomId;
    select (protocol) {
        case mls10:
            CipherSuite acceptableCiphersuites<V>;
            RequiredCapabilities requiredCapabilities;
    };
} KeyMaterialRequest;

The response contains a user status code that indicates keying material was returned for all the user's clients (success), that keying material was returned for some of their clients (partialSuccess), or a specific user code indicating failure. If the user code is success or partialSuccess, each client is enumerated in the response. Then for each client with a client success code, the structure includes initial keying material (a KeyPackage for MLS 1.0). If the client's code is nothingCompatible, the client's capabilities are optionally included (The client's capabilities could be omitted for privacy reasons.)¶

If the user code is noCompatibleMaterial, the provider MAY populate the clients list. For any other user code, the provider MUST NOT populate the clients list.¶

Keying material provided from one response MUST NOT be provided in any other response. The target provider MUST NOT provide expired keying material (ex: an MLS KeyPackage containing a LeafNode with a notAfter time past the current date and time).¶

enum {
    success(0);
    partialSuccess(1);
    incompatibleProtocol(2);
    noCompatibleMaterial(3);
    userUnknown(4);
    noConsent(5);
    noConsentForThisRoom(6);
    userDeleted(7);
    (255)
} KeyMaterialUserCode;

enum {
    success(0);
    keyMaterialExhausted(1),
    nothingCompatible(2),
    (255)
} KeyMaterialClientCode;


struct {
    KeyMaterialClientCode clientStatus;
    IdentifierUri clientUri;
    select (protocol) {
        case mls10:
            select (clientStatus) {
                case success:
                    KeyPackage keyPackage;
                case nothingCompatible:
                    optional<Capabilities> clientCapabilities;
            };
    };
} ClientKeyMaterial;

struct {
    Protocol protocol;
    KeyMaterialUserCode userStatus;
    IdentifierUri userUri;
    ClientKeyMaterial clients<V>;
} KeyMaterialResponse;

The semantics of the KeyMaterialUserCode are as follows:¶

• success indicates that key material was provided for every client of the target user.¶

• partialSuccess indicates that key material was provided for at least one client of the target user.¶

• incompatibleProtocol indicates that either one of providers supports the protocol requested, or none of the clients of the target user support the protocol requested.¶

• noCompatibleMaterial indicates that none of the clients was able to supply key material compatible with the requiredCapabilities field in the request.¶

• userUnknown indicates that the target user is not known to the target provider.¶

• noConsent indicates that the requester does not have consent to fetch key material for the target user. The target provider can use this response as a catch all and in place of other status codes such as userUnknown if desired to preserve the privacy of its users.¶

• noConsentForThisRoom indicates that the target user might have allowed a request for another room, but does not for this room. If the provider does not wish to make this distinction, it can return noConsent instead.¶

• userDeleted indicates that the target provider wishes the requester to know that the target user was previously a valid user of the system and has been deleted. A target provider can of course use userUnknown if the provider does wish to keep or specify this distinction.¶

The semantics of the KeyMaterialClientCode are as follows:¶

• success indicates that key material was provided for the specified client.¶

• keyMaterialExhausted indicates that there was no keying material available for the specified client.¶

• nothingCompatible indicates that the specified clients had no key material compatible with the requiredCapabilities field in the request.¶

At minimum, as each MLS KeyPackage is returned to a requesting provider (on behalf of a requesting IM client), the target provider needs to associate its KeyPackageRef with the target client and the hub provider needs to associate its KeyPackageRef with the target provider. This ensures that Welcome messages can be correctly routed to the target provider and client. These associations can be deleted after a Welcome message is forwarded or after the KeyPackage leaf_node.lifetime.not_after time has passed.¶

5.3. Update Room State

Adds, removes, and policy changes to the room are all forms of updating the room state. They are accomplished using the update transaction which is used to update the room base policy, participation list, or its underlying MLS group. It uses the HTTP POST method.¶

POST /update/{roomId}

Any change to the participant list or room policy (including authorization policy) is communicated via an AppSync proposal type with the applicationId of mimiParticipantList or mimiRoomPolicy respectively. When adding a user, the proposal containing the participant list change MUST be committed either before or simultaneously with the corresponding MLS operation.¶

Removing an active user from a participant list or banning an active participant likewise also happen simultaneously with any MLS changes made to the commit removing the participant.¶

A hub provider which observes that an active participant has been removed or banned from the room, MUST prevent any of its clients from sending or receiving any additional application messages in the corresponding MLS group; MUST prevent any of those clients from sending Commit messages in that group; and MUST prevent it from sending any proposals except for Remove and SelfRemove [I-D.ietf-mls-extensions] proposals for its users in that group.¶

The update request body is described below, using the RatchetTreeOption and PartialGroupInfo structs defined in [I-D.mahy-mls-ratchet-tree-options]:¶

struct {
  /* A Proposal or Commit which is either a PublicMessage; */
  /* or a SemiPrivateMessage                               */
  MLSMessage proposalOrCommit;
  select (proposalOrCommit.content.content_type) {
    case commit:
      /* Both the Welcome and GroupInfo omit the ratchet_tree */
      optional<Welcome> welcome;
      GroupInfoOption groupInfoOption;
      RatchetTreeOption ratchetTreeOption;
    case proposal:
      /* a list of additional proposals, each represented */
      /* as either PublicMessage or SemiPrivateMessage    */
      MLSMessage moreProposals<V>;
} HandshakeBundle;

enum {
  reserved(0),
  full(1),
  partial(2),
  (255)
} GroupInfoRepresentation;

struct {
   GroupInfoRepresentation representation;
   select (representation) {
     case full:
       GroupInfo groupInfo;
     case partial:
       PartialGroupInfo partialGroupInfo;
   }
} GroupInfoOption;

struct {
  select (room.protocol) {
    case mls10:
      HandshakeBundle bundle;
  };
} UpdateRequest;

The semantics of GroupInfoRepresentation are as follows:¶

• full means that the entire GroupInfo will be included.¶

• partial means that a PartialGroupInfo struct will be shared and that the Distribution Service is expected to reconstruct the GroupInfo as described in [I-D.mahy-mls-ratchet-tree-options].¶

For example, in the first use case described in the Protocol Overview, Alice creates a Commit containing an AppSync proposal adding Bob (mimi://b.example/b/bob), and Add proposals for all Bob's MLS clients. Alice includes the Welcome message which will be sent for Bob, a GroupInfo object for the hub provider, and complete ratchet_tree extension.¶

A handshake message could be sent by the client as an MLS PublicMessage (which is visible to all providers), or as an MLS SemiPrivateMessage [I-D.mahy-mls-semiprivatemessage] encrypted for the members and the hub provider as the sole external_receiver. (The contents and sender of a SemiPrivateMessage would not be visible to other providers). The use of SemiPrivateMessage allows the Hub to accomplish its policy enforcement responsibilities without the other providers being aware of the membership of non-local users.¶

The response body is described below:¶

enum {
  success(0),
  wrongEpoch(1),
  notAllowed(2),
  invalidProposal(3),
  (255)
} UpdateResponseCode;

struct {
  UpdateResponseCode responseCode;
  string errorDescription;
  select (responseCode) {
    case success:
      /* the hub acceptance time (in milliseconds from the UNIX epoch) */
      uint64 acceptedTimestamp;
    case wrongEpoch:
      /* current MLS epoch for the MLS group */
      uint64 currentEpoch;
    case invalidProposal:
      ProposalRef invalidProposals<V>;
  };
} UpdateRoomResponse

The semantics of the UpdatedResponseCode values are as follows:¶

• success indicates the UpdateRequest was accepted and will be distributed.¶

• wrongEpoch indicates that the hub provider is using a different epoch. The currentEpoch is provided in the response.¶

• notAllowed indicates that some type of policy or authorization prevented the hub provider from accepting the UpdateRequest.¶

• invalidProposal indicates that at least one proposal is invalid. A list of invalidProposals is provided in the response.¶

5.4. Submit a Message

End-to-end encrypted (application) messages are submitted to the hub for authorization and eventual fanout using an HTTP POST request.¶

POST /submitMessage/{roomId}

The request body is as follows:¶

struct {
  Protocol protocol;
  select(protocol) {
    case mls10:
      /* PrivateMessage containing an application message */
      MLSMessage appMessage;
      IdentifierURI sendingUri;
  };
} SubmitMessageRequest;

If the protocol is MLS 1.0, the request body (appMessage) is an MLSMessage with a WireFormat of PrivateMessage, and a content_type of application. The sendingUri is a valid URI of the sender and is an active participant in the room (a user URI in the participant list of the room).¶

The response indicates if the message was accepted by the hub provider. If a frankingTag was included in the FrankAAD extension in the PrivateMessage Additional Authenticated Data (AAD) in the request, the server attempts to frank the message and includes the serverFrank in a successful response (see the next subsection).¶

enum {
  accepted(0),
  notAllowed(1),
  epochTooOld(2),
  (255)
} SubmitResponseCode;

struct {
  Protocol protocol;
  select(protocol) {
    case mls10:
      SubmitResponseCode statusCode;
      select (statusCode) {
        case success:
          /* the hub acceptance time
             (in milliseconds from the UNIX epoch) */
          uint64 acceptedTimestamp;
          optional struct {
            uint8[32] serverFrank;
            uint8[32] franking_integrity_check;
          };
        case epochTooOld:
          /* current MLS epoch for the MLS group */
          uint64 currentEpoch;
      };
  };
} SubmitMessageResponse;

The semantics of the SubmitResponseCode values are as follows:¶

• success indicates the SubmitMessageRequest was accepted and will be distributed.¶

• notAllowed indicates that some type of policy or authorization prevented the hub provider from accepting the UpdateRequest. This could include nonsensical inputs such as an MLS epoch more recent than the hub's.¶

• epochTooOld indicates that the hub provider is using a new MLS epoch for the group. The currentEpoch is provided in the response.¶

• ISSUE: Do we want to offer a distinction between regular application messages and ephemeral applications messages (for example "is typing" notifications), which do not need to be queued at the target provider.¶

/ FrankingAssertion map /
{
  / RoomURI        / 1: "mimi://hub.example/r/Rl33FWLCYWOwxHrYnpWDQg",
  / SenderUserURI  / 2: "mimi://b.example/u/alice"
}

franking_tag = HMAC_SHA256( salt, application_data)

context = senderURI || roomURI || acceptedTimestamp
serverFrank = HMAC_SHA256(HUBkey, franking_tag || context )
franking_integrity_check = HMAC_SHA256(franking_integrity_secret,
  serverFrank || context)

5.5. Fanout Messages and Room Events

If the hub provider accepts an application or handshake message (proposal or commit) message, it forwards that message to all other providers with active participants in the room and all local clients which are active members. This is described as fanning the message out. One can think of fanning a message out as presenting an ordered list of MLS-protected events to the next "hop" toward the receiving client.¶

An MLS Welcome message is sent to the providers and local users associated with the KeyPackageRef values in the secrets array of the Welcome. In the case of a Welcome message, a RatchetTreeOption (see Section 3 of [I-D.mahy-mls-ratchet-tree-options]) is also included in the FanoutMessage.¶

The hub provider also fans out any messages which originate from itself (ex: MLS External Proposals).¶

The hub can include multiple concatenated FanoutMessage objects relevant to the same room. This endpoint uses the HTTP POST method.¶

POST /notify/{roomId}

struct {
  uint8[32] serverFrank;
  uint8[32] franking_integrity_check;
} Frank;

struct {
  /* the hub acceptance time (in milliseconds from the UNIX epoch) */
  uint64 timestamp;
  select (protocol) {
    case mls10:
      /* A PrivateMessage containing an application message,
         a PublicMessage containing a proposal or commit,
         or a Welcome message.                               */
      MLSMessage message;
      select (message.wire_format) {
        case application:
           optional Frank frank;
        case welcome:
           RatchetTreeOption ratchetTreeOption;
        case proposal:
           /* a list of additional proposals, each represented */
           /* as either PublicMessage or SemiPrivateMessage    */
           MLSMessage moreProposals<V>;
        case commit:
           struct {};
      };
  };
} FanoutMessage;

• NOTE: Correctly fanning out Welcome messages relies on the hub and target providers storing the KeyPackageRef of claimed KeyPackages.¶

A client which receives a success to either an UpdateRoomResponse or a SubmitMessageResponse can view this as a commitment from the hub provider that the message will eventually be distributed to the group. The hub is not expected to forward the client's own message to the client or its provider. However, the client and its provider need to be prepared to receive the client's (effectively duplicate) message. This situation can occur during failover in high availability recovery scenarios.¶

Clients that are being removed SHOULD receive the corresponding Commit message, so they can recognize that they have been removed and clean up their internal state. A removed client might not receive a commit if it was removed as a malicious or abusive client, or if it was obviously deleted.¶

The moreProposals list in a FanoutMessage MUST be the same as the corresponding moreProposals list in the HandshakeBundle of an UpdateRequest.¶

The response to a FanoutMessage contains no body. The HTTP response code indicates if the messages in the request were accepted (201 response code), or if there was an error. The hub need not wait for a response before sending the next fanout message.¶

If the hub server does not contain an HTTP 201 response code, then it SHOULD retry the request, respecting any guidance provided by the server in HTTP header fields such as Retry-After. If a follower server receives a duplicate request to the /notify endpoint, in the sense of a request from the same hub server with the same request body as a previous /notify request, then the follower server MUST return a 201 Accepted response. In such cases, the follower server SHOULD process only the first request; subsequent duplicate requests SHOULD be ignored (despite the success response).¶

• NOTE: These deduplication provisions require follower servers to track which request bodies they have received from which hub servers. Since the matching here is byte-exact, it can be done by keeping a rolling list of hashes of recent messages.¶

  This byte-exact replay criterion might not be the right deduplication strategy. There might be situations where it is valid for the same hub server to send the same payload multiple times, e.g., due to accidental collisions.¶

  If this is a concern, then an explicit transaction ID could be introduced. The follower server would still have to keep a list of recently seen transaction IDs, but deduplication could be done irrespective of the content of request bodies.¶

5.6. Claim group key information

When a client joins an MLS group without an existing member adding the client to the MLS group, that is called an external join. This is useful a) when a new client of an existing user needs to join the groups of all the user's rooms. It can also be used b) when a client did not have key packages available but their user is already in the participation list for the corresponding room, c) when joining an open room, or d) when joining using an external authentication joining code. In MIMI, external joins are accomplished by fetching the MLS GroupInfo for a room's MLS group, and then sending an external commit incorporating the GroupInfo.¶

The GroupInfoRequest uses the HTTP POST method.¶

POST /groupInfo/{roomId}

The request provides an MLS credential proving the requesting client's real or pseudonymous identity. This user identity is used by the hub to correlate this request with the subsequent external commit. The credential may constitute sufficient permission to authorize providing the GroupInfo and later joining the group. Alternatively, the request can include an optional opaque joining code, which the requester could use to prove permission to fetch the GroupInfo, even if it is not yet a participant.¶

The request also provides a signature public key corresponding to the requester's credential. It also specifies a CipherSuite which merely needs to be one ciphersuite in common with the hub. It is needed only to specify the algorithms used to sign the GroupInfoRequest and GroupInfoResponse.¶

struct {
  Protocol protocol;
  select (protocol) {
    case mls10:
      CipherSuite cipher_suite;
      SignaturePublicKey requestingSignatureKey;
      Credential requestingCredential;
      HPKEPublicKey groupInfoPublicKey;
      optional opaque joiningCode<V>;
  };
} GroupInfoRequestTBS;

struct {
  Protocol protocol;
  select (protocol) {
    case mls10:
      CipherSuite cipher_suite;
      SignaturePublicKey requestingSignatureKey;
      Credential requestingCredential;
      HPKEPublicKey groupInfoPublicKey;
      opaque joiningCode<V>;
      /* SignWithLabel(requestingSignatureKey,          */
      /*    "GroupInfoRequestTBS", GroupInfoRequestTBS) */
      opaque signature<V>;
  };
} GroupInfoRequest;

If successful, the response body contains the GroupInfo and a way to get the ratchet_tree, both encrypted with the groupInfoPublcKey passed in the request.¶

enum {
  reserved(0),
  success(1),
  notAuthorized(2),
  noSuchRoom(3),
  (255)
} GroupInfoCode;

struct {
  GroupInfo groupInfo;   /* without embedded ratchet_tree */
  RatchetTreeOption ratchetTreeOption;
} GroupInfoRatchetTreeTBE;

GroupInfoRatchetTreeTBE group_info_ratchet_tree_tbe;

encrypted_groupinfo_and_tree = EncryptWithLabel(
  groupInfoPublicKey,
  "GroupInfo and ratchet_tree encryption",
  room_id,                         /* context */
  group_info_ratchet_tree_tbe)

struct {
  Protocol version;
  opaque room_id<V>;
  GroupInfoCode status;
  select (protocol) {
    case mls10:
      CipherSuite cipher_suite;
      ExternalSender hub_sender;
      HPKECiphertext encrypted_groupinfo_and_tree;
  };
} GroupInfoResponseTBS;

struct {
  Protocol version;
  opaque room_id<V>;
  GroupInfoCode status;
  select (status) {
    case success:
      select (protocol) {
        case mls10:
          CipherSuite cipher_suite;
          ExternalSender hub_sender;
          HPKECiphertext encrypted_groupinfo_and_tree;
          /* SignWithLabel(hub_sender, "GroupInfoResponseTBS", */
          /*                GroupInfoResponseTBS) */
          opaque signature<V>;
      };
  default: struct{};
  };
} GroupInfoResponse;

The semantics of the GroupInfoCode are as follows:¶

• success indicates that GroupInfo and ratchet tree was provided as requested.¶

• notAuthorized indicates that the requester was not authorized to access the GroupInfo.¶

• noSuchRoom indicates that the requested room does not exist. If the hub does not want to reveal if a room ID does not exist it can use notAuthorized instead.¶

• TODO: Consider adding additional failure codes/semantics for joining codes (ex: code expired, already used, invalid)¶

ISSUE: What security properties are needed to protect a GroupInfo object in the MIMI context are still under discussion. It is possible that the requester only needs to prove possession of their private key. The GroupInfo in another context might be sufficiently sensitive that it should be encrypted from the end client to the hub provider (unreadable by the local provider).¶

5.7. Convey explicit consent

As discussed in Section 8, there are many ways that a provider could implicitly determine consent. This section describes a mechanism by which providers can explicitly request consent from a user of another provider, cancel such a request, convey that consent was granted, or convey that consent was revoked or preemptively denied.¶

Since they are not necessarily in the context of a room, consent requests are sent directly from the provider of the user requesting consent, to the provider of the target user. (There is no concept of a hub outside of the context of a room.)¶

POST /requestConsent/{targetDomain}
POST /updateConsent/{requesterDomain}

A requestConsent request is used by one provider to request explicit consent from a target user at another provider to fetch the target's KeyPackages (which is a prerequisite for adding the target to a group); or to cancel that request. The request body is a ConsentEntry, with a consentOperation of request or cancel respectively. It includes the URI of requesting user in the requesterUri and the target user URI in the targetUri. If consent is only requested for a single room, the requester includes the roomId. The combination of the requesterUri, targetUri, and optional roomId represents the ConsentScope. A cancel MUST use the same ConsentScope as a previous request.¶

For a requestContent, the targetUri needs to be in one of the domains of the receiving provider, and the requesterUri needs to be in one of the domains of the sending provider.¶

The response to a requestConsent request is usually a 201 Accepted (indicating the requestConsent was received), optionally a 404 Not Found (indicating the targetUri is unknown), or a 500-class response. The 201 response code merely indicates that the request was received. A provider that does not wish to reveal if a user is not found can respond with a 201 Accepted. Likewise in response to a cancel which has no request matching the ConsentScope, a 201 Accepted is sent and no further action is taken.¶

enum {
  cancel(0),
  request(1),
  grant(2),
  revoke(3),
  (255)
} ConsentOperation;

struct {
  ConsentOperation consentOperation;
  IdentifierUri requesterUri;
  IdentifierUri targetUri;
  optional<RoomId> roomId;
  select (consentOperation) {
      case grant:
          KeyPackage clientKeyPackages<V>;
  };
} ConsentEntry;

struct {
  IdentifierUri requesterUri;
  IdentifierUri targetUri;
  optional<RoomId> roomId;
} ConsentScope;

An updateConsent request is used by one provider to provide explicit notice from a target user at one provider that consent for a specific "requester" was granted, revoked, or preemptively denied. In this context, the requester is the party that will later request KeyPackages for the target. The request body is a ConsentEntry, with a consentOperation of grant (for a grant), or revoke for revocation or denial. Like a request, it includes the URI of the "requesting user" in the requesterUri and the target user URI in the targetUri. If consent is only granted or denied for a single room, the request includes the optional roomId.¶

A grant or revoke does not need to be in response to an explicit request, nor does the ConsentScope need to match a previous request for the same targetUri and requesterUri pair.¶

For example, in some systems there is a notion of a bilateral connection request. The party that initiates the connection request (for example Alice) would send a requestConsent for the target (ex: Bob), and send an unsolicited updateConsent with Bob as the "requestor" and itself (Alice) as the target.¶

In a grant, the sender includes a list of clientKeyPackages for the target user, which can be empty. For the case of a bilateral connection, a grant of consent with a matching ConsentScope often results in an immediate Add to a group. If the list is non-empty this reduces the number of messages which need to be sent.¶

For updateConsent the requesterUri needs to be in one of the domains of the receiving provider, and the targetUri needs to be in one of the domains of the sending provider.¶

The response to an updateConsent is usually a 201 Accepted (indicating the updateConsent was received), optionally a 404 Not Found (indicating the requesterUri is unknown), or a 500-class response. The response code merely indicates that the request was received. A provider that does not wish to reveal if a user is not found can respond with a 201 Accepted.¶

• NOTE: Revoking consent for a user might be privacy sensitive. If this is the case the target provider does not need to send a revoke to inform the requester provider.¶

5.8. Find internal address

The identifier query is to find the internal URI for a specific user on a specific provider. It is only sent from the local provider to the target provider (it does not transit a hub).¶

Note that this POST request is idempotent and safe in the sense defined by Section 9.2.2 of [RFC9110].¶

POST /identifierQuery/{domain}

Consider three users Xavier, Yolanda, and Zach all with accounts on provider XYZ. Xavier is a sales person and wants to be contactable easily by potential clients on the XYZ provider. He configures his profile on XYZ so that searching for his first or last name or handle will find his profile and allow Alice to send him a consent request (it is out of scope how Alice verifies she has found the intended Xavier and not a different Xavier or an impostor). Yolanda has her XYZ handle on her business cards and the email signature she uses with clients. She configures her profile so that a query for her exact handle will find her profile and allow Alice to send her a consent request. Zach does not wish to be queryable at all. He has configured his account so even an exact handle search returns no results. He could still send a join link out-of-band to Alice for her to join a room of Zach's choosing.¶

The request body is described as below. Each request can contain multiple query elements, which all have to match for the request to match (AND semantics). For example matching both the OpenID Connect (OIDC) [OidcCore] given_name and family_name, or matching the OIDC given_name and the organization (from the vCard [RFC6350] ORG property).¶

enum {
  reserved(0),
  handle(1),
  nick(2),
  email(3),
  phone(4),
  partialName(5),
  wholeProfile(6),
  oidcStdClaim(7),
  vcardField(8),
  (255)
} SearchIdentifierType;

struct {
  SearchIdentifierType searchType;
  select(type) {
    case oidcStdClaim:
      opaque claimName<V>;
    case vcardField:
      opaque propertyName<V>;
  };
  opaque searchValue<V>;  /* a UTF8 string */
} QueryElement;

struct {
  QueryElement query_elements<V>;
} IdentifierRequest;

The semantics of the SearchIdentifierType values are as follows. handle means that the entire handle URI matches exactly (for example: im:alice.smith@a.example). nick means that the nickname or handle user part matches exactly (for example: alice.smith). The same account or human user may have multiple values which all match the nick field. email means the addr-spec production from [RFC5322] matches the query string exactly, for example (asmith@a.example). phone means the international format of a telephone number with the "+" prefix matches exactly (for example: +12125551212).¶

partialName means that the query string matches a case-insensitive substring of any field which contains the name of a (usually human) user. For example, mat would match first (given) or middle names Matt, Matthew, Mathias, or Mathieu and last (family) names of Mather and Matali. wholeProfile means that the query string matches a substring of any searchable field in a user's profile.¶

oidcStdClaim means that the query string exactly matches the specified UserInfo Standard Claim (defined in Section 5.1 of [OidcCore]). vcardField means that the query string exactly matches the specified vCard property listed in the vCard Properties IANA registry.¶

As noted above, searches only return results for a user when the fields searched are searchable according the user's and provider's search policies.¶

The response body is described as an IdentifierResponse. It can contain multiple matches depending on the type of query and the policy of the target provider.¶

The response contains a code indicating the status of the query. success means that at least one result matched the query. notFound means that while the request was acceptable, no results matched the query. ambiguous means that a field (ex: handle) or combination of fields (ex: first and last name) need to match exactly for the provider to return any responses. forbidden means that use of this endpoint is not allowed by the provider or that an unspecified field or combination of fields is not allowed in an identifier query. unsupportedField means that the provider does not support queries on one of the fields queried.¶

enum {
  success(0),
  notFound(1),
  ambiguous(2),
  forbidden(3),
  unsupportedField(4),
  (255)
} IdentifierQueryCode;

enum {
  reserved(0),
  oidcStdClaim(7),
  vcardField(8),
  (255)
} FieldSource;

struct {
  FieldSource fieldSource;
  string fieldName;
  opaque fieldValue<V>;
} ProfileField;

struct {
  IdentifierUri stableUri;
  ProfileField fields<V>;
} UserProfile;

struct {
  IdentifierQueryCode responseCode;
  IdentifierUri uri<V>;
  UserProfile foundProfiles<V>;
} IdentifierResponse;

• TODO: The format of specific identifiers is discussed in [I-D.mahy-mimi-identity]. Any specific conventions which are needed should be merged into this document.¶

5.9. Report abuse

Abuse reports are only sent to the hub provider. They are sent as an HTTP POST request.¶

POST /reportAbuse/{roomId}

The reportingUser optionally contains the identity of the user sending the abuseReport, while the allegedAbuserUri contains the URI of the alleged sender of abusive messages. The reasonCode is reserved to identify the type of abuse, and the note is a UTF8 human-readable string, which can be empty.¶

• TODO: Find a standard taxonomy of reason codes to reference for the AbuseType. The IANA Messaging Abuse Report Format parameters are insufficient.¶

Finally, abuse reports can optionally contain a handful of allegedly AbusiveMessages, each of which contains an allegedly abusive message, its franks, and its timestamp.¶

struct {
  /* the MIMI Content message containing */
  /* alleged abusive content */
  opaque mimi_content<V>;
  Frank frank;
  uint64 acceptedTimestamp;
} AbusiveMessage;

enum {
  reserved(0),
  (255)
} AbuseType;

struct {
  IdentifierUri reportingUser;
  IdentifierUri allegedAbuserUri;
  AbuseType reasonCode;
  opaque note<V>;
  AbusiveMessage messages<V>;
} AbuseReport;

There is no response body. The response code only indicates if the abuse report was accepted, not if any specific automated or human action was taken.¶

6.1. Credential encryption

Identifiers of participants and their clients occur in two locations in a room's state: the participant list and the credentials of the room's underlying MLS group. In an MMR, the real identifiers of clients and users are replaced by pseudonyms in the shape of random UUIDs qualified with the domain of the user's provider.¶

In MMRs, all leaves of the underlying group MUST contain PseudonymousCredentials.¶

struct {
  IdentifierUri client_pseudonym;
  IdentifierUri user_pseudonym;
  opaque signature_public_key;
  opaque identity_link_ciphertext<V>;
} PseudonymousCredential

• user_pseudonym: The pseudonym of the client's user in this group¶

• client_pseudonym: The pseudonym of the client identified by this credential¶

• signature_public_key: The signature public key used to authenticate MLS messages¶

• identity_link_ciphertext: A ciphertext containing a credential with the clients real identifier¶

In any given room, the user_pseudonym of a client MUST be the same across all clients of a user and it MUST be the same as the user's entry in the participant list.¶

struct {
  IdentifierUri client_pseudonym;
  IdentifierUri user_pseudonym;
  opaque signature_public_key;
} PseudonymousCredentialTBS

struct {
  /* SignWithLabel(., "PseudonymousCredentialTBS",
    PseudonymousCredentialTBS) */
  opaque pseudonymous_credential_signature<V>;
  Credential client_credential;
} IdentityLinkTBE

The identity_link_ciphertext is created by encrypting the IdentityLinkTBE. The IdentityLinkTBE contains the client's real credential, and a signature over the PseudonymousCredentialTBS signed with the client credential's signature_public_key.¶

• TODO: Specify a key management scheme that ideally - is efficient - allows the basic MIMI flows - ensures that all participants can learn the identities of all other participants at all times - provides FS and PCS w.r.t. metadata hiding¶

  There are several options that represent different trade-offs, but are not yet fully specified. They will be added at a later date.¶

7.1. Room state

The state of a room consists of its room ID, its base policy, its participant list (including the role and participation state of each participant), and the associated end-to-end protocol state (its MLS group state) that anchors the room state cryptographically.¶

While all parties involved in a room agree on the room's state during a specific epoch, the Hub is the arbiter that decides if a state change is valid, consistent with the room's then-current policy. All state-changing events are sent to the Hub and checked for their validity and policy conformance, before they are forwarded to any follower servers or local clients.¶

As soon as the Hub accepts an event that changes the room state, its effect is applied to the room state and future events are validated in the context of that new state.¶

The room state is thus changed based on events, even if the MLS proposal implementing the event was not yet committed by a client. Note that this only applies to events changing the room state.¶

7.2. Cryptographic room representation

Each room is represented cryptographically by an MLS group. The Hub that manages the room also manages the list of group members, i.e. the list of clients belonging to users currently in the room. Application state that is stored in the MLS GroupContext is stored as application components in the app_data_dictionary extension, as described in Section 4.6 of [I-D.ietf-mls-extensions].¶

7.3. Proposal-commit paradigm

The MLS protocol follows a proposal-commit paradigm. Any party involved in a room (follower server, Hub or clients) can send proposals (e.g. to add/remove/update clients of a user or to re-initialize the group with different parameters). However, only clients can send commits, which contain all valid previously sent proposals and apply them to the MLS group state.¶

The MIMI usage of MLS ensures that the Hub, all follower servers and the clients of all active participants agree on the group state, which includes the client list and the key material used for message encryption (although the latter is only available to clients). Since the group state also includes a copy of the room state at the time of the most recent commit, it is also covered by the agreement.¶

7.4. Authenticating proposals

MLS requires that MLS proposals from the Hub and from follower servers (external senders in MLS terminology) be authenticated using key material contained in the external_senders extension of the MLS group. Each MLS group associated with a MIMI room MUST therefore contain an external_senders extension. That extension MUST contain at least the Certificate of the Hub.¶

When a user from a follower server becomes a participant in the room, the Certificate of the follower server MAY be added to the extension. When the last participant belonging to a follower server leaves the room, the certificate of that user MUST be removed from the list. Changes to the external_senders extension only take effect when the MLS proposal containing the event is committed by a MIMI commit.¶

7.5. Participant List

The participant list is a list of "users" in a room. Within a room, each user is assigned exactly one role (expressed with a role_index and described in [I-D.ietf-mimi-room-policy] at any given time (specifically within any MLS epoch). In a room that has multiple MLS clients per "user", the identifier for each user in participants.user is the same across all that user's clients in the room. Note that each user has a single role at any point in time, and therefore all clients of the same user also have the same role.¶

The participant list may include inactive participants, which currently do not have any clients in the corresponding MLS group, for example if their clients do not have available KeyPackages or if all of their clients are temporarily "kicked" out of the group. The participant list can also contain participants that are explicitly banned, by assigning them a suitable role which does not have any capabilities.¶

struct {
  opaque user<V>;
  uint32 role_index;
} UserRolePair;

struct {
  UserRolePair participants<V>;
} ParticipantListData;

ParticipantListData is the format of the data field inside the ComponentData struct for the Participant list Metadata component in the app_data_dictionary GroupContext extension.¶

struct {
  uint32 user_index;
  uint32 role_index;
} UserindexRolePair;

struct {
  UserindexRolePair changedRoleParticipants<V>
  uint32 removedIndices<V>;
  UserRolePair addedParticipants<V>;
} ParticipantListUpdate;

ParticipantListUpdate is the contents of an AppDataUpdate Proposal with the component ID for the participant list. The index of the participants vector in the current ParticipantListData struct is referenced as the user_index when making changes. First the changedRoleParticipants list contains UserindexRolePairs with the index of a user who changed roles and their new role. Next is the removedIndices list which has a list of users to remove completely from the participant list. Finally there is a list of addedParticipants (which contains a user and role) that is appended to the end of the ParticipantListData.¶

Each of these actions (modifying a user's role, removing a user, and adding a user) is authorized separately according to the rules specified in [I-D.ietf-mimi-room-policy]. If all the changes are authorized, the ParticipantListData is modified accordingly.¶

A single commit is not valid if it contain any combination of Participant list updates that operate on (add, remove, or change the role of) the same user in the participant list more than once.¶

7.6. Room Metadata

The Room Metadata component contains data about a room which might be displayed as human-readable information for the room, such as the name of the room and a URL pointing to its room image/avatar.¶

It can contain a list of room_descriptions, each of which can have a specific language_tag and media_type along with the description_content. An empty media_type implies text/plain;charset=utf-8.¶

RoomMetaData is the format of the data field inside the ComponentData struct for the Room Metadata component in the app_data_dictionary GroupContext extension.¶

/* a valid URI (ex: MIMI URI) */
struct {
  opaque uri<V>;
} Uri;

/* a sequence of valid UTF8 without nulls */
struct {
  opaque string<V>;
} UTF8String;

struct {
  /* an empty media_type is equivalent to text/plain;charset=utf-8 */
  opaque media_type<V>;
  opaque language_tag<V>;
  opaque description_content<V>;
} RichDescription;

struct {
  Uri room_uri;
  UTF8String room_name;
  RichDescription room_descriptions<V>;
  /* an https URI resolving to an avatar image */
  Uri room_avatar;
  UTF8String room_subject;
  UTF8String room_mood;
} RoomMetaData;

RoomMetaData RoomMetaUpdate;

RoomMetaUpdate (which has the same format as RoomMetaData) is the format of the update field inside the AppDataUpdate struct in an AppDataUpdate Proposal for the Room Metadata component. If the contents of the update field are valid and if the proposer is authorized to generate such an update, the value of the update field completely replaces the value of the data field.¶

Only a single Room metadata update is valid per commit.¶

9.1. Franking

TBD.¶

• TODO: Present the franking mechanism to CFRG for review.¶

11.1. Normative References

[I-D.barnes-mimi-arch]

Barnes, R., "An Architecture for More Instant Messaging Interoperability (MIMI)", Work in Progress, Internet-Draft, draft-barnes-mimi-arch-03, 4 March 2024, <https://datatracker.ietf.org/doc/html/draft-barnes-mimi-arch-03>.

[I-D.barnes-mls-appsync]

Joël, Barnes, R., Mahy, R., and M. Mularczyk, "A Safe Application Interface to Messaging Layer Security", Work in Progress, Internet-Draft, draft-barnes-mls-appsync-01, 12 December 2024, <https://datatracker.ietf.org/doc/html/draft-barnes-mls-appsync-01>.

[I-D.ietf-mimi-content]

Mahy, R., "More Instant Messaging Interoperability (MIMI) message content", Work in Progress, Internet-Draft, draft-ietf-mimi-content-05, 20 December 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-mimi-content-05>.

[I-D.ietf-mimi-room-policy]

Mahy, R., "Room Policy for the More Instant Messaging Interoperability (MIMI) Protocol", Work in Progress, Internet-Draft, draft-ietf-mimi-room-policy-01, 2 March 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-mimi-room-policy-01>.

[I-D.ietf-mls-extensions]

Robert, R., "The Messaging Layer Security (MLS) Extensions", Work in Progress, Internet-Draft, draft-ietf-mls-extensions-06, 19 February 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-mls-extensions-06>.

[I-D.kohbrok-mls-associated-parties]

Kohbrok, K. and R. Robert, "MLS Associated parties", Work in Progress, Internet-Draft, draft-kohbrok-mls-associated-parties-00, 21 October 2024, <https://datatracker.ietf.org/doc/html/draft-kohbrok-mls-associated-parties-00>.

[I-D.mahy-mls-ratchet-tree-options]

Mahy, R., "Ways to convey the Ratchet Tree in Messaging Layer Security", Work in Progress, Internet-Draft, draft-mahy-mls-ratchet-tree-options-01, 20 October 2024, <https://datatracker.ietf.org/doc/html/draft-mahy-mls-ratchet-tree-options-01>.

[I-D.mahy-mls-semiprivatemessage]

Mahy, R., "Semi-Private Messages in the Messaging Layer Security (MLS) Protocol", Work in Progress, Internet-Draft, draft-mahy-mls-semiprivatemessage-04, 20 October 2024, <https://datatracker.ietf.org/doc/html/draft-mahy-mls-semiprivatemessage-04>.

[OidcCore]

Sakimura, N., Bradley, J., Jones, M. B., Medeiros, B. de., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 2", 15 December 2023, <https://openid.net/specs/openid-connect-core-1_0.html>.

[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>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC5322]

Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/rfc/rfc5322>.

[RFC6125]

Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/rfc/rfc6125>.

[RFC6350]

Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, <https://www.rfc-editor.org/rfc/rfc6350>.

[RFC7231]

Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/rfc/rfc7231>.

[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>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9420]

Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.

11.2. Informative References

[Grubbs2017]

Grubbs, P., Lu, J., and T. Ristenpart, "Message Franking via Committing Authenticated Encryption", 2017, <https://eprint.iacr.org/2017/664.pdf>.

[I-D.mahy-mimi-identity]

Mahy, R., "More Instant Messaging Interoperability (MIMI) Identity Concepts", Work in Progress, Internet-Draft, draft-mahy-mimi-identity-02, 10 July 2023, <https://datatracker.ietf.org/doc/html/draft-mahy-mimi-identity-02>.

[InvisibleSalamanders]

Dodis, Y., Grubbs, P., Ristenpart, T., and J. Woodage, "Fast Message Franking: From Invisible Salamanders to Encryptment", 2018, <https://link.springer.com/content/pdf/10.1007/978-3-319-96884-1_6.pdf>.

[RFC8555]

Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/rfc/rfc8555>.

[SecretConversations]

Facebook, "Messenger Secret Conversations: Technical Whitepaper, Version 2.0", 18 May 2017, <https://about.fb.com/wp-content/uploads/2016/07/messenger-secret-conversations-technical-whitepaper.pdf>.