Moderation tools are great, but if the spammer or troll can easily create a new identity whenever they are restricted, and if the default is access, they can be easy to circumvent.

In most closed silos they have turned to SMS Verification as a tarpit to prevent easily creating new accounts. This works very well, but is limiting to those without SMS access or who don't want to give out their phone number for privacy reasons, etc. And even if one wanted to use SMS Verification on the Jabber network how would one go about proving the verification had taken place?

Basic Idea

A JID can provide (in various contexts, MUC join, MUC membership application, MUC voice request, Subscription request, first message, etc) list of signatures made over their bare JID and a URI that indicates the purpose of this signature is to indicate "they are verified in some way". This could use OpenPGP with a signature annotation for example.

This list of signatures *could* be published via PEP but care should be taken to use whitelist and only add JIDs that are expected to need this information, to avoid leaking possible social graph info publicly.

CA / Robot CA

A signature can be made by an authority which does some kind of verification, manual or otherwise (such as SMS verification, social login, credit card verification, etc). Which authorities any given MUC or user trusts is of course not defined so getting verified only helps if the place you want to get into accepts this CA. It would be useful for communities to indicate "hey, go get verified over here for access" or similar but that is out of scope how they choose to do that.

Chain of signatures

It would be nice to allow trusted users to "vouch" for other users. This works the same technically, but there is much less chance that any given MUC or service has they key for some user and trusts that key to "vouch". Likely they want to check that the user "vouching" has themselves been verified in a way the service trusts.

If users publish signatures in PEP with open access (as suggested to not do above) then any signature could include the JID of the signer, allowing the service to fetch their list of verifications (possibly recursively) and check those. However this definitely leaks social graph data.