Workflow Debt Ledger: What Decentralized Identity Really Costs

Decentralized identity has a marketing problem. The pitch sounds great — you own your data, you carry your credentials, the verifier never sees more than the one fact they asked for. But then you sit down to integrate it, and the first question kills the momentum: what happens when the user loses their phone?

That's the hidden cost. Not the cryptography, not the blockchain debates, but the workflow debt — the dozens of small operational decisions you never planned for. This guide maps that debt, chapter by chapter, based on what actually breaks in production.

Where Decentralized Identity Actually Shows Up in Real Work

Onboarding and KYC: the first place teams try it

A bank's compliance officer hands you a QR code instead of a 27-page PDF. That's the moment decentralized identity stops being theory. The customer scans, approves a few claims from their wallet, and their employment history lands in your system without a single manual re-key. I have watched this exact scene work beautifully—for about six weeks. Then the renewal cycle hits, and someone realizes the verifiable credential expires while the customer's job title has changed. The workflow debt arrives before anyone mentions cryptography. Someone has to re-issue, re-verify, and re-explain to a confused user why their "permanent" digital ID suddenly needs a refresh.

The catch is that KYC was never a single event. It's a continuous obligation, and decentralized identity treats it like a one-time handshake. Banks love the frictionless demo. They forget the reconciliation layer underneath: which credentials map to which regulatory fields, who audits the issuers, and what happens when a credential is revoked mid-transaction. That integration doesn't fail at the wallet level—it fails at the workflow level.

Verifiable credentials in HR and education

Universities started issuing diplomas as verifiable credentials. Great idea, until an alum applies for a job and the hiring system expects a scanned PDF. The credential exists, it's cryptographically sound, but the applicant tracking system never learned to parse it. So the HR person downloads the credential, prints it, re-uploads it as an image, and the whole exercise becomes decoration. The workflow debt is not in the issuance—it's in the consumption side. Nobody, and I mean nobody, budgets for the months of connector development needed to make legacy systems read these things.

What usually breaks first is the verification callback. Your system needs to check the credential's status against the issuer's registry, but that registry lives behind a firewall that changes its API twice a year. You end up with a brittle integration that works in the demo environment and dies in production. The credential's cryptographic proof is perfect. The surrounding business process is held together with tape and scheduled jobs.

The wallet problem: user adoption or user friction?

Let's talk about the wallet. Every pilot I have seen stumbles on the same question: whose wallet, and why should the user care? A construction worker doesn't want to manage a digital identity wallet for a site-entry credential. They want to swipe a badge. The moment you ask them to install an app, create a PIN, and back up a recovery phrase, you have added fifteen minutes of friction to save the company two.

That sounds fine until you multiply it across a thousand workers. Adoption drops, support tickets spike, and the security team quietly builds a fallback that's just a database with a login. The decentralized part evaporates, but the workflow debt—the custom wallet code, the key recovery process, the user education—remains. This is the trap: you inherit the maintenance burden of decentralization while the actual user experience regresses to something worse than a centralized login.

Decentralized identity doesn't fail on the protocol. It fails on the Tuesday afternoon when a user loses their phone and no one knows how to recover.

— identity architect, post-mortem review

The integration trap: SSI inside a legacy stack

Most teams start by wrapping decentralized identity around an existing system. They keep the old database, add a DID resolver, and hope the pieces talk. The problem is that legacy systems assume a server-side identity model—session tokens, account IDs, access control lists. Self-sovereign identity flips that assumption. The user holds the keys, and your system must ask permission every time. In theory, that's empowering. In practice, your authentication middleware was never designed to make async calls to a user's wallet during every request.

The result is latency, timeout errors, and a support backlog of users who can't figure out why their login "sometimes hangs." Teams revert to centralized logins within a quarter, not because the technology is bad, but because the surrounding workflow was never redesigned. The ledger of debt grows with every exception handler, every fallback path, every "just cache the credential for now" shortcut. That's what the cost really looks like—not the token, but the layering of duct-tape decisions on top of a system that was bolted together, not built.

Foundations People Confuse: DIDs, VCs, and Claims

DIDs are identifiers, not credentials

The first mistake I watch teams make is treating a Decentralized Identifier like a password or a proof of anything. A DID is just a URL that points to a public key — a stable handle you control, not a statement about who you're. Think of it as the label on a folder, not the contents inside. The folder can hold bad documents. The label can be attached to someone you've never met. That distinction feels pedantic until someone builds an entire access-control system around "the user has a DID" and realizes it proves nothing about the user at all.

What usually breaks first is the habit of embedding identity claims directly into the DID document. Teams do this because it's easy — you've got a JSON file, why not stuff an email address in there? The catch is that DIDs are meant to be long-lived and portable. Once you attach a transient attribute like "employee at Acme" to the identifier itself, you've created a credential that can't expire without breaking the identifier. That's the over-engineering trap: you solve a short-term display problem by sabotaging the long-term architecture.

I have seen exactly this pattern in a supply-chain pilot. The team put a supplier's certification number inside the DID document, then had to rotate the DID when the cert lapsed. Every verifier holding a reference to the old DID broke simultaneously. Wrong layer. The identifier should stay dumb and stable; the claims should live in verifiable credentials that come and go on their own schedule.

Verifiable credentials: what they actually contain

Here's the mental model that finally clicked for me: a verifiable credential is a signed statement from an issuer about a subject. That's it. It's not a blockchain transaction, not a smart contract, not a magic token that grants access. It's a JSON payload with three parts — the subject's DID, the issuer's signature, and a set of claims — plus some metadata about expiry and revocation. The signature is the whole game. Without it, you're just exchanging plaintext notes that anyone can forge.

The subtle part is what the credential doesn't do. It doesn't verify the subject controls their DID at the moment of presentation. It doesn't tell the verifier whether the claims are currently true — only that the issuer said they were true at issuance time. That gap between "was true" and "is true" is where most production issues arrive. A credential from 2022 stating a contractor passed a safety exam means nothing if the exam was rescinded in 2023 and the revocation list hasn't been checked.

Most teams I talk to assume the verifiable credential is a self-contained proof. That assumption costs them days of debugging when they realize the presentation layer has to check revocation registries, expiration dates, and issuer trust lists separately. The credential is a building block, not a finished verdict.

Claims and presentation: the subtle difference

Here's the nuance that separates working systems from demos: a claim is a statement of fact — "age over 21," "member since 2018," "has a driver's license." A presentation is the act of arranging one or more claims into a context-specific proof. Most people conflate the two, and that conflation drives teams to build reusable presentation templates that don't fit any real use case.

Consider a bar checking age. The claim is "born on March 14, 1999." The presentation is "this person is over 21" — derived from the claim, not stored as a separate credential. If your system stores "isOver21" as a claim, you've created a credential that expires, leaks exact birth dates to every verifier, and requires re-issuance whenever the threshold changes. The right design keeps the raw claim private and lets the holder compute the selective disclosure at presentation time.

The tricky bit is that most identity frameworks push you toward storing precomputed claims because selective disclosure is computationally more complex. That's a trade-off, not a free lunch. I've seen teams accept the complexity and still suffer because their verifier software expects a specific claim name like "ageVerified" that no issuer actually produces. The fix is usually a translation layer, but that layer becomes its own maintenance story.

Not every social checklist earns its ink.

Not every social checklist earns its ink.

Not every social checklist earns its ink.

Not every social checklist earns its ink.

Why confusion leads to over-engineering

When teams blur these terms, they tend to build infrastructure for problems they don't have. They create credential registries for simple key-pair rotations. They build revocation dashboards for claims that should just expire naturally. They design complex multi-issuer verification flows when a single trusted issuer would serve the use case. The result is a system that's hard to explain, harder to audit, and impossible to hand off to a new engineer without a week of onboarding.

The cheapest fix is naming discipline. Call a DID a DID, not an identity. Call a claim a claim, not a proof.

— field note from an identity platform review, 2024

That naming discipline isn't cosmetic. It forces the design to respect the actual boundaries between components. A DID stays stable. A credential has a lifecycle. A presentation is ephemeral and context-bound. When those boundaries are clear, the architecture narrows naturally — you only build what the use case demands. When they blur, every decision gets second-guessed and every layer tries to do three jobs at once.

What I tell teams now: before you write any code, write the claim statements you actually need, list the issuers who can legitimately attest them, and sketch one presentation scenario end to end. If that takes more than an hour, you're probably adding layers that don't need to exist. The right starting point is almost always smaller than you think — a single issuer, a handful of claims, one verifier workflow. Get that working, then grow.

Patterns That Usually Work: Start Narrow, Not Grand

Pick One High-Value, Low-Risk Use Case

The teams that actually ship decentralized identity start with something almost boring. A proof of employment check. A contractor license verification. One workflow where the existing process is paper-based, slow, or requires three phone calls to confirm what should be a simple fact. That narrowness matters more than any technical choice. When you try to verify everything at once—credentials, attributes, relationships, reputation—you build an ontology instead of a product. Wrong order. The successful pattern I have seen repeated: identify a single verification that happens repeatedly, costs real money when it fails, and has a clear owner who feels the pain.

The catch is that “high-value” and “low-risk” rarely sit together naturally. You will likely need to compromise. A high-value use case might be issuing verified credentials for hospital staff across three sites—that has compliance weight behind it. But it also has compliance risk if you get it wrong. A low-risk use case might be verifying alumni status for a university newsletter. That proves the flow works without exposing you to regulatory blowback. Start there. Prove the seam holds. Then widen. This is not glamorous work, but it's the difference between a pilot that gets shelved and a system that survives contact with real users.

Use a Hosted Wallet to Reduce Friction

I have watched teams burn months on wallet UX. They obsess over key management, biometric prompts, backup phrases—all necessary, none differentiating. Meanwhile, the user just wants to prove they're who they say they're. The pattern that works in production: let the issuer or a trusted third party host the wallet initially. Yes, that sounds like a compromise of decentralization. It's. It's also how you get adoption. The user gets a link, taps a button, and their credential lands in a protected space they don't need to understand. Later, once trust builds, you can offer export to a self-hosted option. That sequential path beats forcing sovereignty on day one.

The trade-off is real, however. Hosted wallets reintroduce a central point of failure. If the host goes down, users lose access. If the host gets breached, credentials leak. But the alternative—expecting non-technical users to manage their own keys—produces worse outcomes: lost credentials, locked accounts, support tickets. What usually breaks first is the recovery flow. Design for it before launch. Test it with someone who thinks “two-factor authentication” means calling their bank twice.

Design for Fallback: QR Codes and Deep Links

Not every user will have the right app installed. Not every device will cooperate. The pattern that prevents abandonment: build a path that works with zero prior setup. QR codes scanned by a phone camera, deep links that open a browser-based verifier, a one-time code sent via SMS. These feel like retrograde steps, but they're insurance. The moment your flow requires installing an app, reading a spec, or understanding what a DID even is, you lose a chunk of your audience. Keep the magic accessible through the lowest common denominator.

One concrete example: a logistics company needed to verify delivery driver credentials at warehouse gates. The drivers had varied phones, spotty data coverage, and no patience for new software. The solution used a QR code on the driver’s phone that the gate guard scanned with a company tablet. No app install. No wallet setup. The underlying system used DIDs and verifiable credentials—the driver never saw any of that. The fallback was the feature. Without it, the project would have died in pilot.

Leverage Existing Trust Anchors

Decentralized identity doesn't mean starting from zero trust. The pattern that accelerates adoption: connect your new system to anchors people already rely on. Government-issued IDs, corporate email domains, established accreditation bodies. These anchors don't have to be perfect—they just need to be recognizable. When a user can tie their new digital credential to something they already hold, the verification feels less like a leap of faith and more like a practical upgrade.

The architecture can be decentralized; the adoption never is. People trust what they already know, so build bridges, not islands.

— observation from a systems architect who watched two pilots fail before adding email-domain verification

The tension here is that anchoring to existing systems can undermine the very independence you're trying to create. But the trade-off is worth it in the early stages. A credential backed by a university registrar’s signature carries weight. A credential backed only by a blockchain timestamp carries nothing to the average verifier. The winning move: let the decentralized layer handle portability and user control, while the trust layer leans on institutions that have already earned credibility. That hybrid approach is not a betrayal of the vision—it's the only version that gets past the first hundred users. Start with one narrow case, keep the friction low, build fallbacks, and borrow trust where you can. That's the pattern. It's not grand. It works.

Anti-Patterns and Why Teams Revert to Centralized Logins

Over-engineering trust: proving everything all at once

The first revert I watched happened on a Tuesday. A team had built a beautiful wallet-based flow—crypto-grade, airtight. The user had to present three verifiable credentials just to log in: proof of email, proof of age, proof of account ownership. Every click triggered a cryptographic dance. Sounds secure, right? The catch is that nobody asked whether the login actually needed all that proof. The product was a forum. A forum. The users abandoned at the wallet download step—seventy percent of them, per their own rough telemetry. The team spent two weeks ripping out the SSI layer and wiring up a plain email OTP.

Decentralized identity solves for verifiable claims, not for every authentication event. Over-proving is the fastest way to make users feel like they're applying for a mortgage when they just want to post a comment. The mistake is treating every login as a high-stakes transaction. Most sessions need a bearer token, not a cryptographic handshake. We fixed this by asking one question: what's the worst that happens if this credential is fake? If the answer is "someone posts spam," you don't need a VC. You need a captcha.

Ignoring user fallback: the password reset equivalent

Central auth has a dirty secret—the "forgot password" button. It's ugly, it's mundane, and it saves your product daily. Teams building decentralized flows often forget to build the equivalent escape hatch. Then the user loses their wallet seed phrase. Then they delete the wallet app by accident. Then they buy a new phone. What do they do? They email support, and support has no way to reassign a decentralized identifier. So the account is dead. Not locked—dead. The user is gone, along with their data and their trust.

That sounds fine until it happens to a paying customer. The "self-sovereign" trap is real: shifting all burden to users means shifting all blame to them too. "You should have backed up your keys" is technically correct and completely useless as customer service. The teams that stick with decentralized identity for longer than six months always quietly implement a recovery mechanism—a trusted device, a social recovery option, or a centralized backup of the private key, which defeats the whole point but keeps users alive.

Treating SSI as a drop-in replacement for OAuth

OAuth is not just a login protocol; it's a delegation protocol. It lets a third-party app ask "can this user access this resource?" without the user handing over their password. Decentralized identity, in its pure form, does something different: it puts the user in control of presenting claims. The failure mode is teams swapping out their OAuth flow and expecting the same behavior from a wallet SDK. Wrong order. OAuth is about permission scopes; VC presentation is about attributes. These are related but not equivalent.

I have seen a team ship a "Sign in with DID" button that required users to manually select which credential to present for every single request. No default, no caching, no scope memory. Users clicked through five screens just to view their own dashboard. The product manager called it "user empowerment." The users called it "a nightmare." They reverted to Google login within the sprint. The irony is that a hybrid approach—OAuth for session management, DID for specific high-value claims—would have preserved the experiment while keeping the UX sane.

Decentralization fails when it demands more from the user than the centralized system ever did.

— field note from a consulting engagement, identity infrastructure team

Not every social checklist earns its ink.

Not every social checklist earns its ink.

Not every social checklist earns its ink.

Not every social checklist earns its ink.

The 'self-sovereign' trap: shifting all burden to users

Self-sovereignty sounds noble. It comes with a hidden tax: the user now owns the consequences of every security decision. Centralized systems offer a safety net—password resets, account recovery, fraud teams. Decentralized systems offer a key, and if you lose the key, you lose everything. Most people don't want that responsibility for a shopping account. The teams that succeed here are the ones that pick a narrow use case—a professional license, a government ID, a medical record—where the user already understands the stakes. For everything else, central auth is the honest choice.

What usually breaks first is the support queue. Tickets spike with "I can't access my account" and there's no admin tool to just reset something. You become a key-recovery service with a engineering team attached. The pragmatic fix is to define, upfront, which claims are truly self-sovereign and which ones can live with a trusted intermediary. That's not a betrayal of the philosophy; it's a recognition that identity is a spectrum, not a binary. The teams that revert are the ones who saw decentralization as a religion rather than a tool. The teams that stay treat it as one option among several, chosen deliberately for the few moments where it genuinely matters.

Maintenance, Drift, and Long-Term Costs Nobody Quotes

Key Rotation and the Operational Headache

Every six months, some certificate or key expires. Nobody planned for it. The ledger keeps working—until a verifier refuses a credential signed with a key you rotated last Tuesday. Then you're debugging at 2 a.m. with a vendor who insists the old key is still valid. The catch is that decentralized identity spreads trust across dozens of parties, and each one caches keys differently. You can't just update a config file. You have to coordinate, notify, and pray nobody pinned the old key permanently. I have watched teams lose an entire sprint to key rotation that the architecture diagram never mentioned. That hurts.

The real cost is not the rotation itself. It's the human processes around it—email threads, shared spreadsheets, follow-up calls. Centralized login systems bury this problem inside one team. Decentralized systems push it outward, into every relying party. Wrong order of operations and you have locked out a partner for three days. One credential authority I worked with kept a paper checklist. Paper. Because the tooling didn't exist yet.

Credential Schema Drift: When the Model Changes

Your schema defines what a credential contains: name, license number, issue date. Simple enough. Then the regulator adds a field, renames another, and deprecates a third. Every issuer must update. Every verifier must accept both versions. Old credentials still circulate with the old shape, and suddenly your “versioned” schema is an unversioned mess. Most teams skip this step in their estimates—they assume schemas are stable because they barely change in centralized systems. They're wrong.

Schema drift behaves like software debt, but worse. In code, you can refactor. In verifiable credentials, you're stuck with what you issued. A revoked license issued under an old schema still needs validation logic. A credential from a pilot program three years ago still comes back to haunt you. The drift accumulates silently, and the maintenance cost compounds. We fixed this by freezing all schemas for six months at a time, but that only postpones the problem. The seam blows out during the next mandatory upgrade.

Recovery Workflows: The Silent Killer

The user loses their phone. That's the moment your decentralized identity system stops being elegant and starts being a liability. Centralized login? One click, reset password, done. Decentralized? You need a recovery mechanism that doesn't recreate the centralized authority you were avoiding. Some systems use social recovery—friends who sign off on identity restoration. Others require backup phrases that users write on paper. Most users don't have paper.

“Recovery is the unglamorous part of identity that determines whether users trust you with anything at all.”

— identity engineer, past project post-mortem

Every recovery flow is a potential attack vector. Every recovery flow also requires support staff to handle the edge cases—users who lost both their device and their backup, users who changed their phone number, users who share accounts. I have seen a decentralized identity rollout stall because recovery tickets took twice as long to resolve as password resets ever did. The trade-off is stark: you gain user control, but you lose the comfort of a single reset button. That's not a small cost; it's a daily support burden.

The Cost of Revocation and Trust Lists

Revocation sounds simple until you actually have to do it. A credential is temporary or the issuer needs to pull it early. You publish a revocation list, or you use a registry, or you rely on cryptographic accumulators. Each approach has a different maintenance rhythm. The cheapest method, a status list, requires issuers to keep publishing updates forever. The moment they stop, every verifier assumes everything is revoked. Not a great look.

Trust lists have their own drift. They define which issuers are authoritative, and they change as organizations merge, rebrand, or go out of business. Someone has to maintain that list, vet new entrants, and remove dead ones. Centralized systems just update an allowlist in one place. Decentralized systems scatter that responsibility across every participant. The cost is recurring, invisible, and rarely budgeted. You lose a day here, a day there, and by the end of the quarter nobody remembers why the team is behind. That's the long-term cost nobody quotes: not the initial build, but the endless, unglamorous upkeep that decides whether your identity layer survives past year two. Plan for it, or skip the approach entirely. The ledger doesn't forgive neglect.

When Not to Use This Approach: Scenarios That Scream 'Skip It'

Non-Technical User Bases and the Support Burden

Picture a support ticket from someone who just lost their recovery phrase. They call it "that code thing I wrote down," and they want you to fix it. With a centralized login, you reset the password in ninety seconds. With a self-sovereign wallet, you explain, gently, that their identity is now as unrecoverable as the paper they lost. That conversation ends badly more often than not.

The support burden compounds fast. Every password reset becomes a case review. Every new device requires a walkthrough. We once watched a team burn a full sprint building wallet onboarding for a user base that averaged sixty-two years old. The churn rate didn't budge. The ticket volume tripled.

Decentralized identity demands a certain baseline of digital literacy. Not everyone has it. That's not a judgment—it's a cost model. If your users can't manage a password manager, they can't manage a cryptographic key.

Ask yourself: is your product the place where someone should learn this?

Compliance Teams That Require Centralized Audit

Regulators want answers. They want to know who accessed what, when, and under whose authority. A distributed ledger gives them a cryptographic proof of a claim—not a clean CSV export with timestamps and an approver's signature. The gap between those two things is where compliance projects go to die.

The tricky bit is that most audit frameworks predate decentralized identity. They were written assuming a central authority holds the logs and can produce them on demand. When you tell a compliance officer that the user holds their own credentials, they hear "we lost control of the data." You can explain zero-knowledge proofs until the coffee runs cold. The sign-off still takes six months.

I have seen a promising pilot killed because the legal team demanded a single accountable party for every identity event. The technology could do it. The process could not.

Low-Stakes Logins Where Passwords Are Fine

Here's a blunt truth: not every login needs a revolution. A forum account, a newsletter, a tool that holds no sensitive data—password plus email works. It's boring, it works today, and nobody gets hurt when an account drifts into inactivity.

“The best identity system is the one your users forget exists. Crypto wallets are memorable, and not in a good way.”

— Field note from a product manager who reverted to magic links

Not every social checklist earns its ink.

When the cost of a breach is low, the cost of identity infrastructure is pure overhead. You lose a day to key management, you lose another to key rotation, and for what? Protecting a profile picture?

Not every social checklist earns its ink.

Not every social checklist earns its ink.

The catch is that "low stakes" feels like a moving target. Start with a password, and you can always add decentralized identity later if the product grows. Start with a wallet, and you can't subtract it without alienating early adopters.

Not every social checklist earns its ink.

Hype-Driven Pilots With No Clear ROI

Someone on the executive team read an article. Now you're building a proof of concept for decentralized credentials that solve no user problem you can name. The demo looks slick. The metrics are absent.

Most teams skip this: define the failure condition before you write the first line of code. What, specifically, should improve? Onboarding time? Fraud rates? User trust scores? If you can't name the metric, you can't name the ROI. And without ROI, the project becomes a maintenance drain with no champion.

We fixed this once by forcing the pilot team to write a one-paragraph answer to "what breaks today that this fixes?" They couldn't. The pilot died quietly, and that was the best possible outcome.

Decentralized identity is a tool, not a badge of innovation. Use it where the existing system bleeds. Leave it on the shelf where the status quo merely exists.

Open Questions and FAQ: What's Still Unresolved

Account Recovery: Who Is Responsible, Really?

You lose your phone. Your kid wipes your laptop. The hardware wallet slips behind a shelf and stays there for three years. With centralized login, you click “Forgot password” and answer a few questions about your first pet. With decentralized identity, there is no password reset button. The recovery model shifts entirely — and most teams discover this only after a user is locked out and angry.

The honest answer: recovery is a design decision you make, not a feature the protocol gives you. Some systems lean on social recovery — trusted contacts who sign to restore access. Others use custodial backup keys, which reintroduces a central point of failure. The trade-off is brutal: pure self-sovereignty means no one can save you; practical self-sovereignty means someone can.

I have seen teams ship a DID system with zero recovery path, assuming users would manage. They didn't. Support tickets spiked, churn followed. What usually breaks first is not the cryptography — it's the human expectation that something, somewhere, can undo a mistake. If you can't answer “what happens when the private key dies” before launch, you're building a lock without a spare key.

“Recovery is not a security problem. It's a relationship problem between the user and their own future self.”

— field note from an identity engineer, after a three-hour recovery postmortem

Wallet Provider Dependency: What If They Shut Down?

Your wallet app is the front door to your identity. The startup that built it raises a round, then misses the next one. Servers go dark. Users panic. You, the integrator, suddenly own a support nightmare you never budgeted for.

The catch is that most wallets are not fully self-contained. They rely on cloud sync, push notifications, or remote backup services. When those disappear, the user's stored keys might still exist locally — but the convenience layer that made the wallet usable is gone. The underlying DID remains valid; the experience collapses.

Mitigation exists but costs you: exportable keys, open-source wallet clients, or standards like DIDComm that allow switching providers mid-flight. However, each of those adds integration surface and testing burden. Most teams skip this until it hurts. Wrong order.

Ask yourself: if your wallet provider vanished tomorrow, could your users export their credentials in under ten minutes? If the answer is no, you have a single point of failure wearing a decentralized costume.

Do You Even Need a Blockchain?

Short answer: often no. The blockchain provides a public, append-only registry for DID documents — but if your use case is internal, single-organization, or even just two businesses with a shared API, a plain database with signed JWTs does the job. No miners, no gas fees, no ledger bloat.

The real question is who you trust to resolve DIDs. If both parties trust your server, you don't need a chain. If you need trustless resolution across many unrelated parties, a blockchain starts making sense. The pitfall is momentum — teams hear “decentralized” and assume the ledger is mandatory. It's not. It's a tool for a specific threat model.

We fixed this once by stripping out the chain entirely. The system got faster, cheaper, and easier to audit. The credentials were still verifiable; the registry was just a signed CSV file. Nobody noticed the difference except the ops team.

How Do You Handle Multiple DIDs per User?

One person, five contexts: work, personal, healthcare, gaming, and a pseudonymous blog. Should they all share a single DID? Probably not. But do you want to manage five separate key pairs per user, with five recovery flows and five revocation lists? That way lies administrative chaos.

The pragmatic pattern is a hub-and-spoke model: one primary DID for the person, with per-context DIDs bound to it via verifiable relationships. The primary holds recovery authority; the context DIDs hold only the claims relevant to that sphere. The complexity is not in issuing — it's in keeping the linkage clear when a user revokes one context without nuking the others.

Most implementations I have reviewed ship with one DID per user and call it done. That works until a user wants to separate work credentials from personal ones — and then the entire credential history gets tangled. Plan for multiple DIDs upfront; retrofitting it later means migrating every issued credential.

Next step: pick one of these four questions and run a small pilot with real users. Watch where they stumble. That stumble is your spec for version two.