AD8.6E-Roots of Trust

Roots of Trust

When verifying a verifiable credential, it is possible to confirm that the credential was not modified or tampered with from the original one issued by the issuer by checking the digital signature. However, there is still an additional step to verify who that issuer actually is.

For instance, in a verifiable credential the only information about the subject could be its DID see more about DIDs here. In this case, where can we go to see and verify who is behind that DID? On the opposite side, the credential could include a lot of information about the issuer including name, address, etc. However, how can we know that it was really that entity and not another one impersonating it the one who issue the credential and put that information on it?

One way or another, verifying an issuer of a digital credential requires going to a trusted registry. It could be centralized registry (i.e., the website of who the issuer is claiming to be), but this is very inefficient and non practical, and it can also be faked.

LACChain has developed a blockchain-based mechanism to verify issuer’s identities, replicating the roots of trust we have on our browsers for verifying domains. The same way our browsers’ roots of trust allow us to verify X.509 certificates for verified and secure interaction over the Internet, LACChain’s root of trust allow to verify who is the issuer of a verifiable credential. The proposal consists on two elements: a smart-contract-based root of trust and a verifiable-credential-based root of trust.

Based on Smart Contracts

The way it works is simple and can be described in the following steps:

Registering a DID in a public DID Registry: Any entity, in this case potential issuers of verifiable credentials or other type of assets (e.g., tokens), can register its DID in the DID Registry (see more).
Requesting the operator of a PKD to verify their DID: A trusted entity (i.e., a certifier) maintains a permissioned smart-contract-based public key directory. In this smart contract the trusted entity maintains a directory of information that relates DIDs to information about the real identity of the entities operating those DIDs. In this second step, the owner of a DID asks the operator of the PKD to verify its identity.
Verification of the issuer’s identity: The operator of the PKD accomplishes the verification of the issuer’s identity following whatever processes they have established for it (including proof of control of the keys associated to the DID and proof if identity through traditional mechanisms).
Adding the issuers DID and identity to the PKD: The operator of the PKD adds the issuers DID and identity into the PKD for public consultation.
Creating a Trusted List connected to the PKD: The entity added into the PKD can also operate its own smart-contract-based directory (a trusted list) of DIDs linked to identities. With this, we already have a two-level root of trust.
Iterate the process: This process can be iterate two create an N-level root of trust based on smart contracts that represent verified key directories.

For instance, an international health entity could create a public key directory to list the DIDs of all the ministries of health. Later, each Ministry of Health could create its own trusted list to list all vaccination centers. When a vaccination center issues a vaccination certificate using its DID, the issuer’s identity is verified first again the Ministry of Health’s Trusted List, and immediately after against the regional healths’ entity Public Key Directory.

Managing these directories using smart contracts allows to manage permissioning over the writing, fully transparent access for verification, track corruption, and enable every entity to have governance over its own information while being in a trust registry that is governed by every participant at the same time.

Based on Verifiable Credentials

If at some level the root of trust shall not be public, off-chain verifiable credentials linked to the smart-contract-based directories can be used to proof who the issuer is. Following our example from the previous section, let’s say that the vaccination center is a hospital that wants to extend the root of trust to some doctors but does not want to expose their identities publicly in the smart-contract-based directories. In this case, the vaccination center can issue an off-chain verifiable credential see more about verifiable credentials to the doctor. When the doctor issues any health credential to a patient, they also attach their identity verifiable credential issued by the hospital. When the patient presents their health credential to a verifier, they also attach the doctor’s identity verifiable credential, and from there the verifier starts resolving the root of trust up all the way up through the smart-contract-based directories.

A very similar use case can be implemented in the field of digital diplomas, where a regional academic entity in LAC such as Red Clara, co-founder of LACNet, is implementing a regional Public Key Directory where national Public Lists operated by Red Clara’s national networks will be linked. And, subsecuently, universities can also operate Trusted Lists where they list Faculties, and o force so on. When a digital diploma is used at any academic institution, the entire root of trust is resolved and verified on-chain. Trusted. Below an schema illustrating it.

Tutorials

Check our terms and conditions, privacy policies, and cookies policy.