The IDtech Product Canvas and How to Use It

There are many potential uses for verifiable credentials, but oftentimes the examples break down quickly when you start thinking through the details. Our intention is to help people conceptualize the stakeholders needed to make an IDtech product function. Ideally, builders can map out their concept on a single page and easily communicate how it works and the value they’re providing.

What is the IDtech Product Canvas for?

The canvas is a tool to map out a use case for an IDtech product. It’s a visual guide to help align internal and external stakeholders who will be interacting with the product. This post will include some examples of a “filled out” canvas to stoke the imagination and help make these concepts more concrete. We will follow three examples throughout the rest of the post to illustrate how they map onto the questions outlined in the IDtech product canvas.

  

What is the IDtech Product Canvas NOT for?

While the first version of this tool was called the “Trust Ecosystem Canvas,” after a round of feedback we’ve made some adjustments to the name of the tool to clarify that it should not be used to map out an entire trust ecosystem. This tool doesn’t show everything needed to illustrate a regulated, multi-stakeholder, trust ecosystem that encapsulates many use cases. 

 

The canvas is also not meant to show how all of this works in practice and how to operationalize these concepts. We decided this is beyond the scope of this tool, though we’re actively working on other tools to help builders turn the IDtech Product Canvas into a more actionable product plan. For now, the technical details around credential formats, blockchains, trust registries, API calls, etc. are out of scope. 

The one question to answer before filling out the canvas

What is the problem that you’re solving?

 

Said another way, what is the use case you’d like to map out on the canvas?

 

For the purpose of this blog post, we’ll be exploring three use cases. For the featured use case, we’ll answer all questions on the canvas to clearly illustrate how to fill out the entirety of the tool. For the secondary examples, we’ll just provide final outputs.

 

Featured use case:

 

  • A local government is looking to increase tourism by issuing a tourist pass

 

Secondary use cases:

 

  • Increasing security and convenience by issuing digital banking credentials
  • Streamlining license and credential management for travel nurses

How to fill out the IDtech Product Canvas

The Order: Issuer → Holder → Verifier → Provider

We think it makes sense to start with the issuer box, then move to the holder, verifier, and provider. The issuer, holder, and verifier are common roles within the traditional “trust triangle” of SSI. While they’re all illustrated as separate stakeholders, it’s possible for an issuer to be the holder, if they’re self-attesting to a credential like a favorite color or t-shirt size. It’s also possible for the issuer and verifier to be the same party, if they’re both issuing and verifying membership to a company rewards program.

 

Let’s follow a specific example through the canvas, answering the associated questions.

The Issuer

The party who is issuing credentials in your ecosystem

If you answer the questions from the canvas individually, you’ll get an output like:

  • Who is issuing credentials?
    • The city government
  • What credentials are being issued?
    • A tourist pass
  • How and when are credentials issued?
    • When a tourist plans their trip, they request a tourist pass via an online portal
  • What is the issuer’s incentive to participate?
    • To improve the tourist experience and bring additional economic growth and revenue to their region

Once you’ve answered each question, you can put all of the answers together, mad-lib style, to form a single sentence that communicates the concept:

The city government issues a tourist pass when someone visits their city in order to improve the tourist experience and drive economic activity in their region.

Some other examples of final outputs might be: 

A bank issues a membership credential when they onboard new clients, so they can more securely prove who they’re communicating with in person and online.

Or

A healthcare staffing agency issues certified nurse credentials when they onboard a new staff member so that it’s easier for their partner hospitals to verify their staff.

The Holder

The party holding a verifiable credential

  • Who is holding credentials?
    • Tourists hold the tourist pass credential
  • How do they receive credentials?
    • They receive their credential by applying through the city portal
  • What do their credentials grant them access to?
    • These credentials gain them access to discounts at partner stores and experiences around the city
  • How do users view and share their credentials?
    • They can hold the credential as a pass in their apple or google wallet
  • What is the holders incentive to participate?
    • They want to receive discounts at cool shops, restaurants, and experiences

Putting it all together we get:

Tourists apply through an online portal and receive a tourist pass credential in an Apple or Google wallet, so they can gain access to discounts around the city.

Other examples would be:

Banking clients get a membership credential when they open a new account, so they can more easily prove who they are and access banking services.

Or

Nurses receive certification credentials when onboarding with an agency in their employment portal, allowing them to more easily access work in new places.

The Verifier

The party who is checking the validity of credentials, also called a “relying party” sometimes

  • Who is verifying credentials?
    • Local businesses in the city
  • How and when does verification happen?
    • Businesses can scan the tourist pass just like they would scan a coupon.
  • What is the verifiers incentive to participate?
    • Businesses participate in the tourist pass network to drive awareness and new customers to their organizations.

Putting it all together we get:

Local businesses participate in the tourist pass network to drive new customers, and they verify the tourist pass as if it were a coupon.

Other examples would be:

Online portals and in-person branches verify the bank member credential to more securely and seamlessly identify their customers.

Or

Partner hospitals verify certified nurse credentials in order to more seamlessly onboard new staff members.

The Provider

This is the party who is building the ecosystem. They are the ones onboarding issuers, holders, and verifiers, along with determining the governance rules that are required to make the ecosystem work. The provider is the IDtech company who is building the products that make the ecosystem function.

  • How will you onboard issuers, holders, verifiers?
    • The provider will build an online tourist pass application portal, the ability to add the pass to an Apple or Google wallet, and the verification integration for local companies
  • What trust rules must you establish?
    • Tourist passes must only be issued by the city government and should fail to verify if someone issues a fraudulent tourist pass
  • What are legal and regulatory implications?
    • Passes have terms and conditions like only being redeemable once per person per location
  • Where will you generate revenue?
    • The provider will charge an implementation fee to set up this system in a city, along with a monthly charge based on the number of active users

Putting it all together we get:

Providers will build tools for all parties to interact with the tourist pass ecosystem, setting up trust rules and terms and charging a fee to the local government for the set up and maintenance of the ecosystem.

Other examples would be:

The provider will onboard banks, giving them tools to issue membership credentials to their clients, establishing the trusted issuers and verifiers, and charging a fee for the set up and maintenance of the ecosystem.

Or

The provider will onboard healthcare staffing agencies to issue credentials to the nurses in their network, creating value for them to utilize the credentials with partner hospitals. They will charge an implementation fee to set up the system and then charge based on the number of credentials and verifications on an ongoing basis.

What's next after filling out the canvas?

Whether you’re trying to communicate a value proposition to potential partners, investors, or stakeholders within an ecosystem, you could use the canvas as a visual guide to share with others. The idea of verifiable credentials and user-held data is still new. We’ve heard from builders that they’re using this canvas as a tool to get all of their stakeholders aligned on what they’re building.

 

The IDtech Product Canvas won’t be able to illustrate all the work that needs to be done to launch an IDtech product, but it’s a first step. For more tools on how to operationalize the canvas see our previous previous post on the IDtech Builder’s Guide, review our documentation, and sign up for a free Trinsic account to get started today. Or, if you’d prefer to brainstorm live, you’re always welcome to get in touch with our team.

Zack Jones

Share Post

Related Posts