Verifiable Credentials
Background
Governments interact with the individuals in their country for various purposes - to offer jobs, subsidies, benefits, contracts and more. Private entities such as banks, businesses and educational institutions also interact with individuals to deem eligibility and validity for a number of programs.
The foundation for any of these processes is to establish the attributes of the individual by verifying documents to determine their eligibility for services or benefits.
In the current scenario, both sectors (public and private) spend considerable amounts of effort into verifying the authenticity of the individual’s data, with no guarantee of success. Mistakes can be costly - with large sums of money and opportunities not reaching the intended people. They can also be dangerous - with unverified individual’s gaining access to sensitive systems and processes.
Digitally verifiable credentials, a simple, marginal improvement to existing systems, built using a Digital Public Infrastructure approach can solve this problem at scale.
What are verifiable credentials?
Any issuing authority (whether they are issuing national identity, school certifications, income certificates, recommendation letters, driving licences, tax identity, etc) can make their certificates tamper proof while retaining full autonomy over it.
Paper Certificates can contain a digitally signed online / offline QR code that connects the paper based document to an official server and fetches the original certificate for verification. The soft copies of the certificates can be digitally signed to add an extra layer of security guaranteeing authenticity.
In this method, no centralisation is required. It allows various departments to retain control over their certificates, and prevents single storage databases that inadvertently become the target of cyber attacks as well as leakages.
How does it work?
The application programming interfaces (APIs) of different issuing authorities are opened up to create a real time data fetch between systems. Data is fetched (but not stored) based on API calls made from one system to another asking to validate a particular piece of data based on the individual’s consent. Any data issuing authority and any data-consuming authority can link to the same network by connecting their APIs and clearing their own verification as per the guidelines issued by the country.
Data should only be verified based on an individual’s consent. As with all DPIs, the person should be at the centre of the infrastructure.
An individual can specify the data he wants verified, the party he wants to share it with, and the period of time he wants to share it for. The consent is granular, purpose specific (eg for a loan or benefit), simple to understand, and revocable.
There can be three broad modes of data sharing:
Consent and data are shared at the same time through the same platform: In this model, the interface itself (wallets or e-lockers) obtain user consent through their platform and share the data immediately. For example, digilocker in India
a) Wallets: In digital wallets, users can provide their consent to fetch their digitally signed documents from various entities. These documents are stored on the user’s dashboard and can be shown to anyone. They empower the individual by giving them control over all their verified credentials.
b) e-Lockers: In this, the documents are not stored on any dashboard. When the user provides consent, these documents can be fetched from the provider and displayed to the user or the data-consumer he provides his consent to. These eLockers are managed by one or more entities in the country and allow federation of verifiable credentials.
Consent and data are shared separately and managed through different entities: In this model, the consent is managed through a third-party intermediary known as a consent manager. These entities obtain user consent as per the consent artefact specified and communicate that to data-providers who then separately share that data to the data-consumers. For example, the Account Aggregator ecosystem in India.
Consent is managed through the data provider: In this model, data is shared between two entities such as two government departments without the individual being directly involved (though ultimately for the individual’s benefit). Consent is provided by the data-provider itself at the time of sharing the data.
There are many examples of this DPI:
Singpass in Singapore is now working to issue credentials fetched by the Singpass ID. The EU has recently published digital wallet specifications; Argentina has verifiable credentials as does India, the Open Wallet Foundation strongly drives the portable identity and credentials agenda. Some US states also accept ISO standard mDL (mobile drivers license) credentials (eg California).
Benefits:
Opening up APIs also allows for multiple market players to build direct and indirect products over it. For example, various user-facing applications can be developed, focusing on different target groups, languages, purposes etc. that allow people to seamlessly provide consent (according to a consent artefact specified) to have their data fetched and shared with third parties.
Verifiable credentials empower individuals and institutions alike; they enable people to own their data and allow institutions to focus on delivering last-mile services on the basis of that data.
It is only when we can easily know about each individual that we can effectively build for each individual.
Summary of the DPI approach to verifiable credentials:
| Technical Layer | Governance Layer | Market Layer |
|---|---|---|
a) Using open spec/standard APIs allow interoperability between data-issuing authority and any data-consuming authority b) Embed online / offline machine readable and digitally signed QR codes on all physical documents c) Digitally sign all documents issued online - this can be done by a department on behalf of multiple agencies, by departments or private entities themselves. d) Allow verifiable credentials to be available through eLockers or Wallets. | a) Specify a consent artefact that articulates to the individual what data they are consenting to share, for what purpose, with whom, for how long, and methods to revoke consent b) SROs of market players can be set up to monitor user-facing applications dealing with consent. All applications must be data-blind (they cannot access any data, the data-fetch happens behind the scenes, they are simply for user experience) | a) Allow for multiple applications to be built that cater to different sections of society based on region, language, purpose, etc. |
Additional Resources on Verifiable Credentials:
W3C standards on VCs
Sunbird RC's wiki on VCs
DIVOC (a credentialling infra that has issued 20 m+ documents):
Verifiable credentials 101 deck
Last updated