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.
The way it works is simple and can be described in the following steps:
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.
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.