How to create an effective Decentralized ID Model

The Decentralized ID Model is a strategic template used by Tykn to effectively develop and document an organisation’s Decentralized ID ecosystem. Using this template will lead to insights about how Issuers, Provers and Verifiers interact, how and what information is exchanged and what key partners and resources are required.

Download Free Template Today

When you create your Decentralized ID model you will:

  • Align your team on what value is being provided to Issuers, Provers and Verifiers and how these 3 entities interact.
  • Map what data is being issued and verified.
  • Determine what key partners and resources are required to develop a Decentralized ID ecosystem.
  • Work out possible revenue streams and your cost structure.
  • Understand your Decentralized ID ecosystem in a simple, structured way.

How to use the Decentralized ID Model

Step 1: Issuers

Who are the issuers that you are going to work with? You can have multiple issuers so you need to list all the organisations/entities that are going to be issuing trusted data in your ecosystem.

Key Partners

  • Someone needs to provide a place – the Issuer Wallet – where the Issuer can store their private keys and any details about that themselves. Who will provide the Issuer Wallet?
  • The Issuer Services is what enables the Issuer to issue credentials and write on the blockchain. Who will provide the Issuer Services?

Step 2: Provers

Provers are those who receive the Credentials and use them to prove something about themselves. Provers can be your users, customers, citizens, employees, etc. Who is going to receive the credentials issued by the Issuers?

Define the people that need to verify things about themselves.

Pro tip: anything a Prover attests is only as trustworthy as the issuer who provided it.

Step 3: Verifiers

Verifiers are people, organisations or things that want to verify something about a Prover in order to perform a given action.

Who are those entities?
What is the action enabled by the verification of trusted data?

Key Partners

  • A Verifier needs a Verifiable Credentials Toolkit to be able to request Proofs and read the blockchain. Who will provide this Toolkit?

Step 4: Credentials

What credential will be issued to a Prover?

What Schemas do you need? A Schema is a template outlining the verified data you can issue or verify from your Provers. The Schema contains attributes. Attributes are “fields” of verified data you would like to issue (i.e: Name, Email address, etc). Note that, in many cases, you might not need to create a Schema from scratch. You can browse and use existing Schemas. If there’s already a Schema for your use-case – like a Passport Schema, a European driver’s license Schema, etc – use it. Existing Schemas based on international standards are easier to verify.

How will the credential be issued? (Programatically or manually through a web console)

How will the credential be sent to the Prover? (Via email, SMS or QR code)

Step 5: Wallet

What type of Wallet will the Provers have?

The wallet is where a Prover, the user receiving a Credential, will store their credentials. There are two types of wallets:

  • Mobile Wallets, also known as Edge Wallets, store Credentials on a Prover’s device such as: Mobile App Wallets, Browser Wallets (like Metamask) or Hardware Wallets. From a credential issuer’s perspective, the Mobile Wallet is the ideal option if they don’t want any Personal Identifiable Information stored on their servers or the cloud. All personal data is stored on the users’ device.
  • Web-based Wallets: Some organisations don’t want to introduce the friction of having their users download an app. Web-based identity wallets allow organisations to integrate Verifiable Credentials into their existing web-based journeys. The users’ data, instead of being fully on the user’s device, is encrypted and stored in a personal vault in the cloud. Only the user can access the data and only the user can decide who to share it with.


Key Partners

  • Who will be the Wallet provider?

Note: If you already have an app you can use an SDK that creates a decentralized identity wallet inside your app. If you don’t have an app but would like your users to have an identity wallet, there are several “off-the-shelf” mobile wallet apps available.

Step 6: Proofs

Proofs are how the data contained in the credentials is presented to Verifiers for verification. What attributes does the Verifier need to request from Provers to allow them to perform a given action?

Decentralized Identity allows Provers to selectively disclose their data and allows Verifiers to process that data without the need to store it. With that in mind:

  • How much data does the Verifier actually need?
 Can a Prover use Selective Disclosure? (does the Verifier need the Prover’s entire ID card data or does the name suffice?)
  • Does a Verifier really need to store the requested data on their system once the verification is done?

Step 7: Value

This is all about why you’re looking to implement Decentralized ID.

What value are you delivering to Issuers, Provers and Verifiers?
What problem are you helping to solve?
What needs are you satisfying?

Step 8: Cost Structure

Which Key Resources are most expensive?
Are you building or buying?
If you’re buying, are you integrating via API or do you want a whitelabeled fully managed solution?
What are your cost drivers? (Number of transactions, number of wallets, etc)

Integrating Decentralized ID can be easy nowadays. If you have devs on your team, there are easy APIs you can call to integrate it with your current user journeys and Mobile SDKs to supercharge your own app with decentralized identity capabilities.

You can even buy a whitelabeled and fully managed Decentralized ID solution, deployed on your own private blockchain.

Taking the DIY route is a bit more tricky. To build your own Decentralized Identity solution your developers need to learn/know blockchain, cryptography, P2P Networking, Rust, and more. We estimate it takes at least 6 months to get a dev up to speed on it. We know because we’ve been there!

Step 9: Revenue Streams

Who is willing to pay for this service? Are you going to charge Issuers, Provers and/or Verifiers?
How much are they willing to pay?
Do they currently pay for these services today? How much?

Download Free Template