There is extensive work in the community to standardize elements involved in decentralized identities, and soon it will be much easier to use them.
Decentralized identities are quickly gaining traction, notably outside of the Web3 community. These new technologies will allow the use of digital credentials issued by verified parties, like governments and universities, in a standardized way. The concept introduces the issuer-verifier-holder model, which can be summarized at a high level with this diagram:
One of the most important features shown here is that there is no direct link between the verifier and the issuer, only a trust relationship. This is a crucial privacy enhancement compared to present solutions based on federated logins because the issuer does not know how or when the holder uses the credentials. The issuer thus cannot collect data about the user based on their online behavior. Moreover, with proper implementations, the holder will have much more control over their data and how it is shared with the verifier. The user can share only a subset of identity data or even use zero-knowledge proofs (ZKP) to cryptographically prove some identity information without revealing any data.
There is extensive work in the community to standardize the different elements involved in operating decentralized identities, and it will soon be much easier to implement and use them on a wider scale. As such, decentralized identities will be suitable for a number of specific use cases. Below, I will discuss some of these possible use cases associated with decentralized identities.
As I discuss concrete use cases of decentralized identities, I will usually refer to verifiable credentials or verifiable presentations, as these documents are exchanged between parties. Have a look at this overview of decentralized identities article if you want to familiarize yourself more closely with these terms.
Use Cases of Decentralized Identities
Proving a User’s Age
A common example of a decentralized identities use case, which nicely illustrates what the technology is capable of, is proving to the verifier that the user is above a certain age without revealing the person’s birthdate. Such a use case is beneficial to both the holder and the verifier.
On the one hand, this helps the user avoid oversharing personal information. On the other, the verifier does not have to worry about data-protection regulations as it does not receive that data. With acts like GDPR or CCPA (The California Consumer Privacy Act) affecting more and more companies globally, it’s useful for businesses to spend fewer resources on governing and managing sensitive data.
However, this concrete example requires proper implementation on all sides — the issuer, the holder’s wallet and the verifier — which might hinder the adoption of such use cases.
This feature can be implemented in two ways:
- The issuer can derive claims from the user’s birthdate and put them in the verifiable credential. For example, the issuer can add claims like “is_over_18,” “is_over_21” and “is_over_60” to the document. The verifier can then just check the claim it needs. This is simple to implement but has its limitations — the holder must update the credential whenever a threshold is passed, and the issuer must know upfront which thresholds might be useful to verifiers.
- The issuer can create a verifiable credential document in a way that supports zero-knowledge proofs. Then, the holder’s wallet must support reading such a document and be able to create a verifiable presentation with transformed claims that conform to ZKPs. The verifier must be able to read a verifiable presentation with ZKPs and adequately verify it. In this approach, the holder has almost unlimited possibilities of transforming the original credential and can just use the birthdate from the original credential to compute the “above age X” claim. This is then cryptographically processed to create a zero-knowledge proof. This solution requires all parties to properly implement the technology — the issuer must issue verifiable credentials in a certain way, the wallet must be able to correctly compute claims and create verifiable presentations using ZKP, and the verifier must be able to verify ZKP claims. This solution also requires much more cryptographic work for all parties, which can further strain resources.
Thus, while proving a user’s age is a compelling use case for decentralized identities, it should be noted that it requires a lot of work from different parties before it can be widely used.
Issuing University Degrees as Verifiable Credentials
Another good use case, frequently cited in resources about decentralized identities, is issuing university degrees as verifiable credentials. Since degrees usually don’t change over time, the holder only needs to obtain the document once. University degrees in the verifiable credential form can be used later when applying for a job, a grant or another position. The user will be able to prove ownership of the degree instantly without the need for additional verification.
I feel that verifiable credentials will be used commonly on the web like this: A user will be able to present a verifiable presentation when registering to a website. The user will register without having to fill in any registration form. They will pick the data they want to share with the website, such as their email, name or shipping address. The website will use the data to create an account in its database. The website won’t have to go through the hassle of sending confirmation emails or text messages — the data will come from a verifiable credential, so the website will be sure it is genuine user data. (At least as long as the website trusts the issuer of the verifiable credential.)
Other scenarios might appear in the future where the website could further limit the amount of data it manages. For example, the application could store only an anonymous ID of the user’s passport or other government-issued identity document in its database. Whenever the website would need the user’s shipping address, it could ask them to provide another verifiable presentation document, this time with an address. Should the website be obliged by authorities to provide information about the user’s activity, then the authorities could properly identify the person even though the website would not store and manage that information. Again, this can help companies limit the amount of sensitive data they manage.
Creating Verified Accounts on Social Media
Social media could also use the above technique to create verified accounts. When an account is created, the user can easily prove they are real by providing an anonymous ID of an identity document. As long as the website controls that the same document is not used on multiple accounts, it could inform other users which accounts represent real people. This could tackle the current bot problem, creating a safer environment for all internet users, using standardized technologies for which no one would have to pay additionally.
Proving the Eligibility of Discount Tickets
The ability to prove specific user attributes is a recurring theme of decentralized identities. The feature could also be used when buying discounted tickets to prove discount eligibility such as museum, cinema, event or public transport tickets. A student could use their student card issued as a verifiable credential to buy a discounted ticket and cryptographically tie the ticket to their wallet (the ticket would be issued as a verifiable credential itself). When that ticket is subsequently presented, it wouldn’t have to be presented together with the proof of discount eligibility, as the verifiable document itself already covers it. The same technique can be used with tickets that need to be bound to a specific person, like concert tickets, event tickets or train tickets.
Boarding Passes as Verifiable Credentials
Decentralized identities have an important trait — they break the link between the issuer and the verifier. Thus, people wonder whether this technology would be useful when both parties are part of the same organization. For example, boarding passes are both issued and verified by the same company. Still, if a boarding pass was issued as a verifiable credential, it could be used in other scenarios where the pass is used nowadays. It could be presented in an airport shop to prove eligibility for duty-free shopping or be used at some airports to gain access to Wi-Fi.
Such actions would be possible without revealing any details about the passenger. The verifiable presentation can only contain the destination country, and the airline’s signature will provide the necessary level of trust. Such solutions would significantly increase the traveler’s privacy, and I hope they will be used commonly in the near future.
An essential characteristic of verifiable credential documents is that the subject of the document does not have to be the same as the holder. Consider these scenarios:
- A pet vaccine certificate, where the subject is the vaccinated animal and the holder is the pet owner.
- A marriage certificate will have two subjects, and each spouse will be a separate credential holder.
- A document where the subject is a minor and the document is issued to the parent.
Where Verifiable Credentials Won’t Help
It’s good to note that there are some use cases where verifiable credentials aren’t a good fit. For instance, verifiable credentials and presentations are not meant to replace sessions or access tokens. That is far from the intention behind the concept.
Access tokens are intended to replace credentials normally used in a physical form with a digitally standardized, interoperable format. Even if someone tried to use verifiable presentations for sessions, sending them in every request would drain resources as these documents require intensive cryptographic work to be created and verified.
The verifiable credentials concept also poorly represents credentials with attributes that change quite often, especially when the updated state of the credential is critical from the security point of view. This stems from the fact that the revocation of such credentials is a complicated subject still not standardized by the community. For example, verifiable credentials and presentations are not a good fit to represent an employee’s key card. The access scopes of a card can change quite often or might have to be revoked immediately because of a sudden termination of a contract. (In some systems, however, this limitation can be solved by switching the authorization source. The verifiable presentation might only provide the user’s identity. Then the verifier would apply authorization rules like checking whether the person is an active employee with access to the given part of the building.)
Conclusion
Decentralized identities are still an emerging technology, but they have been used for some time now in the Web3 environment. There are also successful implementations in the government sector (Bhutan has deployed a countrywide e-ID program), and there is strong support from EU authorities. Nonetheless, many of the standards are in the draft stage and change rapidly, and the community still has to figure out some features, like revocation. Implementers should definitely take this into consideration. Regardless, my opinion is that decentralized identities and verifiable credentials will present one of the biggest shifts in the handling of digital credentials we have ever seen.
