App Validation
NOTE: This chapter described the validation steps an application, using OpenMLS, has to perform for safe operation of the MLS protocol.
⚠️ This chapter is work in progress (see #1504).
Proposal Validation
When processing a commit, the application has to ensure that the application specific semantic checks for the validity of the committed proposals are performed.
This should be done on the StagedCommit
. Also see the Message Processing
chapter
if let ProcessedMessageContent::StagedCommitMessage(staged_commit) =
alice_processed_message.into_content()
{
// We expect a remove proposal
let remove = staged_commit
.remove_proposals()
.next()
.expect("Expected a proposal.");
// Check that Bob was removed
assert_eq!(
remove.remove_proposal().removed(),
bob_group.own_leaf_index()
);
// Check that Charlie removed Bob
assert!(matches!(
remove.sender(),
Sender::Member(member) if *member == charlies_leaf_index
));
// Merge staged commit
alice_group
.merge_staged_commit(provider, *staged_commit)
.expect("Error merging staged commit.");
}
External Commits
The RFC requires the following check
At most one Remove proposal, with which the joiner removes an old version of themselves. If a Remove proposal is present, then the LeafNode in the path field of the external Commit MUST meet the same criteria as would the LeafNode in an Update for the removed leaf (see Section 12.1.2). In particular, the credential in the LeafNode MUST present a set of identifiers that is acceptable to the application for the removed participant.
Since OpenMLS does not know the relevant policies, the application MUST ensure that the credentials are checked according to the policy.