W3C Verifiable Credentials explained: a practical guide

A W3C Verifiable Credential is a tamper-evident, cryptographically signed digital claim (“Maya earned this certificate”) that anyone can verify independently — without phoning the issuer. It’s built on a shared data model so it works across wallets, verifiers, and platforms.

“Verifiable Credentials” (VCs) is a W3C standard for expressing credentials — diplomas, licenses, certificates, memberships — in a way that machines can verify cryptographically. The goal is simple: take the trust that’s normally locked inside one organization’s database and make it portable, private, and provable. This guide covers the model and what it means in practice.

What problem do Verifiable Credentials solve?

Traditionally, proving a claim means calling the issuer: a university confirms a degree, an employer confirms a role. That’s slow, manual, and gives the issuer a gatekeeping role forever. Verifiable Credentials flip this — the proof is embedded in the credential itself, so a verifier can check it offline and instantly, while the holder keeps control of when and to whom they present it.

What is the issuer–holder–verifier model (the “trust triangle”)?

Every VC interaction involves three roles:

• Issuer — the organization that makes a claim and signs it (e.g. a school, a certification body, an employer).
• Holder — the person the credential is about, who stores it and decides when to share it (often in a digital wallet).
• Verifier — anyone who needs to check the claim (an employer, a registrar, a platform).

Crucially, the verifier checks the issuer’s signature using cryptography, not by contacting the issuer. The issuer doesn’t even know when verification happens, which is better for the holder’s privacy.

What’s actually inside a Verifiable Credential?

A VC is a structured document — typically JSON-LD — with a few core parts:

• @context — references the VC data model and any vocabularies used, so terms have shared meaning.
• issuer — an identifier for who issued the credential.
• credentialSubject — the claims themselves (who the subject is and what’s true about them).
• issuanceDate / validity info — when it was issued and, optionally, when it expires.
• proof — the cryptographic signature that makes the whole thing tamper-evident.

Because the proof covers the contents, altering any claim invalidates the signature. That’s the difference between a VC and a plain JSON file with a name in it.

How does the cryptography make a credential tamper-evident?

The mechanics mirror how SwanShare issues every credential. The issuer signs the credential with its private key (SwanShare uses RSA-PSS), and a SHA-256fingerprint pins the exact contents. A verifier recomputes the hash and checks the signature against the issuer’s public key. SwanShare additionally writes each fingerprint to a tamper-evident, hash-chained ledger (with optional public-chain or OpenTimestamps anchoring), so you can also prove the credential existed at a point in time and wasn’t backdated.

What about revocation and expiry?

A credential isn’t frozen forever the moment it’s signed. Issuers need to revoke credentials that were issued in error or are no longer valid. The VC ecosystem handles this with status mechanisms the verifier checks during verification. In SwanShare, revoking a credential is a dashboard action, and public verification reflects the revoked status immediately and honestly — a revoked credential doesn’t quietly pass.

How are Verifiable Credentials different from a PDF or a database record?

• vs. a PDF: a PDF can be edited and carries no portable proof of origin. A VC carries its own cryptographic proof.
• vs. a database lookup: a database keeps the issuer in the loop for every check and goes dark if the issuer’s site is down. A VC can be verified independently.
• vs. a vendor “verify” page: a standards-based VC works in any conformant verifier, so the holder isn’t locked to one platform.

How do I issue and verify them in practice?

With SwanShare you issue credentials from a template, and they can be exported as W3C Verifiable Credentials and Open Badges 3.0 so they work with other wallets and verifiers. Recipients (or anyone they share with) verify for free at /verify — no account needed. Because the format is standards-based, the credential keeps proving itself even outside SwanShare.

Is this “blockchain”?

Not inherently. Verifiable Credentials are about signatures and a shared data model — no blockchain is required. SwanShare’s default anchor is a tamper-evident, hash-chained ledger, and public-chain (EVM) or OpenTimestamps anchoring is an opt-in add-on for independent timestamping. We’re deliberately upfront about that distinction.