When we talk about digital identity wallets and use the words “web wallet,” we often get the same reaction:
So it’s custodial? Someone else holds the user’s keys?
If that were the model, we’d have concerns too.
But there’s an important distinction that often gets lost in conversations about wallet architecture:
Where a wallet is hosted is not the same thing as who controls access to it.
A wallet can be hosted in the cloud without the hosting provider having access to the credentials inside it.
In Truvera’s Web Wallet model, credentials are encrypted before they are stored in the cloud.
In the privacy-by-design architecture we recommend for production, the key required to decrypt the wallet’s contents is controlled by the holder, not Dock Labs or the organization hosting the encrypted data vault.
Depending on the implementation, the holder can access the wallet using mechanisms such as a passkey or biometrics.
The important point is that the infrastructure provider does not have the encryption keys needed to simply open the vault and read the credentials inside.
That gives you two things that are often presented as a trade-off:
The convenience of a hosted service, while keeping the holder in control of access to their information.
The more useful question is: who controls access to the keys?
People sometimes divide wallets into two categories:
Mobile wallet = user controlled
Cloud or web wallet = custodial
But those are separate architectural choices.
The more useful questions are:
- Who controls the keys needed to access the wallet and its credentials?
- Can the wallet or storage provider decrypt the holder’s data?
- Where does encryption happen?
- What happens if the infrastructure provider is compromised?
- How is the holder authenticated before the wallet can be unlocked?
- Does the use case require a credential or key to be tightly bound to a specific device?
Those questions tell you much more about the security and trust model than simply asking whether the wallet runs on a phone or is hosted in the cloud.
Cloud is not the answer to everything
There are also good reasons to use a mobile identity wallet.
Some credentials and use cases require tight binding to hardware or a particular device. Others benefit from local storage, offline capabilities or specific mobile security features.
Those credentials have a natural home in a device-based wallet.
Other use cases prioritize accessibility.
A user might need to access credentials across devices. An enterprise might want to introduce digital credentials without requiring customers to use an app. A credential might primarily be used during browser-based journeys.
In those situations, a web wallet can provide a much better experience. That was one of the reasons we built the Truvera Web Wallet: to make reusable digital identity possible in journeys where requiring a mobile app would introduce unnecessary friction.
The point is not to declare one architecture the winner.
It is to choose the wallet model that fits the use case.
One ecosystem can support different wallet models
This becomes increasingly important as digital credentials move beyond isolated pilots.
The same person may eventually hold credentials for very different purposes:
- An identity credential used during online onboarding.
- An employee credential used across enterprise systems.
- An age or eligibility credential presented to a third party.
- A credential tightly bound to a mobile device.
There is no reason all of those interactions need to happen through exactly the same wallet architecture.
What matters is preserving the right security and trust model for each use case.
For us, one of the underlying principles is simple:
The holder controls the key needed to access their information, wherever the encrypted vault lives.
That is a much more useful way to think about wallets than assuming that “cloud” means custodial and “mobile” means user controlled.
The future of digital identity probably won’t have one wallet model.
It will have the right wallet for the right job.
