More Instant Messaging Interoperability (MIMI) Policy

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

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 23 September 2024.¶

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

This document relies on the concepts described by [I-D.barnes-mimi-arch] and [I-D.ralston-mimi-protocol].¶

Policy within MIMI defines who or what is allowed to take a certain action, and what the allowable actions are. Some examples include whether a given user is able to send messages or promote/demote other users within the room. This document outlines the minimum permissions required for interoperability, and how the Role-Based Access Control (RBAC) mechanism works.¶

Some actions are enforceable by the hub server or local follower server in a room, however other actions can only be handled by end clients. Whether a server can enforce the policy largely depends on the server's visibility of the message being checked: MLS Private Messages cannot be inspected, and therefore cannot have policy applied to them by the server. Such messages will need to be checked by the clients instead.¶

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

Terms from [I-D.barnes-mimi-arch], [I-D.ralston-mimi-terminology], and [I-D.ralston-mimi-protocol] are used throughout this document. [I-D.barnes-mimi-arch] takes precedence where there's conflict.¶

Other terms include:¶

Rejected: The action being performed ceases to continue through the remainder of the send/rendering steps. For a hub server, this means the event being sent is not added to the room and is not sent to any other server. For a client, this equates to not rendering or respecting the action.¶

Allowed: The opposite of Rejected. The action is expressly permitted to occur.¶

"Engaging with the room": The user is able to take some actions and send messages in the room, provided the remainder of the policy allows them to do that. The encryption/security layer MAY further restrict a user's ability to take action. For example, the user might need 1 or more clients to be able to successfully send a message.¶

3. Types of Senders

• TODO: Figure out non-user permission structures. https://github.com/turt2live/ietf-mimi-policy/issues/2¶

4. Permissions

Groups of permissions are known as roles. These roles are then assigned to a user or server as needed. Permissions cannot be assigned without being part of a role.¶

Roles do not currently carry aesthetic characteristics, such as a name, badge color, or avatar.¶

Roles, and their assignees, are persisted through the AppSync MLS extension. Changes are proposed with MLS Proposals, and confirmed with MLS Commits. This uses the mimiRoomPolicy applicationId defined by [I-D.ralston-mimi-protocol].¶

• TODO: Define actual example/schema once AppSync is more reviewed by the MLS working group. Initial indications are unclear if a diff or "irreducible" blob is preferred.¶

A role notionally looks like the following:¶

enum {
   /* Iterated later in the document. */
} Permission;

struct {
   select (Permission) {
      /* cases defined later in the document. */
   } permission;
} PermissionValue;

struct {
   PermissionValue permissions<V>;
   IdentifierUri assignees<V>;
   int order;
} Role;

IdentifierUri is as defined by Section 5.2 of [I-D.ralston-mimi-protocol].¶

enum {
   // Whether other users can be added to the room by the role.
   // Default: false.
   add(1),

   // Whether other users can be kicked from the room by the role.
   // Default: false.
   kick(2),

   // Whether other users can be banned from the room by the role.
   // Default: false.
   ban(3),

   // Whether another user's events can be redacted by the role.
   // Senders can always redact their own events regardless of this permission.
   // Default: false.
   redact(4), // TODO(TR): Do we need this one?

   // The actions this role can take against roles. For example, adding or
   // removing permissions.
   // Default: None.
   roles(5),

   // Whether the assigned entities can send messages to the room.
   // Default: true.
   sendMessages(6), // TODO(TR): This likely needs breaking out.
} Permission;

struct {
   select (Permission) {
      case invite: BooleanPermission;
      case kick: BooleanPermission;
      case ban: BooleanPermission;
      case redact: BooleanPermission;
      case roles: RolePermission;
      case sendMessages: BooleanPermission;
   } permission;
} PermissionValue;

struct {
   // When false, the permission is explicitly not granted.
   byte granted;
} BooleanPermission;

struct {
   // The role IDs that can be affected by this role. This includes adding,
   // removing, and changing permissions.
   // TODO(TR): We might want something more comprehensive.
   opaque affectRoleId[];
} RolePermission;

5. User Participation

• TODO: Needs updating considering participation state changes are proposed through AppSync now. The concepts around the rules of state changes still apply.¶

• TODO: "Invite" likely needs swapping for "Add".¶

User participation is tracked as m.room.user state events. The content for such an event has the following structure in TLS presentation language format (Section 3 of [RFC8446]):¶

enum {
   invite,  // "Invited" state.
   join,    // "Joined" state.
   leave,   // "Left" state (including Kicked).
   ban,     // "Banned" state.
   knock    // "Knocking" state.
} ParticipationState;

struct {
   ParticipationState participation;
   opaque reason;  // optional reason for the participation state
} MRoomUserEventContent;

A user is considered to be "joined" to a room if they have a participation state of join. All servers with users in the joined state are considered to be "in" the room.¶

Servers which are in the room can send events for their users directly. The signaling protocol is able to assist servers (and therefore users) in sending the appropriate participation events until they are able complete the join process.¶

enum {
   invite,
   knock,
   public,
} JoinRule;

struct {
  // The current join rule for the room. Defaults to `invite` if no join rules
  // event is in the room.
  JoinRule rule;
} PolicyJoinRule;

6. Security Considerations

• TODO: Verbosely describe the security considerations throughout the doc.¶

7. IANA Considerations

None.¶

Authors' Addresses