How Verifiable Credentials Work

You come into a gathering, and everyone is talking about verifiable credentials. What’s the first thing that comes to mind? You’ll most likely think of certifications, degrees, or anything that belongs to you that can be used to attest that you are who you say you are.

In the physical world, a credential can be a physical asset one can carry around in their wallet to prove their identity. Credentials can be verified by examining them or by making a call to the issuers of such credentials. For example

• A birth certificate issued by a hospital proves when and where you were born and who your parents are
• A passport can be issued by the government of a country to prove that you’re a citizen of that country
• A certificate issued by the university proves that you have an educational degree

All of these are physical examples of credentials with a human subject, but how does this play out in the digital world?

In the first article in this series, we looked at decentralized identity and why it matters. In this piece, we’ll be delving deeper into verifiable credentials and how they work. First, let’s take a look at some of the problems VCs are trying to solve.

1. Identity fraud: Verifiable credentials provide a secure and tamper-proof way of sharing personal information, reducing the risk of identity fraud.
2. Information leakage: Sharing of user data is often done in bulk, leading to leakage of more information than necessary and loss of privacy. Through selective disclosure, verifiable credentials can be used to limit the amount of personal information that is shared while still enabling organizations to verify the information they need.
3. Data silos: Centralized systems often require individuals to share sensitive information with every organization that needs it, leading to the creation of large honeypots of user data with many organizations, increasing the risk of data breaches.
4. Walled gardens: Issuers of credentials can impose barriers to verification if they are involved in the verification process. Verifiable credentials are self-certifying and don’t require the involvement of the issuer when being verified.

How VCs work

There are three entities you’ll come across quite often while studying verifiable credentials:

1. The issuer
2. The holder
3. The verifier

The entity that issues the credential is known as the issuer; the holder is the subject of the credential; and the verifier is the organization that determines if the credential satisfies the requirements for a VC. Let’s take a look at each of these entities in detail:

The Issuer

An issuer in a verifiable credentials ecosystem is an entity that creates and issues digital credentials to holders. These issuers can be academic institutions, banks, the government, or corporate bodies.

For example, a university might be an issuer of a digital diploma to a student named John. The university would be responsible for creating the digital diploma, which would include information such as the student’s name, degree earned, and graduation date.

The university would then issue the digital diploma to the student, who would be the credential holder. The issuer must prove that they are authorized and competent to issue digital credentials by providing a form of identification and proof of identity, which can be done by providing a digital certificate or signature.

The Holder

A holder is an individual or entity that holds or possesses a digital credential, such as a diploma, a driver’s license, or a professional certification. The holder can present the credential to a verifier, such as an employer or a government agency, to prove their identity or qualifications.

John, from our previous example, is a recent graduate from a university. The university is the issuer of John’s diploma. John is the holder of his diploma, meaning he possesses it in a digital format.

The holder can also compile the data sent by one or more issuers and create a verifiable presentation.

The Verifier

A verifier is an entity that checks the authenticity of a credential issued to a holder by an issuer. It also checks for other things, like validity and competency.

In this example, when John applies for a job, the employer, who is the verifier, will ask John to present his diploma to prove that he has completed his degree. The employer uses a set of verifiable credentials protocols to check the authenticity of the credentials. This includes verifying the issuer’s signature, checking that the credential has not been tampered with, and confirming that the information in the credential matches the information that the employer has on file for John.

Once the employer has verified the credential, they can trust that the information in the credential is accurate and that it was issued by a trusted issuer, which allows the employer to make informed decisions about John’s qualifications for the job.

Let’s graphically look at the workflow for verifiable credentials:

The issuer signs an identity and sends it to the holder. The holder creates a verifiable presentation and sends it to the verifier. The verifier checks to know if the data is competent, viable, and authentic. Another possible workflow is that the verifier requests data from the holder, who reaches out to the issuer to send the data.

In the Verifiable Credentials ecosystem, the issuer and holder are required to use decentralized identifiers or DIDs. A decentralized identifier (DID) is a technique to identify something or oneself online without depending on a centralized entity, such as a large corporation or the government. Imagine it as the digital equivalent of your passport or license that you may use to verify your identity online.

Deconstructing a Verifiable Credential

A subject is typically a person, but it could also be a thing, such as hardware device type, expiration, and issuer, which are properties of the credential proof used to verify the integrity of a credential. A proof is typically expressed as a digital signature, made with the private key of the issuer.

Main problems currently experienced in the VC world.

According to Cheqd’s deep-dive survey on technical trends in decentralized identity, the top 5 blockers to the adoption of decentralized identity by enterprises

The fundamental element of SSI is receiving a set of claims and verifiable credentials in your identity wallet and then presenting them to a third party.

The mechanism that delivers one verifiable credential to a holder’s wallet must be able to connect with a totally separate piece of software that is receiving a verifiable credential or presentation on the end of the verifier in order for SSI to become an interoperable ecosystem.

Different systems for issuing and verifying verifiable credentials should be compatible, making it easy for credentials to be recognized and accepted across different platforms and organizations.

However, the various systems currently do not allow for credential interoperability.

Verifiable credentials are also not as user-friendly as they should be and are difficult for individuals and organizations to understand and use, as they require a certain level of technical knowledge and may involve multiple different software and hardware components.

The Decentralized Identity Foundation (DIF), the W3C Credentials Community Group, and the Verifiable Organizations Network (VON) are working to promote the development of open standards for self-sovereign identity (SSI) and verifiable credentials. They aim to make SSI systems more user-friendly and to promote interoperability between different SSI systems.

While these organizations are working to solve these problems, they still persist. The complexity of verifiable credentials and the infrastructure required to support them still make them difficult for individuals and organizations to understand and use. Additionally, interoperability issues between different systems for issuing and verifying verifiable credentials remain a problem, as do the privacy and security issues that verifiable credentials can pose.