Original text:
to join who has access to the GroupInfo object.  External joins do not allow for more granular authorization checks to be done before the new member is added to the group, so if an application wishes to <del> both allow external joins and enforce such checks, then the application will need to do such checks when a member joins, and remove them if checks fail. </del>  Application setup may also determine other criteria for membership validity.  For example, per-device signature keys can be signed by an agree on which signers are allowed to send proposals, but any other policies must be assured to be consistent as above. <del> ** RECOMMENDATION:** Have an explicit group policy setting the </del>  conditions under which external joins are allowed. 5.5. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations can interoperate to form federated systems if they use compatible <del> authentication mechanisms, ciphersuites, and infrastructure functionalities. </del>  5.10.

Reviewer comments:
WGLC comments to Functional Requirements Section: Include text for case when external joins are authorized by members autonomously Fix formatting of one RECOMMENDATION section Reference the mls-federation document (informational)
Following on from discussion in Even once a GroupInfo has been published to a prospective new joiner, there are still a few opportunities to apply authorization policy to the join: The DS can block the external Commit from reaching the group members (requires intelligent DS) The clients in the group can all refuse to apply the external Commit (requires consistent policy) Any client can remove the member after allowing them to join (might expose some group comms to the joiner)
Comment by NAME This seems rather risky? What could such a member do in the short time between getting added and getting kicked? Would they see message history? Group membership? How many devices a user has? When members were last online? Why support such a group type? Wouldn't it be better to not support this and have an automated "special member" being a bot that handles member addition?
Until someone else sends a message, a new joiner doesn't learn anything non-public. If you think about it, how would they? They're outside the group before they send an external join, and the external join just establishes a new shared secret with the group for future communications. More specifically: Message history - MLS's forward secrecy guarantees mean that new joiners don't get message history. Group membership - This is public anyway via the GroupInfo that an external joiner needs to join How many devices - To the degree this is exposed, it would be in the group membership Last online - MLS doesn't have any notion of this As for an "add me bot", it's a useful idea, but not applicable to a bunch of cases. The bot has to be a member of the group and has to be always-online. So now you have the group's secrets on a server somewhere, instead of just in the communicating endpoints, already an additional point of compromise. And it can't be the DS's server, since the whole point is to protect against the DS.
This statement in the draft is just plain wrong. In our implementation, we actually do validation of External joins at the application layer. I addressed this in (dating from WGLC) which says the following: "External joins do not allow for more granular authorization checks to be done before the new member is added to the group, so if an application wishes to both allow external joins and enforce such checks, then either all the members of the group must all have the ability to check and reject invalid External joins autonomously, or the application needs to do such checks when a member joins and remove them if those checks fail."

Revised text:
to join who has access to the GroupInfo object.  External joins do not allow for more granular authorization checks to be done before the new member is added to the group, so if an application wishes to  <ins> both allow external joins and enforce such checks, then either all the members of the group must all have the ability to check and reject invalid External joins autonomously, or the application needs to do such checks when a member joins and remove them if those checks fail. </ins> Application setup may also determine other criteria for membership validity.  For example, per-device signature keys can be signed by an agree on which signers are allowed to send proposals, but any other policies must be assured to be consistent as above.  <ins> *RECOMMENDATION:* Have an explicit group policy setting the </ins> conditions under which external joins are allowed. 5.5. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations can interoperate to form federated systems if they use compatible  <ins> authentication mechanisms, ciphersuites, application content, and infrastructure functionalities.  Federation is described in more detail in I-D.ietf-mls-federation. </ins> 5.10.