Table of contents

DIDs, VCs, SBTs and other web3 identity acronyms

https://www.dynamic.xyz/blog/introduction-to-sbts-vcs-dids
DIDs, VCs, SBTs and other web3 identity acronyms
DIDs, VCs, SBTs and other web3 identity acronyms
Download

Overview

Can you imagine being able to selectively share your personal information, like proving you’re a New York State resident without disclosing your home address or a university graduate without revealing your diploma? It has recently become increasingly difficult to navigate the web without having copious amounts of personal data collected and stored about us. It feels like over time, more and more of our information is out there. For the past few years though, the crypto space has been tackling these exact scenarios of our online identity and privacy — how can you interact with the web without revealing all of your information? 

As companies and developers invent solutions for the use cases above, a debate is brewing on what technology will power this new landscape. This blog post delves into two potential (and at times non-mutually exclusive) paths forward - (1) Verifiable Credentials (VCs) & Decentralized Identifiers (DIDs) and (2) Soulbound Tokens (SBTs).

What are Verifiable Credentials (VCs)?

VCs are digital certificates that help prove an individual’s or system’s identity, similar to a physical passport or driver’s license. Digital certificates are not entirely new — they are used to authenticate login credentials, verify a website’s identity, and much more. VCs improve these safeguards by interacting with the blockchain to provide an inviolable and universally verifiable alternative. The W3C Consortium defines the VC standard. 

There are three key abstractions in the VC Data Model that enable secure credentials:

  • VCs
  • DIDs
  • Verifiable Data Registry

Structure of a VC

Practically, a VC is a certificate containing a series of claims attested by an issuer and validated by a verifier.

A VC has three key components:

  1. Credential Metadata - contains key information about the VC, such as the issuer's DID, the type of credential, and the issuance date. 
  2. Claims - A list of claims the VC asserts about the subject (e.g., they have a valid driver's license, they are alumni of XYZ University). Each claim will have a DID that will resolve into a DID Document (discussed below).
  3. Proofs - contains information on the cryptographic signature and the keys that can be used to verify the VC.
The three key components of a VC

Decentralized Identifiers (DIDs)

Decentralized Identifiers are globally unique references in a VC (also standardized by W3C) that can be used to verify a subject’s (an individual, corporation, or entity) identity — similar to license numbers, passport numbers, or telephone digits. However, unlike the examples above, DIDs are decoupled from any issuing authority, and each subject can create and revoke their own DIDs at will. The entity the DID refers to is called the DID Subject. 

A DID is a string composed of three parts:

  1. The DID Scheme: The URI identifier always starts with “did:”.
  2. The DID Method: A custom method that defines how to handle dids. There are numerous such methods, and each has its CRUD operations interacting with a specific data registry. These methods are built to be interoperable so that any application can resolve DIDs.
  3. The DID method-specific Identifier: the unique ID that allows the method to resolve to a specific DID document.
The three parts of DID

The verifier uses the DIDs in a verifiable presentation (detailed referenced below) to resolve the associated DID Document using the data registry. This document contains information on the DID Subject, such as their public key and instructions on how they can verify their identity. The organization of the DID Document can be created and modified by an entity known as the DID Controller.

Verifiable Data Registry

The Verifiable Data Registry is a trusted intermediary maintaining the DIDs and VC schemas. It can be either decentralized and stored directly on the blockchain or closed and controlled by a centralized third party for some internal company use cases. 

The registry will contain logic on resolving the DID to the DID Document. There can be multiple registries in an ecosystem, and they can leverage blockchains as a ledger system for storing and amending information. 

Lifecycle of a VC

Let’s explore an example to understand how VCs are issued and verified. Alice is currently a student at a university that issues her VC as a credential for her enrollment.

  1. Alice (receiver/prover) requests a verifiable credential from the university. The university (issuer) already has its own DID registered with the DID registry.
  2. The university requests Alice’s DID.
  3. The university validates that she is indeed a student and provides Alice with a VC signed by the university’s DID and Alice’s DID. The VC contains a list of claims the issuer has endorsed about Alice, such as her enrollment status, graduation year, immigration status, and more. 
  4. Alice stores the VC safely in her digital wallet. 

Now Alice would like to use her VC to access a student discount at a museum. To do this, she needs her VC verified.

  1. Alice creates a verifiable presentation (VP), an entity that contains a subset of the claims in her VC, to maintain privacy and ensure the verifier does not receive more information than appropriate. 
  2. The museum (verifier) receives the VP containing one or more claims. For each claim, the verifier uses Alice and the university’s DIDs to retrieve the DID Documents for Alice and the university using the registry. 
  3. Using the keys on the documents, the verifier concludes whether the signatures in the claim are from Alice and the university. Once her VP is verified, Alice is allowed to pay a discounted entry fee for the museum.
The lifecycle of a VC

The DID methods chosen provide the issuer and VC holder with different features or permissions. Some DID methods allow the issuer or recipient to revoke the VC at any time or replace it with a new one. In this example, the university can revoke the proof of enrollment VC it provides Alice if she graduates or takes a leave of absence. 

Alice can hold multiple VCs issued by different organizations in her wallet and control which credentials to showcase. However, Alice has to ensure the security of the VC since the verifier cannot attest to the identity of the individual who provided the presentation. She must revoke access if she is aware her wallet has been compromised.

Why Verifiable Credentials?

While digital certificates are not new, their web2 instantiations – login cookies and Facebook pixels – are controlled by centralized tech behemoths. Applications like Facebook and Google store credentials and user history that they then sell to third-party advertisers — a week of ads from Chipotle across all platforms will follow an innocent search about burritos. 

The VC architecture gives individuals control over who their identity is shared with, and allows them to revoke access when necessary. 

What are Souls and Soulbound Tokens (SBTs)?

In a recent blog post, Vitalik Buterin outlined his vision for a decentralized society (DeSoc), powered by Soulbound Tokens (SBTs) and Souls. He defined SBTs as NFTs that are “publicly visible, non-transferable (but possibly revocable-by-the-issuer)” and the wallets that hold these SBTs as Souls. An individual can receive an SBT to signify an affiliation to a particular entity — for instance an educational institution, an employer, or a geopolitical state. 

SBTs are motivated by what Buterin sees as the drawbacks to the current NFT system – since NFTs are transferable and cannot be permanently bound to any specific individual, they’ve become a commodity signaling wealth. SBTs, on the other hand, can’t be bought and sold. They are public, on-chain credentials that signal reputation and memberships that have to be earned.

The SBTs proposal has sparked a great deal of discussion and debate, in part because the concept of on-chain tokens representing personal identifiable information (PII) is controversial. This contrasts with the existing “off-chain” identity stack centered around VCs and DIDs that are inherently more private (one can argue information stored within SBTs can be made private over time).

Differences between VCs/DIDs and SBTs

Since the proposal of SBTs/Souls, there have been many discussions on Twitter and elsewhere in the crypto ecosystem regarding the difference between SBTs and VCs/DIDs. Many question the need for SBTs at all, given the existing work on VCs/DIDs. 

While SBTs are mostly conceptual at the moment, and their implementation details haven’t been fully worked out, the main difference between them and VCs boils down to privacy:

VCs/DIDs

  • DIDs are not publicly accessible
  • The verification step takes place off-chain

SBTs

  • SBTs are public (PII contained in the SBT may be public)
  • All transactions take place and stored indefinitely on-chain

Some advantages to VCs over SBTs include the following:

  1. Interoperability: DIDs are chain-agnostic, so the operations are not permanently bound to a single blockchain. 
  2. Privacy: Users can choose what credentials and information they want to store locally in their wallet or on a backup server. They are able to maintain privacy as the blockchain will never permanently store their personal information. 
  3. Scalability: Writing everything on chain can get expensive. Maintaining a subset of credentialing transactions off-chain can reduce gas fees and costs.

Meanwhile, the advantages of SBTs over VCs include the following:

  1. Composability: Since everything is already on-chain, SBTs facilitate integration with existing on-chain protocols. 
  2. Decentralization: SBTs obviate the need for a separate decentralized network to verify issuers; issuing entities can just use regular smart contracts that trigger certain criteria.

Conclusion

While web3 first gained prominence for championing a trustless, permissionless, anonymous environment, it is working to redefine identity rather than reject it.  Many players in the space have released VC-leveraging products into the market to capture a slice of the burgeoning new technology: Microsoft has introduced VCs into their Azure product suite; Verite.id and Quadrata use VCs to prove KYC and identity claims; Spruce, Disco.xyz and others help create and manage identifiers.  

However, while VCs, DIDs, and SBTs are some of the most recent proposed frameworks that validate a need for a new credentialing system built on top of the blockchain, they likely won't be the last.

Further Reading

This article does not strive to cover all aspects of DIDs, VCs and SBTs. Here are a few great articles to dive into for further reading:

  1. A Technical Commentary on DeSoc by Kevin Yu, The Dolphin Meditations
  2. The future of Social Media by Jason Levin, Twitter Thread
  3. Decentralized Society: In Search of the Soul of Web3 by John.Nichol, Mirror.xyz
  4. The Credential Economy by jmeks.eth, Mirror.xyz
  5. Upgradeable Decentralized Identity - DID Method Traits by Wayne Chang, Spruce

Share this article

https://www.dynamic.xyz/blog/introduction-to-sbts-vcs-dids
Itai Turbahn

Itai is the co-founder and CEO of Dynamic. Before Dynamic, Itai spent 7 years in product management leadership positions, and was previously a consultant at the Boston Consulting Group. Itai holds an MBA from Harvard Business School and B.Sc degrees in EECS and Economics from MIT.

Related articles

Dynamic takes minutes to set up

(Oh, and we also offer a free multi-chain wallet adaptor)

Get started