Decentralized Identity (DID) Explained: Self-Sovereign Identity & Verifiable Credentials

Decentralized identity asks a simple question: who should control personal information? It can put control back in individuals’ hands, rather than leaving every identity check to a central authority. Yet approximately 850 million people worldwide still cannot claim ownership of their identity, limiting participation in essential services.

What is a decentralized identity? This guide explains how a decentralized identity wallet stores credentials, how decentralized identifiers and verifiable credentials support selective disclosure, and how issuers, holders and verifiers work together. It also examines decentralized identity crypto, blockchain’s optional role, and practical risks including lost recovery keys, scalability and compliance.

What Is Decentralized Identity?

Online identity has traditionally depended on an organisation that stores information and decides how a person proves access. Decentralized identity changes that arrangement by allowing an individual or organisation to hold identity evidence and choose when to present it. Instead of creating a separate identity record for every service, the holder can use credentials issued by trusted authorities across different interactions.

Centralised and Federated Identity vs Decentralized Identity

A centralised identity model places identity data with one service provider. A person may create a username and password for each website, application or digital service. Each provider then stores account details in its own database. This siloed approach gives the user little control over what information is retained, how it is used or how it is shared. It also creates registration fatigue, repeated password management and multiple stores of personal data.

A federated model reduces the number of separate log-ins. The user selects an option such as “Sign in with” a third-party identity provider, which confirms their identity to participating services. This arrangement offers convenience, but the provider remains the middleman of trust. It controls the identity credentials and can accumulate information about the user’s activity across connected services. A central database can also become an attractive target for attackers because it contains information belonging to many users.

Decentralized identity uses a different relationship between the parties. The identity holder keeps credentials in a decentralized identity wallet, usually on a smartphone, laptop or browser plug-in. A trusted authority issues evidence, while a service provider verifies it when the holder chooses to share it. The authority does not need to operate as an intermediary for every later interaction.

For example, a university can issue a digital degree credential. The graduate stores it in a wallet and presents it to an employer when applying for a role. The employer checks the credential and its issuer rather than asking the university to repeat the same verification each time. Thus, the holder can reuse trusted evidence without creating a new identity record at every service.

The model has three roles:

• Issuer: a trusted authority, institution, company or individual that provides a credential.
• Holder: the person or organisation that owns the identity information and stores the credential.
• Verifier: the organisation or person that checks whether the credential satisfies a requirement.

The arrangement does not mean that every participant automatically trusts every credential. A verifier can assign a level of assurance according to the issuer’s identity and reputation.

How Self-Sovereign Identity (SSI) Defines User Control

Self-sovereign identity, or SSI, provides the user-control model behind many decentralized identity systems. It gives individuals or organisations ownership of their identity information and the ability to decide who receives it. The holder can approve access for a particular interaction and withdraw that access afterwards, rather than handing permanent control to a platform.

The wallet acts as the holder’s storage and control point. It contains credentials representing identity attributes, such as a driving licence, tax identifier, university qualification, business licence or medical information. The wallet can be protected through common device authentication methods, including Face ID or Touch ID. Private keys remain under the holder’s control, while corresponding public information supports verification.

SSI also supports selective disclosure. A person applying an age requirement can prove that they meet the required age without presenting an address or other details contained on an identity document. Zero-knowledge proof methods can go further by proving that a condition is satisfied without revealing the underlying information. For that reason, a verifier receives only the evidence needed for the transaction.

This structure supports data sovereignty, meaning that the person or organisation controls its data. It also supports technological sovereignty where the identity system is not owned by one company. In practise, decentralized identity can improve privacy, reduce unnecessary data collection, support portable credentials and give users a consistent way to interact with services.

Decentralized identity crypto is often associated with blockchain, but SSI does not require blockchain in every implementation. A blockchain or another distributed ledger can record public identifiers or credential-related information that helps participants verify authenticity. Personal identity data remains outside that public registry. Other systems can provide the required trust and verification functions without using a blockchain, so the technology should be selected according to the identity system’s needs rather than treated as a definition of SSI.

The Building Blocks: DIDs, Verifiable Credentials and Wallets

A decentralized identity system combines identifiers, credentials and software that manages cryptographic keys. Each component performs a separate task. A DID identifies an entity, a verifiable credential carries an attested claim, and a wallet controls the keys and credentials used during an interaction. Together, these components create a technical basis for portable identity evidence without placing personal information in a shared identity database.

Decentralized Identifiers (DIDs) and DID Documents

A Decentralized Identifier, or DID, is a globally unique URI that can identify a person, organisation, device or other subject. Its structure includes the did: scheme, a DID method and a method-specific identifier.

A DID resolves to a DID document. This document does not normally contain a person’s name, address or other personal attributes. Instead, it provides the public information required for cryptographic interaction, including public keys, authentication methods and service endpoints. A resolver accepts the DID and returns the relevant document according to the rules of its DID method.

The private key remains with the controller, while the public key appears in, or can be obtained through, the DID document. When the controller signs a message, another party can use the public key to check control of the DID. An entity can also create multiple DIDs for separate relationships or contexts, which reduces the need to use one identifier everywhere.

Related Article: Public Key vs Private Key: What’s the Difference and How They Work Together [2026]

W3C Verifiable Credentials: Claims, Issuers and Digital Signatures

A verifiable credential is a structured set of claims about a subject. A claim might record a qualification, licence, identity attribute or membership. The issuer creates the credential and signs it with a private key. The signature provides evidence that the credential came from that issuer and that its contents changed after signing.

The W3C Verifiable Credentials Data Model defines a common way to represent elements such as the credential type, issuer, subject, issue date, expiry date and proof. Other formats exist, including ISO/IEC 18013-5 for mobile driving licences and AnonCreds. Protocols such as OpenID4VC define how credentials are created, obtained and presented.

During verification, the relying application checks the issuer’s public key, the signature, the credential’s dates and its status. It can also check the link between the credential and the presenting holder. A credential may contain a subject identifier connected to a DID, while a holder proof demonstrates control of the corresponding private key.

Claims need not expose every underlying value. For instance, an issuer can provide an age_over_18=true claim rather than the holder’s full birth date. Selective disclosure and zero-knowledge proof techniques allow the holder to present only the condition required by the verifier.

What a Decentralized Identity Wallet Stores

A decentralized identity wallet is an application that stores credentials and manages their related private keys. It may run on a mobile phone, browser extension, hardware device or remote service. The wallet also creates presentations, prompts the holder for approval and performs cryptographic signing.

A self-contained wallet keeps keys locally and avoids a third party inspecting its contents. A cloud-based wallet can provide access from multiple devices and support backup or recovery, but it introduces a service provider into key management. In either model, the wallet must protect private keys because anyone who obtains them may be able to impersonate the holder.

The wallet can also maintain several DIDs, organise credentials and record consent for a particular presentation. It should show which claims an application requests before the holder approves disclosure.

Blockchain’s Optional Role as a Verifiable Data Registry

Blockchain is one possible verifiable data registry for DID records, public keys, status information or cryptographic events. Its shared transaction history can help participants detect unauthorised changes, but it does not store the credential itself. Personal data should remain off-chain because public records can create persistent correlation points.

Other registries include databases, decentralized file systems and peer-to-peer networks. Some DID methods, such as did:key and did:jwk, can operate without a separate registry. Therefore, decentralized identity crypto describes one possible implementation choice, not a requirement of DIDs or verifiable credentials.

How Credential Issuance and Verification Work

The exchange follows a defined relationship between three parties: the issuer creates evidence, the holder controls it in a wallet, and the verifier decides whether that evidence meets a particular requirement. This process separates issuing a credential from presenting it, so the same credential can support more than one interaction.

An Issuer Checks Claims and Signs a Credential

An issuer first collects and checks the information required for a credential. The underlying process may involve student enrolment, employment records, an identity check or another issuer-specific procedure. The issuer then creates a credential dataset containing claims about the subject, such as a qualification, licence or proof of income.

The issuer selects a supported credential format and constructs the credential with relevant metadata. This can include the issuer, credential type, subject, issue date, validity period, status information and schema. The issuer signs the resulting data with a private key. The signature makes later changes detectable and allows a verifier to check that the credential was created by the claimed issuer.

Issuance may use an authorisation flow in which the holder authenticates and gives consent. Alternatively, a pre-authorised flow can prepare the issuance before the wallet requests the credential. In either case, the wallet obtains permission to call the issuer’s credential endpoint. The request may also include proof that the wallet controls a private key to which the credential should be bound.

The issuer can deliver the credential immediately or provide a transaction reference for later collection. It can also publish metadata describing the credential types, formats and cryptographic methods it supports. These protocol details allow different wallet and issuer implementations to exchange credentials in a consistent manner.

A Holder Receives and Presents the Credential

The holder’s decentralized identity wallet receives the signed credential and stores it with the related key material. The wallet may act as an agent for the holder by managing credentials, creating presentations and asking for consent before information leaves the device or service.

When a verifier requests evidence, the holder reviews the request and authorises a presentation. The presentation may contain one credential, several credentials from different issuers, or only selected claims derived from a credential. For example, an age-related request can disclose an eligibility claim without sharing every attribute in a driving licence.

The wallet can send the presentation through an online channel or a proximity channel such as near-field communication. It may also provide a proof of possession, showing that the presenter controls the key associated with the credential. This check helps distinguish the legitimate holder from someone presenting a copied file. The credential itself remains available for later use, subject to its status and validity rules.

A Verifier Checks Issuer Trust, Signatures, Expiry and Status

The verifier first checks that the presentation follows the expected format and that any required proof is present. It then verifies the issuer’s signature using trusted verification material, such as a public key associated with the issuer’s DID or another approved trust source. A valid signature confirms authorship and integrity, but it does not prove that every claim is true.

Accordingly, the verifier applies its own business rules. It checks whether the issuer is trusted for the type of claim, whether the credential concerns the relevant subject, and whether the presentation satisfies the requested purpose. Where holder binding applies, it verifies control of the associated private key or uses an approved claims-based method.

The verifier also checks validFrom and validUntil dates, if present, and consults the credential’s status mechanism to identify suspension or revocation. Status information may be published in a privacy-conscious list rather than through a separate record for every credential. If any required signature, trust, date, status or holder check fails, the verifier rejects the presentation rather than relying on the claim.

What Decentralized Identity Changes for Users and Organisations

The practical effect of decentralized identity appears when a person must prove the same fact to several services. Instead of sending a complete identity document each time, the holder can present a narrower, cryptographically verifiable answer. This changes the exchange from routine document copying to purpose-based disclosure.

Selective Disclosure to Reduce Personal Data Sharing

A verifier should request the attributes needed for a particular decision, while the holder decides whether to release them. Selective disclosure allows a person to reveal one claim from a credential rather than the full set of information it contains. For instance, an age check can establish that the holder is over 18 without revealing their date of birth, address, licence number or full name.

The holder creates a verifiable presentation from one or more credentials. That presentation may contain only selected claims, or it may use a privacy-preserving method such as a zero-knowledge proof to demonstrate that a condition is satisfied without exposing the underlying value. Formats and protocols support this process in different ways. SD-JWT VCs can make individual claims disclosable, while ISO mobile documents can keep data hidden until the holder approves particular elements. OpenID for Verifiable Presentations and DCQL allow the verifier to specify the information required.

This arrangement changes the balance of control. Users can see what an application requests and withhold optional information. Less personal data travels to the verifier, so fewer unnecessary details enter its systems. Organisations likewise reduce the amount of personal information they collect, store and protect. They can align a request with a defined purpose, reduce exposure from avoidable retention and give users a clearer account of the data involved.

Selective disclosure does not make every claim true by itself. The verifier still assesses the issuer, proof, subject, claims and its own business rules. Furthermore, repeated presentations can create correlation risks if the same identifier or distinctive data appears in multiple interactions. Privacy-preserving designs therefore need unlinkable disclosure where separate presentations cannot be connected between verifiers.

Reusable Credentials to Reduce Repeated Document Checks

A signed credential can represent the information found on a physical document, but it can be transmitted rapidly and checked remotely. Once an approved issuer has created it, the holder can retain it in a decentralized identity wallet and present it to different verifiers without asking the issuer to repeat the original check.

For example, a university can issue a qualification credential. The graduate may present it to several employers, each of which checks the university’s authorship, the signature, the credential’s validity and its status. The holder can also combine credentials from different issuers in one presentation when an application requires several claims.

Reusable evidence reduces repeated uploads, manual document reviews and duplicated checks. It also gives organisations a consistent way to receive structured, machine-readable claims. Nevertheless, reuse does not remove verification duties. Each verifier decides whether the issuer is trusted and whether the claims meet its policy, while expiry or status changes can make an earlier credential unsuitable for a later transaction.

Where Decentralized Identity Is Used

Applications of decentralized identity show value when credentials move between institutions with trust relationships. The same decentralized identity wallet can support finance, study, professional practise, employment and public services, although each sector sets acceptance rules.

Finance: Reusable KYC Credentials Within Trusted Networks

Financial institutions can issue a reusable KYC credential after checking identity evidence and completing customer due diligence. A customer stores it in a wallet and presents it to another bank or regulated service. The verifier checks the issuer’s signature, status and compliance with its policy, rather than requesting every document again. This supports onboarding across borders and reduces duplicated storage of personal and financial information. Trusted networks still need agreed issuers, standards and monitoring.

Education: Digital Diplomas for Job Applications

Universities and training providers can issue digital diplomas, certificates and learning records. A graduate keeps the credential and shares it with an employer, which checks the institution’s signature and verifies the award without waiting for a registrar. This gives applicants portable proof of study, competencies and learning. For instance, WA TAFE uses My eQuals for signed, tamper-evident qualifications, while paper records remain available.

Healthcare: Portable Professional Licences

Healthcare professionals move between employers, regions and regulatory jurisdictions. A medical board or training body can issue a credential for a licence, board certification, education or education. The professional presents it to a new provider, which verifies eligibility before granting access or assigning duties. Status checks can show when a licence expires or is revoked, supporting accountability and patient safety.

Enterprise IAM: Employee Credentials for Access Control

In enterprise IAM, employee credentials can connect identity evidence with access policies. An organisation may issue credentials for employees, contractors or vendors, then map claims to roles or attributes in its identity provider. During onboarding, a worker can prove qualifications or background-check status without sending documents to each application. The same model can support building entry, VPN access and resources, while access remains limited to the right person and time.

Government: Digital Credentials for Public Services

Government agencies can issue digital credentials for identity, driving entitlement, disability status, benefits or public-service access. A citizen can present only the evidence a service requires, such as eligibility for a disability ride service, without disclosing the specific condition. Credentials can support voting systems, benefit distribution and assistance when documents are unavailable. A verifier checks the issuing authority and status, while the holder controls presentation.

How to Adopt Decentralized Identity and Manage Its Risks

Start with a Limited Pilot Alongside Existing IAM

Begin with one workflow, such as employee onboarding or supplier access, while existing IAM remains available. Define the issuer, holder and verifier roles, then test the flow with a group before expanding, and record each decision point for later review by the governance team promptly.

Test Wallet and Credential Compatibility Across Providers

Wallet and credential compatibility must work across providers. Check supported formats, DID methods, presentation protocols and verification behaviour. A provider must not force counterparties to adopt its software. Use resolver-based discovery for public credentials and wallet exchange for confidential access; decentralized identity crypto remains optional.

Plan for Lost Devices, Key Recovery and Credential Revocation

Document recovery routes before deployment. Test replacement devices, key backup and re-issuance procedures, then define how issuers suspend or revoke credentials. A lost device must not grant access, while recovery must not let an attacker impersonate the holder.

Address GDPR Duties, Correlation Risks and Wallet Attacks

Map each data field to a purpose and retention rule. Avoid persistent identifiers where unlinkable presentations can serve instead. Test wallets against phishing, replay, device theft, malicious verifiers and storage provider data mining.

Measure Verification Time, Completion Rates and Support Needs

Record verification time, completion rate, failed presentations and support requests. Compare wallet and resolver journeys, since this shows whether users can complete checks without assistance. Review results before widening the pilot, so that operational changes follow evidence.

Conclusion – Decentralized Identity

Decentralized identity gives people and organisations greater control over how identity evidence is stored and shared. DIDs provide identifiers, verifiable credentials carry trusted claims, and wallets let holders manage keys and approve selective disclosure. Issuers and verifiers still have distinct responsibilities, because a valid signature does not remove the need to check trust, expiry, status and purpose. Blockchain can support these exchanges, although it is not essential to SSI. Practical adoption depends on compatible wallets, reliable recovery, privacy protection, regulatory compliance and careful testing. Overall, limited pilots can show whether decentralized identity reduces repeated checks while giving users a safer, more portable way to prove who they are.

You May Also Be Interested In: Fintech Explained: How Technology Is Reshaping Money, Banking, and Payments