A hand holding a cell phone at an angle, in a dark room, with coloured spots of light
Image: Rodion Kutsaev (@frostroomhead) on unsplash.com

How you can implement VCs

Many technology parts of VCs are provided by the Government of British Columbia’s Digital Identity & Trust Program. The diagrams below show how BC DITP components could interact with business systems and individuals in a VC ecosystem.

The four-part VC ecosystem diagram, with issuers issuing to holders' digital wallets, who then send VC proofs to verifiers, who verify those on the distributed ledger
An architecture diagram of the flow back and forth as a holder (a person) gets issued credentials, and then uses them to verify themselves to a verifier.

Becoming an issuer: step-by-step

Becoming an issuer or validator of VCs is a combination of:

  1. understanding your business processes, and
  2. getting your technology team up to speed with the right concepts and tools.

Here’s the process involved.

The five step process: coordinate with verifiers, decide VC actions and contents, organize your data, set up the technology, prepare everyone for launch

Let’s look at a step-by-step overview of becoming an issuer.

Step 1: Coordinate with verifiers and prove the business case

Before you begin any technical steps you need to have initial verifiers on board. This is because there is (to start with) a close relationship between you and verifiers: without verifiers, there is no point in issuing VCs, and without you issuing VCs, there’s no point having verifiers. So verifiers need to be as engaged as you are, if your VCs are to gain traction.

Two circles, each made up of arrows arranged end to tail. One has issuers supply and verifiers demand, the others has issuers and verifiers supply, and holders demand.

Before exploring a VCs Proof of Concept you should talk to verifiers and coordinate efforts, and also ensure there’s a solid business case for why individuals would wish to hold and use these VCs.

Step 2: Decide VC actions and contents

The next step in becoming an issuer of VCs is deciding exactly what information to issue in your new VC, and when you will issue them.

To decide what you will issue, the permit or other physical credential that you already issue to people is your starting point. You will already have a list of fields that make up that credential, such as name, address, expiry date, and so forth.

However, because you are starting afresh online with a new credential, this is your opportunity to expand or change the fields to better meet your needs.

You can ask yourself questions like:

  • What information do other organizations always want to know about our existing credentials, that we could build into this new VC?
  • What feedback have we had from other organizations about the structure or information types in our existing credentials? (This could be an opportunity to fix things.)
  • What parts of our existing credential could be removed, as they are used only for human verification of the credential which will no longer be necessary? (A person’s Date of Birth would be a good example.)
  • Now that our credential will be digital, what additional information could be added that didn’t fit on a physical credential before?
  • What could the VC now contain that wasn’t desirable before because that information couldn’t be encrypted?
  • What do other credential issuers across our industry and around the world include in their credentials?
  • What could we now include in the VC, knowing that a person may not need to disclose the whole credential to a verifier, just the parts that are needed?

Once you decide on the structure of the credential—which is called the credential schema— it is more difficult to change later, so take the time now to decide exactly what your VC holds.

(Note that in time, credential schemas will likely become more standardized, and you will not need to reinvent the wheel. However, in these early days, you have the opportunity to innovate and explore what works best.)

Once you have decided what you will issue, you will also need to decide when you will issue VCs. For example:

  • Exactly when will you create, update, and revoke credentials? For example, will certain information need to be available or formally signed off before a credential can be issued?
  • What business events and processes will trigger those actions?
  • If you are extending an app or web service to handle credentials, what specific events in the app or service will trigger those actions?

Often, thinking about these action points will improve and formalize business processes as a side benefit.

With your new VC schema and processes decided, it’s time to organize your data so you can issue those VCs to people.

Step 3: Organize your data

When you issue your new VC to a person—perhaps they have logged into your website and requested it, for example—you will need to have all of the VC data online and fully available, so it can be issued at a moment’s notice.

Your data systems may not support this at present. Perhaps, for example, someone currently has to manually enter information into a credential document. Or maybe not all of your databases of credential information are fully online.

Your technical teams will need to organize your data so everything in your VC can be accessed automatically and instantly by the issuer software.

Before and after diagram of organizing data. Before, there is a manual process of getting credential data from a partial database, spreadsheet, and/or filing cabinet. After, issuer software automatically takes database data for VCs.

Step 4: Set up the technology

The next step is for your tech team to get a issuer software service up and running, first as a Proof of Concept and then with a plan towards going live. The Issuer Kit example from the BC Gov’s DITP team is one example of software that’s available and working today.

Below is a high-level view of how the technology will look once set up.

A high-level technology view for issuers

Step 5: Prepare everyone for the new service

All involved parties will need to know that you are issuing VCs—especially if you are phasing out another way of issuing credentials.


  • Verifiers need to know when you plan to start issuing VCs, so they are ready to launch their verification service at broadly the same time.
  • Holders (individuals) will need to know about this new service, including how it works, whether they can use the old approach alongside the new one, what technology they need (e.g. which digital wallets they can choose from and download), and so forth.
  • Your teams will need to understand the technology and processes fully, so they can support individuals who get in touch with questions, build VC considerations into governance steps (e.g. for when the license details get updated), maintain the technology seamlessly, update training materials, and so forth.

It is likely worth having a brainstorming session on this preparation as far away from the launch date as possible, so that all of your business systems and processes support this new service.

Becoming a verifier

The steps to become a verifier are much simpler than becoming an issuer. This is because:

  • The structure of the credentials (the schema) has already been defined by the issuer
  • The verification of credentials is handled by a managed DITP service
  • The managed DITP service should integrate easily into your existing website

Here is an overview of the technology setup you will require. You will actually have much of the “Your Business Logic” and “Your Website” parts already in place, so integrating the Verifier Engine should be fairly manageable.

If you’re not using the VCs to grant access to a website—for example, if you want to use VCs to grant access to a building—then you may need different software, and perhaps some additional technology. Contact one of the BC teams if you need to discuss your ideas further.

A high-level technology view for verifiers

Also In This Section


Need to speak to someone in the BC community about Digital Trust? Get in touch.