Add detail and address feedback on identity doc

[richardhuaaa]

Preview the doc here: https://github.com/xmtp/libxmtp/blob/rich/identity-doc-updates/xmtp_mls/IDENTITY.md

Adding more detail that was requested during review, as well as addressing feedback.

• Add context on ethereum wallets
• Add detail on signature formats and signature labelling
• Add installation_public_key to credentials
• Clean up time representation
• Add detail on credential validation and installation synchronization
• Add detail on revocation
• Add account-level membership description

[neekolas]

I'm not sure this is going to be viable as part of the message processing flow. Any race condition here could lead to part of the group accepting a commit and part of a group rejecting it. Even if we are only checking whether the installation was revoked at the time the message was sent, and not the time it was read, it still opens the door to potential race conditions given that revocation state does not have the same total ordering properties as topic contents.

The good news is that revocations don't need to be instant.

I propose we don't check for revocation when reading payloads and instead do it before synchronizing the group state. Anyone with privileges allowing them to remove users would check the network for any revoked members of the group and submit a commit to remove the revoked installation from the group before processing any other intents.

How this interacts with group permissions is TBD. Maybe we want a carve-out allowing anyone to remove a revoked installation so that we don't have to wait for an admin to come online. Maybe we have each user go through all their groups and remove themselves as part of revocation.

[richardhuaaa]

My preference is to have total ordering between revocations and commits, which is a little more robust, but I concede that the current direction of decentralization work doesn't seem to be heading that way.

Updated the revocation approach in 18c7f93!

[karthikbhargavan]

These clarifications address all the security considerations we considered, so it looks great. The only thing I would add is an explicit note that we the installation_key should only be used in MLS and not elsewhere. If it is, then we need to review those use cases to ensure signature non-collisions.