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: it can skip the checks if it really needs to. In summary: the idea is basically to tell app/AS devs when/which are the right checks to perform to get good security & availability but also to leave it up to them to make those checks meaningful. Finally, regarding "consistency": in my mind creds are validated relative to a context (e.g. a time-stamp for checking expiration, a root CA cert, a blockchain or even particular block for checking wallets and/or balances, etc.) One way to get consistency is for the app/AS to ensure that all clients use the same context when checking the creds in a ratchet tree regardless of when they perform their checks.
In my mind, applications are only ever in one of two states: A.) I'm reading backlogged messages, or B.) I've read all the messages and I'm waiting for new ones. When you're in state B, you can send messages and also check time-related things. When you're in state A, you have no idea when the messages you're reading were truly sent. We don't currently provide any way to communicate a "context" against which time-related things should be validated in state B. So I don't see how we can implement b or c from this list?
Implementing b. and c. in some spec compliant way is actually trivial because the spec doesnt require "consistency" (in the sense that I defined that term in my previous post.) The only thing the spec says about consistency is that if you want guarantee (3.) then you need consistent cred validation. So e.g. always returning true when validating in cases b. and c. while doing something more interesting for cases (a.) would be fine; i.e. spec compliant. You just wouldn't necessarily get guarantee (3.) is all. But I figure what you meant is how to implement (a.) b. and c. to be consistent, right? And that'd be a good question that any app trying to avoid forks would have to think about. (Notice, the RFC already creates this concern for such apps with out my proposed changes because to avoid forks now you already need commit sender and receivers to agree on their validation.)