The W3C Verifiable Credentials specification is a fairly recent addition to the digital identity space. In this article, I give you an introduction to the Verifiable Credentials concept.

 

Verifiable credentials analogy – a wallet with cards

The most common analogy for the verifiable credentials concept is a physical wallet with one or more physical identity cards. Just as with a wallet in the physical world, an app on your mobile phone can act as a wallet in the online world. Verifiable credentials are identity cards you can put into your wallet app.

A web service on the internet can ask you to present a verifiable credential, just the same way you would present an identity card when you enter a building, or present a loyalty card when making purchases at a grocery store.

There are no restrictions on who can issue verifiable credentials, again very much matching the analogy of issuers of various identity cards in your wallet.

A wallet with identity cards next to a wallet app by Microsoft

Wallet with identity cards vs wallet app by Microsoft

Examples of issuers:

  • Governments issuing official passports, ID cards, driver’s licenses etc.
  • Company registries issuing identity cards representing legal roles within a company
  • Education institutions issuing identity cards with educational credentials
  • Organisations issuing identity cards to employees
  • Businesses and non-profits issuing customer loyalty and membership cards

The issuer of an identity card prints information, such as a person’s name, company name, membership number etc. on the card. Verifiable credentials contain claims to represent this kind of information.

One clear distinction between identity cards and verifiable credentials is how they are verified when presented. Physical identity cards typically have some physical security features such as holograms, watermarks or company logo to prevent counterfeiting and forgery, with various levels of security. The verifier, who is often a human, needs to know what physical details to look for when verifying a physical identity card.

Verifiable credentials on the other hand are machine verifiable, cryptographically protected data objects. When a verifiable credential is presented, the recipient or verifier looks up the public keys of both the issuer and the presenter of the credential. The verifier and issuer have a one-way trust relationship where the verifier gets to decide what issuers it trusts, just as with physical identity cards where the verifier wouldn’t trust unfamiliar identity cards.

W3C Verifiable Credentials and related specifications are aimed at interoperability across wallet apps and identity cards from different issuers. Ideally, you could use a single wallet app to hold all of your credentials from different issuers.

 

Privacy

Users on the internet are increasingly aware of privacy issues. Tracking a person’s activity is rarely desirable and unintended sharing of a user’s personal data can compromise privacy.

Two major concepts of how verifiable credentials address privacy are Self-Sovereign Identity and Zero-Knowledge Proof.

Self-Sovereign Identity (SSI)

With SSI, your wallet app lets you be in control of when and where you use and present your verifiable credentials. The wallet app will not let applications access your credentials without your consent. This matches very well how you would use physical identity cards from your wallet: you only present your identity card when needed.

Zero-Knowledge Proof (ZKP)

ZKP is a more advanced concept than SSI and relies on advanced cryptographic algorithms. ZKP extends the SSI concept by letting you control how you share your credentials.

To prevent tracking, your wallet app can generate uncorrelatable versions of your credentials for each verifier. This means that the subject value of the credential is cryptographically transformed so that each verifier sees a different, uncorrelatable value.

To prevent unintended sharing of personal data, your wallet app can generate versions of your credentials with only the minimum necessary claims, leaving out other personal data that is not needed. For example, to generate claims that prove a person is over a certain age without disclosing their date of birth. This is somewhat similar to using a photo editor to mask out details, such as a date of birth, from a photocopy of a passport or ID card.

 

Conclusions

The Verifiable Credentials specification is quite new, and many pieces that are required to create interoperable solutions are still incomplete or missing at time of writing. However, there is significant momentum around verifiable credentials (VCs). This is partly attributed to VCs being part of the solution for blockchain-based decentralised identity.

In future posts, I’ll cover verifiable credentials in more depth. This will include posts covering topics such as VC use cases, technical details, comparison with existing technologies and how we see VCs working with Ubisecure software and services. Sign up to our monthly identity newsletter to stay informed of future posts.