Identity is at the core of each and every interaction. While the required level of trust between identities can vary from one interaction to another, the necessity to exchange it in a secure and privacy preserving manner is universal.
We implemented our identity system as “distributed Self-Sovereign Identity (SSI)”. Kindly note that it is fully ERC725/735 compliant plus some payment/settlement related functions.
All Web Services for our distributed Self-Sovereign Identity are available in the Identity Namespace: https://coin.codeb.io/identity.asmx
Create Self-Sovereign Identity Contract
To create and roll out an identity contract you need function CreateIdentity from the Identity Namespace.
CreateIdentity requires two parameters:
ChainAddress: Blockchain address of private key to be used for roll-out. This address will also be the owner of the new SSI.
Password: Password to unlock the private key on the server.
MnemonicPhrase: This parameter can be left as empty string (it is optional) in case you have imported your key already to the server.
GenericID: Even this parameter can be left as empty string. It can be used optionally to add a claim as “Generic ID” to the identity. For example an alternative logon name, etc.
Please note that you can also use our websocket to create a SSI: Create Self-Sovereign Identity
Add permission to other keys
After the deployment of an identity contract you can assign roles to other keys. To do so you need to add hashes of the other public keys to the identity with the function AddKeyHash2Identity.
For example if you want to allow another identity to add verifiable claim you need to add the other identity’s key hash with purpose 3 (claim signer).
AddKeyHash2Identity requires five parameters:
SSIAddress: Chain Address of the Self-Sovereign Identity the claim has to be attached. Kindly note that you need to be the owner of that SSI or keccak256 hash of your public key has to be registered as a “Claim Signer Key” (Purpose 3) in the SSI.
Keccak256_KeyHash: This is the hash of the public key to be added.
Purpose: Every key has a purpose define. For example: 1 = Management Key (owner), 3 = Claim Signer and 11 = Financial Manager allowed to transfer funds.
KeyType: The Crypto Algorithm supported by the key. For example: 1 = ECDSA, 2 = RSA, etc.
ChainAddress: Blockchain address of private key to be used to attach claim. This address myst be registered in the SSI as owner, manager (purpose 1) or claim signer (purpose 3) will also be the owner of the new SSI.
Password: Password to unlock the private key on the server.
Note: With the additional parameter DataHEX in AddKeyHashAndData2Identity you can add additional data to the keyhash. For example the public key itself. You can query that additional data with with: getKeyData. Additional data written is permanent. It can never be overwritten or deleted!
Once you receive the transaction hash you can check its status with the following REST API:
https://coin.codeb.io/blocks.aspx?fr=<hash> for example:
You can also query the Transaction hash via Web Services function GetReceipt in the Tools Namespace. This function will return the blocknumber in HEX.
If you need more information about your transaction you can query the Transaction hash via Web Services function GetFullReceipt in the Tools Namespace.
Retrieve purpose from SSI for a given key
With the function getKeyPurpose of the Identity Namespace it is very easy to retrieve the purpose of a given key from a SSI Contract.
The function requires two parameters:
SSIAddress: Chain Address of the Self-Sovereign Identity to query.
Keccak256_KeyHash: This is the hash of the public key to query.
Store data to SSI
With SetData you can store data in your SSI contract. It can be retrieved with the command GetData. This is ideal for example to store and share CDR Records for CDR Reconciliation.
Use SSI as a single logon network
If you pass a password to SetUserPassword it will be salted and hashed and that hash then stored inside the SSI. The function TestUserPassword carries out the same salting and hashing before passing that hash to the function. Only if it matches the hash stored with SetUserPassword it returns true.
Note: This is an ideal method to keep authentication data safe and distributed across many systems. We use that for example (just with a different salt) for our SMS SMPP Gateway.