Original text:
identical to the "signature_key" in the LeafNode containing this credential. <del> Each new credential that has not already been validated by the application MUST be validated against the Authentication Service. Applications SHOULD require that a client present the same set of identifiers throughout its presence in the group, even if its Credential is changed in a Commit or Update.  If an application allows clients to change identifiers over time, then each time the client presents a new credential, the application MUST verify that the set of identifiers in the credential is acceptable to the application for this client. </del> 6.3.1.  MLS implementations will presumably provide applications with a way to request protocol operations with regard to other clients (e.g., removing clients).  Such functions will need to refer to the other

Reviewer comments:
Replaces This PR attempts to add precision to the credential validation requirements in the document, along the lines NAME suggests in , in the spirit of what NAME wrote up in and drawing inspiration from what RFC 6125 does in the context of TLS. It seems like this gives a clearer definition of (a) what the AS's job is and (b) when it needs to be done.
While this is spread out throughout the document, it would be beneficial to spell out in which scenarios a Credential MUST be verified (with the AS): When fetching a KeyPackage to add a new member When discovering a KeyPackage in an AddProposal from another member When joining a new group (verify all other members' Credentials), both when receiving a Welcome message and when joining through an External Commit When a member updates its leaf ... anywhere else?
Thanks for picking it up!

Revised text:
identical to the "signature_key" in the LeafNode containing this credential.  6.3.1. <ins> The application using MLS is responsible for specifying which identifiers it finds acceptable for each member in a group.  In other words, following the model that RFC6125 describes for TLS, the application maintains a list of "reference identifiers" for the members of a group, and the credentials provide "presented identifiers".  A member of a group is authenticated by first validating that the member's credential legitimately represents some presented identifiers, and then ensuring that the reference identifiers for the member are authenticated by those presented identifiers. The parts of the system that perform these functions are collectively referred to as the Authentication Service (AS) I-D.ietf-mls- architecture.  A member's credential is said to be _validated with the AS_ when the AS verifies the credential's presented identifiers, and verifies that those identifiers match the reference identifiers for the member. Whenever a new credential is introduced in the group, it MUST be validated with the AS.  In particular, at the following events in the protocol: When a member receives a KeyPackage that it will use in an Add proposal to add a new member to the group. When a member receives a GroupInfo object that it will use to join a group, either via a Welcome or via an External Commit When a member receives an Add proposal adding a member to the group. When a member receives an Update proposal whose LeafNode has a new credential for the member. When a member receives a Commit with an UpdatePath whose LeafNode has a new credential for the committer. When an "external_senders" extension is added to the group, or an existing "external_senders" extension is updated. In cases where a member's credential is being replaced, such as Update and Commit cases above, the AS MUST also verify that the set of presented identifiers in the new credential is valid as a successor to the set of presented identifiers in the old credential, according to the application's policy. 6.3.2. </ins> MLS implementations will presumably provide applications with a way to request protocol operations with regard to other clients (e.g., removing clients).  Such functions will need to refer to the other