A university wants graduates to present course credentials to employers without asking the university to operate every login, while employers still need to know who issued each claim and whether it remains valid. Decentralized identity methods let people or organizations use identifiers and credentials across services without one platform becoming the sole account authority. Decentralized identifiers and verifiable credentials reorganize trust among issuers, holders, and verifiers; they do not eliminate it.
Identity systems handle sensitive relationships, so architecture matters more than labels. An issuer still decides whether someone earned a credential, a wallet may store it, a verifier decides whether to accept it, and a registry or status service may support key updates and revocation. Personal details do not need to be written to a public chain. In fact, publishing durable identifying data can create serious privacy and safety problems.
What you will learn
- Distinguish identifiers, credentials, presentations, and human identity
- Explain issuer, holder, verifier, registry, and status-service roles
- Design a credential flow that minimizes unnecessary disclosure
- Evaluate recovery, revocation, correlation, and issuer-trust risks
Identifiers are reference points, not complete identities
A DID is a URI associated with a DID method. Depending on that method, resolving it may produce a DID document containing verification methods and service information. Control is demonstrated using cryptographic keys under the method's rules. The identifier can be useful without embedding a legal name, birthday, or address. It points to verification material; it does not certify every claim anyone attaches to it.
Different DID methods make different choices about registries, update authority, costs, and availability. Some use blockchains, while others use web domains, peer exchange, or alternative systems. Therefore, the word decentralized is not enough to establish resilience or user control. Reviewers must ask who can update or deactivate the identifier, how keys rotate, what infrastructure resolution requires, and whether another compatible wallet can use it.
Credentials preserve the issuer-holder-verifier relationship
A verifiable credential contains claims and evidence that allows tampering and issuer authenticity to be checked. A training academy might issue a credential stating that a particular subject completed a course. The learner holds it and later creates a presentation for an employer. The employer verifies the proof, checks the issuer and status, and decides whether that issuer and course satisfy its own policy.
Cryptographic verification answers narrow questions: was this data altered, and is its proof connected to the stated verification method? It does not establish that the issuer investigated carefully, that the underlying statement remains true, or that the verifier must accept it. Trust moves from a platform account database toward an explicit issuer and policy relationship. Product copy should describe that relationship rather than suggesting mathematics makes claims truthful.
Privacy depends on disclosure and correlation design
A reusable identifier can become a tracking handle when presented to many services. Even without a legal name, observers may correlate activity across contexts. Good systems support purpose-specific identifiers, minimal claims, short-lived presentations, and clear consent screens. Some credential formats can support selective disclosure or proofs about predicates, such as confirming an age threshold without sharing a full birth date, but support varies by implementation.
Putting raw credentials on a public blockchain is usually a poor default because public records are replicated, difficult to correct, and available for future analysis. Encryption does not guarantee permanent confidentiality; keys can leak and cryptographic assumptions can change. A safer pattern keeps personal data under appropriate holder or issuer controls while using a ledger only for narrowly scoped identifiers, integrity references, or status information when that infrastructure adds value.
Recovery and revocation are core product flows
People lose devices, rotate keys, change names, and dispute issuer decisions. A usable identity wallet needs understandable backup, recovery, migration, and delegation. Recovery contacts or custodial services can help, but they introduce actors who may collude, fail, or be compelled to act. Product teams should document these powers and test recovery with ordinary users before describing the system as user-controlled.
Credentials also age. An issuer may need to suspend a compromised credential, correct an error, or publish an expiration. Verifiers need fresh status information and a policy for unavailable status services. Permanent acceptance can preserve bad claims; instant revocation without due process can harm holders. The design task is to balance issuer accountability, holder recourse, verifier needs, privacy, and operational reliability rather than maximizing one abstract decentralization score.
Common misconceptions
“Decentralized identity means a person's private information is stored onchain.”
Identifiers and verification references may use shared registries, while credentials and personal data can remain offchain and be disclosed selectively to intended verifiers.
“A cryptographically valid credential proves that its claim is objectively true.”
Verification can show integrity and issuer authorization. The verifier must still assess issuer reliability, claim meaning, current status, and suitability for its policy.
“User-controlled identity removes every intermediary.”
Issuers, wallet providers, DID infrastructure, status services, and verifiers retain distinct responsibilities and powers even when holders gain portability.
Risks and limitations
- Reusing one identifier or wallet across contexts can let services correlate a person's activity and infer sensitive relationships.
- Publishing personal claims or stable identifying references on a permanent public ledger can make correction and deletion impractical.
- Lost keys or a failed wallet provider can make credentials unusable when migration and recovery were not designed in advance.
- A malicious or careless issuer can create validly signed but false credentials, while arbitrary revocation can deny a holder fair recourse.
Key takeaways
- A DID provides an identifier and verification relationship; it is not a complete human identity record.
- Verifiable credentials connect explicit issuers, holders, and verifiers without making claims automatically trustworthy.
- Personal credentials usually should not be published directly on a public blockchain.
- Selective disclosure and context-specific identifiers can reduce unnecessary exposure and correlation.
- Recovery, migration, expiration, revocation, and appeals are essential identity product flows.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.