Building the Personal Data Locker: Decentralized Identifiers (DIDs) & Verifiable Credentials (VCs)

Written byRon KreutzerMay 23, 2019
Digital identity is the starting point for creating a PDL, and digital credentials that help prove your identity enable services to trust your identity.

As I discussed in part one of this series, the concept of a Personal Data Locker (PDL), a secure storage area for each individual’s personal data, has been a core goal of the Pillar Project from its earliest days. Digital identity is the starting point for creating a PDL, and digital credentials that help prove your identity enable services to trust your identity.


To make such an ecosystem work, we need standard methods for how identity providers, digital wallets and service providers communicate this identity data. Luckily, there has been a lot of work performed in this area to create standards that allow for interoperability between all the participants and systems.

Groups of individuals interested in digital identity and in adding a trust layer to the internet have organized and are leading the push toward standards in this area. I recently attended the 28th session of the Internet Identity Workshop (IIW) where over 100 workshop sessions were conducted around concepts, standards and best practices for identity. From this workshop, ideas move on to the Rebooting the Web of Trust (RWOT) workshop, where individuals organize into groups around topics and participate in creating papers that form the basis for getting proposed standards into working groups of standards bodies, like the World Wide Web Consortium (W3C). In addition, industry groups such as the Decentralized Identity Foundation (DIF) focus on bringing the foundational components of digital identity together.

The two most evolved proposed standards are Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs).

Decentralized Identifiers

The DID specification is undergoing review at the W3C, and you can learn all the details by clicking the link. In basic terms, a DID is an identifier, a string of letters and numbers, that is used to identify you to another person or entity. Identifiers you use today can include your passport number, driver’s license number, health insurance policy number, etc. What makes a DID different from these identifiers is that each identifier in the previous list was issued by someone to you.

A DID is issued, owned and controlled by you and is described as “self-sovereign”.

Just like the identifiers above, a DID doesn’t contain any of your personal data, but can be associated to certain personal data. In the case of centralized identifiers, this personal data is typically stored in a central place controlled by a government or business, and is a target of hackers. However, with a DID, the personal data associated with it is owned and controlled by you.

So, how does all this work? Let’s use a simple example that I want to communicate to Bob that my first name is “Ron”. I create a text string such as “name=Ron”, then I use my DID to digitally sign that text string. I then send Bob an email with the text string, my DID and the signature. When Bob receives the email, he can verify that someone with control over that DID said his name is Ron.

OK, now that you have a basic understanding, let’s go a level deeper to clarify some things. Typically you wouldn’t use email for the communication, instead both parties would use an app that performed these functions. Also, DIDs don’t sign the data, instead the private key associated with the DID performs the signing.

When a DID is created, a keypair used for signing transactions is also made. The keypair consists of a private key that you use to cryptographically sign a message and a public key that you distribute so others can verify your signature. For a DID, the public key is stored in a DID Document, which is a small text file that is stored in the cloud and possibly anchored to a blockchain. Similar to how someone who knows a URL, like “”, is displayed a website, someone who knows a DID, like “did:sov:123456abcedf”, is displayed a DID Document. So, in the example above, Ron signs the text string with the private key of his DID. Then Bob uses the DID to retrieve the DID Document, which contains the public key, and uses that to verify the signature.

An individual has a primary DID, which is typically linked to their main identity and credentials (described below). The individual can create additional DIDs to use in interactions with others, to increase their privacy. For example I can create a DID to use in my connection with Bob and another DID to use in my connection with Charlie. Using this structure, Bob and Charlie can’t correlate my identity.

Verifiable Credentials

This example works great if Bob only needs to know that an identity, identified with a specific DID, is named “Ron”. There are cases, however, where this level of assurance is not adequate. Maybe Charlie needs to know my first and last name from my passport.

Much like in the physical world, I could tell Charlie the name on my passport, but he likely wants to see the passport for himself. This is where we need Verifiable Credentials.

The Verifiable Credentials specification is also undergoing review at the W3C. Also known as attestations, they are a claim by someone that some personal data about you is accurate. For example, a passport issuing authority could issue a credential certifying that all data elements on your passport are accurate, or a university can issue a credential to you stating that you’ve earned a diploma in a specific area of study. These credentials are cryptographically signed by the issuer and can later be verified by a receiving party.

Verifiable Credentials are stored in your wallet or identity hub (more on this in a future article). They can be used by you later to prove to someone else that your personal data is accurate. You (your wallet) can create a “proof” of a subset of one or more credentials to provide to a requestor, such as a company where you are establishing a service relationship. For example, such a proof could include your name and nationality, but not your birthdate or passport number from your passport credential.

A proof could be issued by the DID that you’ve created for the specific relationship, even though the credential was issued to your primary DID, with the ability for the requestor to verify that you own the credential. Attestations can be self-certified, and these data elements can be included with certified data elements in proofs.

In Pillar, a persona is a named proof of a set of personal data elements that are provided to one or more connections. Verifiable Credentials are claims made against an identity (DID), such as age, nationality, etc. that are verified by a third party. These claims are cryptographically secure, privacy-respecting and machine-verifiable.

Proofs can also contain abstract data, such as proof that you are over 21 years old without disclosing your birthdate.


We’ve covered a lot in this article. Now you have a better understanding of how decentralized identifiers and credentials can be used to return control of your identity back to you, and how you can use this identity in the digital world. In the next part of this series, we’ll look at the credential issuance process and how you’ll be able to use these credentials in your everyday life.