Registration

In order for identity to be able to register on a mediator, the mediator DID Document needs to have DecentrlMediatorRegister service available. This service looks something like this

{
  "id": "did:web:mediator.decentrl.network#mediator",
  "type": "DecentrlMediatorRegister",
  "serviceEndpoint": {
    "uri": "https://mediator.decentrl.network/register",
    "routingKeys": ["did:web:mediator.decentrl.network#key-ECDH-1"]
  }
}

• serviceEndpoint should be a URL linking to the POST route for registration.

• routingKeys should be an array of references to the public encryption keys used by the mediator to enable E2EE communication. Minimum of one routing keys is required in order to establish secure communication with the mediator.

Registration

When registering on a mediator, an encrypted payload containing a list of mediator features you wish to enable for your identity has to be sent.

Choosing which features identities wish to have enabled on the mediators increases the privacy of the identities. Take Elon Musk for an example, let's say Elon wishes to have a DID from which he can post status updates to his followers, something like Twitter. In this case, he might want only one-way public communication channels enabled on his mediators to prevent random people from messaging and spamming him.

He could however have a different DID setup for encrypted communication with his friends. This did would have a two-way private feature enabled on the mediator. Because DIDs are private and cannot just be guessed, only people who know the id of Elons private communication DID will be able to contact him.

It is suggested to use different DIDs for different services as it increases the security of your identity.

Unencrypted payload should look something like this

{
  "features": ["TWO_WAY_PRIVATE", "ONE_WAY_PUBLIC"],
}

Once you have your payload prepared, you can encrypt it using ECDH-ES A256GCM JWE encryption using your private EC P-256 key and one of the public routing keys specified in the mediator's service endpoint. When setting protected JWE headers, set kid property to the id of the public key related to the private key that was used for encryption. That way it's easier for mediator to verify the identity of the sender.

The encrypted payload can now be posted to the registration endpoint. It should be included in the body in the following format

interface {
  encryptedPayload: string;
}

Once the mediator receives and decrypts payload, it will know which features to register for the current identity and it will also have a verificaiton of the identity due to the nature of eliptic curve encryption (authcrypt)

Mediators can be public, meaning that anyone can register and they can also be private allowing registration of only selected identities.. (might require payment to use, etc..)