As the designer of this SSI environment, I would like each participant to route all outgoing messages through it's afilliated cloud agents

[francis-pouatcha]

This DIDComm messaging v2 mediator should support:

1. maximum privacy for the sender of a message: means that the IP address of the initial sender of the message should only be viewable to a relay affiliated with that sender (sender cloud agent).
2. protect itself against denial of service: means each registered consumer (agent) will have a dedicated key used to authenticate with the relay.

ToDo: Design and implement a routing coordination protocol with respect to ideas described in comments below.

[francis-pouatcha]

Following strategies can be used by a relay to allow for tracking of registered consumers.

Consumer Database Maintain a database of public keys of registered consumers. Then lookup consumer every time a message is deposited.

This strategy limits the scalability of the relay with the database holding the list of consumers.

This strategy allows the relay to maintain metadata on the list of registered consumers and can manage subscription and business operation in that table.

Consumer Issued Public Key We can leverage the concept of hierarchical deterministic keys to prevent the use of an extensive database.

Each registrant will be given:

1. a service master key id: the identifier of the master key used to service this relay. This can be a hash of the parent key at the service.
2. a chain code source: info used by the service to hardened derive a child private key for this consumer. This can be made of <consumer.public.key, valid.from, valid.to, service.level>
3. public key: the corresponding service public key: authentication of a message will be successful, when the service can derive the private and public key from provided message data.

This approach has the disadvantage, that the service can not maintain metadata on a consumer.

This approach can nevertheless use tokenization to manage economics. For example, the service can provide an interface, where a registered client can buy a token (special purpose public key) that is good for a number of messages. This enabling service can then be designed to maintain metadata on registered consumers.

[francis-pouatcha]

According to the analysis above, we have to distinguish between:

• The registration service, that maintain a table of registrants, including payment, and locks, ...
• The token service that allow a consumer to produce (buy) tokens used for sending messages
• The relay service (proxy), that processes messages based on stateless auth tokens.

Recall that token in this context are specially generated, dedicated public keys, that are not supposed to be shared by the consumer with others.

[francis-pouatcha]

Denial of Service A consumer that loses his toke to a malicious party will be considered the malicious party. This way, misuse of the token will lead to a suspension of the consumer.