Update on our MGC Verifiable Data Chain Demonstrator
We just increased performance of our Verifiable Data Chain demo and integrated our Corporate Wallet solution for managing private keys of the entities involved in the demo.
Key management is done via vaults. Vault policies are defined in accordance to compliance requirements of an enterprise. We are using the following set-up for identities and vaults:
Account: Entities that require identity(-ies). Accounts are spaces where identities can be managed. An account can be created for human, legal entity, machine or any other physical or virtual object. Inside of accounts, we work with: Participants, Vaults and Sub-Identities. Sub-Identities are represented by wallets (key-pairs) and managed inside vaults.
Participant: Participant devices can be created within a particular account. After requesting participant creation, it needs to be activated on a dedicated iOS device or with a cloud software agents (embedded devices to be supported later), to further trace operations from vaults of the corresponding account where participant was specified as a quorum member, so that it can provide approvals for pending operations. In the essence, participant’s device, holds the secret that gives it a possibility to manipulate wallets that exist inside connected Vaults.
Vault: Vaults are managed identity groups. Vaults group a single or multiple wallets, and define quorum policies for managing them. At the time of vault creation, there is a need to specify the list of participants that will have a right to approve operations on behalf of wallets identities that can be generated within.
Sub-identity/Persona/Wallet: Each vault can have multiple wallets which are sub-identities (or personas) for of vault group or account holder. As an example, let’s consider that some wallet identity is being used to sign some data in order to build a verifiable claim. In this case, after the signing process will start, participants that correspond to a respective vault, will be notified about a pending operation. And after gathering the required number of approvals, the operation will be processed.
Vault Quorum Policy: Vault’s Quorum Policy is a rule set. Vault’s Quorum Policy is being defined at vault creation time. It describes the list of participants who participate in a quorum and the number of required approvals that need to be collected from all vault’s participants for progressing a operation (signing or joining a vault).
In case you are interested in the above, we would be happy to demonstrate the integration of vaults with legal entities, identity/device management and digital twinning for machine twins and verifiable data chains.
Log in or sign up for Devpost to join the conversation.