You've probably heard the pitch: decentralized identity puts users in control, eliminates central servers, and solves privacy problems that federated identity can't touch. The architecture is real, the standards exist, and production implementations are shipping. But the conversation around it is cluttered with myths that make practitioners hesitate or, worse, build the wrong mental model before they start.
These myths persist because decentralized identity requires unlearning patterns that have been true for twenty years of OAuth 2.0 and SAML. The shift from "prove who you are by asking a server" to "prove who you are by presenting signed data you hold" is a genuine paradigm change, and paradigm changes breed misconceptions. Let's clear up six of them.
Myth 1: Decentralized identity means no servers at all
Reality: Issuance, revocation, and key resolution still involve servers. What changes is when they're needed.
Traditional federated identity requires a live server conversation every time a user proves something. Sign in to an application, and it calls your identity provider to verify the token. Decentralized identity moves that verification offline: the credential is issued once, signed by the issuer, and the verifier checks the signature locally against the issuer's public key material.
But issuance itself is still a server operation. An employer issues an Employee credential through a credential lifecycle manager that evaluates attribute changes and stages credentials for delivery. Revocation messages travel through a mailbox service. Decentralized Identifiers resolve to public keys via DID documents, which may be stored in distributed ledgers or served over HTTPS depending on the DID method. The "decentralized" part means trust doesn't flow through a central service at verification time, not that servers disappear.
Myth 2: Wallets are just credential viewers
Reality: A wallet is a key store and a protocol state machine, and both parts matter for security.
The visible part of a wallet, the UI that shows credentials and asks for consent, is the least interesting part architecturally. Under the hood, a wallet manages cryptographic keys bound to the device. On iOS, that means keys live in the Secure Enclave and credential data in the keychain, which is why wallet SDKs don't run on simulators.
When a verifier requests proof, the wallet doesn't just display stored data. It signs a challenge with the device's private key, proving the credential is being presented by the device it was issued to, not a screenshot or a copy. This binding is what prevents credential theft from being useful: the cryptographic material that validates the presentation never leaves the Secure Enclave.
The state machine aspect matters just as much. A wallet moves through discrete states, unpaired, paired, receiving, presenting, and every integration decision you make is really a decision about which messages move the machine between states and what your app does at each transition.
Myth 3: OpenID4VP means full interoperability out of the box
Reality: Standards compliance gets you partway there, but format and feature choices still create walled gardens.
OpenID for Verifiable Presentations defines how a verifier states what it needs and how a wallet responds. W3C's Verifiable Credentials standard defines the data format for tamper-evident statements. Those are the interoperability foundations, and they work: a standards-compliant wallet can present to a standards-compliant verifier.
But real deployments make choices that affect interoperability. The PingOne Wallet SDK supports OpenID4VP-based credentials and a PingOne-proprietary format that adds capabilities inside the Ping ecosystem. If your verifier expects the proprietary format, credentials issued by non-Ping systems won't match. If you need to support verifiers outside your control, you need to know which format they expect and whether your issuer can produce it.
Interoperability also depends on presentation exchange descriptors, the JSON structures that describe what claims a verifier needs. Two verifiers asking for "proof of employment" might describe the requirement differently enough that matching logic fails, even though both are standards-compliant. Test against real verifier requests, not just the examples in the spec.
Myth 4: Users control their data, so privacy is automatic
Reality: Control and privacy are design choices you make in the presentation flow, not properties the protocol enforces.
Decentralized identity gives users the ability to control what they share, but your app decides whether that ability becomes real. The privacy win comes from a specific ordering of operations:
- The presentation request arrives.
- Matching happens on-device, locally, before the user sees anything.
- Only if a match exists does your app show the request and ask for consent.
- The user decides which credential to present (if multiple match).
- The signed response goes to the verifier.
If you flip that order, say, by logging every presentation request to your backend before checking for a match, you've leaked information about what verifiers are asking for, even when the user has no matching credential. If you auto-approve presentations without showing the user what's being shared, you've removed control.
The W3C Verifiable Credentials Data Model and OpenID4VP give you the building blocks for privacy-preserving flows. Whether you actually preserve privacy depends on how you implement the consent and matching logic in your wallet integration.
Myth 5: Credentials work like long-lived access tokens
Reality: They're closer to signed assertions, and the revocation model is fundamentally different.
The mental model "a credential is like a long-lived SAML assertion or OIDC ID token that doesn't have to be reissued on every sign-on" is useful, but it breaks down at revocation. When you revoke an access token, the authorization server stops accepting it immediately. When you revoke a credential, you send a revocation message to the wallet, and the wallet is responsible for removing it.
That means revocation is eventually consistent, not instant. If a user's employment ends and you revoke their Employee credential, the revocation message travels through a mailbox service and arrives when the wallet next polls (every three seconds by default in the SDK we examined). Until the wallet processes that message, the credential still exists on the device.
For high-stakes use cases, verifiers can check revocation status in real time by querying a revocation registry or status list. But that's an additional step, not automatic. If your threat model requires instant revocation, design for it explicitly, don't assume credential-based flows give you the same guarantees as token-based ones.
Myth 6: Decentralized identity replaces federated identity
Reality: They solve different problems and often coexist in the same architecture.
Federated identity excels at single sign-on across applications within a trust boundary. You authenticate once to your identity provider, and a session or token carries you through multiple applications. Decentralized identity excels at presenting proof to parties outside your usual trust boundary, without requiring them to integrate with your identity provider.
Consider a contractor who needs to prove employment to access a client's facility. Federated identity would require the client to trust the contractor's employer's identity provider and integrate with it, a heavy lift for a temporary access scenario. Decentralized identity lets the employer issue a credential once, and the contractor presents it to the client's verifier without any live connection between the employer and client systems.
In practice, you'll use both. Employees authenticate to internal applications with OIDC or SAML. They present credentials to external verifiers when federation isn't practical. The hard part is deciding which pattern fits which use case, and that decision depends on trust boundaries, integration costs, and whether you need real-time revocation.
What to do instead
Start with a threat model, not a technology choice. What are you trying to prove, to whom, and what happens if the proof is forged or replayed? Decentralized identity's value shows up when the verifier and issuer don't share infrastructure and can't easily federate, or when user consent over specific claims matters more than session convenience.
When you do integrate a wallet SDK, treat it as a state machine. Map out the states (unpaired, paired, holding credentials, presenting), the messages that trigger transitions (pairing requests, issuance, presentation requests), and what your app does at each transition. Most integration bugs are really state machine bugs, a message arrived in the wrong state, or your app didn't handle a transition.
Test against real presentation requests from the verifiers you'll support in production. The gap between "standards-compliant in theory" and "works with this verifier's descriptor" is where interoperability breaks. If you're building a verifier, publish example presentation exchange descriptors so wallet developers know what to test against.
And don't assume decentralized identity solves problems it wasn't designed for. It's not a session management protocol. It's not a real-time authorization system. It's a way to issue signed statements once and verify them later without a live connection to the issuer. Use it for that, and use other tools for the rest.
