Original text:
7.3.3.1. One important feature of MLS is that all Members know which other <del> clients are in the group at all times.  If all Members of the group </del>  and the Authentication Service are honest, no parties other than the members of the current group can read and write messages protected by the protocol for that Group. <del> Beware though, the link between the cryptographic identity of the client and the real identity of the End User is important.  Details about how to verify the identity of a client depend on the MLS Credential type used.  For example, cryptographic verification of </del>  credentials can be largely performed autonomously on the clients for the "x509" Credential type.  In contrast, when MLS clients use the "basic" Credential type, a larger degree of trust must be placed in a *RECOMMENDATION:* Select the strongest MLS Credential type available among the target members of an MLS group. <del> While the Authentication Service is often very well protected from external attackers, it might be the case that this service is compromised.  In such infrastructure, the AS could validate a (or generate a new) signature keypair for an identity which is not the expected one.  Because a user can have many MLS clients running the MLS protocol, it possibly has many signature keypairs for multiple devices.  Note that when a "basic" Credential is used, the Authentication Service also needs an out-of-band mechanism to verify the identity asserted in the Credential. With some Authentication Service designs, a private or centralized authority is trusted to validate signature keypairs used in the MLS protocol.  This is typically the case in some of the biggest messaging infrastructures. </del>  In the case where an adversarial keypair is generated for a specific identity, an infrastructure without any transparency mechanism or

Reviewer comments:
The Section has three recommendations, but the discussion rambles. The proposed text places topics related to each recommendation before that recommendation.
Thanks!
Comment by NAME Why allow this in the MLS protocol? How can this "typically" be the case of some of the biggest messaging infrastructures? Clearly those don't run the MLS protocol? Perhaps you meant to compare a similar function to the AS in other messaging protocols? That is, I would clarify what is the issue, what is possible in MLS and how it compares to non-MLS existing deployments.
At a high level, MLS was designed to be agnostic about the authentication design, so I don't think there's much normative for MLS to say here. With that said, it seems to me that there are two practices here: A centralized/private authority. As the text says, this is very common and seems like a fairly natural design, whether we like it or not. That authority generating keys rather than signing them. That seems bad, and I guess we could discourage it, but it can't be enforceably prohibited
That was probably meant to be a comparison, yes, but this entire block has been removed through the multiple changes already made anyway. The important part was to describe things as ekr suggested which is already the case and there is already a recommendation to not design a system which generates the keys in the section about the AS.

Revised text:
7.3.3.1. One important feature of MLS is that all Members know which other  <ins> members are in the group at all times.  If all Members of the group </ins> and the Authentication Service are honest, no parties other than the members of the current group can read and write messages protected by the protocol for that Group.  <ins> Details about how to verify the identity of a client depend on the MLS Credential type used.  For example, cryptographic verification of </ins> credentials can be largely performed autonomously on the clients for the "x509" Credential type.  In contrast, when MLS clients use the "basic" Credential type, a larger degree of trust must be placed in a *RECOMMENDATION:* Select the strongest MLS Credential type available among the target members of an MLS group.  <ins> If the AS is compromised, it could validate a (or generate a new) signature keypair for an attacker.  Because a user can have many MLS clients running the MLS protocol, it possibly has many signature keypairs for multiple devices.  These attacks could be very difficult to detect. *RECOMMENDATION:* Provide a key transparency mechanism for the Authentication Services to allow public verification of the credentials authenticated by this service. Note that when a "basic" Credential is used, the Authentication Service also needs an out-of-band mechanism to verify the identity asserted in the Credential. </ins> In the case where an adversarial keypair is generated for a specific identity, an infrastructure without any transparency mechanism or