A Beginner’s Guide to Decentralized Identity and Verifiable Data

Trevor Butterworth

VP Communications & Governance

The Internet Was Built Without A Way To Identify People, Organizations, Or Things Other Than Computers

Now, there are 5+ billion people and 20+ billion devices, tens of millions of businesses and organizations — and AI.

If you are one of the 5.18 billion people online, you are likely to have a digital “identity”— or more precisely, a digital identifier. You likely have many of these digital identity-identifiers — email addresses, social media accounts, and a whole bunch of user accounts and profiles to purchase goods and access services. You may even use one of these identity-identifiers, such as a Facebook profile, to access multiple sites and services.

We refer to these digital identities as “centralized.” This is because the personal data you provide to create an email address or a user account is stored by the entity you are opening an account with in a “central” database, and the management and verification of your identity, and what you have access to, all happens within that single environment.

One of the consequences of centralizing identity is that your identifiers and identities are not under your control. You provide information about yourself and that information is verified by the identity provider to a greater or lesser degree (for example, you might submit a phone number to the provider and then input a code sent to your phone by that provider to prove you are the person they are interacting with). The email provider, business, or service then stores and is responsible for that account information on a database under its control.

This is how digital identity and the authenti- cation of digital identities have come to be managed online. “Federated” identity, where one identity account can be used to access several sites and services, is still centralized because the identity account and the personal data associated with it is still held and controlled by the original identity provider.

We do things this way because the internet wasn’t designed to manage human or organ- izational identity; it was designed to recognize computers, because that’s what the network was built to connect (and for many years the number of connected computers was so low, it was possible for everyone to know who was using them). No one envisaged the internet evolving into the World Wide Web and connecting 65 percent (and counting) of the world’s population and billions more devices.

Centralized identity provided a way for all these people and organizations to participate online, which is a stunning achievement. But it is an imperfect solution to the structural absence of a reliable identity layer, one measurable in the cost of fraud, friction, loss of privacy and the complexity of compliance with data-protection regulation.

We must solve the underlying verification problem so that data can be trusted

The structure of centralized identity — usernames, passwords, emails — make digital identities and identifiers easy to fake or steal, whether it is through guessing a simple password (1, 2, 3, 4, 5…) or using a phishing email or robocall to get you to enter your account details.

Even if you are wise to these scams and do nothing wrong, databases holding massive amounts of personal data are attractive targets for identity theft, and the centralized model means that it only takes a single point of failure in the defense of a database to compromise the entire database. The resulting cost in fraud and data breaches is enormous in both the losses incurred and in the burden of playing defense.

Similarly, if a centralized identity system fails, you are shut out of your account — or several accounts, if the failure involves federated identity. And then, on top of all these external threats, there are internal issues: Who has access to your data and what did you agree to let them do with it by ticking the “consent” box when you opened your account?

It was once thought and passionately argued that no one cared about data privacy given the convenience of doing everything online; but that is no longer the case. The expansive growth in data collection and surveillance has driven both public and political concern, which has resulted in extensive data privacy laws such such as GDPR — the European Union’s General Data Protection Regulation — and other global variants, all of which aim to protect people’s personal data from being exploited. Storing personal data is now a compliance headache and cost for businesses and organizations.

Finally. no one loves the friction of passwords: If they are hard to crack, they are hard to remember; if they are easy to remember, they are easy to crack. Multi-factor authentication adds more protection but also more friction, even as the overall course of the digital world is to make things as streamlined and simple as possible; it is also not impervious to hacking. The scale of our digital dependence on passwords is vast: one study estimates the average person has 100 passwords, all of which need to be frequently changed, sufficiently complex to avoid being easily guessed, unique to each account, and not reused; 24 billion were stolen in 2022.

These problems combine to make digital interaction more complex and costly and more untrustworthy, even as businesses, consumers, and the public sector all seek and embrace more digitalization. But if people and organizations keep failing at online security, then maybe online security needs to be designed to address how people behave and organizations function, rather than how we want them to behave and function?

The need for billions of connected machines to have identifiers amplifies the scale of the problem, while the evolution of artificial intelligence expands the scope and complexity of fakery and fraud. Now, we must account for deepfakes of images and voice in our identity systems. In short, we must solve the underlying verification problem so that data can be trusted. This is where decentralized identity steps in.

What is Decentralized Identity?

Decentralized identity removes the need for centralized control of identity by answering these questions:

Who should control your digital identity-identifiers?
Where should your personal data be stored?
How should your personal data be shared?
And how can all this be done in a way that enables a digital identity and the data associated with it to be verified as trustworthy?

In terms of business and organizational implementation and user experience, the technology that does this must also be easy to integrate into existing infrastructure, easy to use by everyone, privacy-preserving, frictionless, scalable, and low cost.

If you want to skip ahead, you can get all this in a virtual box from Google Marketplace and soon, AWS Marketplace; but if you’re finding the journey illuminating, let’s start with how these questions are answered.

1. Who should control your digital identity-identifier?

Answer: You should! The key technical development allowing you to do this is a decentralized identifier, aka a “DID.” Think about phone numbers, emails, and websites. In a sense, they’re all addresses for either contacting someone or some entity or accessing resources or services.

A DID is also a kind of address — one that you can create to represent yourself, or an organization, or a thing that’s under your control. But unlike a phone number, email, or website address, you fully control your DID. It doesn’t require an identity provider or a certificate authority or a central registry to exist.

Hold that thought.

2. Where should your personal data be stored?

Answer: With you! If you can create a digital address for your identity, you can accept information sent to that address, such as an ID credential like a digital passport or driver’s license. you can store these credentials with this information in special software on your mobile device — a digital wallet app — or in the cloud.

Again, hold that thought.

3. How should your personal data be shared?

Answer: By you choosing who you want to share it with. If you can hold your personal data, you can consent to sharing it. Of course, there are many situations where you are legally obligated to share data or prove your identity. But there are many more where this isn’t the case.

DIDs and Verifiable Credentials

You probably have many questions about how all this works, and we will get to those. First, let’s summarize:

You can create an address for your identity.
You can store your personal data (or any other important information about an organization or a thing).
You can control who you choose to share that data with.

What we’ve done is removed the need for centralized databases filled with personal data to create and manage digital identities and identifiers. Instead, we now hold our data, which means we control our data. This has significant implications for privacy and security. That little checkbox where we tick away our personal data so advertisements can follow us around the internet (and for other, unknown purposes) no longer has the power it once had.

4. How can this be done so that a digital identity and the data associated with it can be verified as trustworthy?

Answer: Verifiable credentials. This is where things get even more exciting and, also, complicated. First, the view from 40,000 feet: the owner of a DID can cryptographically prove that they control their DID.

How? Shortest possible version: When you create a DID, you define what the DID is an address to — you personally, the department of motor vehicles, a business, a bank. In your case, you’re the controller; in the case of a business or government agency, there may be multiple controllers.

So far, so good.

Each DID has a public cryptographic key paired with a private cryptographic key. (What are cryptographic keys? Strings of characters with algorithms—functions—that encrypt and decrypt data).

When you contact your bank’s DID, you use the bank’s public key to encrypt your message. Only the bank has the private key to decrypt your message. If the bank responds to your message, you know it controls the bank DID. And because you are using your DID to connect to the bank, the bank can also verify that you control the DID in your name, and therefore are the account owner.

All this happens instantaneously and through a direct and secure communications channel created between the DIDs called DIDComm. This is why saying a DID is an address for identity doesn’t quite capture what a DID is: it’s an address with a built in communications endpoint that allows you to securely communicate with other DIDs.

What this means that when DIDs connect, they mutually authenticate each other over encrypted, peer-to-peer communications channels. What this means: we now have a way to verify the source of any information.

Security bonus: because you can create any number of DIDs, each interaction with another DID can be uniquely encrypted, thereby preventing digital interactions from being correlated.

Now we can both control our digital identities and mutually authenticate them before sharing data with each other. But how do you 1) get a DID and 2) find a DID?

1). The software in your digital wallet creates DIDs for you. 2). The issuer of a credential will post a public DID to a verifiable data registry or distributed ledger and send a link so that you can connect and create that DID to DID communication channel.

Verifiable data registries are blockchains for identity and they are used for writing and verifying public DIDs, which is to say the DIDs for credential issuers (and not your personal DIDs). Credential issuers use a distributed ledger network to write addresses and public keys and by doing so, the credentials they issue can be verified.

As information is written to and stored by a blockchain-based ledger in a special, linked way, any attempt to alter that information breaks the time-stamped chain of blocks and is detectable.

Additionally, because there are multiple copies of a ledger on a network, each copy of the ledger records and distributes what is written to any one ledger. All the copies of the ledger in the network must be in agreement (“consensus”) as to what is written to the ledge

What this means: A distributed ledger network provides a way to find and authenticate the addresses for sources of information and prove information hasn’t been tampered with.

Now that we have this architecture for creating trusted relationships, how is the actual data shared? We started out this section with the answer, ”verifiable credentials.”

One way to understand a verifiable credential is to think of it as a shipping container for identity and data. You can’t fake the origin of the container or alter the data inside the container without breaking the container, which is instantly revealed. You hold these containers in a digital wallet application on a mobile device.

Technically, a credential is a digital schematic for assembling information. A verifiable credential for a passport contains a description of the passport’s structure and the fields for specific information. A government issuing a passport credential will write this ”schema” to a distributed ledger network, along with information that links this schema to the passport office.

The passport office sends a QR code to the passport applicant. This enables the potential holder to connect over DIDComm (if the person doesn’t have a digital wallet app to enable this, they will be prompted to download one).

Once a DIDComm connection has been established, the person is offered their passport as a verifiable credential. If they accept, they receive a credential populated with their specific data. The data has been digitally signed with a cryptographic stamp to make sure the information comes from the issuer and hasn't been altered.

Only the passport office (the issuer) and you, the person who has just received a verifiable credential, hold your actual passport data. This data isn’t written to the distributed ledger network and doesn’t need to be for verification to work. If there is an iron law of decentralized identity networks, it’s that personal data should never be written to a ledger.

For example…

Let’s say I’m a bank. I’ve approved you for a new account by going through all the traditional assurance steps needed to prove that you are who you say you are. I’m now going to offer you a way to prove you are an account holder by issuing you a verifiable credential for your account using the technology we’ve described.

First, I (the bank) send you a QR code, either via email or a text message, with the offer of an account credential and you scan this QR code with your mobile device. This establishes a secure, direct connection, over DIDComm, which enables you to accept and receive a verifiable credential.

Second, you accept (or decline) the offer of this credential. If you accept, you’ll receive the credential and store in special software on your mobile device — a digital wallet app. The credential contains relevant details about your account.

We use DIDs and DIDComm and the schema and other credential metadata on the network to do all the work of verification. This means that a verifiable credential can be verified anywhere (as long as you have the appropriate software) and at any time without checking in with the source of the data or cross checking the data with a third party.

One additional important note. Blockchain-based networks have come under scrutiny for energy consumption. This concern does not apply to blockchain-based identity networks for the reason that no “mining” is required for verification. Writing a schema to a ledger or looking up a DID consumes no more energy than a web search.

Finally, you use this credential to log into your account and to make and approve account transactions instead of a username or password and multi-factor authentication.

The bank knows it’s you logging into your account because it can verify that you are in control of your DID and — equally important — you’ll know you are interacting with your bank and not someone pretending to be your bank because the software automatically validates the bank’s DID.

When it creates your verifiable credential, the bank sends you your account details directly: they’re in the verifiable credential.

The bank will also write a cryptographic digital signature and metadata about the structure of the credential — called the schema — to the distributed ledger network.

This information means the authenticity of the credential can be verified along with the integrity of the information contained within the credential, namely, that the information hasn’t been tampered with.

No personal information is written to the distributed ledger. If your personal data was written to the ledger, anyone could see it.

The verifying software can be used by any other entity to confirm you are a bank account owner, opening a multiplicity of ways to mitigate fraud and streamline processes, such as mortgage approval.

This is a powerful way for a bank or payment service to verify its customers and customers to verify they are interacting with their bank.

*We call the software managing the credential issuing, storing, presenting, and verifying “agents.”

Issuing, holding, and verifying an account credential

Verifier software creates ecosystems for verifiable identity and data

Open standards and interoperability mean data and identity can be shared and authenticated across different ecosystems

Verifiable identity and data enable seamless processes

Because each party can authenticate each other before sharing information and trust the source and integrity of the information that is shared, the information can be acted on immediately. It enables instant decision-making in interactions where data needs to be trusted. Anyone with verifier software can verify a credential and the data inside it. This allows trust to expand creating ecosystems and integrating other networks.

As an example, consider how verifiable credentials manage something like a mortgage application: Instead of having to gather numerous paper documents that either must be hand delivered or scanned and emailed, often repeatedly, you will be able to hold all this information through a variety of verifiable credentials — one for your bank statements, one for your pay stubs, one for your personal ID — and then combine them all to send to a broker.

Any information that can be conveyed through a credential schema is now verifiable, along with the source of that information. Trust lists for issuers and complex information flows and approvals are managed by machine-readable governance files directly sent to the agent software of each participant in the credential ecosystem.

Security and privacy

A key feature of decentralized identity is that it makes third-party centralized databases redundant. Personal data doesn’t need to be stored in order to verify identity and manage access to accounts, resources, or services. If there’s no personal data in the vault because no vault is needed, business and organizations dramatically improve their security.

And, because verification is seamless, businesses and organizations can more easily deploy “zero-trust” security. Zero trust means, “never trust, always verify” with respect to providing an employee or user access to any resource in a system.

But storing personal data is not just about security, it’s about privacy and compliance with data protection regulation. This is where decentralization assists companies and organizations to comply with regulations like Europe’s General Data Protection Regulation.

If, as a company or service, you can verify identity and process requests or sales without storing personal data, complying with rules on data processing and storage are simplified.

Finally, the burning question — what if I lose my phone?

What if you lose your phone or someone steals it? Biometric binding and liveness checks ensure that it is you who is using your phone and digital wallet app. Backups can be held in the cloud. And verifiable credentials can be revoked and quickly reissued.

But there are also features built into some credential formats that provide even greater privacy features. We can choose to selectively share specific data, based on the attribute field in the schema.

We can also prove data about ourselves in ways that don’t require sharing the specific data. This is called a “zero-knowledge proof,” an example of which would be the ability to answer “yes” or “no” to the question “are you over 18?”

Derivative credentials are another way of proving something without sharing specifics. Say you must pass a health test to enter a country. This data can first be issued by a healthcare provider in the form of a verifiable credential. But the credential can then be verified by a government authority, which in turn issues a second credential that only attests to the test results having been verified. The person could then use this credential to prove their health without having to share any health or personal data whatsoever.

Think of it as the ability to create a data-less proof from the data in a prior proof.

Decentralized identity in action

Verifiable credentials in travel and tourism

Aruba is leading the decentralized identity revolution in travel with AHOP. Watch a short explanatory video

How verifiable credentials are changing travel — an Indicio Meetup discussion

Verifiable credentials in agriculture

Trust Alliance New Zealand explain how verifiable credentials are providing farmers with control of their data to meet compliance and sustainability requirements — an Indicio Meetup discussion

Verifiable credentials in education

United School Administrators (USA) Kansas explain how verifiable credentials are helping it certify leadership training for school administrators across Kansas, and the benefits from being able to issue and verify micro credentials and transcripts directly to recipients — an Indicio Meetup discussion

For more information and where to start…

Hopefully, this beginner’s guide gives you a sense of what this technology does, how it works, and how powerful and useful it is. By necessity, it leaves out many terms and things in the interests of making it easier to “picture” how it works and what it means.

There are many resources available for you to dive deeper—not least those listed below, along with the Hyperledger Foundation and the Trust over IP Foundation. In the end, the best way to learn about what this technology can do is to get your hands on it and use it!

Indicio’s verifiable identity and information products make it possible for businesses and organizations to make lightning-fast decisions and implement seamless processes.

From account, device, and facility access to identity orchestration, KYC, certifications, qualifications, device monitoring and audit, the use cases are unlimited.

So how do you start?

Indicio Proven®: Verifiable identity and data in one out-of-the box package, with all the components you need to implement quickly and scale.

Holdr+: A customizable digital wallet for storing verifiable credentials available on iOS and Android.

Indicio Proven Mobile SDK: We’ve made it easy to develop customized apps for verifiable identity onto existing apps for both iOS and Android.

Indicio Network: A professionally-managed, globally- distributed distributed ledger network with free TestNet for developing.

Indicio Academy: The only training and certification program, specific to the industry. Comprehensive, hands-on courses on all aspects of verifiable identity and data.

Digital Travel Credential (DTC): The world’s first complete digital travel credential based on ICAO standards. Award winning for data privacy and security, the DTC enables pre-authorized check in and seamless border crossing in seconds. Works on any airline or airport system.

Indicio Open Badges make it easy to use the globally-recognized standard for digitally proving educational achievements, skills, and endorsement. But we’ve added powerful new features that enable badge holders to hold their badges in digital wallets, share them directly, and communicate with badge issuers.

Connect with us:

PreviousIndicio Whitepapers NextIndicio Proven®

Last updated 1 month ago

Was this helpful?