Skip to main content

DIDs and VCs, explained!


This document provides an overview of Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs).

Decentralized Identifiers (DIDs)

A DID is:

  • like an alias for our existing addresses (Ethereum address, Bitcoin address, PGP Key, or any other cryptographic identifier) that makes it easy to prove ownership and control over other identifiers and data.
  • self-generated + self-owned.
  • a safeguard for aspects of our digital presence via cryptography. Each address is unique to a single DID, like a keychain that holds many keys we need to use to access gated doors!
  • a non-centralized, universally discoverable way for you to own your credentials.

It’s a globally universal and resolvable nametag. The DID subject is whom or what the DID represents. A DID subject can be any organization, person, or object!

Although the DID is just an identifier, it allows you to resolve to a DID document. This DID document is a blob of descriptive data about the DID subject, which contain a mapping of someone’s public keys and optional service endpoints.


DIDs are unique identifiers that specify a resolution method for a blockchain based or other cryptographic identifier representing its owner. It typically consists of three parts:

  • a scheme: usually did
  • a DID method: different libraries that specify various operations of creating/resolving/updating DIDs and their associated DID documents. Disco uses Ceramic’s 3ID, so our DIDs will typically look like this (notice the 3 as the method): did:3:kjzl6cwe1jw149mq5riadts0nk6glwype5j2cnib0qobc9hju3ufqtmwi75lk96.
  • Lastly, the method-specific identifier: allows us to do a lookup using the specific DID method. This is the unique part!

So what?

DIDs allow to have a persistent identifier that you can bring to interact with various systems online.

DIDs become very powerful when paired with Verifiable Credentials, which act as digital certificates, IDs, diplomas, or many others. This way, it is possible to verify the identities of an entity, person, or object and allow them to take control of their own data without sacrificing its integrity.

Let’s look at an example. If Disco issued me a membership credential, it would come from the organization’s DID, and the subject would be my DID.

We can verify that Disco’s DID is truly theirs and that they do own it by contextualizing the DID document or linking accounts that they own (Twitter: @disco, and the relevant Domain:

Verifiable Credentials (VC)

Ok, time to dive into Verifiable Credentials.

A Verifiable Credential:

  • Is a signed attestation or statement written by one party about another or itself
  • Is in the form of specially formatted data (JSON), consistent with the World Wide Web Consortium (W3C) tech specs.
  • Is revocable or can be set to expire. Think of them as a digital version of your membership cards, IDs, library cards, or any other important document that you get from some other authority.
  • Is signed. In most cases, a Verifiable Credential is cryptographically signed by one DID about another DID, and because the credential is signed, it means nobody can tamper with it.
  • Contains proof or an attestation about the recipient or user. I.e., Bob is a member of DAOHaus or Boys Club. Bob’s diploma from Waterloo University or course completion.
  • Is an open-sourced standard by the W3C Verifiable Credentials Data Model, which is a set of specifications and verifiable documentation that allow credentials to be verified and shared on the web.

According to the W3C, “Verifiable Credentials represent statements made by an issuer in a tamper-evident and privacy-respecting manner.”

What does this mean? Let’s think about the physical credentials we use in our daily lives. An ID card or car insurance card is a physically issued credential…that represents my association, membership, or identification with the government or another entity. Why/How is this trustworthy?

In most cases, we implicitly trust the source who issued it.


Verifiable Credentials are a new digital mechanism allowing proofs or claims using public-key cryptography. Essentially, these credentials are blobs of data that are digitally signed/watermarked by a private key. The “public key” is essentially a public address everyone knows and is controlled by a private key.

Eventually, you will be able to disclose certain data from your credentials without exposing all the data from the credential. (imagine proving you are above the age of 21 without showing your ID card!), where third parties can instantly verify the data in question.


Time to dissect. Three components make up a Verifiable Credential:


Metadata is data about data. Think of this as credential properties such as the issuer, expiration, image, public key, etc. It’s usually formatted as JSON key-values:

key: "value",
expiration: "January 2, 2024"


A statement that is relevant to a particular subject.

“Bob went to Harvard,” or “Janice’s birthday is 12/20/1999”, or “Jamie is a member of DAOHaus” are all examples!


A proof is data containing the encoded digital signature and additional context. It also includes the identifier of the public key, which is how we can tell which entity/individual issued the credential. See an example below:

  "proof": {
// the cryptographic signature suite that was used to generate the signature
"type": "RsaSignature2018",
// the date the signature was created
"created": "2017-06-18T21:19:10Z",
// purpose of this proof
"proofPurpose": "assertionMethod",
// the identifier of the public key that can verify the signature
"verificationMethod": "",
// the digital signature value
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X

When we use the terminology “Verify a credential,” we are verifying this proof and checking that its contents are valid and have not been tampered with.

We use the RSA Signature Encryption method, which the W3C standard recommended. To read more about RSA and Digital Signatures, click here.


  • Verifiable Credentials are private, only visible to you if you choose. You have your DID as your identifier, and no other personal info is public.
  • The ID Holder can choose what attributes of their identity they want to disclose. For example, they could show their birth year without disclosing the day and month they were born. This is known as Selective Disclosure and will be in our upcoming roadmap.
  • The ID Holder is always in control of the relationship with ID Verifiers. They know what data was shared and when (there’s an audit trail)
  • They are tamper-evident through the use of cryptographic signatures
  • Portable. Verifiable Credentials are yours to store in your wallet and can be shared with parties you trust.

IMPORTANT DISTINCTION: There is a difference between verification and validation when it comes to VCs.

To verify a Verifiable Credential, a comprehensive evaluation is necessary to determine the authenticity and the statement in question. This includes checking: the credential conforms to a set of specifications (data model), the cryptographic method/signature is satisfied and optionally, and a status check.

To validate a Verifiable Credential, it is sufficient to determine whether it meets the needs of a verifier for relevant fields (issuer DID, timestamp, etc) for the specific credential in question.

How do they work together?

Recall that we identify users with DID’s. In a verifiable credential, you’ll have a subject and issuer, and we use the DID’s to identify them!

Additional Learning

Still want to read up more on VC’s and DID’s? We got you.