Change:
duplicative with the "path" field in the Commit.  The committer MUST prefer any Remove received, or the most recent Update for the leaf if there are no Removes.  If there are multiple Add proposals containing <del> KeyPackages with the same "endpoint_id", the committer again chooses one to include and considers the rest invalid.  Add proposals that contain KeyPackages with an "endpoint_id" tuple that matches that of an existing KeyPackage in the group MUST be considered invalid.  The committer MUST consider invalid any Add or Update proposal if the Credential in the contained KeyPackage shares the same signature key with a Credential in any leaf of the group, or indeed if the KeyPackage shares the same "hpke_init_key" with another KeyPackage in the group. </del> <ins> KeyPackages that the committer considers to represent the same client or a client already in the group (for example, identical KeyPackages or KeyPackages sharing the same Credential), the committer again chooses one to include and considers the rest invalid.  The committer MUST consider invalid any Add or Update proposal if the Credential in the contained KeyPackage shares the same signature key with a Credential in any leaf of the group, or if the KeyPackage shares the same "hpke_init_key" with another KeyPackage in the group. </ins> The Commit MUST NOT combine proposals sent within different epochs. Due to the asynchronous nature of proposals, receivers of a Commit

Discussion:
This involved a couple of changes other than just removing the field and references to it: Detecting duplicative Adds is now a little more ambiguous, since you can't just match on . However (a) this doesn't degrade the security of the protocol, just makes it a little less efficient (b) as discussed in , if applications want to sharpen it, they can add an -like identifier in an extension. The External Commit language around resync got generalized to say that the KeyPackage needs to meet the requirements of an Update for the removed node, which captures the successor notions we've discussed. I also noticed that when we forbade proposals by reference in , we didn't totally remove them. So I went ahead and fixed that here.
Comment by NAME What is the logic to make MLS128DHKEMX25519AES128GCMSHA256_Ed25519 the only MTI? It contains both FIPS and not FIPS items, pleasing no one.
I remember arguing that the FIPS suite should be MTI at one of the interims. The argument (iirc) was that people that need FIPS are going to implement FIPS anyways, so the MTI should be the one that's subjectively / widely-considered best. "But then wouldn't a FIPS-only client not conform to the RFC?" Yes, but the people that require FIPS will not care.
Well I know from IKEv2/IPsec, that we do take this into account and do ensure there is only FIPS MITM. I also know we are discussing this in openpgp and also for that reason are adding AES_GCM there. So if the only reasoning is "FIPS will force people to break RFCs anyway", that's kinda weak :P
You mean "MTI"? I don't think the MITM folks care about FIPS :) I think NAME summary captures the state of the art pretty well. Note as well that , so this will soon be moot anyway. (For some government-speed definition of "soon".) So yes, some FIPS folks might be sad in the short run, but things will even out. The working group had a robust discussion on this, and landed on this as a compromise that could get consensus. I don't think these FIPS concerns are worth upsetting that consensus.

Realistically, most folks using end-to-end encrypted instant messaging today are already using a variation of the DoubleRatchet protocol, using Ed25519. Many of our largest customers normally use FIPS, but have exceptions to use Ed25519 in this context and have no problem using Ed25519 for MLS.
(yes MTI :) That NIST doc is from 2017, so I"m not sure what you mean with "soon" :) I personally think it should be fixed but won't block it. Let's see what the IESG says though :)
We added to have a way to reference a member that is stable over the member's lifetime in the group. However, is never used in the protocol; the main need for such references is to give applications a way to tell an MLS stack what to do, e.g., which member to remove. isn't really required for this purpose, either: Leaf indices have the same stability as (since members don't change leaves), and no need for explicit checks on uniqueness. Applications can add their own unique identifiers in KeyPackage extensions Applications often want to refer to non-unique identifiers, e.g., asking to remove all devices belonging to an email address So it seems like at this point, can safely be removed.
NAME NAME NAME - tagging you all here since I seem to recall you had opinions on this topic.
With the changes in enforcing consistent verification methods and the fact that a prior key signs off on any new signature key, I think we have a fairly consistent chain for the identity and the endpoint_id can probably be removed. Leaving it in may strengthen security in some way, but I do not immediately see an issue.
What NAME said. I left a comment in regarding the details on the check, but otherwise, I think we're ok to remove . As you pointed out earlier NAME if an application decides it's necessary, they can always add it via an extension.
Thanks for taking care of the cleanup here after the discussion on . If the application has to provide a function that determines if a given KeyPackage represents a valid update, we could use the same function to determine if an Add is a duplicate. Although admittedly, in that case one would have to compare with all other KeyPackages in the group and the function might not be very efficient. Generally, I'm ok with this solution, though .