Why decentralized identity DID fails at scale
In a pilot, decentralized identity DID looks robust: the identifier belongs to the owner, the registry is distributed, no intermediary is needed. With hundreds of users, the system behaves predictably.
Failures begin when the count reaches tens of thousands of wallets and several independent participants.
The single point of failure is almost never in the blockchain itself. It is in the supporting infrastructure: a single identifier resolution service, an identifier-to-account mapping cache, an external key store, a single signing service.
While there is one node, discrepancies are not visible; with a second one, registry desynchronization becomes a normal mode rather than an outage, and no one notices it until the first check.
Keys are more difficult: recovery is not built into the model itself. Loss of access means that the identifier and accumulated reputation no longer belong to the owner, and there is no one to return them centrally.
Key revocation goes along a chain of confirmations: until the update reaches all participants, the compromised key can still be used.
A separate issue is accounts in business systems: they live separately from the registry, and reconciliation is done manually. The discrepancy surfaces at the most inconvenient moment — during signature verification or before a payout, when it is already too late to fix.
Next, we examine how these causes of failure are addressed at the level of architecture and operations.
Implementation effect: issuance time, access revocation, failure rate
Previously, issuing an account was a chain of requests, approvals, and manual creation in several systems. This meant hours and days of waiting, during which the person was not working.
In the decentralized identity DID scheme, the key is created on the owner's side, and only confirmation goes to the registry — issuing an identifier takes minutes.
The record format and verification rules are defined in the W3C specification, so different services read the same identifier in the same way.
Access revocation previously stretched over days: permissions were revoked separately in each service, and any missed service remained open.
Here, a single record in the registry is enough, and the verifying party checks the status on every login attempt — access revocation time no longer depends on the number of connected systems.
Access recovery is built on a threshold scheme: several trusted holders or backup keys, a sufficient share of which is enough to re-confirm the owner. The "lost device" scenario no longer requires manual investigation and does not turn into multi-day downtime.
The login failure rate falls due to a whole class of causes — desynchronization of accounts between systems and permissions left over from previous roles.
Signature and status verification is deterministic: the result does not depend on whether a particular database has managed to synchronize.
Options for building a trust perimeter and their limitations
The DID perimeter rests on three decisions: who issues the identifier, where keys are stored, and how access is revoked. Both the integration effort and the class of failures depend on them — key loss, intermediary compromise, or registry unavailability.
The schemes are advantageous in different scenarios, so they are chosen based on requirements for revocation, access recovery, and legal validity, not on "progressiveness."
| Identity perimeter option | When it fits | Limitations |
|---|---|---|
| Centralized registry | Internal services of one organization, short access issuance cycle | Single point of failure: registry unavailability blocks login, and a database leak exposes all accounts |
| Federated login through a trusted intermediary | A partner network where participants already trust each other | The intermediary sees all logins and decides who to admit; one participant leaving breaks related scenarios |
| Self-sovereign identity | The user owns the keys and transfers them between services | Key loss equals loss of access; separate recovery and revocation procedures are needed |
| Hybrid registry | Public mandate verification and managed revocation are needed simultaneously | Two permission perimeters, state desynchronization, a separate key storage policy |
We start with a threat model: if access must be revoked instantly and by organizational decision, the pure self-sovereign option is not suitable. If the identifier must outlive the service, keys cannot be locked in a central database, and the perimeter is built as hybrid.
Implementation stages: from role audit to system handover
We carry out the work in stages — from role inventory to handing over the assembled perimeter to your team. Each stage ends with a verifiable artifact: a role registry, a key issuance scheme, a revocation policy, a failure verification report.
- Access and role audit. We build a map: who has access to which systems, which operations are performed manually, where permissions are over-provisioned and not reviewed. The output is a role registry with owners and an authorization matrix.
- Key issuance scheme. We determine where keys are generated, who signs the credential, how the identifier is assigned to a person or service, and how access is restored when a device is lost. Separately, we record which data remains with the user and which is verified without disclosure.
- Key rotation and revocation policy. We define key lifetime, the procedure for scheduled replacement, and immediate revocation upon dismissal, role change, or compromise. Revocation is performed with a single action and confirmed by a log entry.
- Perimeter assembly. We deploy credential issuance and verification services, connect them to your user catalog and access control systems, and configure redundancy and monitoring.
- Failure scenario testing. We simulate node unavailability, key loss, re-signing, and login with a revoked credential. Each branch ends predictably: either access or a clear denial, without a stuck status.
- Training and handover. We hand over configurations, instructions for administrators and support, and review typical incidents using your data. After that, your team maintains the perimeter.
Registries, subject documents, and key issuance policy
A decentralized identity system lives longer than a contractor on a project: keys rotate, subjects revoke consent, and verification requirements change.
Therefore, along with the code, a package of artifacts is handed over that answers not the question "how it is built" but the question "what to do on Monday morning."
- Identity documentation — a map of registries, the composition and owners of subject document fields, and a scheme of links between the base and derived identifiers.
- Authorization matrix — which role issues, revokes, and delegates authority, which operations require two confirmations, and where the support boundary ends.
- Access policies — rules for issuing verifiable documents, their lifetimes, revocation conditions, and the procedure for acting when a signing key is compromised.
- Key issuance and rotation policy — a step-by-step procedure with decision points: where key material is stored and how authority is divided.
- Support instructions — common requests with a diagnostic tree and signs that an incident should be passed to development.
- Recovery procedure — switching to a backup node, rolling back a release, and restoring the registry from backups with integrity verification.
Each item is checked at acceptance: if the document does not allow an action to be performed without contacting us, it is returned for revision. Describe the task — we will return with an assessment and a plan, including the composition of this package.
Case study: single sign-on for a partner network of 40 participants
How it was before moving to a unified perimeter
The partner network Альянс «Открытый контур» — 40 companies operating under a common brand. Each had its own list of accounts, and access to neighboring services was granted upon request.
Connecting a new employee took 4–6 business days: request, approval, manual account creation in each system, and an email with login details.
Access revocation was the most burdensome. A termination request went through three approval queues and was closed on average in three days, while some records remained active for weeks: there was no unified login log.
What we changed
We migrated the network to a unified decentralized identity perimeter. The partner itself issues a DID to the employee and signs it with its own key; the network services accept such a login without an intermediate account database.
Revocation became a single operation: the partner's signature is no longer accepted at the next check, and the active session is closed when the access token is refreshed.
What happened after implementation
Onboarding was reduced to 20 minutes per employee, access revocation to several minutes, and the share of "forgotten" active records fell to zero.
Support requests on the topic "can't get into the service" dropped fourfold, and the login log was consolidated into a single registry: you can see who logged into each network service and under which identity.
How does DID differ from federated login?
The difference is not in login convenience, but in who owns the key and who has the right to close access. With federated login, the account lives with a trusted intermediary, and the service simply trusts its assertion.
In DID, self-sovereign keys remain with the owner, and the identifier is recorded in the registry according to the W3C specification — the verifier confirms the signature itself.
| Criterion | Federated login | DID |
|---|---|---|
| Key storage | with the intermediary | with the owner |
| Intermediary | required | not needed |
| Access revocation | session closure | status in the registry |
| Who revokes | the intermediary | the key owner |
| Activity visibility | all services at once | nothing without disclosure |
| Impact of error | loss of access everywhere | key loss |
The speed of revocation differs fundamentally. With federated login, access lives until the issued pass expires, so revocation is not instantaneous.
In DID, revocation is recorded in the registry and visible at every presentation — but only if the verifying party checks the status; otherwise the revoked key will continue to work.
The risks are mirrored. The intermediary is a single point of failure and correlation: it sees a person's activity across all connected services and can block login with a single decision.
Self-sovereign keys remove the intermediary but shift responsibility to the owner — key loss means loss of the identifier, so recovery schemes are needed: key splitting among custodians, multisignature.
A hybrid is often chosen: the identifier is in the registry, and federated login is one way to prove control over the key.
Common doubts and limitations of the chosen approach
The registry does not allow deleting a record retroactively — this is both the strength of the approach and its limitation.
Instant revocation works only where the verifier checks the status at the moment of presentation: if the verification service reuses a previously obtained response, the revoked identifier still passes for some time.
The status check point and the period for which a response can be reused are the subject of a separate architectural decision.
Key loss is not a password reset: the key itself is proof of ownership, and there is nothing to restore here until the procedure is designed in advance.
We record responsibility for recovery and the procedure for initiating it in the policy before commissioning, and we build the link to the existing account catalog as an attribute that can be rolled back.
What to do if a user loses their key?
Without a pre-designed recovery, reissuance remains: the old identifier is revoked, a new one is tied to the person again, and accumulated confirmations are collected from scratch.
Therefore, the recovery scheme — secret sharing among trusted custodians or a backup key in an isolated storage — is built in before launch, not after an incident.
How are identifiers linked to the current account catalog?
The catalog remains the source of truth for access rights, and the identifier adds user ownership to it. The link is stored as an attribute, and migration proceeds in groups: first issuance, then migration of checks.
While the attribute is not filled in, login via the previous scheme works — this is the rollback path.
What about the legal validity of the record?
The registry records the fact, time, and authorship of an action — for internal processes this is sufficient.
For transactions with counterparties, validity is provided by a signature recognized by the parties and regulation: we agree on the data composition and retention periods in advance.
Let's discuss the task: where to start and what to prepare
To make the project assessment accurate rather than "by eye," we need a description of scenarios, roles, and constraints — we will clarify the rest with questions.
Below is a checklist: mark what is already known, and do not go deep where there are no answers yet — that is normal at the start. In response, you will receive an architecture diagram, a stage-by-stage work plan, and the boundaries of the pilot perimeter.
- Use cases. Where exactly decentralized identity DID is needed: login to services, qualification confirmation, access to closed data. Describe 2-3 main scenarios and the system behavior on a failed check.
- Roles and trust model. Who issues credentials, who presents them, who verifies them, and who has the right to revoke. This determines the choice of registry method and the key management scheme.
- Standards and compatibility. Whether compatibility with W3C DID and verifiable credentials is needed, and whether external participants are planned who must accept your identifiers.
- Privacy and data. What goes into the public registry and what remains off-chain; requirements for deletion, access logging, and storage of personal information.
- Integrations. Existing user catalogs, login services, internal systems to which credentials must be transferred, and methods of data exchange between them.
- Pilot perimeter and documentation handover. How many participants are needed at the first stage, who on the customer side accepts the result, and in what form descriptions, policies, and code rights are needed.
After that, we fix the work plan, the composition of the pilot, and the documentation handover procedure. Describe the task — we will return with an assessment, a scheme, and a stage plan.