Authenticated Anonymity

Is the seemingly paradoxical notion of “Authenticated Anonymity” possible or is authentication essentially incompatible with anonymity?

Anonymity and specifically sender anonymity have become essential requirements for many privacy-related applications. On the other hand, anonymity may be abused for various malicious activities.

With the new feature “Authenticated Anonymity” CodeB addresses both with protocols for authenticated anonymous communications channels. In those channels, the client can authenticate with the Group SSI while the latter can only authenticate the fact that an address is one of the qualified members of a defined group.

Use Cases

  • Allow a group of suppliers to pre-negotiate without revealing their identity.
  • Allow requests for GDRP critical customer information for a group of defined business partners.

All functions required are exposed in our Messaging Web Services API on:

Additionally we abstracted all required APIs into our CommandLine Interface HERE.

As mentioned before the new feature will only authenticate if a chainaddress is member of a defined group. It is is impossible for the system to identify or trace the owner of that address.

All groups are hosted in a Key Distribution Self-Sovereign Identity Contract. In our example that is the contract 0x5c18670e28b3bfd9636c8e3d65dc1eed47c5b673 (referred to as variable GroupSSIAddress)

The administrator of the GroupSSI can now define GroupID’s (from 0 to 9999) and add other Self-Sovereign Identity Contracts (MemberSSIs). Those other SSI contracts can be either the organisations contracts or specifically dedicated identity contracts. Adding of those contracts to the Key Distribution Self-Sovereign Identity is done with the following function:


The function parameters are explained HERE and the function is available at:

Identity Keys

Group members identity contracts must at least have one principal identity assigned to a specific role with RegisterKeyInMemberSSI so that the Key Distribution Self-Sovereign Identity is able to assign ZKP material. This principal identity MUST NOT have any other role assigned in the members identity contract. Ideally you create a new, dedicated principal identity with the function CreateMSGKeyOnNode. Details are explained HERE.

To be able to remain 100% anonymous you need to create a second principal account (also called Reply2Address) with CreateMSGKeyOnNode and which MUST NOT be registered anywhere. You can create as many Reply2Addresses as you wish and delete them after their use with DeleteMSGKeyFromNode.

Distribute Zero Knowledge Proof Crypto Material

The system works with several overlapping layers of ZKP’s. The required material is distributed to all identities registered as message receiver in the organisations SSIs. This means that at least one principal account of a organisational SSI has to be registered with RegisterKeyInMemberSSI. message receivers have to be registered!

Now that everything has been registered you can proceed with the function CalculateZKPKeys on URL Detailed information can be found HERE.

Create and Validate Messages

Now you can proceed and send your message.

Note: You MUST NOT forget to use an unregistered key as Reply2Address!

You can create or send a broadcast to a complete group via CreateMSG2Group and SubmitMSG2Group. To send to a specific address or identity use functions CreateMSG2Address or SubmitMSG2Address.

Manual ZKP validation of a message JSON can be carried out via ValidateMSG.

To enumerate an view your message postbox you need to use any of the retrieve functions explained HERE.

Questions? Just contact us on