Identity

Each participant in a Kore Ledger network has a unique identifier and a private key that allows him/her to sign the transactions made. In addition, depending on their interest in each subject and their level of involvement with the network, each participant will have one or more different roles.

Given the strong influence of KERI¹ in our project, the reflection on the reference model to establish the identifiers in our protocol starts from Zooko’s triangle². This is a trilemma that defines three desirable properties desirable in the identifiers of a network protocol, of which only two can be simultaneously. These properties are:

• Human Meaningful: Meaningful and memorable (low entropy) names to users.
• Secure: The amount of damage a malicious entity can inflict on the system should be as low as possible.
• Decentralized: Names are correctly resolved to their respective entities without using a central authority or service.

Although several solutions to the trilemma have already been proposed, we have prioritized decentralization and security to shortly implement a design equivalent to the Ethereum Name Service . Specifically, in our approach we have considered three types of identifiers, which in turn represent three types of cryptographic material:

• Public key, the identifier of the roles participating in the network.
• Message digest, the identifier of the content of messages resulting from applying a hash function to this content.
• Cryptographic signature, the identifier of the signatures made by the roles on the messages, which serves as verifiable proof.

This cryptographic material is large binary numbers, which presents a challenge when used as identifiers. The best way to handle identifiers is through a string of characters and, for conversion, we have adopted the Base64 encoding, which encodes every 3 bytes of a binary number into 4 ASCII characters. As the cryptographic material to be managed is not a multiple of 3 (32 bytes and 64 bytes), it is filled with an additional character (32 bytes) or two (64 bytes). As in KERI, we have taken advantage of these additional characters to establish a derivation code to determine the type of material by placing the derivation character(s) at the beginning.

The following table details the currently supported derivation codes:

New types of cryptographic material have already been incorporated into the roadmap, thinking of devices limited to operations with RSA³ or P256⁴, and post-quantum cryptography, such as Crystal-Dilithium⁵. In the case of RSA or Crystal-Dilithium, we are dealing with a binary size of cryptographic material that is too large to be represented as identifiers, so we will have to incorporate a different derivation mechanism.

References