Hi, I am 0xKantaro, the Founder of a dApp called C-Voxel, the product that allows you to publish your on-chain activities as a web3 personal work history tied to your DID.

In this article, I will introduce Verifiable Credentials, which is also familiar to C-Voxel.

What is Credential?

First of all, what are credentials? Although the literal translation is credentials, credentials are essential in today’s society and are used everywhere in our lives.
For example, a driver’s license proves that one is competent to drive a motor vehicle. A university degree proves your level of education, and a government-issued passport proves your nationality and can be used to travel between countries.
In this way, a credential is proof of some credential or characteristic of an individual by an issuing authority. These traditional credentials are called Physical Credentials.
Physical Credentials are said to have the following six elements.

1. Information related to identifying the subject of the credential (for example, a photo, name, or identification number)
2. Information related to the issuing authority (for example, a city government, national agency, or certification body)
3. Information related to the type of credential this is (for example, a Dutch passport, an American driving license, or a health insurance card)
4. Information related to specific attributes or properties being asserted by the issuing authority about the subject (for example, nationality, the classes of vehicle entitled to drive, or date of birth)
5. Evidence related to how the credential was derived
6. Information related to constraints on the credential (for example, expiration date, or terms of use).

While Physical Credentials are essential to life in the modern world and benefit us when used in the physical world, they also present many inconveniences.

For example, a driver’s license or health insurance card is a physical card that must be carried with you at all times if necessary, and can be misused if lost. Degrees, for example, can be faked, and verification of degrees can be costly, as can contacting the university.

In addition, you may be asked to present your driver’s license or passport as proof of identity at stores or online services, but in many cases you may be forced to disclose more personal information than what you want to prove in order to present the card itself.
Verifiable Credentials are proposed to solve such inconvenience of Physical Credentials.

What is the Verifiable Credentials?

The following introduction is based on the definition of Verifiable Credentials as developed by the W3C, which was drafted in 2017 and will become the latest version of the Recommendation in March 2022.

Verifiable Credentials translates to verifiable credentials. It provides a standard way to represent credentials on the Web in a way that is cryptographically secure, respects privacy, and is systematically verifiable. In other words, they are digital personal information whose content can be verified online.

Verifiable Credentials fulfill all six elements of the Physical Credential described above, plus several additional benefits.
One is that they are more tamper-resistant and more trustworthy due to additional features such as digital signatures. This means that it is harder to be falsified.

Another advantage often cited is that, combined with zero-knowledge proof, you can prove that you have the credential without having to disclose your personal information.

I’ll introduce the Zero Knowledge Proof at another time because it’s a long story, but if you want to learn more about it, I recommend this video from WIRED.

Other than that, Verifiable Credentials are represented on the web, making them more convenient than Physical Credentials when you want to establish trust by proving credentials over a long distance. Especially in the web3 domain, where global activities are often assumed, Verifiable Credentials may be an area in which widespread use is especially desired.

Verifiable Credentials ecosystem

Let’s take a more concrete look at how Verifiable Credentials (VC) work: according to the W3C, there are various factors involved in each specific case, but the abstract ecosystem is defined as having five core actors.

holder: A role an entity might perform by possessing one or more verifiable credentials and generating verifiable presentations from them. Example holders include students, employees, and customers.

issuer: A role an entity performs by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder. Example issuers include corporations, non-profit organizations, trade associations, governments, and individuals.

subject: An entity about which claims are made. Example subjects include human beings, animals, and things. In many cases the holder of a verifiable credential is the subject, but in certain cases it is not. For example, a parent (the holder) might hold the verifiable credentials of a child (the subject), or a pet owner (the holder) might hold the verifiable credentials of their pet (the subject). For more information about these special cases, see Appendix C. Subject-Holder Relationships.

verifier: A role an entity performs by receiving one or more verifiable credentials, optionally inside a verifiable presentation, for processing. Example verifiers include employers, security personnel, and websites.

verifiable data registry: A role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as verifiable credential schemas, revocation registries, issuer public keys, and so on, which might be required to use verifiable credentials. Some configurations might require correlatable identifiers for subjects. Example verifiable data registries include trusted databases, decentralized databases, government ID databases, and distributed ledgers. Often there is more than one type of verifiable data registry utilized in an ecosystem.

Here is a new concept that you may not be familiar with. It is “Verifiable Presentation. This is defined as follows

Data derived from one or more verifiable credentials, issued by one or more issuers, that is shared with a specific verifier. A verifiable presentation is a tamper-evident presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesized from, but do not contain, the original verifiable credentials (for example, zero-knowledge proofs).

In other words, you have seen that in the VC ecosystem, rather than disclosing specific VCs, you can only present matters (or verifiable proof results) that you want to prove by combining zero-knowledge proofs or other VCs.

27 Requirements for Verifiable Credentials

In addition, the following 27 elements are listed as desirable requirements for the VC ecosystem above.
These requirements define in detail the behavior and nature of each actor in the ecosystem.
It would be quite difficult to read them all, so you may skip them, but just looking at them will help you understand the big picture.

• Credentials represent statements made by an issuer.
• Verifiable credentials represent statements made by an issuer in a tamper-evident and privacy-respecting manner.
• Holders assemble collections of credentials and/or verifiable credentials from different issuers into a single artifact, a presentation.
• Holders transform presentations into verifiable presentations to render them tamper-evident.
• Issuers can issue verifiable credentials about any subject.
• Acting as issuer, holder, or verifier requires neither registration nor approval by any authority, as the trust involved is bilateral between parties.
• Verifiable presentations allow any verifier to verify the authenticity of verifiable credentials from any issuer.
• Holders can receive verifiable credentials from anyone.
• Holders can interact with any issuer and any verifier through any user agent.
• Holders can share verifiable presentations, which can then be verified without revealing the identity of the verifier to the issuer.
• Holders can store verifiable credentials in any location, without affecting their verifiability and without the issuer knowing anything about where they are stored or when they are accessed.
• Holders can present verifiable presentations to any verifier without affecting authenticity of the claims and without revealing that action to the issuer.
• A verifier can verify verifiable presentations from any holder, containing proofs of claims from any issuer.
• Verification should not depend on direct interactions between issuers and verifiers.
• Verification should not reveal the identity of the verifier to any issuer.
• The specification must provide a means for issuers to issue verifiable credentials that support selective disclosure, without requiring all conformant software to support that feature.
• Issuers can issue verifiable credentials that support selective disclosure.
• If a single verifiable credential supports selective disclosure, then holders can present proofs of claims without revealing the entire verifiable credential.
• Verifiable presentations can either disclose the attributes of a verifiable credential, or satisfy derived predicates requested by the verifier. Derived predicates are Boolean conditions, such as greater than, less than, equal to, is in set, and so on.
• Issuers can issue revocable verifiable credentials.
• The processes of cryptographically protecting credentials and presentations, and verifying verifiable credentials and verifiable presentations, have to be deterministic, bi-directional, and lossless. Any verification of a verifiable credential or verifiable presentation has to be transformable to the generic data model defined in this document in a deterministic process, such that the resulting credential or presentation is semantically and syntactically equivalent to the original construct, so that it can be processed in an interoperable fashion.
• Verifiable credentials and verifiable presentations have to be serializable in one or more machine-readable data formats. The process of serialization and/or de-serialization has to be deterministic, bi-directional, and lossless. Any serialization of a verifiable credential or verifiable presentation needs to be transformable to the generic data model defined in this document in a deterministic process such that the resulting verifiable credential can be processed in an interoperable fashion. The serialized form also needs to be able to be generated from the data model without loss of data or content.
• The data model and serialization must be extendable with minimal coordination.
• Revocation by the issuer should not reveal any identifying information about the subject, the holder, the specific verifiable credential, or the verifier.
• Issuers can disclose the revocation reason.
• Issuers revoking verifiable credentials should distinguish between revocation for cryptographic integrity (for example, the signing key is compromised) versus revocation for a status change (for example, the driver’s license is suspended).
• Issuers can provide a service for refreshing a verifiable credential.

Conclusion

So far, we have introduced what Verifiable Credentials are, using the W3C definition as a base. This article is only an introduction, and we will summarize more detailed mechanisms and systems in the next article.

With the recent rise of web3C, we have been hearing more and more about Verifiable Credentials and DID, and I feel that my personal understanding has been deepened by learning again from the definition of the origin. I know that there are many technical terms and many parts are long and difficult to read, but I hope that you can get an overall picture of what it is all about.

Personally, I believe that areas such as Verifiable Credentials and DID are closely related to our lives and will bring more benefits to us in the future than Defi and NFT. This is also the reason why we are so determined to make such a future a reality. If you are interested, please visit us on Twitter or Discord.

Twitter:

Discord: