What are verifiable credentials?

A verifiable credential is a digital statement an issuer makes about a subject, cryptographically signed in a way that anyone can later confirm: the named issuer signed it, the contents have not been tampered with, and the credential has not been revoked.

That definition packs a lot in. This article unpacks it, with attention to why the design choices were made the way they were.

The shape of a verifiable credential

A verifiable credential (VC) under the W3C specification is a structured JSON document with four core sections:

1. Context: references to the JSON-LD vocabularies the credential uses, so the meaning of each field is unambiguous across systems.
2. Issuer: the identifier of the entity making the claims. Usually a decentralized identifier (DID) or a URL the issuer controls.
3. Credential subject: the entity the claims are about, plus the claims themselves (the person’s name, the certification level, the issue date, anything else).
4. Proof: the cryptographic signature that ties the credential to the issuer and protects it from tampering.

The proof is the load-bearing part. Without it, a VC is just JSON. With it, the credential becomes mathematically verifiable.

How verification works

When a verifier (a hiring manager, a credential checker, an automated system) receives a credential, the verification process runs three checks:

1. Resolve the issuer. Look up the public key associated with the issuer’s identifier.
2. Check the signature. Use the public key to confirm that the issuer’s private key signed this exact credential, and that nothing has been changed since signing.
3. Check the status. Look up the credential in the issuer’s revocation list. If it is listed, the credential is no longer valid.

All three steps can run without any back-and-forth with the issuer’s platform. The verifier does not need an API key, does not need to be registered, and does not need to trust the issuer’s infrastructure to stay online. The cryptography is the trust.

This is the key architectural difference from legacy badge platforms: in those systems, verification is a lookup against the vendor’s servers. The credential’s validity is bound to the vendor’s infrastructure. In the VC model, the proof is part of the credential itself; verification is a property of the document, not a service call.

Why the standard exists

The W3C Verifiable Credentials Data Model was finalized in 2019, with a 2.0 update in 2024. Its design responds to two long-standing problems with digital credentials:

Problem one: paper credentials do not travel well. A printed diploma, a wallet card, a certificate of completion. These were the universal form of credentials for centuries. They have obvious limitations: they can be forged, lost, or destroyed; they cannot be transmitted electronically without losing the proof of origin; and they cannot be partially disclosed.

Problem two: digital badge platforms locked credentials inside vendors. The first wave of digital credentialing produced “badges” issued through specific platforms. The credential was an entry in the vendor’s database, viewable through the vendor’s website. If the vendor changed terms, raised prices, or went out of business, the badge had no off-ramp.

The W3C VC standard solves both. Credentials are digital (problem one) but their proof is self-contained and verifiable independently of any vendor (problem two). The recipient holds the credential. The verifier verifies it. The issuer does not have to be in the loop.

What a “VC-native” platform actually does

A VC-native credentialing platform like Credostar handles four things for the issuer:

1. Key management. Each issuer organization has a key pair. The private key signs credentials; the public key is published so verifiers can find it. Credostar stores private keys in a managed key management service, so they never leave a controlled boundary.
2. Credential structure. The platform produces credentials with the correct W3C VC fields, the correct context references, and the correct proof format.
3. Delivery. The platform delivers credentials to recipients (typically via email with a recipient-side portal), and lets recipients export the credential to take it wherever they want.
4. Status maintenance. The platform publishes the issuer’s revocation list and keeps it current. Verifiers consult the list when they verify.

What the platform does not need to do is be in the verification loop. The credential is sufficient on its own.

What recipients actually receive

A recipient receives a credential that looks, depending on the wallet or viewer they use, like a digital certificate or badge. Visually it carries the issuer’s branding, the recipient’s name, and the credential’s claims (program name, date, level, hours).

Underneath the visual, the recipient has access to the raw JSON of the credential. They can:

• Add it to a digital wallet that supports VCs.
• Share a link that anyone can use to verify it.
• Download the JSON and submit it to a verifier that consumes VCs directly.
• Move it to a different wallet or registry as the ecosystem evolves.

The credential belongs to the recipient. The recipient’s relationship with the issuing platform is optional.

What this means for buyers

If you are evaluating a credentialing platform, the VC posture matters in three concrete ways:

1. Vendor lock-in. Proprietary badge formats validate only through the issuing vendor’s tooling. W3C VCs validate through any compliant verifier, so the credential and the recipient have real portability from day one.
2. Verifiability. A VC verifies anywhere. A proprietary badge verifies only through the vendor’s site. The first is universally interoperable; the second is a closed loop.
3. Audit defensibility. A cryptographically signed credential is admissible evidence in a way a screenshot of a vendor’s dashboard is not. For compliance training, regulated certifications, or any high-stakes use, VCs are the right substrate.

For a comparison of how Credostar implements W3C VCs against other platforms, see Credostar vs Credly, Credostar vs Accredible, and Credostar vs Sertifier.

Where to go next

Read OpenBadges 3.0 explained for the specific badge specification that builds on top of the W3C VC standard. Read Digital vs paper credentials for the practical migration argument. Or jump to Credential types compared for a comparison of the kinds of credentials Credostar issues.

If you are ready to issue verifiable credentials at scale, apply for early access to the Credostar Design Partner Program.