What is a Verifiable Credential?
A Verifiable Credential (VC) is a tamper-evident digital statement made by one party (the issuer) about another party (the holder) — which any third party (the verifier) can independently verify without contacting the issuer.
The W3C (World Wide Web Consortium) standardised the Verifiable Credentials Data Model in 2019, creating a universal format for digital credentials. A VC looks like this conceptually:
- Issuer: AssureLocker (or a regulated institution)
- Subject: Rahul Sharma, DID: did:web:ind.id.assurelocker.com:holder:1a2b3c...
- Claim: KYC assurance level: HIGH, verified via Aadhaar OTP + face liveness
- Proof: Cryptographic signature by AssureLocker, verifiable against its public key on the registry
- Validity: Issued 2025-01-15, valid until 2026-01-15
No raw Aadhaar number. No document scan. Just a cryptographically verifiable assertion.
The trust triangle: issuer, holder, verifier
Every verifiable credential involves three roles and one shared reference point. The relationship is usually drawn as a triangle, because trust flows in a particular direction: the issuer signs once and steps away, and the verifier checks that signature without ever having to know, or contact, the issuer directly.
The issuer
The issuer makes a claim and signs it. In AssureLocker’s case the issuer is a regulated institution — a bank, NBFC, or other obliged entity — that has run a KYC process and is willing to attest to its result. The issuer holds a private signing key and publishes the matching public key, under a Decentralised Identifier (DID), to the registry. Its signature binds four things together: the claim itself, the issuer’s identity, the validity window, and a reference to the holder’s own key — so a credential cannot be silently altered, back-dated, or replayed by someone who is not the holder.
Issuance is not a one-way street: the issuer can also publish a revocation statusto the registry, so a credential can be marked invalid before it naturally expires — for example if the underlying KYC is later found deficient. As an issuer, AssureLockerattests only to the assurance level it computed from source checks; it does not make a lending decision, score the subject’s creditworthiness, or guarantee any outcome. That judgement stays with the institution.
The holder
The holderis the subject the credential is about, and the party that decides when to present it. A holder might keep credentials in a consumer wallet, inside an institution’s own system, or on AssureLocker’s holder surface — the format is identical regardless. What matters cryptographically is holder binding: the credential is tied to a key the holder controls, so presenting it proves possession, not merely knowledge of a value someone could have copied. Presentation is always holder-initiated and consent-gated; nothing moves without the holder choosing to share it — and, as covered below, the holder can often share far less than the whole credential.
The verifier
The verifier(the relying party) receives a presentation and runs a fixed set of checks: that the signature is valid against the issuer’s registered public key; that the issuer is one it is willing to trust; that the credential has not expired; that it has not been revoked; and that the holder-binding proof matches the party presenting it. Only if all of these hold does the verifier accept the claim — and even then it applies its own policy about which issuers and which assurance levels it will act on. AssureLocker supplies the verifiable evidence; the verifier still makes its own decision.
India's identity stack — where VCs fit
India has built one of the world's most sophisticated digital identity stacks. Understanding where W3C VCs fit requires mapping the existing layers:
| Layer | System | Role | VC relationship |
|---|---|---|---|
| Root identity | Aadhaar (UIDAI) | Biometric-anchored unique identifier | Root of trust for VC issuance |
| Document vault | DigiLocker (MeitY) | Stores government-issued documents | Source documents for VC claims |
| KYC record | CKYC (CERSAI) | Central KYC repository | VC can assert CKYC completion |
| Financial data | Account Aggregator (RBI) | Consent-based data sharing | Complementary — financial VCs possible |
| Credential layer | AssureLocker (W3C VC) | Reusable identity assertions | The portable layer above all others |
W3C Verifiable Credentials do not replace Aadhaar or CKYC — they sit above them as a portable, reusable assertion layer. AssureLocker uses Aadhaar as the root of trust and CKYC completion as one of the claims in a credential.
AssureLocker’s approach vs. consumer SSI wallets
It is worth distinguishing between two types of verifiable credential deployments:
Consumer SSI wallets
Consumer self-sovereign-identity (SSI) wallets focus on giving individuals a place to hold their own VCs from various issuers. The use case is consumer-driven: “I hold my own identity and share it when I choose.”
B2B trust infrastructure (AssureLocker)
AssureLocker is not a consumer wallet. AssureLocker is a B2B infrastructure platform that enables regulated Indian institutions to issue, verify, and manage verifiable credentials as part of their existing KYC and onboarding workflows.
The distinction matters because the regulatory requirements, the integration patterns, and the buyer are completely different:
- An NBFC's compliance head doesn't need a consumer app — they need an API and an audit trail.
- A bank's onboarding system needs a verification endpoint, not a wallet SDK.
- A regulator needs registry-anchored evidence of credential lifecycle events, not a mobile app UX.
AssureLocker provides the infrastructure layer. The wallet (or lack thereof) is an implementation detail on the holder's side.
Framed honestly, AssureLockeris a trust-service provider: it issues credentials on behalf of regulated institutions and lets other parties verify them. It does not lend, does not make the accept-or-reject decision, and does not guarantee any subject — those responsibilities stay with the institutions that rely on the evidence. You can see how this runs end to end in the DigiKYC platform.
The W3C standards AssureLocker implements
- W3C Verifiable Credentials Data Model 2.0: The credential format itself — JSON-LD with cryptographic proofs.
- W3C Decentralised Identifiers (DIDs) 1.0: Cryptographic identifiers for issuers and holders, anchored to an immutable registry.
- OID4VCI (OpenID for VC Issuance): The protocol for issuing credentials to holders.
- OID4VP (OpenID for VC Presentation): The protocol for presenting credentials to verifiers.
- SD-JWT VC: Selective disclosure JWT credentials — allows holders to prove specific claims without revealing everything in the credential.
- AnonCreds: Anonymous credential format supporting zero-knowledge proofs for privacy-preserving verification.
Selective disclosure: proving less to reveal less
A paper KYC document is all-or-nothing: to prove one fact you hand over the whole page, including every other fact printed on it. Selective disclosure breaks that trade-off. With SD-JWT VC, the issuer signs each claim in a way that lets the holder later reveal a chosen subset while the signature still verifies over exactly what was shown — no more, no less.
In an Indian context this is the difference between usable and over-collecting. A holder can prove “KYC assurance: HIGH” to an onboarding flow without disclosing their date of birth; prove they are over 18 without revealing the birth date that establishes it; or prove that CKYC was completed without exposing the underlying documents behind it. The verifier learns the single fact it needs, the raw Aadhaar number never travels, and the data-minimisation expectations of the DPDP Act are met by construction rather than by promise.
AnonCreds goes one step further, supporting zero-knowledge proofs of a predicate— proving that a statement such as “age ≥ 18” holds without disclosing any field at all, not even a redacted one. Institutions weigh the broad interoperability of SD-JWT against the stronger privacy of AnonCreds differently, so AssureLocker implements both and leaves the choice with the deploying institution.
Registry-anchored trust and offline verification
The shared reference point in the triangle is a verifiable data registry. It is deliberately boring: it holds issuer DIDs, their public keys, and revocation status — and no personal data. In AssureLockerthat registry is anchored to immutable registry infrastructure, so an issuer’s key material and a credential’s lifecycle events cannot be quietly rewritten after the fact.
Anchoring the keysrather than the credentials is what makes verification independent of the issuer’s availability. Because the verifier reads the issuer’s public key from the registry — and can cache it — it can validate a presentation with no live call back to the issuer at all. That has three consequences that matter in the field:
- It works offline. A verifier with a cached trust list and status list can check a credential in a low-connectivity branch or on a rural agent visit, where a real-time call to the issuer would simply fail.
- It leaks nothing to the issuer.Because there is no phone-home step, the issuer never learns where, when, or how often a holder presents a credential — a privacy property a call-the-issuer model cannot offer.
- It removes a single point of failure.Verification does not break when the issuer’s servers are slow, down, or decommissioned.
The one value that genuinely changes over time is revocation. Verifiers handle it by reading a published status listfrom the registry, which can be cached and refreshed on a chosen freshness window: a strict verifier re-fetches it before every high-value decision, while a field verifier may accept a recent cached copy. Either way, the registry stores only hashes, keys, and status — never the credential or the personal data inside it, consistent with AssureLocker’s minimum-data-retention posture.
Why open standards matter
Proprietary credential formats create vendor lock-in. An institution that builds on a bespoke identity format cannot interoperate with other platforms, other countries, or future regulatory frameworks.
W3C VCs are already being adopted by the EU (eIDAS 2.0), the UK, Australia, and Singapore. India's Digital India and IndiaStack vision is directionally aligned. Institutions that adopt W3C VCs today are building on a foundation that will only become more valuable as interoperability requirements grow.
To understand how Aadhaar is used as the cryptographic root of trust in AssureLocker's VC issuance, read our guide on Aadhaar-Anchored DID in India. To see how credentials are presented using OID4VP, see our OID4VC in India guide.