Change:
This PR addresses URL
Thanks!
In the context of this document, the meaning of the term Messaging Service (MS) seems a little unclear to me. The document states that the protocol is intended to be embedded in a concrete protocol such as XMPP. However, is a MS meant to be a messaging service such as SMS or MMS? Or a service on the application layer, such as FB or WhatsApp? Essentially who provides / controls the AS and DS? I would be grateful for some clarification on this. Thanks.
It is meant to mean application layer, would changing that to "service provider" work better for you?
Thank you. I do think that the term service provider is less ambiguous.
Ack, will fix soon.
I can make a PR, if you want?
Sure, please go for it.
Fixed by

Discussion:
and is commonly deployed in many such systems.  In this context, "end-to-end" captures the notion that users of the system enjoy some level of security - with the precise level depending on the system <del> design - even when the messaging service they are using performs </del> <ins> design - even when the service provider they are using performs </ins> unsatisfactorily. Messaging Layer Security (MLS) specifies an architecture (this

2. Informally, a group is a set of users who possibly use multiple <del> endpoint devices to interact with the Messaging Service (MS).  A group may be as small as two members (the simple case of person to person messaging) or as large as thousands. </del> <ins> endpoint devices to interact with the Service Provider (SP).  A group may be as small as two members (the simple case of person to person messaging) or as large as thousands. </ins> In order to communicate securely, users initially interact with services at their disposal to establish the necessary values and credentials required for encryption and authentication. <del> The Messaging Service (MS) presents two abstract services that allow </del> <ins> The Service Provider presents two abstract services that allow </ins> clients to prepare for sending and receiving messages securely: An Authentication Service (AS) which is responsible for

A typical group messaging scenario might look like this: <del> Alice, Bob and Charlie create accounts with a messaging service and obtain credentials from the AS. </del> <ins> Alice, Bob and Charlie create accounts with a service provider and obtain credentials from the AS. </ins> Alice, Bob and Charlie authenticate to the DS and store some initial keying material which can be used to send encrypted

2.1. While informally, a group can be considered to be a set of users <del> possibly using multiple endpoint devices to interact with the Messaging Service, this definition is too simplistic. </del> <ins> possibly using multiple endpoint devices to interact with the Service Provider, this definition is too simplistic. </ins> Formally, a Client is a set of cryptographic objects composed by public values such as a name (an identity), a public encryption key

2.3. The Delivery Service (DS) is expected to play multiple roles in the <del> Messaging Service architecture: </del> <ins> Service Provider architecture: </ins> To act as a directory service providing the initial keying material for clients to use.  This allows a client to establish a

The protocol is designed in a way that limits the server-side (AS and DS) metadata footprint.  The DS only persists data required for the delivery of messages and avoids Personally Identifiable Information <del> (PII) or other sensitive metadata wherever possible.  A Messaging Service provider that has control over both the AS and the DS, will not be able to correlate encrypted messages forwarded by the DS, with the initial public keys signed by the AS. </del> <ins> (PII) or other sensitive metadata wherever possible.  A Service Provider that has control over both the AS and the DS, will not be able to correlate encrypted messages forwarded by the DS, with the initial public keys signed by the AS. </ins> [[OPEN ISSUE: These privacy statements seem very strong.  BB.  I would be willing to keep them as requirements since we have example

of these protections includes padding messages in order to produce ciphertexts of standard length.  While this protection is highly recommended it is not mandatory as it can be costly in terms of <del> performance for clients and the MS. </del> <ins> performance for clients and the SP. </ins> Message content can be deniable if the signature keys are exchanged over a deniable channel prior to signing messages.

As described in client-compromise, MLS provides strong authentication within a group, such that a group member cannot send a message that appears to be from another group member.  Additionally, some services <del> require that a recipient be able to prove to the messaging service </del> <ins> require that a recipient be able to prove to the service provider </ins> that a message was sent by a given client, in order to report abuse. MLS supports both of these use cases.  In some deployments, these services are provided by mechanisms which allow the receiver to prove