Decentralized identity aims to let people and organizations present verifiable information without requiring every verifier to query one central identity database. A university might issue a digital diploma, a wallet might hold it, and an employer might verify that it was issued by the university and has not been altered. The approach uses cryptography and standards, but it does not eliminate institutions or make every identity claim self-proving.
The W3C ecosystem separates several roles. An issuer creates a credential, a holder controls or presents it, and a verifier evaluates it. The subject is the person or thing the claims concern. These roles can overlap, but distinguishing them prevents the vague idea that an identity “lives on a blockchain.”
Decentralized identifiers
A decentralized identifier (DID) is a URI such as did:example:123 governed by a DID method. Resolving it can produce a DID document containing verification methods, such as public keys, and service information. The DID controller uses corresponding private keys or another method-defined mechanism to update or authenticate control.
Not every DID uses a blockchain. A DID method can rely on a distributed ledger, a web domain, a peer-to-peer relationship, or another system. The W3C DID Core specification defines a data model and operations, while each method defines how identifiers are created, resolved, updated, and deactivated.
A DID is also not automatically a civil identity. Anyone may create certain kinds of identifiers. The value comes from credentials and trust relationships: for example, a licensing authority signs a claim linking a DID to a professional qualification. A verifier must decide whether it recognizes that authority.
Verifiable credentials and presentations
A verifiable credential is a set of claims with cryptographic proof and metadata. It can state that a subject completed a degree, is over a threshold age, holds a membership, or is authorized for a role. The issuer signs the credential or uses another supported proof mechanism. Verification can detect changes and establish which key produced the proof.
A holder normally does not publish the full credential to a public chain. The wallet stores it and creates a verifiable presentation for a requesting service. The verifier checks proof validity, issuer identity, validity dates, credential status, intended audience, and its own policy. A valid signature shows that a key signed the data; the verifier still needs confidence that the key belongs to the claimed issuer and that the issuer is authoritative.
Credentials may be encoded and secured in different ways, including JSON-based proofs or signed tokens. Interoperability depends on shared schemas, proof suites, status methods, and presentation protocols—not just use of the W3C vocabulary.
What an identity wallet does
An identity wallet manages identifiers, private keys, credentials, and consent to presentations. It may run on a phone, browser, hardware device, or custodial service. A well-designed wallet helps the user understand who is asking, what information will be shared, for what purpose, and whether the request is excessive.
“Self-sovereign” language can obscure operational reality. If a user loses all keys and backups, recovery may be impossible. If a cloud provider can recover the wallet, the provider has a role in the trust model. Social recovery, multiple devices, guardians, and issuer reissuance can help, but each needs protection against impersonation and coercion.
Wallet security is critical because credentials may be valuable even when they cannot move money. Malware could reveal health, employment, travel, or eligibility data. Device encryption, secure key storage, phishing-resistant authentication, minimal backups, and clear transaction previews are therefore central requirements.
Selective disclosure and privacy
Traditional identity checks often collect far more data than needed. A venue checking whether someone is over 18 may copy a document containing full name, address, birth date, photograph, and document number. Selective-disclosure techniques can let a holder reveal only necessary claims or prove a predicate such as “age is at least 18.”
Some credential formats support revealing selected signed fields. More advanced schemes use zero-knowledge proofs to prove statements without exposing the underlying value. These techniques can improve data minimization, but metadata still leaks. Reusing one identifier across shops, employers, and health services allows correlation even if each presentation reveals little.
Pairwise identifiers, unlinkable presentations, local processing, and avoiding public credential registries can reduce correlation. Verifiers should not retain presentations longer than necessary. Issuers should avoid putting personal information or stable hashes of predictable personal data on immutable public ledgers, because hashes can sometimes be guessed and verified.
Status, revocation, and expiration
Credentials change. A driving privilege can be suspended, an employee can leave, or a key can be compromised. Expiration handles some cases, while status mechanisms let verifiers check whether a credential remains active. A simple public revocation list may reveal when and where a particular credential is checked, so privacy-preserving status designs are important.
Status checks also create availability risks. If every verification requires the issuer’s server, the system recreates an online dependency and lets the issuer observe usage. Cached status lists or privacy-preserving accumulators can reduce contact, but verifiers must decide how stale a status result may be.
Where blockchains may fit
A blockchain can anchor identifier updates, public keys, schema references, or tamper-evident status information. It can provide a shared registry when participants do not want one operator to control it. However, writing credentials or personal attributes directly to a public ledger conflicts with privacy, correction, and data-minimization goals.
Blockchain finality also does not establish that a real-world claim is accurate. A dishonest accredited issuer, compromised signing key, or fraudulent enrollment process can produce a cryptographically valid false credential. Governance must define who may issue which credential types, how keys are rotated, how disputes are handled, and when trust is withdrawn.
Practical evaluation
For each system, ask who issues credentials, how verifiers discover trusted issuers, what the wallet exposes, how users recover, and how credentials expire or are revoked. Check whether presentations are linkable and whether personal data is placed on public infrastructure. Determine whether the verifier can request unnecessary attributes and whether the holder can meaningfully refuse.
Decentralized identity can shift data from centralized account silos toward user-mediated credentials. Its success depends less on adding a token and more on interoperable standards, secure wallets, trustworthy issuance, privacy-preserving presentation, and accountable governance.