Skip to content
Financial Context Wiki

Decentralized identity (DID)

A practical guide to decentralized identifiers and verifiable credentials: what they prove, how issuance and presentation work, and where trust, privacy, and recovery risks remain.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

Decentralized identity is an architecture in which a subject can use identifiers and cryptographically protected credentials across services without making one platform account the universal source of identity. The common building blocks are decentralized identifiers (DIDs), verifiable credentials (VCs), holder software such as a wallet, and rules that tell verifiers which issuers, evidence, and assurance levels to accept.

A DID is a URI such as did:example:123. Its DID method defines how the identifier is created, resolved, updated, and deactivated. Resolution can return a DID document containing verification methods, relationships such as authentication or assertionMethod, and optional service endpoints. Controlling the corresponding key can prove control of the DID under that method; it does not by itself prove a legal name, age, uniqueness, employment, or ownership of an external account.

A verifiable credential carries claims made by an issuer about one or more subjects. A holder stores the credential and can create a verifiable presentation for a verifier. A successful cryptographic check establishes the integrity and authorship of the secured data under the selected proof mechanism. The verifier must separately decide whether it trusts the issuer, whether the claims satisfy its policy, whether the credential is current, and whether the presenter is entitled to use it.

“Decentralized” therefore does not mean trustless, anonymous, blockchain-based, or free of intermediaries. It means that identifiers, credentials, registries, wallets, and verification policies can be separated so that no single login provider must observe and control every relationship. A design is only as decentralized as its actual issuers, DID-method operators, status services, wallet vendors, recovery administrators, governance keys, and verifier policies.

How it works

  1. Define the claim and trust framework. Specify the subject, requested attributes, acceptable issuers, proofing process, assurance level, retention policy, jurisdiction, and redress path. A cryptographic format cannot decide whether a university, government, employer, or community is an appropriate authority.
  2. Create or obtain identifiers and keys. An issuer and holder may use DIDs, HTTPS URLs, or other supported identifiers. If a DID is used, its method determines the registry and lifecycle rules. The controller protects the private key; the resolved document exposes only the verification material and endpoints required by the use case.
  3. Proof and bind the subject. The issuer checks evidence according to policy, then binds the resulting claims to a credential subject. Binding can refer to a holder-controlled key, an account, or another identifier. The issuer must distinguish evidence about a person from evidence that the current presenter controls a key.
  4. Issue the credential. The issuer creates claims, validity dates, schema or type information, and any status reference, then secures the credential with a supported proof. In Data Integrity credentials, fields such as cryptosuite, verificationMethod, proofPurpose, and proofValue identify how the proof is verified.
  5. Store and select. The holder keeps the credential in local or hosted wallet software. A wallet should explain what the verifier requested, disclose only necessary data where the credential format allows it, and avoid silently reusing a stable identifier across unrelated contexts.
  6. Present with freshness and audience binding. The verifier sends a request with its identity, purpose, nonce or challenge, and expiry. The holder returns the credential or a derived presentation bound to that request. Domain and challenge checks help prevent a captured presentation from being replayed to another verifier or session.
  7. Verify cryptography and policy. Resolve the issuer’s verification material from an authenticated source; validate the proof suite, purpose, challenge, domain, dates, schema, and status; then apply business rules. A result such as verified: true is an input to authorization, not an instruction to grant access.
  8. Operate the lifecycle. Rotate compromised keys, suspend or revoke credentials, update status data, provide recovery and appeals, preserve required audit evidence, and publish migration or shutdown plans. Historical verification requires clear rules for old keys, old documents, and the time at which a credential was presented.

The three main roles are issuer, holder, and verifier; the credential subject can be different from the holder. For example, a parent might hold a credential about a child, or a company agent might present a credential about an organization. Implementations must not infer that the presenter is the subject unless the credential and protocol establish that binding.

DIDs and VCs are independent. A VC can use a non-DID issuer identifier, and a DID can be used without any VC. Likewise, a DID method may use a blockchain, distributed database, web domain, or peer-to-peer exchange. The method’s security and governance properties must be evaluated directly instead of being inferred from the did: prefix.

Worked example

Suppose a service must confirm that a customer is at least 18 without collecting a birth date. An accepted authority proof-checks the customer and issues an age credential to a wallet. The credential might contain the birth date, or it might contain only an ageOver18 claim; those choices create different disclosure and reuse properties.

At sign-up, the service requests an age-over-18 presentation for merchant.example, challenge n-7f3a, and a 5-minute validity window. The wallet shows the request and, if the credential and proof suite support it, derives a presentation that reveals only the required predicate. The service checks the authority’s verification method, proof, challenge, domain, time window, and credential status before recording the minimum result needed for its audit policy.

This flow reduces the service’s need to retain document images or full birth dates, but it does not eliminate trust or risk. The authority might enroll the wrong person; the wallet or device might be compromised; a stable subject identifier or status request might correlate uses; the service might ask for excessive data; and an incorrect suspension could deny access. Selective disclosure narrows the data shown in the presentation, not all metadata visible to issuers, wallets, networks, and verifiers.

Key rotation illustrates another boundary. If the issuer replaces a compromised key, new credentials should use the new verification method. Whether an old credential remains verifiable depends on the DID method’s history, the proof’s creation time, the verifier’s policy, and the credential’s status. Simply deleting the old key from the current DID document can make legitimate historical checks fail or can hide which key was authorized when the proof was created.

Risks and controls

  • False or overbroad claims: A valid signature preserves what the issuer said; it does not make the claim accurate. Define evidence requirements, issuer liability, assurance levels, audits, expiry, and correction procedures.
  • Weak holder binding: A copied credential might be usable by someone else if the presentation does not prove control of an intended key or authenticator. Bind proof-of-possession to the verifier, challenge, purpose, and session where appropriate.
  • Key and wallet compromise: Malware, phishing, cloud-wallet takeover, or insecure backups can expose credentials and signing keys. Use phishing-resistant authentication, hardware-backed protection where justified, compromise reporting, and narrowly scoped recovery.
  • Recovery centralization: A single recovery administrator can become the real identity controller. Document who can replace keys, what evidence is required, how abuse is detected, and how users appeal or migrate.
  • Correlation: Reusing one DID, verification method, signature pattern, service endpoint, or status-query path can link activity across services. Use pairwise identifiers, domain-separated keys or proofs, privacy-preserving status mechanisms, and metadata testing.
  • Public personal data: DID documents and ledger history can be publicly indexed and difficult to erase. Keep names, document numbers, biometrics, and other personal claims out of public DID documents and immutable registries.
  • Status privacy and availability: A verifier contacting an issuer for every status check can reveal where a credential is used; an outage can block valid users. Prefer privacy-preserving, cacheable status designs with freshness limits, authenticated updates, and defined fail-open or fail-closed behavior.
  • Revocation abuse: An issuer or administrator can censor holders by suspending credentials or changing status data. Limit authority, log changes, expose reason and appeal processes, and support replacement or alternative issuers where possible.
  • Resolution and method risk: A resolver can return stale or malicious DID documents, while a DID method can depend on centralized infrastructure or mutable governance. Authenticate resolution results and assess finality, update authorization, availability, governance, and versioning for each method.
  • Semantic mismatch: Two systems can parse the same fields yet interpret a claim, unit, jurisdiction, or assurance level differently. Use stable schemas and vocabularies, validate context and type, and version policy semantics.
  • Replay and confused verifier attacks: A presentation not bound to a nonce, audience, domain, action, and expiry can be reused or redirected. Validate every binding required by the presentation protocol.
  • Excessive disclosure: A wallet can technically support selective disclosure while a verifier still demands the full credential. Enforce data minimization in policy and interface design, record purpose, and prevent optional fields from becoming mandatory by habit.
  • Ecosystem lock-in: Proprietary wallets, proof formats, registries, or recovery processes can make credentials nonportable. Test standards conformance, export, multi-wallet use, cryptographic agility, and migration before deployment.
  • Governance capture: A multisignature or ledger does not guarantee broad control if one vendor chooses issuers, software updates, schemas, and status rules. Map operational authority component by component and publish change controls.

Common misconceptions

  • “A DID proves who a person is.” A DID identifies a subject and can expose verification methods; identity attributes require additional claims, evidence, and trust decisions.
  • “A valid credential means the claim is true.” Verification shows that protected data has the expected proof and has not been altered. It does not validate the issuer’s original investigation or judgment.
  • “The holder is always the credential subject.” The roles can differ, so the verifier needs an explicit subject-to-presenter binding when the use case requires one.
  • “Everything belongs on-chain.” Public immutable storage magnifies privacy, correlation, deletion, and governance risks. Many systems keep credentials off-chain and publish only necessary verification or status material.
  • “Selective disclosure guarantees anonymity.” Revealed attributes, stable identifiers, proof fingerprints, status lookups, timing, IP addresses, and issuer logs can still correlate presentations.
  • “Decentralized means no trusted issuer or administrator.” Trust is distributed and made explicit, not removed. Issuance, proofing, wallet distribution, recovery, status, and verifier acceptance remain governed processes.
  • “One DID equals one human.” A person can control many DIDs, and a DID can identify an organization, device, dataset, role, or other subject. Uniqueness and personhood require separate mechanisms.
  • “A wallet signature is sufficient authentication.” It proves control of a key under specified conditions. The application still needs phishing resistance, freshness, audience binding, authorization, and account-recovery rules.

Sources

Navigation

Search the wiki...