Supercharging the IDtech Category: Trinsic’s Vision for the Future

A yearly update from Trinsic’s CEO on the decentralized identity market and where Trinsic is heading next

It’s been about a year since our funding announcement and we’re excited to share what we’re seeing in the decentralized identity market and how it has influenced our product direction going forward.

Brief history of Trinsic

In 2017, I started my journey in identity at Sovrin Foundation, where I worked on strategies for driving adoption of self-sovereign identity (SSI) for almost two years—until realizing the best way for me to impact adoption was to build a great SSI-powered product. In 2019, I started Trinsic (originally, Streetcred ID) together with Tomislav Markovski and Michael Boyd, two of the original set of open source developers in the Hyperledger Aries project. Suffice it to say we care a LOT about SSI. At first, we did a variety of things.

  1. We built open source libraries and participated in standards groups.
  2. We did consulting for companies looking to adopt those open source projects (including training the team at Commerzbank on launching what is now Lissi/IDUnion).
  3. We built cloud infrastructure and developer tools based on these open source libraries which were used by hundreds of developers around the world.
  4. We built the Trinsic Studio, an issuer/verifier dashboard that required no code, allowing anyone to issue credentials FREE in less than five minutes.
  5. We opened it up for the developer ecosystem and to enterprise customers and had strong revenue growth sufficient to raise a competitive seed round.

Overall, we were not focused enough. Look at the five items in the numbered list above. Consulting companies will always build subpar developer tools. The talent to build amazing consumer products is different from that needed to build standards. Et cetera. The lack of focus meant we weren’t being best-in-the-world at anything.

Where we were wrong about adoption

Adoption is the self-sovereign identity industry’s elephant in the room. I’ve written about this several times before. The ratio of interest (even zealotry) to real-world traction in this space is mind-boggling.

Our original belief was that the solution was to make it easy for anyone to become an issuer or verifier of credentials. But that was the wrong framing, because nobody is sitting around thinking “I wish my identities were self-sovereign” or “if only I could issue verifiable credentials, my problems would be solved!”. Nobody wants to verify credentials that don’t exist—which is indicative of the intractable chicken-and-egg problem with this strategy. No issuers will have an incentive to start until verifiers exist—but no verifiers will sign up until there are issuers. (More on how to solve this problem later.)

The state of the decentralized identity market

While we were experimenting, dozens and dozens of undifferentiated competitors were entering the space we were in. Today, there are almost 100 companies (that I’m aware of) building practically the same thing we originally built—a wallet app, a dashboard for issuing & verifying credentials, and some APIs for integrating. Many of these products are practically shot-for-shot remakes of things we did three years ago; including things we learned through painful experience are doomed to fail.

This is tragic for our industry, because tens of thousands of person-hours and millions of dollars are being wasted reinventing the wheel. Just a few things people have mentioned to me in off-the-record conversations:

  • “We have 4 engineers (~$500k/yr) on our ‘protocol team’ maintaining SSI standards full-time.”
  • “We went with an open source codebase, but an update broke our product, and we had to spend ~$25k on external consultants and a ~month of delay to fix it.”
  • “Our budget for building our product was $350k. It ended up taking 10x that amount and more than a year longer than projected.”

This results in a lower probability of success for each company, slower progress, and more competing instead of pie-expanding.

An industry stuck spinning its wheels

As companies have proliferated, so too have the technical standards/protocols to choose from (these are partly related, of course). There was a time when JSON-LD Verifiable Credentials and Anoncreds were the two relevant credential formats. Today, there are almost 20. There are 169 DID methods and at least another dozen supporting protocols.

But as I wrote in another post:

“despite divergence [of standards] being a healthy part of new technologies finding “product/market fit,” its downsides are obvious: confusion in the market, duplication of efforts, and delaying the benefits of interoperability.”

When you combine 100+ companies who are all trying to keep up with 100+ standards, you end up with lots of spinning wheels and little forward momentum. The many-to-many problem grows with each new standard, protocol, and credential format introduced.

Adoption should be the north star

If we continue down this road, I fear the result. Big tech, proprietary ‘reusable ID’ schemes, and surveillance companies are not waiting around. While the SSI & decentralized identity communities are sitting in committees at the Linux Foundation figuring out governance, theorizing about new “layers” of interoperability, and waiting for governments to mandate open wallet use top-down, proprietary reusable ID schemes are racing to onboard tens of millions of users at breakneck pace. Relying parties are being brought into those ecosystems instead of verifiable credentials. Simultaneously, entire industries are lobbying governments to deploy centralized or surveillance-based approaches.

Adoption is the existential risk for verifiable credentials.

Companies implementing verifiable credentials should focus on the only thing that matters: adoption. Otherwise, not only will their company/product fail, but we’ll collectively miss an important moment in time to create a better world for humanity—a world where people can spend less time waiting in lines, filling out forms, and oversharing their personal data. To repeat myself: it doesn’t matter how elegant or interoperable the standards are if no one uses verifiable credentials—none of it matters.

What’s missing from the issuer-holder-verifier model

The W3C VC Data Model was “formed [on] the basis” of the image above. When you look at the image, ask yourself: “Who will drive adoption: issuers, holders, or verifiers”? The reality is that none have an incentive to adopt in isolation—that is, if verifiable credentials are the only thing on the menu, issuers will only adopt once verifiers are present, and visa versa. Said another way, verifiable credentials won’t drive their own adoption. Despite this, companies (including Trinsic, previously!) went ahead and built software that was limited to issuer/verifier/holder stuff.

Providers—the missing participant

Provider: The entity that creates the ecosystem, onboards the issuers, holders and verifiers and establishes trust.

IDtech providers are the ones driving real-world adoption of verifiable credentials. Providers solve two problems for the participants in a verifiable credential ecosystem:

  • Providers give participants a product to adopt. They build products that solve real problems for end-users. Providers find nails that need hammers, instead of wielding a hammer and searching for a nail.
  • Providers create the ecosystem where trusted credential exchange happens. Participants in a verifiable credential ecosystem won’t adopt in isolation—providers bring the ecosystem participants together simultaneously, or proxy one side of the ecosystem, to enable value creation immediately.

Our focus: IDtech infrastructure for providers

With the context sufficiently set, what are we going to do? We need to focus in order to be the best in the world at something—and since our objective is to drive successful adoption of verifiable credentials, the answer is clear. We’re focused specifically on providing the best infrastructure for companies building reusable identity products—or, infrastructure for providers. We can be the best in the world at providing infrastructure, so our partners can be the best in the world at solving problems for their customers.

Trinsic's product for providers

What does this mean for our product and our vision going forward? We’ve designed our product to solve for the unique challenges that hinder adoption of decentralized identity in order to create a viable alternative to proprietary identity schemes. Below we’ve outlined some of the core design decisions driving our platform:

Zero-onboarding identity experiences

We build for adoption first. In the spirit of successful fintech, open banking, and web3 products, Trinsic allows you to deliver verifiable credentials with little-to-no user onboarding. This means wallets can be embedded in existing workflows and your users don’t need to download additional apps in order to get started. Providers can tap into an existing user-base by creating wallets only accessible by individuals and pre-populating their wallets with valuable credentials.

No-code issuer portal and white label wallet

While Trinsic is known for easy-to-use SDKs and a top-tier developer experience, we consistently heard from teams that they need to sell their product vision before writing any code. We’ve recently launched a new set of tools that empower teams to build demos quickly and communicate what’s possible with verifiable credentials.

Our new release features a wallet that can be customized with your branding, where only your users can log in and view their credentials. Additionally, without any code, you can invite someone to join your ecosystem as an issuer and give them a portal to start issuing verifiable credentials. You can check out these features in the dashboard and start building your demo environment.

Solving the many:many problem of standards

We focus on staying updated on standards work and implementing the most adoption-ready protocols into our platform. Providers building on Trinsic can get the latest and greatest developments without spending the resources to research newly proposed standards and dedicating engineering resources to building integrations. We do that for you.

This also means that you’ll be able to interoperate across ecosystems that are getting adoption. If you need to support a standard that your customers or users require, we can build the bridges.

Pragmatism that respects user control

Through launching fully decentralized/self-sovereign products, we’ve learned through our own experience (and from our peers in the industry) that it’s not a path to adoption. Instead, products that meet users where they are and guide them to a self-sovereign future are the ones that will succeed. Our infrastructure is designed to map to the vision of SSI long-term. This means we give developers choices about how they implement their solutions. You can sign credentials with Trinsic and send them to edge devices. You have the option to upgrade DIDs to a blockchain. You can decentralize your trust registry. You can verify Trinsic proofs with other libraries.

As a user, you can export your credentials from Trinsic and import them to a wallet of your choice. As a provider building on our infrastructure, you can export all of your data and delete it from our service and decide to go elsewhere. Trinsic allows you to launch adoption-ready products right now with the comfort of using open standards, so you can progressively decentralize.

Supercharging the IDtech category

We’re in a critical moment right now where the possibility of a dystopian identity world is very real. Decentralized identity, self sovereignty, verifiable credentials are all potential solutions to this problem and could lead the world in a better direction. But if IDtech companies fail to bring their products to market, we don’t stand a chance against the incumbents.

Trinsic wants to be a superpower to companies who are serious about bringing products to market that honor user control and provide great user experiences. If you’re ready to create the future of identity, start building with Trinsic, or get in touch with our team.

Riley Hughes

Share Post

Related Posts