Verifiable credentials (VCs) are the digital upgrade to every piece of paper in your wallet — issued once by a trusted authority, carried on your phone, and shown to any service that needs to check a fact about you. Think of a passport: the government issues it once at a counter, then you flash it at every border on the trip without ever getting a new stamp re-issued per country. VCs do the same for everything else — your CCCD, driver's licence, university diploma, health record, employment proof — and they add a property paper documents never had: a service can verify your credential is real without you handing over the whole thing.
That last sentence is the heart of this article. Most digital identity content stops at "scan a QR code and show your ID on the phone." The real story is what danh tính số (digital identity) built on VCs unlocks, and how a vc vp workflow — the "issue once, present many" loop — turns identity verification from a per-service chore into a one-time, reusable infrastructure.
Figure 1: The Digital Passport Analogy — paper is re-verified at every counter; verifiable credentials are verified once and shown everywhere
Why Every Service Re-Verifies You (and Why That's Broken)
Today, proving who you are is a per-service ritual:
- A bank asks you to visit a branch and show your CCCD
- An employer asks you to hand over a notarized copy of your diploma
- A hospital asks for your health book and insurance card — again
- Every one of them re-enters your name, date of birth, and address into their own database
Each service pays to verify the same facts, stores a copy of the same documents, and becomes one more honeypot waiting to be breached. You, meanwhile, carry photocopies and re-perform the ritual hundreds of times. The system treats identity as if it were impossible to reuse — because with paper, it genuinely was.
Verifiable credentials break that assumption. A VC is a digital document that:
- Is issued once by an authority you already trust (government, university, employer, bank)
- Is signed cryptographically, so anyone can check it wasn't tampered with
- Lives in your wallet, not in the issuer's database
- Can be presented to any number of verifiers with zero re-issuance
The result is the same passport model we've used for a century — but now applied to every credential, with cryptographic verification replacing the human eyeballing of paper stamps.
The Three Players: Issuer, Holder, Verifier
Every VC lives inside a three-party ecosystem defined by the W3C (World Wide Web Consortium), the same standards body behind HTML. The W3C's Verifiable Credentials Data Model 2.0 became a formal web standard on May 15, 2025, and it fixes three roles:
| Role | Who | What they do |
|---|---|---|
| Issuer | Government, university, bank, employer | Signs claims about you into a VC and sends it to your wallet |
| Holder | You | Stores the VC in a wallet and presents it (or part of it) when asked |
| Verifier | Any service | Checks the signature, checks the claim, grants access |
The key design decision: in the old model there was a central identity provider — a database that logged you in everywhere and saw everything you did. The VC model decouples issuing from verifying. The issuer signs once and walks away; the verifier never talks to the issuer in real-time; you are the one who moves the credential around.
Figure 2: The VC/VP Workflow — issued once, presented many, verified in milliseconds without re-contacting the issuer
Anatomy of a Verifiable Credential
Under the hood, a VC is JSON with a signature attached. Here's a simplified one:
`json { "@context": ["https://www.w3.org/ns/credentials/v2"], "type": ["VerifiableCredential", "UniversityDegreeCredential"], "issuer": "did:vn:university-of-science", "validFrom": "2026-08-01", "credentialSubject": { "id": "did:vn:alice-nguyen", "name": "Nguyễn Thị An", "degree": { "type": "Bachelor of Science", "major": "Computer Science" } }, "credentialStatus": { "type": "BitstringStatusListEntry", "statusListIndex": "42" }, "proof": { "type": "DataIntegrityProof", "cryptosuite": "eddsa-2022", "proofValue": "z4s6...signature" } } `
Walk through it piece by piece:
credentialSubject— the claims: who the credential is about and what it says (name, degree, etc.)issuer— who signed it, usually a DID (decentralized identifier) or a URLvalidFrom— when the credential becomes validcredentialStatus— a pointer used for revocation: if the university revokes a degree, verifiers check this list and reject itproof— the cryptographic signature that makes the whole thing tamper-evident
The signature is what turns "a JSON file" into "a verifiable credential." Anyone can modify the JSON — but the moment they do, the signature no longer matches, and the verifier rejects it. This is the digital equivalent of the border officer checking that the stamp and the passport page weren't photocopied.
The VC/VP Workflow: How a Claim Actually Gets Proven
This is where the vc vp workflow becomes concrete. A full round-trip has four steps:
1. Issue
The issuer authenticates you (in person, or via eKYC like Vietnam's ND 13/2023 remote onboarding), signs a VC, and delivers it to your wallet over an encrypted channel. This is the only expensive step — and it happens once.2. Store
Your wallet holds the VC locally. The issuer's database can be deleted — the wallet is the source of truth now. This is why VCs are the foundation of self-sovereign identity: your credentials are not rented from a login database; they are owned by you.3. Present
A service asks for proof — say, "show that you graduated with a Bachelor's degree." Your wallet builds a Verifiable Presentation (VP): a wrapper containing the relevant VC plus a proof that you possess the wallet's private key. This is the crucial step that prevents someone from presenting a copy of your credential — they would need your key to make a valid presentation.4. Verify
The verifier checks three things, all offline and in milliseconds:- Signature valid? (was the VC really issued by this issuer, unmodified?)
- Not revoked? (checks the credentialStatus list)
- Holder bound? (is the presenter really the credential's subject?)
Pass all three → access granted. The verifier never calls the issuer, never stores a copy of your data, and — with selective disclosure — may never even see most of the credential.
` Issuer ──signs──▶ Wallet ──builds VP──▶ Verifier │ │ │ 1. signature valid? │ │ 2. not revoked? │ │ 3. holder is subject? │ └──────── result: VERIFIED ✓ `
Selective Disclosure: Only the Page the Verifier May Read
A physical passport has this property intuitively: at the border, the officer opens to your photo page. They do not read your visa history or your next of kin. But a paper credential can't enforce that — they could photocopy every page.
Verifiable credentials can enforce it. Two mechanisms exist:
- Signature-based selective disclosure — cryptosuites like
ecdsa-sd-2023andbbs-2023let the issuer sign the whole credential once, then let you present only a subset of fields, with the signature still validating over the shown subset.
- Zero-knowledge proofs (ZKPs) — the full power-up. Instead of revealing the field, you reveal a proof that the field satisfies some predicate: "this credential proves age ≥ 18" without revealing the birth date, "this diploma is from an accredited university" without revealing the GPA.
This is exactly where verifiable credentials and zero-knowledge proofs combine into the most privacy-preserving identity system we can build. The W3C explicitly designed VC 2.0 to be crypto-modular — meaning ZKP circuits can plug into the credential format as a new proof type without redesigning the ecosystem.
Figure 3: Selective Disclosure from One VC — only the needed page leaves the wallet; ZKP proves the claim without revealing the data
Example: "Age ≥ 18" without your birth date
Your VC contains birthDate: 2000-05-10. A bar asks "prove you're 18+."
- Without selective disclosure: you hand over the whole VC — name, address, everything
- With a ZK proof: your wallet runs a circuit that checks
today − birthDate ≥ 18 years, produces a zero-knowledge proof, and the bar verifies it. The bar learns one bit — "yes, 18+" — and nothing else
Your birth date never leaves your phone. This is the same logic that powers ZK-KYC pilots on VNeID in Vietnam, where services verify citizenship or age against a signed credential without ever seeing the underlying CCCD data.
Vietnam's Digital Identity: VCs Are Already Here
Vietnam has quietly become one of the most advanced testbeds for this technology, because the legal and platform layers already exist:
- Decree 69/2024/NĐ-CP (effective July 1, 2024) replaced the earlier e-identification decree and formalized the VNeID national digital identity platform, including e-identification cards for citizens and, from 2025, for foreign residents with residence cards
- 62M+ VNeID accounts have been issued by the National Data Centre (C06) as of 2024-2025
- VNeID already lets citizens store documents beyond the CCCD — the social insurance certificate, driver's licence, and health information — all presented in the app with the same legal weight as the physical papers
What Vietnam lacks today is the final layer: issuing those in-wallet documents as W3C Verifiable Credentials so that banks, telcos, and hospitals verify signatures and revocation status instead of re-scanning CCCD photocopies at every onboarding. That upgrade — wrapping the existing VNeID data in VC format and adding ZK selective disclosure — is a software change, not a regulatory one. ND 13/2023 already mandates remote eKYC for onboarding; VC + ZKP is how the same onboarding stops collecting your data at all.
| Layer | Vietnam today | With VC + ZKP |
|---|---|---|
| Legal basis | Decree 69/2024, ND 13/2023 | Unchanged |
| Platform | VNeID (62M+ accounts) | Same app, VC-format documents |
| Identity data | CCCD, social insurance, licence | Same data, cryptographically signed |
| Bank onboarding | eKYC re-scan every time | Verify signature once, keep nothing |
| Age check at a bar | Show CCCD photo | ZK proof "18+", birth date stays in phone |
The Honest Tradeoffs
VCs are not magic. Adopting them means accepting real costs:
- Key management is user responsibility. Lose your wallet keys, lose access to your credentials. Recovery mechanisms (social recovery, custodial backup) add their own trust assumptions.
- Issuer trust remains. A VC is only as trustworthy as the authority that signed it. Verifiers choose which issuers to trust — the signature proves who issued, not that the issuer is honest.
- Revocation needs connectivity. Checking
credentialStatusrequires reaching the status list — offline verification trades away freshness. - Revocation is a control point. The issuer can revoke your credential. That's by design (stolen IDs should be killable) but it means "you own your credential" is ownership with conditions.
- Standards are young. VC 2.0 became a standard in May 2025; wallet interoperability and ZK integration are still maturing.
Verifiable Credentials in the Real World
The pattern is already spreading beyond Vietnam:
- EU Digital Identity Wallet — the European Union is rolling out an EU-wide wallet carrying national ID, driver's licence, and diplomas as VCs, verifiable across all 27 member states
- Digital driver's licences (mDL) — standardized via ISO 18013-5, now being issued in the US, Canada, and EU states
- University diplomas — institutions from MIT to Vietnamese universities are issuing degrees as VCs so employers verify without requesting transcripts
- Enterprise credentials — employment verification, professional licences, and compliance certificates issued once and verified by any counterparty
Each of these is the same "issued once, shown everywhere" pattern — different issuers, different claims, identical cryptography.
Common Questions About Verifiable Credentials
What is a verifiable credential in simple terms?
A digital document signed by a trusted authority (government, university, bank) that you store on your phone and show to any service. Unlike a paper certificate, its signature makes it instantly and cryptographically checkable, and you can present only part of it.What's the difference between a VC and a Verifiable Presentation (VP)?
A VC is the credential itself, issued to you once. A VP is a one-time package you build when a service asks for proof — it wraps the relevant VC plus a proof that you own the wallet key. VCs live in your wallet; VPs are the short-lived envelopes you send out.Do verifiable credentials need blockchain?
No. VCs work with ordinary web infrastructure — the signature alone proves authorship. Blockchain or other verifiable data registries are optional and useful for DIDs, revocation lists, and trust anchors, but they are not required for the core model.What does "danh tính số vc" mean for Vietnamese users?
It means turning the documents already in VNeID — CCCD, social insurance, driver's licence — into W3C verifiable credentials. A bank or hospital then verifies the cryptographic signature instead of re-scanning a photocopy, and with zero-knowledge proofs, services can confirm facts like "age ≥ 18" without ever seeing your birth date or ID number.How do verifiable credentials relate to zero-knowledge proofs?
They're complementary. A VC proves who issued a claim; a ZK proof lets you prove that a claim is true (age ≥ 18, citizenship, credit score) without revealing the claim itself. VC 2.0 is designed to be "crypto-modular," so ZK proofs plug in as a supported presentation method.Can a verifiable credential be revoked?
Yes. ThecredentialStatus field points to a revocation list (e.g., a Bitstring Status List). If the issuer revokes the credential — because it was stolen, expired, or the claim changed — verifiers checking the status list will reject it.
The Bottom Line
Verifiable credentials flip the identity model upside down. Today, every service re-verifies you from scratch because paper credentials can't be reused safely. With VCs, the verification is done once at issuance, the credential travels in your wallet, and any number of services can check its signature in milliseconds — offline, privately, and without copying your data into their databases.
The digital passport analogy is exact: issued once, shown everywhere, verified cheaply. And when you add zero-knowledge proofs, you get a passport with a new superpower — the ability to show a border officer a stamp without letting them read the rest of your book.
Vietnam already has the wallet (VNeID, 62M+ accounts), the law (Decree 69/2024, ND 13/2023), and the documents (CCCD, social insurance, licences) in place. The missing piece is the credential format itself — and that piece is a W3C standard ready to deploy today.
The future of danh tính số is not a bigger database. It's a smaller credential — issued once, shown everywhere, and never fully revealed.
Quick Reference
| Property | Verifiable Credentials |
|---|---|
| Standard | W3C VC Data Model 2.0 (Recommendation, May 2025) |
| Ecosystem | Issuer → Holder → Verifier |
| Issued once by | Government, university, bank, employer |
| Stored in | User's digital wallet (self-sovereign) |
| Presented as | Verifiable Presentation (VP), short-lived |
| Tamper-evidence | Cryptographic signature (proof field) |
| Selective disclosure | SD-JWT, ecdsa-sd-2023, bbs-2023, ZKP |
| Revocation | credentialStatus → Bitstring Status List |
| Vietnam platform | VNeID (62M+ accounts, Decree 69/2024) |
| Vietnam law | Decree 69/2024/NĐ-CP, ND 13/2023 (eKYC) |
| Main risks | Key loss, issuer trust, revocation control, young standards |
| ZK synergy | Crypto-modular VC 2.0 + ZK proofs = prove without revealing |