A year ago, we launched Truvera’s monetizable credentials, an approach to making verified data reusable and sustainable. At the time, it felt like uncharted territory. Since then, we’ve had the opportunity to test our model in the real world, gather meaningful feedback, and speak with teams exploring different paths.
This post, written by Richard Esplin, Dock Labs’ Head of Product, is a reflection on what we’ve learned so far.
It shares the reasoning behind the key decisions we made, what options we considered, the trade-offs involved, and why we ultimately chose this path.
Our goal isn’t to offer the “right” answer, but to contribute to the ongoing conversation by sharing a perspective shaped by real-world implementation.
How does your approach work? (quick context)
For those who don’t want to read the previous post or the documentation, here are the key features of our approach:
- An ecosystem administrator invites trusted issuers and verifiers to an ecosystem. The administrator determines who is trusted to issue credentials based on a specific schema, and who is authorized to verify credentials using that schema.
- The ecosystem administrator can assign a price to a schema. Credentials issued using a schema with a price will be ecosystem-bound—locked to the ecosystem so that only authorized members of the ecosystem can verify proofs of those credentials.
- The issued credential is stored in the holder’s identity wallet the same as any other W3C compliant JSON-LD VC.
- During verification, the holder provides the verifier with a two part proof presentation. The first part contains the disclosed attribute data but is not by itself resistant to tampering. Before trusting the data, the verifier will pass the second part of the proof to the ecosystem broker who will check the verifier’s ecosystem membership before returning whether the data is valid or invalid.
- The ecosystem administrator can generate a report showing which verifiers used which schemas from which issuers. The administrator can then bill the verifiers and pay the issuers.
- Credential issuers and ecosystem administrators cannot see which specific user or credential was verified.
Why we use a broker
Our solution requires an ecosystem broker to approve or reject verification requests.
Currently, this is a centralized service that we provide to ecosystems that use our platform. As standards mature, we foresee a future where ecosystems can have multiple brokers that are provided by competing technology providers.
The broker provides a few important benefits:
- It prevents the issuer from interacting with verifiers, preventing correlation attacks related to network connections and timing.
- It allows ecosystem participants to audit a single broker instead of every issuer.
- It removes the need for issuers to run highly available services for credentials to be used, as specialists in the ecosystem perform that function.
- Ecosystem administrators and verifiers can choose to continue to rely on credentials from defunct issuers. Credentials remain verifiable as long as the ecosystem membership is intact and the broker is online.
- The broker can be moved to a decentralized system like a blockchain along with ecosystem membership information. This would allow credential validation to continue without involvement from any centralized party. Beyond mitigating risks to business continuity, this future architecture would provide additional benefits to privacy and censorship resistance.
Why we don’t provide a payment mechanism
We considered processing the payments from the verifier to the issuer, but our early adopters already have invoicing systems and do not want us complicating their processes.
Using our ecosystem report, they have the flexibility to pay issuers whatever makes sense for their business, and they can give verifiers bulk discounts or make other deviations from the ecosystem list price.
In the long term, we would like to facilitate payments both within our current closed ecosystems and with verifiers who are not ecosystem members. We’d love to discuss our plans with those who are interested.
Why we don’t work with open ecosystems… yet
Outside of core identity credentials issued by governments, open ecosystems of verified data don’t exist today. Trusted data exists within a relationship of issuers and verifiers. This is the model that we are improving.
We are currently working to add features that allow verifiers to pay for credentials without needing ecosystem membership or API integration. We will also make it easier for ecosystems to advertise the credentials they make available, and for potential verifiers to request ecosystem membership.
We look forward to the emergence of open credential ecosystems. We already support the necessary technical standards used in many parts of the world, and we want to participate in the relevant governance schemes.
As payment mechanisms for open ecosystems are standardized, we plan to implement them. We expect that open ecosystems will live alongside closed ecosystems tailored to specific business cases.
We are proud to deliver a solution that enables existing business cases to adopt decentralized identity now, and naturally interoperate with open ecosystems as they grow.
Why we don’t lock only the revocation registry
Because verifiers already need to check a revocation registry to determine credential status, it is a convenient place to enforce payment from verifiers.
Verifiers might see that a credential is valid, but they wouldn’t want to rely on that credential for important business processes without checking that it has not been revoked. We think this works well in many circumstances, and could allow an open ecosystem that captures payment from previously unknown verifiers.
When we presented this approach to our customers, they wanted a stronger guarantee. They were concerned that verifiers might accept credential data without checking the revocation registry, or might cache registry information from one check to bypass paying for subsequent checks. They told us that they want to know that for every verification the verifier can’t tell the difference between valid credential data and a forged credential. Our approach provides this strong guarantee by verifying ecosystem membership before validity is determined. We also verify ecosystem membership before providing revocation status.
Why we don’t have the wallet enforce payment by the verifier
Another approach we considered is for the wallet to check that a verifier has paid for a credential before sharing data with that verifier.
This approach requires more customization to the holder wallet, and it also requires that the holder wallet be trusted to not reveal the credential data outside of the paid path. To enforce that trust, you would have to certify all wallets used in an ecosystem.
Not only does this require changes to the protocol to check that a wallet can be trusted, it puts up additional barriers to ecosystems opening up. Since we implemented our solution, we see that the EUDI ARF is discussing requiring wallet certification for additional reasons, which means that it may not necessarily increase the complexity of a paid credential solution in that ecosystem.
We feel that our approach provides a stronger guarantee than can be provided by wallet certification, because the verification status cannot be checked without the ecosystem confirming the membership status of the verifier regardless of whether the wallet has been compromised.
Why we don’t have the network enforce payment
A blockchain network could be leveraged to enforce that verifiers pay before verification and then reward issuers. Our customers did not like this approach because they wanted the simplicity of payment with fiat currency and flexibility in their payment models.
Why we don’t issue a different key to each verifier
It has been proposed that an issuer could regularly rotate their key and only give the key to paid verifiers, or generate a different key for each paid verifier. These techniques have many of the same properties as our approach with an ecosystem broker while being less flexible and harder to implement in a privacy preserving way.
Conclusion
Designing a model for credential monetization comes with many trade-offs—and we’ve explored a lot of them. The approach we’ve chosen reflects the needs of our early adopters, our desire to preserve privacy, and our commitment to enabling real-world business use cases today.
We don’t believe there’s a one-size-fits-all answer. But by sharing why we chose this path, and not others, we hope to contribute to the broader conversation about how credential ecosystems can be both sustainable and practical.
If you're building in this space or thinking through similar questions, we'd love to hear from you.
