Code change:
5.3.2. <ins> In some credential schemes, a valid credential can "expire", or become invalid after a certain point in time.  For example, each X.509 certificate has a "notAfter" field, expressing a time after which the certificate is not valid. Expired credentials can cause operational problems in light of the validation requirements of credential-validation.  Applications can apply some operational practices and adaptations to Authentication Service policies to moderate these impacts. In general, to avoid operational problems such as new joiners rejecting expired credentials in a group, applications that use such credentials should ensure to the extent practical that all of the credentials in use in a group are valid at all times. If a member finds that its credential has expired (or will soon), it should issue an Update or Commit that replaces it with a valid credential.  For this reason, members SHOULD accept Update proposals and Commits issued by members with expired credentials, if the credential in the Update or Commit is valid. Similarly, when a client is processing messages sent some time in the past (e.g., syncing up with a group after being offline), the client SHOULD accept signatures from members with expired credentials, since the credential may have been valid at the time the message was sent. If a member finds that another member's credential has expired, they may issue a Remove that removes that member.  For example, an application could require a member preparing to issue a Commit to check the tree for expired credentials and include Remove proposals for those members in its Commit.  In situations where the group tree is known to the DS, the DS could also monitor the tree for expired credentials and issue external Remove proposals. Some credential schemes also allow credentials to be revoked. Revocation is similar to expiry, in that a previously valid credential becomes invalid.  As such, most of the considerations above also apply to revoked credentials.  However, applications may want to treat revoked credentials differently, e.g., removing members with revoked credentials while allowing members with expired credentials time to update. 5.3.3. </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

Related discussion:
text: Side note: under the general rubric of "validity changes over time", revocation is also an issue! Overall, my thinking aligns with what NAME says here. Saying that the credentials presented by group members should be valid at all times is a concise, clear standard. It is arguably implied by the current requirement to validate credentials on joining (if you also assume that the group should be joinable at any time). The more difficult question is how it is implemented in practical reality. I don't think we can really write hard requirements around this. The only remediation is Remove, and we don't have other situations where we say a client MUST send a specific proposal. In part because this might conflict with application-level policies about who is allowed to send Proposals/Commits. And it seems like there are valid situations where availability might trump authenticity (cf. browsers' click-through on expired certs). Overall, this seems like more of an operational question than a core protocol question here. In terms of how to reflect all this in documents: The details of how to manage credential freshness seem better suited for an implementation guidance document. (I believe NAME is gathering ideas for one?) In the MLS protocol spec, we could add some high-level guidance, something like the following: I think that would fit well either in the Credentials section (between "Credential Validation" and "Uniquely Idenitfying Clients") or in the security considerations.
We could use the sender_generation field of the MLS message to signal what was the global app generation of the sender. Functionally, this allows receivers to know if they received all previous application messages from the sender. In the current design, if S sent M0, M1, M2 you can know if you missed M1 when receiving M2, but you cannot know if you missed M2. There are many ways of doing this: global sender counter, counter between two operations of the sender...
We seemed in agreement at the interim because it prevents the application message suppression attacks
Looks great thanks NAME I like the separate treatment of expired vs. revoked. Looks good to me now!