Change:
This PR adds a way for the members of a group to indicate the credential types they support, and how to negotiate which credential types may be used in a group.
I discussed this offline with NAME and we arrived at: We might need multiple credentials later (as I suspect) If we do that (say in an extension), we will need to update this text We should capture the general theory that covers both single- and multiple-credential cases The proposed additions here just abstract the principle of universal compatibility (which we need in a single-credential world) to one of "at least something" compatibility (which is more compatible with a multi-credential world).> The types of credential that may be used in a group is restricted to what all I think this is too restrictive if we adopt PR . I think it is between the client and its AS if all the clients need to support every credential type used in the group. If you agree with the concept, I am happy to propose slight changes.I think this makes sense.

Discussion:
described in credentials. The "capabilities" field indicates what protocol versions, <del> ciphersuites, protocol extensions, and non-default proposal types are supported by a client.  Proposal types defined in this document are considered "default" and thus need not be listed.  Extensions that appear in the "extensions" field of a LeafNode MUST be included in the "extensions" field of the "capabilities" field. </del> <ins> ciphersuites, extensions, credential types, and non-default proposal types are supported by a client.  Proposal and extension types defined in this document are considered "default" and thus need not be listed, while any credential types the application wishes to use MUST be listed.  Extensions that appear in the "extensions" field of a LeafNode MUST be included in the "extensions" field of the "capabilities" field, and the credential type used in the LeafNode MUST be included in the "credentials" field of the "capabilities" field. </ins> The "leaf_node_source" field indicates how this LeafNode came to be added to the tree.  This signal tells other members of the group

Verify that the LeafNode is compatible with the group's parameters.  If the GroupContext has a "required_capabilities" <del> extension, then the required extensions and proposals MUST be listed in the LeafNode's "capabilities" field. </del> <ins> extension, then the required extensions, proposals, and credential types MUST be listed in the LeafNode's "capabilities" field. Verify that the credential type is supported by all members of the group, as specified by the "capabilities" field of each member's LeafNode, and that the "capabilities" field of this LeafNode indicates support for all the credential types currently in use by other members. </ins> Verify the "lifetime" field:

when they receive the KeyPackage in an Add proposal. The field "leaf_node.capabilities" indicates what protocol versions, <del> ciphersuites, protocol extensions, and non-default proposal types are supported by the client.  (Proposal types defined in this document are considered "default" and not listed.)  This information allows MLS session establishment to be safe from downgrade attacks on the parameters described (as discussed in group-creation), while still only advertising one version / ciphersuite per KeyPackage. </del> <ins> ciphersuites, credential types, and non-default proposal/extension types are supported by the client.  (Proposal and extension types defined in this document are considered "default" and not listed.) This information allows MLS session establishment to be safe from downgrade attacks on the parameters described (as discussed in group- creation), while still only advertising one version / ciphersuite per KeyPackage. </ins> The field "leaf_node.leaf_node_source" of the LeafNode in a KeyPackage MUST be set to "key_package".

can be imposed by including a "required_capabilities" extension in the GroupContext. <del> This extension lists the extensions and proposal types that must be supported by all members of the group.  The "default" proposal and extension types defined in this document are assumed to be implemented by all clients, and need not be listed in </del> <ins> This extension lists the extensions, proposals, and credential types that must be supported by all members of the group.  The "default" proposal and extension types defined in this document are assumed to be implemented by all clients, and need not be listed in </ins> RequiredCapabilities in order to be safely used. For new members, support for required capabilities is enforced by

14.3. <ins> In order to ensure that MLS provides meaningful authentication it is important that each member is able to authenticate some identity information for each other member.  Identity information is encoded in Credentials, so this property is assured by ensuring that members use compatible credential types. The types of credential that may be used in a group is restricted to what all members of the group support, as specified by the "capabilities" field of each LeafNode in the RatchetTree.  An application can introduce new credential types by choosing an unallocated identifier from the registry in mls-credential-types and indicating support for the credential type in published LeafNodes, whether in Update proposals to existing groups or KeyPackages that are added to new groups.  Once all members in a group indicate support for the credential type, members can start using LeafNodes with the new credential.  Application may enforce that certain credential types always remain supported by adding a "required_capabilities" extension to the group's GroupContext, which would prevent any member from being added to the group that doesn't support them. In future extensions to MLS, it may be useful to allow a member to present more than one credential.  For example, such credentials might present different attributes attested by different authorities. To be consistent with the general principle stated at the beginning of this section, such an extension would need to ensure that each member can authenticate some identity for each other member.  For each pair of members (Alice, Bob), Alice would need to present at least one credential of a type that Bob supports.  ## Extensions </ins> This protocol includes a mechanism for negotiating extension parameters similar to the one in TLS RFC8446.  In TLS, extension negotiation is one-to-one: The client offers extensions in its