Verifiable Credentials (VC) Implementation Guide
Tomohiro Iida · Published May 16, 2026 · Updated July 12, 2026
Verifiable Credentials (VCs) are a W3C-standardized specification for "electronically signed attribute credentials that a third party can verify as genuine." They run on a three-party model — Issuer, Holder, and Verifier — and can be secured using one of several formats, including JSON-LD/Data Integrity, JWT-VC, SD-JWT VC, and COSE-VC. The VC Data Model 2.0 became an official W3C Recommendation in May 2025.
This article organizes VCs from an implementation standpoint: the three-party model, how to choose among the securing formats, the major libraries, and the implementation flow. Read it alongside DID as a guide to designing identity-verification and credential-issuance systems.
The three-party model of a VC
Every VC design starts from the three-way relationship between Issuer, Holder, and Verifier. Clarifying who issues what, and who verifies what, is the first step.
- Issuer
- The party that issues the VC — a university, local government, company, or country. The issuer signs the VC with its private key to guarantee authenticity. Examples: a university (degree), a local government (residency record), a healthcare provider (prescription), a company (employment certificate).
- Holder
- The party that receives a VC and stores and manages it in their own wallet — in most cases, the end user themself. Examples: an individual acting as a student, citizen, patient, or employee.
- Verifier
- The party that receives a presented VC and verifies it — checking the signature, expiry, and revocation status, and judging whether the attribute information can be trusted. Examples: a hiring company, a financial institution, a car-rental company, a pharmacy, an e-commerce site.
Comparing the four securing formats
W3C VC 2.0 lets the same data model be implemented in several securing formats, each with different use cases, compatibility, and implementation difficulty.
| Format | Media type | Signature | Best suited for |
|---|---|---|---|
| JSON-LD VC + Data Integrity | application/vc | Data Integrity Proofs (DI) | Public and educational credentials, and ecosystems where interoperability matters. Pros: clear semantic meaning, easy vocabulary sharing via JSON-LD context, close fit with the core W3C VC 2.0 representation. Cons: JSON-LD processing is heavier, canonicalization is complex to implement, tends to sit apart from existing JWT infrastructure. |
| JWT-VC (JOSE) | application/vc+jwt | JWS (JSON Web Signature) | Migrating from existing OAuth/OIDC infrastructure, internal credentials, lightweight PoCs. Pros: compatible with existing JWT infrastructure, lightweight to implement, familiar to OAuth/OIDC developers. Cons: JWT alone is not well suited to selective disclosure, tends to expose all claims when presented, weaker semantic vocabulary linking than JSON-LD. |
| SD-JWT VC | application/vc+sd-jwt | SD-JWT (Selective Disclosure JWT) | Age verification, identity verification, privacy-sensitive attribute proofs. Pros: supports selective disclosure, lighter than zero-knowledge proofs, gaining attention in mobile wallets and high-assurance identity. Cons: the spec and implementation ecosystem are comparatively new, disclosure units and metadata need designing, wallet compatibility needs checking. |
| COSE-VC | application/vc+cose | COSE (CBOR Object Signing) | Mobile driving licences (mDL), IoT devices, highly efficient mobile credentials. Pros: high binary efficiency, suited to mobile and embedded environments, aligns well with ISO mdoc/mDL design. Cons: requires CBOR/COSE implementation knowledge, heavier to handle via web APIs than JWT, a learning cost for typical web developers. |
Major implementation libraries
| Library | Language | License | Notable for |
|---|---|---|---|
| Veramo | TypeScript / Node.js | Apache-2.0 | A plugin-based architecture supporting multiple DID methods and VC formats. The most widely adopted choice for web applications. |
| Walt.id | Kotlin / JVM | Apache-2.0 | Strong support for EU eIDAS and EUDI Wallet specifications, with enterprise-grade Issuer/Verifier infrastructure included. |
| SpruceID / DIDKit | Rust (FFI: Node/Python/JVM) | Apache-2.0 | Built for mobile embedding — lightweight, and can also run in-browser via WebAssembly. |
| Hyperledger Aries / AnonCreds | Python / Rust | Apache-2.0 | Zero-knowledge-proof-based anonymous credentials, typically paired with enterprise DID (Indy). |
| sd-jwt-js | TypeScript | Apache-2.0 | A lightweight library close to the reference implementation of the SD-JWT spec, widely used in OpenID for VC implementations. |
Implementation flow (five steps)
- Step 1 — Schema design: define the attributes (claims) the VC will express, aligned to JSON Schema, schema.org, a custom vocabulary, or an industry-standard schema — for a credential, items such as name, expiry, issuing body, and qualification name. Aligning the design with OID4VCI credential definitions pays off for future interoperability.
- Step 2 — Building the Issuer: design the issuer's identifier (including a DID) and signing key, and implement a VC-issuance API (OID4VCI is recommended). Decide at issuance time whether to use JSON-LD/Data Integrity, JWT-VC, SD-JWT VC, or COSE-VC, and choose the corresponding library.
- Step 3 — Choosing a Holder wallet: decide which wallet users will use to store and present VCs. Options include Microsoft Authenticator/Entra Verified ID, Trinsic, Walt.id, or an in-house wallet. If you are targeting the EU market, you will need to confirm compatibility with the EUDI Wallet and OID4VC-family protocols.
- Step 4 — Building the Verifier: implement a VC-verification API on the verifier side (OID4VP is recommended). Signature verification, revocation checking, expiry checking, and Issuer DID resolution are the four required functions. If you adopt SD-JWT, you also need verification logic for selectively disclosed claims.
- Step 5 — Revocation/status design: design a mechanism for checking revoked or suspended status. In a VC 2.0 context, Bitstring Status List v1.0 is an important option — the issuer publishes a bit string, each VC's status maps to a specific position in it, and verifiers check the relevant bit based on the status information in the VC. Privacy, operational load, and update frequency all need to be balanced at the design stage.
A minimal PoC (an Issuer, a Verifier, and a sample Holder wallet) can typically be brought to a working demonstration in four to eight weeks. Netsujo's PoC design package (JPY 800,000, roughly 4 weeks) covers VC schema definition, securing-format selection, and implementation-library evaluation for your intended use case; see the pricing page for details.
Frequently asked questions
- What are Verifiable Credentials (VCs)?
- A VC is a W3C-standardized specification for an electronically signed certificate whose authenticity a third party can verify. It is a way of issuing and circulating "attribute proofs" — degrees, qualifications, employment certificates, residency records — as tamper-evident, digitally signed data instead of paper or PDFs. The VC Data Model 2.0 became an official W3C Recommendation on May 15, 2025.
- What is the difference between a VC and a DID?
- A DID is an identifier; a VC is an attribute credential. If a DID is roughly analogous to a driving-licence number, a VC corresponds to the information written on that licence — name, date of birth, licence class, and so on. That said, a VC's subject ID does not always have to be a DID; depending on the use case, it can be designed around a different identifier, or none at all. See our "What Is a DID (Decentralized Identifier)?" article for more on DIDs.
- Which should I choose: JWT-VC, JSON-LD VC, SD-JWT VC, or COSE-VC?
- Choose JWT-VC if compatibility with existing JWT infrastructure matters most; JSON-LD/Data Integrity if you want the semantic expressiveness and vocabulary linking central to W3C VC 2.0; and SD-JWT VC if you need selective (minimal) disclosure. COSE-VC is also worth considering for mobile driving licences (mDL) or embedded, binary-efficiency-sensitive contexts. In practice, the decision should be driven by your target market, wallet compatibility, and the implementation burden on the verifier side.
- What is selective disclosure?
- A mechanism letting a holder disclose only part of their VC to whoever they present it to. For example, when using a driving-licence VC for age verification at a liquor purchase, you can hide your name, address, and licence number and disclose only the fact that you are over 20. This is implemented with SD-JWT or BBS+ Signatures (zero-knowledge proofs).
- How is VC revocation implemented?
- In a VC 2.0 context, Bitstring Status List v1.0 is an important option. The issuer publishes a bit string, with each VC's status mapped to a specific position, so verifiers can check revoked or suspended status. Verifiers look up the status list from the VC's embedded status information and check the relevant bit. Update frequency, caching, privacy, and SLAs all need to be decided together at design time.
- Can this integrate with Japan's My Number Card?
- Yes. A realistic design uses the My Number Card's public individual authentication (JPKI) for identity verification, and issues the result as a VC. Japan's Digital Agency has, through its "Trusted Web" promotion council, also indicated a direction that bridges public authentication with self-sovereign VCs.
- What are OID4VCI and OID4VP?
- OpenID for Verifiable Credential Issuance (OID4VCI) is the protocol for issuing VCs; OpenID for Verifiable Presentations (OID4VP) is the protocol for presenting them. OID4VCI 1.0 was published as a Final Specification in September 2025, and OID4VP 1.0 in July 2025. Neither protocol limits VCs to a single format — both are designed to handle SD-JWT VC, ISO mdoc, W3C VCDM, and other formats.
- What is the EUDI Wallet?
- The European Digital Identity Wallet is a framework, under the EU's eIDAS 2.0 regulation, in which EU member states provide digital identity wallets to citizens and residents. Each member state is understood to be required to offer at least one wallet by around the end of 2026. This is likely to become a large-scale implementation case for VCs and digital attribute credentials, so Japanese companies serving the EU market should keep tracking the implementation specifications, adoption obligations, and covered industries as they develop.
- How long does a PoC take, and what does it cost?
- A minimal-scope PoC (an Issuer, a Verifier, and a sample Holder wallet) can typically reach a working demonstration in four to eight weeks. Netsujo's PoC design package (JPY 800,000, roughly 4 weeks) covers VC schema definition for your intended use case, securing-format selection, and evaluation of implementation libraries. See the pricing page for details.
- What are the main challenges in running this in production?
- There are four: (1) wallet adoption — VCs cannot spread without an environment where users can actually receive them; (2) confirming issuer trustworthiness — a mechanism for the verifier to judge who counts as a legitimate issuer; (3) revocation operations — the frequency and SLA of revocation updates; and (4) recovery when a user loses their key. Spelling all four out at the design stage is a precondition for going to production.