What Is DID (Decentralized Identifier)?

Netsujo Inc. · Published: April 7, 2026Last updated: October 18, 2026

DID (Decentralized Identifier) is a W3C-standard identifier for subjects such as people, organizations and devices. Control and resolution depend on the DID method; a blockchain is not required. DIDs can support self-sovereign identity (SSI), but identity checks, recovery and availability require separate design. DID Core 1.0 became a W3C Recommendation on 19 July 2022. This guide explains why interest in DID is rising (data-breach costs, platform lock-in), what DID is compared with centralized IDs and federated (SSO) identity, and the three technical building blocks: the DID Document, Verifiable Credentials (VCs, used in a three-party Issuer/Holder/Verifier model), and DID methods. It covers four early-adopter use cases — digital certificates, supply-chain traceability, self-sovereign health data, and community currency or membership credentials — the technology stack needed to build a DID system, a comparison of six DID methods (did:key, did:web, did:ion, did:ethr, did:polygonid, did:jwk), typical PoC-to-production cost and duration ranges, and the practical issues to resolve before going live: legal alignment, private-key loss and revocation design, and user experience.

DID and VC: standards and enterprise acceptance (October 2026)

A DID identifies a subject, such as a person, organization or device. A Verifiable Credential records claims made by an issuer. VCs do not require DIDs. W3C DID Core 1.0 has been a Recommendation since July 19, 2022, and W3C VC Data Model 2.0 became a Recommendation on May 15, 2025. Signature verification does not by itself prove that a claim is true, legally accepted or bound to the intended person.

• Issuer trust and acceptance: identify which issuers and proofs verifiers accept before choosing a wallet or DID method.
• Revocation and recovery: test expiry, revocation, key loss and the distinction between regaining control of a DID and reissuing a credential.
• Minimum enterprise PoC: exercise issuance, storage, presentation, validation and revocation with real systems, and compare support and maintenance costs against existing SSO or a shared database.
• AI agents: identifying an agent or its operator does not authorize every action. Delegated scope, expiry, revocation, audit and accountability require separate controls.

Why interest in DID is rising

IBM's Cost of a Data Breach Report 2025 puts the global average cost of a single data breach at USD 4.44 million, and USD 10.22 million in the United States (checked 2026-07-11) — credential-acceptance workflows and conventional authentication require their own security controls; adopting DID does not automatically prevent credential theft. Platform dependency compounds the risk: with centralized identity, account management, API terms, and usage policy all sit with the platform, so both the service operator and the user carry the risk of an outside decision disrupting the service. The EU's eIDAS 2.0 regulation, in force since May 2024, requires member states to offer an EU digital identity wallet by the end of 2026, and in Japan the Cabinet Secretariat and Digital Agency's "Trusted Web" initiative has run DID/VC use-case trials, including an expert panel on VC governance in 2025 (checked 2026-07-11).

What DID is

Centralized ID

An ID and password managed per service, with the platform holding the data — the user bears the risk of a breach, deletion, or service shutdown.

Federated identity (SSO)

Authentication delegated to a provider such as Google or Apple. Convenient, but dependency on the provider increases — losing the account can lock a user out of every linked service.

DID (Decentralized Identifier)

A W3C-standard identifier, expressed as a did:method:identifier URI. Methods define control, resolution and updates; distributed ledgers are not required. DIDs can reduce dependence on a particular service, but dependencies on keys, domains, ledgers or operators must be checked. A company or server outage is not automatically harmless. W3C published DID Core as a Recommendation in July 2022.

How DID works: three building blocks

• DID Document — verification methods and service endpoints associated with a DID. Retrieval, generation and updates depend on the method; storage on a blockchain or distributed storage is not required. Design visibility and handling of personal information separately.
• Verifiable Credentials (VC) — a W3C data model for issuer claims presented by a Holder and checked by a Verifier using a supported proof mechanism. A DID is optional. Detecting tampering does not establish truth or business acceptance; direct contact with the issuer depends on status-checking and other dependencies.
• DID methods — the protocol specification for creating, resolving, updating, and revoking a DID. Over 100 methods are registered (e.g. did:ethr on Ethereum, did:ion on Bitcoin Layer 2, did:key using a local key pair only), chosen according to use case, regulation, and infrastructure requirements.

Netsujo is co-researching and developing DID/VC-based profile-disclosure management with Proof of Your Life Inc., and supports companies and local governments in structuring DID adoption plans and technical evaluation.

Four use cases

Digital certificates and credentials

Diplomas, professional qualifications and training credentials presented to schools or employers. In addition to proof checks, agree on accepted issuers, validity, revocation status and binding to the person. Whether this reduces enquiries or cost depends on status-checking arrangements and comparison with existing work.

Supply-chain and origin traceability

Issuer proofs attached to records of materials, manufacturing or transport can support tracing origin and certification information. Detecting tampering and establishing the correctness of real-world inputs are separate; a DID or signature does not guarantee product quality or the truth of certification claims.

Self-sovereign health data

Present necessary medical or qualification information as VCs. Separately design storage, access rights, disclosure mechanisms and emergency procedures. Selective disclosure requires a supported mechanism; adopting DIDs or VCs does not establish compliance with personal-information rules.

Community currency and digital membership

DIDs used for membership or points in local governments, shopping districts or communities. Agree on issuance, acceptance, revocation and necessary infrastructure; smart contracts do not remove the need to sustain operations and costs. Netsujo's own product Cycle uses this model.

Five possible future uses and their conditions

These are examples for considering future use, not established adoption results or guaranteed benefits. Use them to decide who issues, accepts and supports credentials.

Turn adoption challenges into operational checks

Selecting technology does not complete adoption. Agree on responsibilities and test a small scope, including failure handling.

Formats and interoperability

Responsible parties: Issuer, wallet and verifier. Agree on credential and proof formats, DID methods, exchange procedures, accepted issuers and status checking; test issuance through presentation using the actual combination. Sharing a standard name is not evidence of compatibility.

Recovery and reissuance

Responsible parties: DID controller, issuer and support. Distinguish recovery of DID control, VC reissuance and VC revocation. Decide who verifies the person and handles old keys or credentials after loss or compromise; exercise the recovery procedure.

Status, connectivity and capacity

Responsible parties: Verifier and operations. Define acceptable validity and status-information freshness. Offline signature verification does not necessarily reveal current revocation status. Check schema and other dependencies, dependency outages and capacity in the chosen deployment.

UX and assisted access

Responsible parties: Service and support teams. Check whether representative users can obtain, store, present and recover credentials. Explain recipients and disclosures, support accessibility, and provide alternatives or in-person help for people facing device or usability barriers.

Participants and governance

Responsible parties: Issuers, verifiers and policy owners. Agree on issuance grounds, acceptance criteria, corrections, disputes and responsibilities. Review relevant public or industry rules and existing identity operations; standards conformance alone does not establish legal compliance.

Cost and sustainability

Responsible parties: Business owners and participating organizations. Identify who pays for issuance, verification, support and updates, and whose work improves. Compare existing IDs, SSO or shared databases; do not hide costs behind assumed user growth or future revenue.

Progress by acceptance criteria, not calendar predictions

• Limit the business scope: agree on required credentials, accepting parties, coexistence with existing IDs, storage and who pays.
• Test the actual combination: check issuance, presentation and verification, plus expiry, revocation, key loss, connectivity failures and user assistance.
• Expand within operational capacity: confirm acceptance, correction and support owners, costs and relevant rules. Revise scope or architecture where conditions are unmet.

Japan’s Digital Agency is examining VC and digital identity wallet governance, risks and interoperability. The European Commission describes member-state wallet availability as planned by the end of 2026. These are institutional initiatives and schedules, not evidence that every use case is already operating or that DIDs are mandatory (checked 8 September 2026).

Five questions about future use

Can I recover everything if I lose my phone?

Recovery is not automatic. Recovering DID control and reissuing a VC are different processes and depend on the chosen method and operator. Check identity verification, handling of old credentials, recovery destinations and support before use.

Can everyone, including older people and children, use it?

Test the intended users instead of assuming simplicity. Design authority for representatives or assistants, understandable disclosure explanations, and alternatives for people without a suitable device.

Do DIDs and VCs guarantee security and minimal disclosure?

Identifiers and signatures do not complete security or privacy. Alongside device, key and issuer management, check minimal-attribute issuance or selective-disclosure mechanisms, correlation of presentations, and storage.

Will existing public or workplace IDs become unnecessary?

There is no universal replacement. Coexist with existing identity checks or workplace IDs and decide who accepts which credentials. Standards support and institutional or business acceptance are separate.

Can this eliminate fake accounts and misuse?

A DID alone does not establish human existence or legitimate behavior. Check trusted issuers, subject binding, validity, status, authority and purpose; provide cancellation, correction and support procedures.

Sources and interpretation

DID Core informs the ledger and recovery boundaries; the VC Data Model informs verification, trust, status and privacy. The scenarios, responsibilities and acceptance steps above are Netsujo’s editorial interpretation of these sources, not measured customer outcomes or adoption rates.

W3C DID Core

W3C Verifiable Credentials Data Model 2.0

Digital Agency: Trust（日本語）

European Commission: European Digital Identity

Choosing a DID method

Cost and duration by stage

Points to check before adopting DID

• Legal and regulatory alignment — confirm fit with applicable regulation (e.g. Japan's Act on the Protection of Personal Information, KYC-related law) and existing standards before production rollout.
• Private-key loss and revocation design — decide upfront between social recovery (distributed among trusted parties), HSM-backed backup, or a custodial design, and design revocation alongside VC issuance, not after the fact.
• Simplifying user experience — hide key management from the user and reduce visible actions to something like "add a credential" and "disclose it"; for enterprise use, bridging to an existing internal IdP (SAML/OIDC) is often the practical route.