What Is DID (Decentralized Identifier)?
Netsujo Inc. · Published April 7, 2026 · Updated July 12, 2026
DID (Decentralized Identifier) is a W3C-standardized identifier format that a user controls directly, rather than handing it to a platform — the core technology behind what's called self-sovereign identity (SSI). 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.
Key takeaways
- DID (Decentralized Identifier) is a W3C-standardized identifier format that a user controls directly, rather than a platform controlling it on their behalf.
- DIDs work together with Verifiable Credentials (VCs) in a three-party model: an Issuer signs and issues a credential, a Holder stores it in a wallet, and a Verifier checks the signature without contacting the Issuer.
- Four early-adopter use cases: digital certificates and qualifications, supply-chain/origin traceability, self-sovereign health data, and community-currency or membership credentials.
- DID method choice (did:key, did:web, did:ion, did:ethr, did:polygonid, did:jwk) depends on the use case, who operates it, and revocation requirements.
- PoC-stage verification can start from roughly a few hundred thousand yen using a lightweight method like did:key; full production deployments with recovery design and external-system integration can run into the tens of millions of yen, depending on scope.
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) — authentication models built on ID-and-password combinations remain a persistent single point of failure. 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 format, expressed as a did:method:identifier URI (e.g. did:ethr:0x1234...abcd). The identifier is registered on a blockchain or other distributed ledger, and the user — not a platform — controls it. Its validity does not depend on any single company or server staying online. W3C published the DID specification as a Recommendation in July 2022.
How DID works: three building blocks
- DID Document — the metadata attached to a DID: public keys, authentication methods, and service endpoints, stored on a blockchain or distributed storage as a publicly readable JSON document.
- Verifiable Credentials (VC) — the W3C standard for a verifiable claim of attributes or qualifications, issued and signed by an Issuer, held in a wallet by a Holder, and checked by a Verifier without needing to contact the Issuer directly.
- 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
- University diplomas, professional qualifications, and training certificates issued as VCs, removing the need to contact the issuing body every time the credential is presented for a job change, admission, or loan application. Verification is a signature check, dramatically cutting verification cost.
- Supply-chain and origin traceability
- Each step — raw materials, manufacturing, transport — is signed with a DID, building tamper-resistant traceability. This is being adopted for fair-trade and organic certification, and for carbon-footprint documentation where ESG-document credibility matters.
- Self-sovereign health data
- Patients hold their own medical records, medication history, and test results as VCs, disclosing only the specific information needed to a clinic or insurer — implementing data minimization at the architecture level, in line with the GDPR and Japan's Act on the Protection of Personal Information.
- Community currency and digital membership
- DID-based membership or point credentials issued by a local government, shopping district, or community, without a central management server, combined with smart contracts to support a self-sustaining local economy. Netsujo's own product Cycle uses this model.
Choosing a DID method
| Method | Backing store | Persistence | Revocation | Best fit |
|---|---|---|---|---|
| did:key | The key itself | None (key = ID) | Not possible (key rotation only) | PoC / short-term trials |
| did:web | DNS + HTTPS | For as long as the domain is held | Possible via JSON update | An organization running its own official identity |
| did:ion | Bitcoin + IPFS | Effectively permanent (on-chain) | On-chain update | Public credentials needing long-term tamper resistance |
| did:ethr | Ethereum | While the chain is maintained | Via smart contract | Web3-ecosystem integration |
| did:polygonid | Polygon ID | While the chain is maintained | Zero-knowledge proof + state tree | Privacy-focused VC verification |
| did:jwk | JWK (JSON Web Key) | For as long as the key is retained | Key rotation | Integrating with an existing JWT/OIDC stack |
Cost and duration by stage
| Stage | Typical duration | Typical cost | Main scope |
|---|---|---|---|
| Technical-verification PoC | 2–4 weeks | From several hundred thousand yen | Confirm issuance/verification flow feasibility using e.g. did:key |
| Small-scale production | 2–4 months | From several million yen | Single-organization issued credentials/membership, e.g. via did:web |
| Full deployment | 6+ months | Up to the tens of millions of yen | Includes revocation/recovery design and KYC or external-system integration |
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.
We take on enquiries about DID use cases, method selection, and regulatory fit before requirements are finalized.
Discuss DID adoption