When implementing verifiable credentials, there are important technical considerations and requirements. We help you unpack them.

Verifiable credentials are gaining in popularity across sectors, from health to finance and beyond. As verifiable credentials allow people and systems to exchange trustable information securely and efficiently – and without relying on intermediaries – the number of potential use cases for is far-reaching. 

But how exactly do verifiable credentials work, and what are some of the technical considerations and requirements?

A verifiable credential is a digital representation of information that is securely issued by a trusted authority and can be verified independently. It is a way of verifying claims about people, organizations, or objects without needing to rely on a central authority for verification every time the information is shared. Consequently, its most common use case is for identity. 

To create a trust-building ecosystem, a number of roles and responsibilities are involved:  

Credentials 

A credential is a set of attributes that both describe and are assigned to a subject. For example, an ID includes attributes such as the full name, birth date, and country of issuance. Some of these attributes are unique to the person, for example, their full name; some are unique and assigned to the subject, such as the ID number; while others are commonly shared among subjects, like the issuing country. 

Issuers 

Credentials are created by issuers. Most commonly, issuers are governments, companies, or other organizations, though there are some cases where a person may be an issuer. By creating and issuing a credential, the issuer is making an assertion that the attributes captured in the credential are, in fact, attributes of the subject. 

Subjects 

The subject is the entity described by the attributes contained in the credential. This could be a person, organization, animal, or thing. For example, the subject of an ID is a person. The subject of a sustainability certification in a supply chain could be the box of harvested cacao. 

Holders 

The holder (sometimes referred to as the subscriber) is the entity responsible for managing the credential once issued. In most cases, the holder is also the subject, though not always. For example, a parent or guardian may be the holder of a child’s birth certificate before they reach a certain age.  

Reliant parties 

The reliant party (also called the relying party, verifier, or other terms) is the entity that will receive some or all the attributes in the credential (often called a proof or a presentation) from the holder. The reliant party then processes or uses this data for the transaction’s ultimate purpose. 

Simply, the reliant party is the recipient of the data. For example, border patrol is the reliant party when presented with a passport during a border crossing. The bank is the reliant party when receiving information to open an account.  

Trust registry 

Within a specific domain, trust registries play an important function as an authoritative source of information used for validation. This information includes things like the public signing keys for issuers and definitions of valid credential schemas (outlined in further detail below). They are who the reliant party checks with to verify that they can trust the information presented to them. 

Digital wallets 

There needs to be a place for the holders to store verifiable credentials. This storage place is called a digital wallet. In common parlance, the term “digital wallet” is used for several different types of technology. It’s a useful analog, as the behaviors related to its use mirror similar behaviors we have with physical wallets that contain a variety of physical data (e.g., identity, money, access cards, etc.). 

In the digital space, different types of data or technologies are handled by different types of wallets.  

One of the defining characteristics of verifiable credentials is that they are “verifiable.” But what does that mean? What is being verified? 

Credentials, as outlined, are a collection of attributes describing a subject and created by an issuer. This collection is then signed with one or more digital signatures. This allows the issuer to have the confidence necessary to hand the credential over to the holder. The issuer knows that if the holder tries to make any changes to the credential, they will invalidate it. 

So, verification ensures the credential: 

1. Is still the same as it was when created by the Issuer; and 
2. Was created by a specific issuer. 

It does not verify that the information contained in the credential is correct. That’s entirely up to the issuer. 

Because of this, the reliant party is put in a position where they must decide whether to trust the credential. The two questions they need to ask themselves are: 

1. Do I recognize this issuer? 
2. Do I trust this issuer for this type of credential? 

The various verifiable credential schemes offer one or more mechanisms to assist the reliant party in answering these questions. Commonly, some form of a trust registry is used for this purpose. 

1. The issuer registers their validation information with the trust registry. 
2. The issuer creates and issues a credential about the subject and gives it to the holder. 
3. The holder presents some or all the information contained in the credential to the reliant party. 
4. The reliant party contacts the trust registry to verify the validation information of the issuer, which it then uses to verify the data provided by the holder. 

This approach supports the creation of trust within the system. 

For example, my local government might accept a verifiable credential from my local car shop related to my car’s safety and emissions requirements. However, even if properly formatted and digitally signed, the government would not accept a driver’s license verifiable credential from that same car shop. 

Taking a close look at the diagram, one will notice that there is no direct connection between the issuer and the reliant party. The credential is handed over to the holder, who can share the data it contains with any reliant party that they chose — without permission or oversight from the issuer. This chain of custody and permission structure is the foundation of the claims that verifiable credentials are more privacy preserving and people centric than many other approaches. 

Verifiable credentials are possible only through cryptography. While this subject can be deeply complex, there are a couple of concepts that are key to understanding how verifiable credentials and the related technology work. 

Hashes: “fingerprinting” data 

If we want to know whether some data has been changed, we need a way to compare it to the original data. This can be difficult, especially in cases of large data sets or when there is limited / no access to the original data. 

Consequently, it would be beneficial to have a short, accessible representation — like a “fingerprint” — of the original data. If we have that, we can generate the “fingerprint” of the data we’ve received and compare them. If the “fingerprints” match, the data is the same. 

These “fingerprints” are called “hashes” and are foundational to digital signatures, which is where we are going. We’ll also get to how we verify if we have the original hash here shortly. 

When hashes are created, the action is only one way — meaning that while it may be easy to calculate the hash for any given data, finding the data that creates a specific hash isn’t. Any change to the input data will create a vastly different hash. Let’s look at an example using md5sum, a simple hashing algorithm:

Notice that changing the slightest detail — e.g., adding a period or changing the case of a single letter — completely changes the resulting hash. 

Some key points: 

• The hashing function always creates hashes of the same length, so a 20GB file has the same hash length as our examples here.  
• All data can be “uniquely” identified with a hash, whether it is a document, a video, an image, or an archived database. 

There is one caveat here: if all hashes from a certain hashing function are the same length, multiple input data will result in the same hash, as there is an infinite number of data inputs and a finite number of potential hashes. However, because small changes drastically change the output hash, the chance that another file produces the same hash that was 1) not just random characters, 2) relatable to the original data, 3) beneficial to the creator of the false data, and 4) discoverable in a useful time at a reasonable cost, is so infinitesimally small as to not be a concern. 

Why? In our example, before we even consider the file’s content, the chance that any two files have the same hash value is about 1 in 3.4 x 1038. For context, the diameter of the observable universe is approximately 8.8 x 1026 meters, which is numerically 386 billion times smaller than the number of potential hash values. For all intents and purposes, the hash is unique. 

With that, we now have a way to detect changes. Next, we need a way to trust that the hash we were given is the original one. 

Public key cryptography 

In cryptography, a cypher is used to encrypt/decrypt data. The first cypher discovered by most English-speaking children is the simple A=1, B=2, C=3, etc. scheme. Obviously, more complex schemes are used for things like digital signatures. 

Public key cryptography is a special type of cryptography where instead of using one cypher, we use two. We call each of the cyphers “keys”: the public key and the private key. The private key is kept secret by the entity that created the key pair. The public key can be distributed far and wide to anyone and everyone. 

Known as a keypair, these two keys have a special relationship. Data encrypted by one key can only be decrypted using the other key and vice versa. This lets us do some interesting things. 

Using the public key, anyone can decrypt data encrypted with the private key and thereby know that data could only have originated from the entity possessing the private key. Likewise, anyone could encrypt data using the public key that could only be encrypted by the holder of the private key. 

This is the basis for most encrypted communication apps, secure web browsing, etc. used today.   

Here, we’re particularly interested in its use in digital signatures. 

Digital signatures 

With hashes and public key cryptography in hand, we can now create a digital signature, which is simply an encrypted hash. The hash provides the ability to make sure that the data hasn’t been changed. The fact that it is encrypted ensures that we know the source. 

Transacting digitally signed data 

Putting this all together, we can complete a transaction with digitally signed data.  

In its simplest form, the process is as follows: 

While this process works well, there is still one outstanding question: how does one get the public key in a trusted manner? That’s required for this whole process to work, and there are multiple approaches that can be used, including public repositories, blockchains, and technologies such as KERI. It’s one of the design decisions when building a verifiable credential–based system, and each approach has its own pros and cons.

To maximize the benefits of verifiable credentials and minimize the challenges, there are a number of elements that need to be considered, from ensuring informed, meaningful consent to effective revocation. 

Informed, meaningful consent 

Consent — or more specifically, the consent of the holder — plays a key role in the design of verifiable credentials. Holders must be active participants. Requests for data come from the reliant party, and the holder must make an active decision to provide that data. 

This does require additional effort by the holder, though there have been some suggestions that smart agents (possibly powered by AI) may be able to reduce this. The problem is an acute one, as we have seen that consent in and of itself is not enough. The collective experience of the web browser cookie consent has been an apt example. Dark patterns not only allow but encourage click-through behavior. 

With differing levels of digital literacy, regulation enforcement, and policy outcome expectations, ensuring that the holders understand the process sufficiently to be able to give informed, meaningful consent can be difficult. Addressing this requires efforts from technology, policy, regulation, and enforcement working together. 

When implementing digital credentials, issuers must consider how best to foster effective consent practices. 

Selective disclosure 

Some forms of verifiable credentials also allow for what is known as “selective disclosure.” Hinted at earlier, this is where only some of the data in a verifiable credential is shared with the reliant party, while still maintaining the ability to check its provenance and integrity. This is powerful because most forms of identity contain far more information than is needed to complete most transactions. For example, a delivery person may only need to verify someone’s name while not needing their birthdate. 

When implementing digital credentials, issuers must consider how much information should be available to potential reliant parties. 

Predicates 

A related feature supported by some forms of verifiable credentials is what is known as a “predicate.” This is the technical name for things such as cryptographically proving that someone is over the age of 18 or 21 without disclosing their actual birthdate. This benefits both the subject (privacy of not having to reveal this much detail) and the reliant party (not becoming legally liable for holding and protecting that level of personally identifiable information). 

When implementing digital credentials, issuers must consider how – and when – predicates should be used. 

Revocation 

What happens when a credential needs to be revoked, which may happen for any number of reasons (issuance mistakes, expiration, status change, legal requirements, etc.)? Different verifiable credential implementations handle this in different ways, but they do have these capabilities. One such approach is for the issuer to publish “status” lists of credentials. However, a simple listing of credentials would be a privacy nightmare, as would requiring a reliant party to directly ask the issuer about a specific credential, which would indicate to the issuer who was using the credential where (consider the plight of an oppressive regime trying to track down a dissident who had fled to another country). 

Approaches such as the Bitstring Status List allow for a privacy-preserving “status” list while still supporting revocation. 

It should also be mentioned that there are cases where revoked credentials are still valuable. For example, if a holder has a credential representing a governmental security clearance that has simply lapsed, being able to present it to a reliant party, say a new employer, is still valuable. It would show up as revoked, but the fact that the individual had the security clearance at one point could suggest that they may be able to have it reactivated instead of starting from scratch. Verifiable credentials can support such a use case — proving that something that isn’t currently valid was valid at a certain point. 

When implementing digital credentials, issuers must consider how to enact potential revocation – while still maintaining sufficient privacy for the holder.

Verifiable credentials offer a powerful approach to identity and other data sharing. There are many possible use cases for verifiable credentials, as the ability to independently verify data integrity without having to go all the way back to the source (i.e., the issuer) is powerful indeed.

When thoughtfully designed, implemented, and governed verifiable credentials can provide meaningful benefits for people, while providing them privacy, consent, and control over their personal data.