In a recent webinar, Richard Esplin, Head of Product at Dock Labs, and Agne Caunt, Product Owner, walked through a live demo of our new browser-based approach to digital identity.
The session focused on a growing challenge many organizations face: identity data scattered across multiple applications, acquisitions, and partner ecosystems. Instead of trying to unify everything into a single system, Richard and Agne introduced a different architectural model, one where verified identity data is packaged into reusable digital credentials and accessed through an embedded, largely invisible wallet experience.
Through a step-by-step demo, Agne showed how this works in practice, from signing into newly acquired platforms without re-onboarding, to verifying identity with external partners using privacy-preserving credentials. Along the way, they explored the underlying architecture, trade-offs around security and decentralization, and how this model can unlock both better user experiences and new business opportunities.
Below is a breakdown of the key insights from the session.
The webinar frames identity fragmentation as the core problem
- The main problem described is identity being trapped in separate systems.
- Agne sets up the story around Quotient, a fast-growing company with web and mobile apps, a recent acquisition, and external partners.
- Each system has its own database, verification process, and logic for recognizing the customer.
- These systems work for their original purpose, but they were not designed to talk to each other.
- The issue is presented as structural, not just a tooling issue.
- Agne says IAM and IDV tools work well “inside their own walls.”
- The problem starts when a customer moves outside those walls, such as to a partner site or a newly acquired platform.
- In those cases, the customer is treated like a stranger again, even if they were already verified elsewhere.
- This creates repeat verification, extra cost, and poor user experience.
- Agne says customers may need to fill in another onboarding form or complete another identity check.
- She also says partners may pay a third party to verify a customer even when Quotient has already verified that person.
- The result is that the same identity gets re-verified across silos instead of being reused.
- Different business teams feel the same problem in different ways.
- The CFO sees climbing IDV costs.
- IT sees long integration projects after acquisitions or due to partnerships.
- Security sees risk because customer identity data is stored in too many places, which increases the attack surface.
The proposed solution is reusable digital identity built from trusted existing data
- Agne presents the solution as creating a verified digital identity layer for each customer.
- Sarah, the fictional chief identity officer, stops trying to solve each pain separately.
- Instead, she creates a reusable digital identity for each customer using data Quotient already has.
- The goal is to package already verified data into something reusable and portable.
- Agne says the verified data is turned into something that can “travel.”
- It works in browsers, on mobile, and across partners.
- The point is to reuse identity that already exists rather than recreate it in each channel or system.
- The experience is meant to be largely invisible to the user.
- Richard opens the webinar by referencing Nick Lambert’s view that the best wallet experience is when you do not notice it because it is already inside the apps you use.
- Agne’s demo is meant to show that kind of experience.
- Henry, the example user, does not need to manually manage the process and may not even know the wallet exists in the background.
- The broader aim is to reduce how much effort the holder has to do.
- Agne says one of her reflections from working on these products is that it is often too hard “to be the holder.”
- She says identity should not require people to work so hard for something that is their own.
- She sees this kind of embedded experience as a step toward something ordinary users, including less technical users, could realistically use.
The demo shows two main user flows
- The first flow is signing into a newly acquired platform using an existing identity.
- Henry visits Equinet, the acquired company, and sees a “Sign in with Quotient” button.
- The web wallet appears and shows him what information will be shared.
- After authentication, the account is set up using his Quotient digital identity.
- The key point of this first flow is avoiding both re-verification and custom integration work.
- Agne says Sarah did not need to build a custom integration between the two systems.
- Henry did not need to prove who he was again.
- The credential already in his wallet handled the work.
- The second flow is a partner checkout and verification experience.
- Henry buys wine from a partner store and wants to use his discount.
- He needs to prove he is over 21 and also use his loyalty card benefit.
- The wallet flow handles age verification, loyalty discount application, and optionally uses stored address data to reduce manual entry.
- The demo is meant to show the same experience across desktop and mobile.
- Agne shows Henry using the same credentials on desktop through the web wallet and on mobile through the Quotient app.
- Her point is that the experience stays consistent across devices.
- She emphasizes that the user does not need to think about the credentials separately in each place.
Privacy-preserving verification is a key part of the flow
- The age-check example is designed to share only the minimum needed information.
- Agne says the wine shop does not need Henry’s exact date of birth or exact age.
- It only needs to know that he is over 21.
- She explicitly says they are using zero-knowledge proofs for that.
- Selective disclosure is part of how the wallet builds presentations.
- Later in the webinar, Agne says the wallet finds credentials that satisfy the proof request and builds a presentation using only the needed attributes.
- Richard also describes this as part of how the verifier requests specific data for a transaction.
- The presentation is unique to each proof request.
- The wallet is designed to reduce unnecessary holder decisions in simple flows.
- Agne says that in the demo they wanted to avoid burdening the user with manually selecting credentials.
- If the verifier already knows what information it needs and the wallet has it, the process can happen automatically after approval.
- She also notes that other wallet experiences are possible when user choice is more important, such as when someone has many possible credentials to use.
The web wallet and cloud wallet are related but not the same thing
- Agne distinguishes between “cloud wallet” and “web wallet.”
- She says the cloud wallet refers to the storage layer, where credentials live in encrypted cloud storage or an encrypted data vault.
- The web wallet is the actual wallet experience shown to the user, such as the popup interface and authentication flow.
- The credentials shown in web and mobile are not duplicates.
- Richard asks whether the same credentials appearing in web and mobile means they are duplicated.
- Agne answers that they are not duplicate credentials.
- She says they are the same credentials, accessed through shared encrypted storage.
- The mobile wallet can connect to the same encrypted storage used by the web wallet.
- Agne explains that as credentials are added to the mobile wallet, they can also be added to the encrypted data vault.
- Then the web wallet can access those same credentials using the same authentication method.
- Passkeys are used in the demo, but she says other authentication methods could also be used depending on the deployment.
- Cloud storage also supports recovery scenarios.
- Agne says that even without using the web wallet, cloud storage is valuable because it allows users to recover credentials if they lose their phone.
- If a user installs the app again on a new device, the credentials can still be available through the cloud-backed storage.
- She presents that as an important practical advantage.
The architecture shown is API- and SDK-based
- Credential issuance starts after an organization decides what data it trusts.
- Agne says issuance is done using the Truvera API after identity proofing.
- The proofing itself can come from different processes already in place.
- Richard later adds examples such as government IDs, document verification, HR systems, healthcare databases, and other trusted sources.
- The wallet experience is built using Truvera’s wallet SDK.
- Agne says Quotient uses the wallet SDK embedded in the mobile app and also uses it to build the web wallet.
- The same SDK is the foundation for the holder-side experience.
- Verification also relies on API-driven proof requests.
- Agne says the verification side uses the API to build proof requests that trigger the wallet and request information.
- Richard explains that the verifier defines what is requested through a verification template in the workspace.
- The requested data is then presented through presentation exchange.
Dock Labs’ role starts after identity proofing
- Richard draws a clear line between identity proofing and credential integrity.
- He says Dock Labs does not control the identity proofing step.
- That part is done by the customer’s existing onboarding process or by partner providers.
- He names companies like Daon, Youverse, and Fourthline as examples of partners that help with that stage.
- Dock’s focus is protecting and reusing trusted identity data once it has been issued.
- Richard says their role is to issue a credential once the data is trusted according to policy.
- From there, they make sure the credential is not modified or tampered with as it moves from issuer to wallet to verifier.
- That is the part he describes as Dock Labs’ expertise.
Security and fraud prevention are discussed in practical terms
- The demo itself uses passkeys, not biometric-bound credentials.
- Richard says that in this demo they did not use a biometric for Henry.
- They assume Henry provides a passkey that is registered against the wallet.
- That passkey may be protected by device-level biometrics through the OS keychain, but the demo does not rely on a separate biometric-bound credential.
- Biometric-bound credentials are positioned as an optional stronger security control.
- Richard says if the threat model includes concerns like someone other than Henry completing the transaction, then biometric-bound credentials may be appropriate.
- He refers to a previous webinar explaining how Dock Labs ties biometrics to credentials in privacy-preserving ways.
- Fraud prevention is split into two layers.
- The first is making sure the original identity data is authentic, which Richard says is handled during onboarding and proofing.
- The second is making sure that once a credential is issued, it cannot be modified or tampered with.
- Dock’s role is focused on that second layer.
The design makes trade-offs between decentralization and practical deployment
- Agne argues that cloud-backed storage does not automatically undermine decentralization.
- She says the encrypted data vault is end-to-end encrypted.
- In her view, only the holder can see the information, so the model still preserves important decentralization properties.
- She presents the approach as adding flexibility rather than abandoning decentralization.
- Richard gives a more explicit trade-off analysis.
- He says this model can be considered a custodial wallet in the specific setup shown.
- In the demo flow, the ecosystem administrator or issuer helps set up the wallet on behalf of the holder and sees the cryptographic material during setup.
- He says they should discard that material afterward, but he is clear that this setup introduces a different trust model.
- Richard does not reject SSI ideals, but he also does not want to be doctrinaire about them.
- He says Dock Labs believes in the benefits of self-sovereign identity.
- At the same time, he says they do not want to be purists if that prevents real deployments from getting the benefits.
- He describes the approach as trying to balance those ideals with what real businesses and users actually need.
- Recovery and custodial support are presented as things real users often want.
- Richard says they have heard feedback that many users prefer custodial wallets.
- He gives the example of a user saying they trust their bank and want the bank to be able to restore their identity.
- He contrasts this with the fear of losing access entirely, which many people associate with crypto-style self-custody.
Monetization and ecosystem reuse are important commercial themes
- The partner use case is explicitly tied to a monetization opportunity.
- In the wine shop scenario, Agne says the partner can pay Quotient a small fee rather than paying for another age verification service.
- Across a partner ecosystem, she says that can add up and turn identity into a revenue stream.
- Richard separately points to monetizable credentials in the credential SDK.
- He says the open-source credential SDK includes support for monetizable credentials.
- In that model, credentials can be locked so only trusted verifiers can verify them and be invoiced.
- He also says this can be done without recording holder interaction, which preserves holder privacy.
Standards, protocols, and implementation details matter
- The zero-knowledge proof implementation referenced is BBS 2023.
- When asked what ZKP they implemented, Richard says they use BBS 2023.
- He says that implementation lives in the credential SDK.
- He also says the SDK includes accumulator-based revocation.
- Dock supports both DIDComm and OpenID for Verifiable Credentials.
- Richard says DIDComm is their default support.
- He also says they support OpenID for VC issuance and verification.
- He adds that they particularly like DIDComm for wallet-to-wallet communication.
Apple Wallet and Google Wallet are not part of this web wallet flow today
- Agne says the cloud-stored credentials are not currently connected to Apple or Google native wallets.
- She says native wallets do not currently support the kind of verifiable credentials flow they want to use here.
- She leaves open the possibility of future interoperability if those ecosystems become more open.
- Richard explains that the main issue is flexibility.
- He says OS-level wallet approaches tend to be more restricted, requiring issuers and verifiers to register.
- That may work for some public ecosystem scenarios, but he says it is not flexible enough for many dynamic business use cases.
- By contrast, the Truvera wallet model is meant to support more flexible private-ecosystem use cases.
- He does note support for the Digital Credentials API in Android mobile flows.
- Richard says if a mobile wallet is installed on Android, they do support the Digital Credentials API.
- But he says the web wallet flow shown in the webinar is different and must explicitly reference the ecosystem wallet.
- In other words, the demoed flow is not a generic “look in any wallet on the device” experience.
Business and organizational wallets are presented as a major next opportunity
- Agne says business wallets may be even more compelling than individual wallets in many cases.
- She says adoption for consumer wallets is hard and takes time.
- By contrast, business identity pains are already very real and many companies are actively looking for solutions.
- She also says web wallets make more sense than mobile wallets in many business contexts.
- Richard says two major ingredients are needed for business wallet use cases.
- First, key access has to work in enterprise environments, including storing keys in enterprise systems and giving access to authorized representatives.
- Second, organizational wallets need delegation capabilities so people can prove things like signing authority or purchasing authority.
- They position delegation as an important future area.
- Agne says delegation is the kind of use case where the holder has to be more visibly involved.
- Richard ends by saying they are working on delegation and will talk more about it when it is ready.
- Both treat it as an important next step for more advanced wallet use cases.
The current product direction is deliberately focused on adoption and ease of use
- Richard says one of the biggest objections they hear is that users do not want to install a mobile app.
- He presents the web wallet as a direct answer to that concern.
- The point is that credentials can still be used without forcing app installation.
- He compares the desired feel to OAuth-like experiences users already understand.
- The team sees hiding the wallet as important for adoption in simple use cases.
- Richard says that today many real-world use cases involve only one or two credentials.
- In those cases, a fully visible and complex wallet management experience may not be necessary.
- They see invisible or low-friction flows as the right place to focus first.
