The form has been successfully submitted.
Please find further information in your mailbox.
Hire usSelect language
About us
TechnologiesIndustriesPortfolio
You’ve probably seen it yourself: feed GPT a selfie, ask for a passport-style document, and within minutes, you get something that can get past basic visual checks. Add voice cloning and synthetic video, and “liveness” starts to look like theater. That’s the real break in digital identity in 2026. The photo-based KYC model itself is wearing out. If identity proof still depends on images being hard to fake, you’re building on sand.
So where does that leave us? With a pretty obvious shift: away from storing identity data and toward verifying claims cryptographically. Instead of collecting a passport scan and parking it in another database, the system asks for proof: are you over 18, have you passed KYC, are you cleared for this transaction, and can you prove it without revealing anything else?
But what changes exactly? Why are we suddenly talking about DIDs and verifiable credentials?
Because in a DID-based model, trust doesn’t come from what something looks like. It comes from who signed it and whether you can prove control over it. A deepfake selfie doesn’t help if the verifier expects a credential signed by a trusted issuer and bound to your cryptographic keys. You’re no longer trying to “look real.” You’re proving possession of a valid, signed claim. Images stop being the source of trust. Signatures take over.
And that’s the point of this guide: I’ll show how that model works, why it’s becoming the serious path forward, and where blockchain fits into it.
A decentralized identifier, or DID, is a URI-based identifier designed to be controlled through cryptographic keys rather than issued and managed by a central directory. Under the World Wide Web Consortium (W3C) DID standard, a DID resolves to a DID document that informs other systems on how to verify signatures, authenticate the controller, or discover service endpoints associated with that identifier. In plain English: a DID is not your profile, your passport, or your account record. It’s the pointer other parties use to verify that you control a specific identifier and the keys behind it.
This is where people often flatten everything into “just another ID.” It’s not.
An email address is really a locator inside someone else’s system. If the provider suspends the account, the identifier is effectively gone. An SSN is a state-issued identifier, but it has no built-in cryptographic proof layer; anyone who gets the number can replay it. OAuth tokens are different again: they’re not identity identifiers at all, but delegated access artifacts issued by an authorization server so a client can call a protected resource. Useful, yes. Portable identity layer, no.
A DID works differently. It is meant to be resolved, not merely looked up in a vendor database. Control sits with the subject through key material and the rules of the DID method, not with a mail provider, SaaS platform, or identity broker. That distinction matters in practice. If you’re building reusable credentials, wallet-based login, or verifier flows that should work across organizational boundaries, an email or app-specific user ID won’t carry enough trust semantics. A DID can.
At the syntax level, the W3C model is simple: a DID has three parts: the DID scheme, a method name, and a method-specific identifier. In other words: did:method:identifier.
Take did:web:example.com as a concrete example.
With did:web, resolution typically maps to a DID document published at a well-known HTTPS location on that domain. With something like did:ethr, resolution depends on Ethereum-linked method rules. Same DID syntax, different trust and update model.
That’s the key point: the DID string itself is only the handle. The method tells you how to resolve it. The DID document gives you the verification material. Once you get that, you can verify signatures, authenticate a holder, or validate a credential presentation without treating the identifier as just another row in somebody’s user table.
Up to this point, we’ve looked at DIDs and verifiable credentials as data structures: identifiers, documents, signatures. But that’s only part of a working identity system. In real deployments, the harder problem is interaction: how credentials are issued, how they’re presented, and how verifiers decide whether to trust them.
In production systems like the EU Digital Identity Wallet or US mobile driver’s license (mDL) pilots, wallets and verifiers don’t just “resolve a DID” and stop there. They communicate through defined protocols and credential formats:
The important distinction is that DIDs and verifiable credentials define what is being verified. These protocols define how it moves between the issuer, holder, and verifier in real systems.
Without this layer, DIDs remain a resolution mechanism. With it, they become part of a working identity infrastructure.
If we strip it down, decentralized identity is a model where identifiers, credentials, and verification flows are not controlled by a single provider. Instead, identity is anchored in cryptographic keys (via DIDs), and claims about that identity are issued and verified independently of where they’re used. A useful way to think about it: identity stops being an account stored in someone else’s database and becomes a set of verifiable statements you control and reuse.
Let’s break that down against the models you’re already working with.
Centralized identity is still the default everywhere. A platform owns the user record, stores your data, and acts as the authority for verification. If you want access, you authenticate against that system. Everything, including login, permissions, recovery, flows through it.
The problem isn’t just security (though breaches are a constant issue). It’s architecture:
Decentralized identity flips this. The system doesn’t need to store your data. It only needs to verify the claims you present. The trust shifts from “we have your data” to “we can verify this cryptographic proof.”
Federated identity (OAuth, SAML, OpenID Connect) tried to solve fragmentation by introducing identity providers, such as Google, Microsoft, or Apple, that vouch for users across services.
It works, up to a point. But federated identity still has a central dependency:
Decentralized identity removes that dependency. There’s no single issuer that must be online at the time of verification. Credentials are verified via signatures, not API calls. That means:
It’s closer to how physical credentials work: you don’t call the passport office every time someone checks your ID.
These terms get mixed up a lot. SSI is more of a design philosophy: the individual controls their identity, chooses what to share, and isn’t locked into a provider. Decentralized identity is the technical stack that makes that possible:
You can implement decentralized identity systems that aren’t fully “self-sovereign” (for example, enterprise-controlled wallets or permissioned networks). And you can talk about SSI without specifying the infrastructure. In real systems, the two usually converge, but it’s useful to keep the distinction clear when you’re designing architectures.
Wallets are where decentralized identity meets real-world constraints. In theory, control over identity comes from controlling cryptographic keys. In practice, that creates a problem traditional systems don’t have: what happens when the user loses access?
If a DID is tied to a private key and that key is lost, there is no default recovery mechanism. There’s no “reset password” flow unless the system is explicitly designed to support it. Loss of the key can mean loss of control over the identifier and the credentials bound to it.
That’s why production systems introduce recovery and custody models on top of the DID layer:
The trade-off is unavoidable: the more control shifts to the user, the more responsibility shifts to key management. That’s why most real-world deployments balance self-sovereignty with usability instead of pushing full key ownership entirely onto the user.
It’s worth pausing here, because DID-based identity only really clicks once you separate its core primitives. The identifier is not the credential, the credential is not the wallet, and the on-chain marker is not the identity itself. Each layer has a distinct function, and that separation is what makes the model work.
These two components form the core of the decentralized identity model. In some systems, especially in Web3 environments, additional on-chain mechanisms are used to enforce access or roles.
Soulbound tokens (SBTs) are one example. They are non-transferable tokens tied to a wallet and used for things like KYC gating, accreditation, or protocol permissions. Smart contracts can check them directly.
However, SBTs are not part of the identity stack itself. They are an optional enforcement layer built on top of identity signals, and they come with trade-offs: public visibility on-chain, limited portability, and challenges around revocation and key recovery.
Traditional identity systems fail because they treat trust as a storage problem. Every platform collects the same raw evidence, such as passport scans, selfies, and proof of address, then stores it inside its own compliance perimeter. That creates the same mess everywhere: duplicated PII, weak portability, broad breach surfaces, and onboarding flows that get heavier without getting much better.
In the traditional model, identity systems accumulate risk over time. KYC vendors, exchanges, fintech apps, HR platforms, and marketplaces all end up storing roughly the same evidence set: government ID, face scan, address data, and metadata from the verification session itself.
From an implementation standpoint, the problem usually gets compounded by copy proliferation. The same user data ends up in onboarding systems, fraud tools, CRM layers, support tools, data warehouses, and compliance archives. Even if the primary verification stack is locked down, the surrounding systems often aren’t held to the same standard.
Traditional identity gives the user almost no control over the verification state. The platform controls the record, the retention policy, the re-verification schedule, and the rules for reuse.
That means the user can’t carry trust from one context to another. Passing KYC at Platform A does nothing at Platform B because the verification result is trapped inside Platform A’s compliance perimeter. The underlying claim may still be valid, but there is no portable cryptographic artifact that the next verifier can rely on.
This is where the model starts to break economically. Every platform pays to rebuild trust from scratch because identity is stored as internal data, not issued as reusable proof.
The legacy model also reveals too much by default. To prove a narrow fact, users are usually asked to disclose the full source document behind it.
That is a bad privacy pattern, but it is also a bad systems pattern. Once identity is tied to account-based records and repeated document submission, correlation becomes easy across services, sessions, and counterparties. The verifier gets more data than it needs, stores more than it should, and increases liability without improving trust quality proportionally.
This is the operational tax everyone already knows. The same person completes KYC over and over because each platform runs its own trust stack and can’t consume verification as a portable credential.
If you’ve worked on tokenization, exchange onboarding, or regulated wallet flows, you’ve seen how wasteful this gets. The bottleneck is the fact that trust can’t move cleanly between systems, so every institution rebuilds the same verification pipeline around its own database boundary.
And even verifiable credentials don’t fix that by themselves. A valid signature only proves that a claim was issued by a specific party. It does not prove that this party had the authority to issue that claim. That is the part that many DID pilots underestimate. Verifiers need to know which issuers are legitimate, which credential schemas are accepted, and under which rules a claim can be relied on.
In production, this is handled through trust frameworks: eIDAS 2.0 trust lists in the EU, VICAL-style trust coordination for mobile driver’s licenses under ISO 18013-5, OpenID Federation trust chains, and national trust service provider registries.
Without that layer, you don’t get reusable identity. You get credentials that verify mathematically but mean nothing operationally. The signature is valid. The trust is missing.
“Why does the decentralized identity model work? Because it gives each party less to store, less to expose, and less to re-check. The user reuses trusted proof, the verifier gets only the claim it needs, and the platform avoids becoming another PII vault. At Innowise, that usually means off-chain credentials for portability, on-chain attestations for access control, and selective disclosure for privacy-sensitive checks.”
Blockchain Expert & DeFi Analyst
Enough with definitions. What matters here is the verification path: how a DID becomes resolvable, how an issuer binds a claim to it, and how that claim is checked later without falling back to a central registry. Let’s walk through the flow end to end.
A DID only becomes useful once it can be resolved. It is generated with key material and published according to a DID method. Resolution returns the DID document, which exposes the public keys and verification methods others use to validate signatures.
Once the subject has a DID, an issuer can attach a signed claim to it as a verifiable credential. The issuer runs its checks first, then signs a credential that binds the claim to the subject identifier. What moves forward is not raw evidence, but an attested result.
The holder stores the credential, usually in a wallet, and presents it when proof is needed. Depending on the stack, that can be the full credential or a derived proof. The point is reuse: the holder presents an already verified claim instead of restarting onboarding.
The verifier checks the issuer’s signature, confirms the subject binding, and evaluates credential status, such as expiry or revocation. To do that, it resolves the issuer’s DID and retrieves the public key from the DID document. No issuer callback is required.
A DID only becomes useful once it can be resolved. It is generated with key material and published according to a DID method. Resolution returns the DID document, which exposes the public keys and verification methods others use to validate signatures.
Once the subject has a DID, an issuer can attach a signed claim to it as a verifiable credential. The issuer runs its checks first, then signs a credential that binds the claim to the subject identifier. What moves forward is not raw evidence, but an attested result.
The holder stores the credential, usually in a wallet, and presents it when proof is needed. Depending on the stack, that can be the full credential or a derived proof. The point is reuse: the holder presents an already verified claim instead of restarting onboarding.
The verifier checks the issuer’s signature, confirms the subject binding, and evaluates credential status, such as expiry or revocation. To do that, it resolves the issuer’s DID and retrieves the public key from the DID document. No issuer callback is required.
Once the flow is clear, the real design questions show up: how identifiers are used and how keys are managed over time.
A public DID is stable and discoverable. Issuers typically use it because verifiers need a consistent way to resolve keys and validate signatures. A pairwise DID, on the other hand, is generated per relationship. The same user presents different identifiers to different verifiers, which prevents cross-service correlation.
That choice is not cosmetic. Reusing a single DID across services makes linkage trivial. Pairwise DIDs break that linkage at the identifier level.
Then there is key management, which is where most systems struggle in production. A DID is only as reliable as the keys behind it, so you need to plan for:
In practice, this is where the complexity sits. Signature verification is straightforward. Keeping identifiers usable, recoverable, and non-correlatable over time is the harder engineering problem.
Once you move past the flow, the next question is how identifiers are actually resolved and maintained. That comes down to two things: the DID document structure and the DID method that defines how it is created, updated, and resolved.
A DID document is the resolution output of a DID. It tells verifiers which keys, controllers, and service endpoints are authorized for that identifier. In practice, it is not a user profile. It is a verification descriptor.
Core fields you usually care about:
And the key implementation point stays the same: a verifier resolves the DID, selects the appropriate verification method, and checks whether that key is authorized for the operation being performed.
So far, we’ve mostly talked about identity as something a person controls. In B2B systems, the key subject is often an organization. Banks, logistics providers, and RWA platforms need to verify not just who signed something, but whether that person was authorized to act for a company.
That is where organizational DIDs get more complex. Control is distributed across roles, custody systems, signing policies, and delegation rules. A production setup has to define who can sign, what they can sign, and how that authority is revoked.
In practice, this can involve vLEI from GLEIF for legal entity identity, corporate wallets with HSM-backed signing, and authorization capability chains such as ZCAP-LD.
DID documents are not static. Keys expire, devices get lost, signing infrastructure changes, and issuer keys need rotation. A serious DID design has to handle this without breaking existing credentials.
Key rotation usually means adding a new verification method, changing which key is authorized for a given relationship, and retiring the old key. But the detail that matters is purpose. Rotating an authentication key affects login or challenge-response flows. Rotating an assertionMethod key affects credential issuance and verification.
The update path depends on the DID method. With did:web, you update the hosted DID document. With did:ethr, you publish a transaction to the registry. The hard part is continuity: verifiers must know which key was valid when a credential was issued and whether that credential has since been revoked, expired, or superseded.
And that brings us to DID methods, because the method defines exactly how creation, resolution, updates, and deactivation work in the real system.
A DID method is the implementation layer behind the standard DID syntax.
It defines the rules for:
In other words, the DID syntax is standard (did:method:identifier), but the method shapes the whole infrastructure model behind the DID.
These three methods cover most real-world use cases:
Now the table gives you the mechanics. The harder part is deciding which failure mode you can live with: DNS dependence, chain cost, no rotation, public auditability, or weaker portability. So here’s my take on how to choose.
Before choosing, ask the ugly production questions:
In real deployments, you usually mix methods. Issuers often use did:web or did:ethr; holders use pairwise or ephemeral identifiers. That split keeps issuer trust stable while reducing correlation risk for users.
Let’s clear this up early: you don’t need a blockchain to implement decentralized identity. The World Wide Web Consortium DID Core spec doesn’t require it, and many production systems run entirely off-chain.
So why is blockchain even in the conversation? Because it solves one specific problem really well: shared trust without a central owner. Not storage, not identity itself, but coordination around keys, identifiers, and status.
In DID-based systems, blockchain acts as a public, tamper-resistant registry. Depending on the method, it can be used to:
The key point: the blockchain is not verifying identity. It is providing a common reference point that verifiers can rely on without trusting a single party.
For example, with did:ethr, the DID resolves against on-chain data. The verifier trusts the chain state, not the issuer’s infrastructure.
This is where many DID implementations go wrong. Blockchain is useful for shared state, but it is a terrible place for raw identity data. You do not put passports, biometrics, full credentials, or personal records on-chain. You use the chain for proof material and coordination data, then keep sensitive identity payloads off-chain.
A clean split usually looks like this:
On-chain:
Off-chain:
The reason is simple: privacy and cost. Blockchains are public, permanent, and costly to update. Identity data needs privacy, deletion, correction, and access control. Those two don’t mix.
Blockchain is usually used for anchoring, not storage. You commit a small proof of state to the chain, such as a DID document hash, issuer registry update, credential status reference, or key rotation event, while the actual identity data stays off-chain.
That gives verifiers three useful properties:
The trade-off is permanence. If you put the wrong data on-chain, you cannot cleanly remove it. That’s why mature DID systems anchor hashes, references, and state transitions, not full credentials, documents, or personal data.
Blockchain is the wrong tool when it doesn’t remove a trust dependency. If the same organization controls the issuer, verifier, and application, putting DID state on-chain usually just adds fees, latency, and operational noise.
Skip blockchain when:
That’s why did:web works so well for many enterprise identity flows. It keeps the DID model, but uses existing web infrastructure instead of forcing every update through a blockchain transaction.
Use blockchain when independent parties need a shared state that they can verify without trusting your server. Otherwise, keep it off-chain. More decentralization on paper does not automatically mean better identity architecture.
In systems like the EU Digital Identity Wallet or mobile driver’s licenses (ISO 18013-5), PKI was chosen largely because public L1/L2 networks don’t meet core identity requirements: privacy, data sovereignty, and regulatory control. Identity data can’t be publicly replicated, and jurisdictions need strict control over where data is processed and stored.
But newer architectures introduce a third option: permissioned zk-L2 systems. These combine:
The key idea is the separation of concerns at the infrastructure level:
This avoids a core limitation of public chains: data exposure. At the same time, it avoids a limitation of pure PKI: reliance on closed trust hierarchies without shared auditability.
Another important property is multi-domain architecture. Different actors — ministries, regulators, banks, or regions — can operate in separate execution zones with their own compliance boundaries, while still contributing to a shared verifiable state through proofs.
This expands the design space for identity systems. Instead of choosing between centralized PKI and public blockchain, new deployments can combine privacy, compliance, and shared trust in a single model.
Ok, so by now it should be clear what DIDs do differently from standard KYC. But the more practical question is: what does that actually change for me? Fair question. From what I’ve seen in real implementations, the impact depends a lot on which side you’re on, so it’s worth breaking it down.
For users, the biggest shift is control over when and how identity is shared.
In practice, this turns identity from something you constantly re-submit into something you present when needed.
For organizations, the shift is less about UX and more about risk and cost structure.
What changes operationally is this: you stop being a data custodian and start being a verifier of claims.
For developers, the value is in how identity logic is structured.
From an engineering standpoint, the shift is from “manage users and sessions” to verifying proofs and enforcing conditions.
Let’s drop the theory for a second and just walk through this like we would in a real system. What does DID actually feel like in practice? Where does it stop being a diagram and start being something you’d ship?
You’ll notice something as we go: the objects change — diploma, job history, KYC status — but the flow barely does.
Say you’ve just graduated and need to prove your degree to a future employer. The usual path is clumsy: upload a PDF, attach a scan, maybe wait while someone emails the registrar. It works, but barely. The whole process depends on manual trust.
With a DID-based credential, the university issues a verifiable credential when you graduate. It sits in your wallet, signed by a key published in the university’s DID document.
Months later, you apply for a job. The employer doesn’t need to contact the university. You present the credentials, and their system checks:
That’s the beauty of the model: the university signs once, you reuse the proof, and every verifier can check it independently.
How much of a CV do you actually trust? Titles get inflated. Dates get fuzzy. “Led a team” can mean anything from managing ten people to running standups.
Now flip the model. When you leave a company, they issue you a credential:
Next time someone asks, “Can you prove you’ve done X?” you don’t explain. You present. And no, that doesn’t mean exposing the whole work history every time. With the right credential format, the holder can prove a narrower claim, like:
…without handing over the full employment history. That’s a very different posture from “send us your entire CV and references.”
Here, reusable identity gets obvious. You verify once with a trusted provider: passport checked, sanctions screening passed, jurisdiction confirmed. The provider issues a KYC credential to your wallet.
Next platform? You present the credentials instead of uploading the same documents again. The platform checks:
Some tokenization teams also use soulbound tokens as on-chain KYC markers: this address passed the required check. The identity data stays off-chain; the chain carries only the eligibility signal.
Useful, but only if the marker is broad, revocable, and not a permanent privacy leak.
Healthcare is where DID architecture needs a short leash. Say a clinic gives you a vaccination credential, a lab signs your blood test result, and your doctor issues a prescription credential. You keep them in your wallet instead of letting each record disappear into another portal.
Then you change doctors. Do you wait for one system to talk to another? Chase PDFs? No. You share the specific credential the new provider needs. They verify the issuer, the signature, and the status.
And just to be clear: none of this requires putting medical data on-chain. The chain is for identifiers, keys, maybe status registries. The sensitive stuff stays off-chain. If that boundary isn’t respected, the design is broken.
Now let’s step away from people. Pick up a product — say, a bottle of olive oil. Premium label, nice packaging. Is it real? Instead of trusting branding, you tap your phone on an NFC tag. Behind that tag is a DID tied to the product batch.
What you get back is signed data:
You can literally follow the product from source to shelf. Does it solve everything? No. If the first data entry is wrong, everything after it just preserves the error. But at least now you know who signed each step. That’s a big upgrade from “trust us.”
Government is where DID-style identity leaves the crypto bubble. One major reference point is the EU Digital Identity Wallet under eIDAS 2.0, a large-scale initiative aiming to provide wallets to citizens, residents, and businesses across all Member States.
But the broader landscape is more diverse. Some of the largest and most mature digital identity systems globally are not strictly DID-based, yet follow similar patterns around reusable credentials and holder-controlled data:
The common shift across these systems is the same: moving from centralized identity records toward reusable, user-presented proofs. At the same time, it’s important to separate trust models. Systems like eIDAS rely on federated PKI and trust service lists, while DID-based systems rely on cryptographic identifiers and verifiable credentials. In practice, these models often coexist rather than replace each other.
So far, everything works nicely inside a single system. But what happens when credentials cross system boundaries? That’s where things get strict. You need shared standards so the data makes sense everywhere, and you need governance, so verifiers know which issuers to trust. Here are the standards and governance layers that matter most.
Standards make credentials interoperable. Governance makes them acceptable. Without standards, nothing parses. Without governance, nothing is trusted. Real systems only work when both layers are defined together.
Standards tell you how a DID system should behave. Production tells you where it gets messy. Today, most risks don’t come from DID syntax or signature algorithms themselves. They show up around wallets, key recovery, revocation, interoperability, and whether enough issuers and verifiers actually agree to use the same trust model.
In DID systems, identity depends on key control. That’s powerful, but unforgiving. If a user loses the key, recovery is not automatic. If an attacker gets the key, they can impersonate the holder. That’s why serious implementations rarely rely on a raw seed phrase alone. They usually need MPC, social recovery, hardware-backed keys, or some hybrid custody model.
Credentials age. KYC expires, employees leave, licenses get suspended. So verification cannot stop at “is the signature valid?” The verifier checks the credential status at the time of use. That usually means status lists, revocation registries, or short-lived credentials. Miss this part, and old credentials keep looking valid.
Standards help, but they don’t magically make every wallet, issuer, and verifier compatible. One stack may use JSON-LD credentials, another may prefer JWT. DID methods. Presentation protocols differ. So yes, the ecosystem is moving toward interoperability, but real projects still need integration work and strict profile choices.
The hardest part is coordination. A DID system needs issuers people trust, verifiers willing to accept credentials, users able to manage wallets, and governance rules everyone understands. Until those pieces line up, adoption happens in pockets: regulated finance, tokenization, workforce credentials, government ID, and closed ecosystems first.
Most DID systems today rely on elliptic curve cryptography: Ed25519, secp256k1, or P-256. These schemes are widely deployed, but they are not post-quantum secure. A sufficiently powerful quantum computer could break them with Shor’s algorithm, making signature forgery a real long-term risk.
That matters because identity credentials often live for years. Diplomas, licenses, and legal attestations issued today may still need to be verified long after the cryptography behind them ages out.
Standards are already moving in that direction. NIST has finalized post-quantum signature schemes such as ML-DSA (Dilithium) and SLH-DSA (SPHINCS+), while the DID/VC ecosystem is exploring hybrid signatures and crypto-agility.
DID systems should support multiple verification methods, new signature suites, and clear key rotation paths from day one. Post-quantum signatures are much larger than Ed25519 or ECDSA signatures, which affects QR presentations, registries, and on-chain status mechanisms. But for long-lived government and enterprise identity, crypto-agility is a must.
The mistake we see most often is treating DID as something you “add” to an existing identity stack. In practice, it’s a shift in how you model trust, data flow, and responsibility. The technical pieces are rarely the hardest part. Most projects succeed or fail on coordination, governance, and integration.
Start by identifying where you store identity data only to verify it later: KYC status, age, employment, licenses, accreditation, and access rights. The goal is to store less raw data and verify more signed claims. That reduces liability, simplifies compliance, and makes identity portable across systems.
Before choosing tools, define the trust model in concrete terms. In real projects, that typically results in:
Without this, you get credentials that verify correctly but are not accepted by verifiers.
Now choose the technical stack. Pick the DID method, credential format, wallet flow, and revocation model. did:web usually fits enterprise and SaaS flows. did:ethr fits smart contract enforcement and on-chain identity. did:key fits short-lived or local identifiers.
Don’t pick the most “decentralized” option. Pick the one that matches your trust boundary.
Don’t start with “identity for everything.” Start with one flow where the pain is clear. Good pilots include:
Scope it tightly: one credential type, one or two issuers, one verifier flow, clear revocation rules. Avoid starting with:
Prove the flow end-to-end, then expand.
Once you move from a pilot to production, issuing credentials is only half the problem. The harder question is what happens when a credential should no longer be trusted: a KYC check expires, an employee leaves, a license is suspended, or a wallet is compromised.
There is no single standard approach, and each model comes with trade-offs:
Different ecosystems take different approaches. For example, ISO 18013-5 mobile driver’s licenses rely on issuer validation and trust lists rather than W3C-style revocation. Without a clear revocation strategy, the “reusable credential” model breaks. A compromised credential can continue to be presented unless its status is actively checked.
A typical DID/VC project moves in phases. A pilot usually takes 3–4 months and validates one use case end-to-end, typically in the range of $150K–$300K, depending on scope. A production rollout takes 9–12 months and expands to multiple issuers, verifiers, and credential types, usually ranging from $800K to $2M+, depending on integration complexity and compliance requirements.
A typical team includes:
In practice, the complexity is rarely in cryptography. It’s in integration, governance, and user experience.
To wrap this up, let’s zoom out a bit. DID-based identity is not a finished stack. It’s still evolving, mostly around proof systems, wallet infrastructure, interoperability layers, and regulatory integration. From what I see in real implementations, a few directions are becoming clear.
Reusable identity is the obvious endgame, but the bottleneck is not signature verification. That part already works. The harder part is issuer trust, credential schemas, and acceptance rules.
In the future, a KYC credential issued in one regulated environment should be reusable across exchanges, tokenization platforms, lending products, and compliant DeFi interfaces, provided the issuer DID is resolvable, the schema is understood, and the verifier accepts the issuer under its trust framework. That’s where the real work is: not proving that a signature is valid, but agreeing on what the signed claim actually means.
Today, many systems still reveal attributes. The future is proving conditions. Instead of showing your date of birth, you prove you’re over 18. Instead of exposing full KYC data, you prove you passed a defined compliance policy. Instead of sharing a jurisdiction field, you prove eligibility for a transaction.
Technically, that points toward BBS+ signatures for selective disclosure and zk-SNARKs or zk-STARKs for predicate proofs. The verifier checks the proof against issuer-controlled public keys, while the underlying personal data stays hidden. That changes the privacy model from “share less data” to “don’t share the data at all when a proof is enough.”
Interoperability will decide whether decentralized identity stays fragmented or becomes usable infrastructure.
The weak spots are still familiar: JSON-LD vs JWT credentials, different DID methods, different wallet protocols, different presentation flows. That’s why production systems increasingly define strict profiles: approved credential formats, supported DID methods, trusted issuers, and accepted presentation protocols.
Over time, I expect more convergence around wallet-to-verifier flows, presentation exchange, and trust registries. Without that, every DID project becomes another identity island. With it, credentials can move across platforms without custom integration every time.
Regulation is turning decentralized identity from a technical option into public infrastructure.
In the EU, eIDAS 2.0 and the EU Digital Identity Wallet are the big signal. Member states are required to provide wallet infrastructure, with credentials for identity attributes, licenses, qualifications, and public-private sector use cases. That creates a regulated credential layer across Europe.
In the US, National Institute of Standards and Technology is updating digital identity guidance (e.g., NIST 800-63) to account for cryptographic credentials, assurance levels, and privacy-preserving verification. The US will likely keep a more market-driven model, while the EU pushes a coordinated wallet framework.
So where does this go? Toward fewer document uploads, more reusable credentials, more local cryptographic checks, and more selective disclosure. The winners won’t be the systems that store the most identity data. They’ll be the ones that can verify the right claim with the least exposure.
A decentralized identifier is a unique, resolvable identifier that points to a DID document containing public keys and verification methods. It allows entities to prove identity or control without relying on a central authority. In practice, it replaces database lookups with cryptographic verification.
A DID resolves to a DID document with public keys. An issuer signs a credential, a holder stores it, and a verifier checks the signature and status using the issuer’s DID. No direct call to the issuer is required. This makes verification portable and independent of any single system.
Decentralized identity is the overall model of issuing and verifying claims without central storage. A DID is just one component of that model. It acts as the identifier layer used to resolve keys and verify signatures. Without DIDs, the system would lack a consistent way to locate and trust verification material.
Not necessarily. Some DID methods use blockchains for resolution or anchoring, but many, like did:web, rely on standard web infrastructure. The DID itself is a reference, not a data record. What may be stored on-chain are keys, hashes, or status references, not identity data.
They are used to link identities to cryptographic keys, enable verifiable credentials, support reusable KYC, workforce verification, digital IDs, and access control in both web and blockchain-based systems. Their role is to make identity verification portable across systems.
You generate a key pair and create a DID according to a chosen method. Then you publish or register it so it can be resolved to a DID document. The exact process depends on the DID method (e.g., web, blockchain, or key-based). The method determines how the DID is anchored, updated, and resolved.
Blockchain Expert & DeFi Analyst
Andrew translates decentralized concepts into secure, functional financial tools. He navigates the volatile DeFi landscape to build scalable blockchain infrastructures that address real-world utility, moving past the buzzwords to deliver technical value.
