A verifiable credential is a tamper-evident set of claims about a subject, such as a person’s age, degree or license, that is digitally signed by an issuer, stored by a holder and presented to a verifier who can check its authenticity without contacting the issuer. In digital identity, it is the building block that lets people carry trustworthy attributes in a wallet the way they carry paper documents today.
The concept is standardized in the W3C Verifiable Credentials Data Model, and related formats such as SD-JWT VC and the ISO mobile document format used for mobile driving licenses follow the same principles. From a privacy perspective, its importance lies in data minimization: the holder can disclose what a verifier needs and nothing more.
The issuer, holder and verifier model
Verifiable credentials rely on a triangle of trust between three roles. The issuer asserts claims and signs them, the holder keeps the credential in a digital wallet and decides when to share it, and the verifier checks the presentation and decides whether to accept it.
| Role | Typical example | Main responsibility |
|---|---|---|
| Issuer | University, government agency, bank | Verify facts and sign the credential |
| Holder | Citizen, student, employee | Store credentials and consent to presentations |
| Verifier | Employer, online shop, border control | Check signature, status and issuer trust |
| Trust registry | Accreditation body or national list | Confirm which issuers are authorized |
The verifier trusts the credential because it trusts the issuer’s key, not because it trusts the holder. The issuer’s public key is discovered through a decentralized identifier, a certificate chain or a trust list, depending on the ecosystem.
What a verifiable credential contains
A credential is a structured document with a defined set of components. When the holder shares it, it is usually wrapped in a verifiable presentation, signed by the holder to prove possession and bound to the verifier’s request through a nonce, which prevents replay of captured presentations.
| Component | Purpose | Example content |
|---|---|---|
| Issuer identifier | Names who made the claims | Identifier of a university |
| Credential subject | Holds the claims about the subject | Name, degree, graduation year |
| Validity period | Defines when the credential is valid | Valid from and valid until dates |
| Credential status | Allows revocation or suspension checks | Reference to a status list entry |
| Proof | Cryptographic signature over the content | Digital signature by the issuer key |
| Holder binding | Links the credential to the holder’s key | Public key held in the wallet |
Revocation is typically handled with status lists: compressed bitstrings where each credential has one position. A verifier downloads the whole list, which hides which credential is being checked from the issuer and avoids revealing usage patterns.
Privacy properties and selective disclosure
A plain signed credential forces the holder to reveal every claim it contains, because removing a field breaks the signature. Selective disclosure solves this by letting the holder reveal only chosen claims while the signature stays verifiable.
| Format family | Selective disclosure | Unlinkability across presentations | Predicates such as age over 18 |
|---|---|---|---|
| Signed JSON without hashing | No | No | Only if issued as a separate claim |
| SD-JWT and mobile document formats | Yes, through salted hashes | Only with fresh credentials per use | Through pre-issued boolean claims |
| BBS signatures and zero-knowledge schemes | Yes | Yes, by deriving new proofs | Yes, in some schemes |
Linkability is the less obvious risk. If the same signature or holder key appears in every presentation, colluding verifiers can correlate the holder across services. Mitigations include batch issuance of single-use credentials and zero-knowledge proof formats.
Verifiable credentials compared with other identity approaches
Verifiable credentials differ from federated login, in which an identity provider sits in the middle of every transaction. With credentials, the issuer signs once and is not informed when the credential is used, which reduces central tracking.
| Approach | Issuer involved at use time | User control | Typical weakness |
|---|---|---|---|
| Verifiable credential | No | High, wallet-based | Wallet loss and ecosystem maturity |
| Federated login | Yes | Moderate | Provider sees every login |
| Scanned document upload | No | Low, full copy shared | Easy to forge and over-shared |
| Decentralized identity | Varies | High | Broader concept, not a credential itself |
Limitations and implementation pitfalls
A credential is only as trustworthy as the issuer’s onboarding process. Strong cryptography cannot fix a weak identity check at issuance.
- Over-asking verifiers can still request more claims than needed, so wallets must show clear consent screens.
- Key loss in a wallet without recovery can lock users out of their credentials.
- Phone-home status checks that query the issuer per credential reveal usage and undermine privacy.
- Trust framework gaps leave verifiers unsure which issuers to accept.
- Long-lived identifiers reused across services create correlation risks.
In everyday language
A verifiable credential is a digital version of an official document that is stamped with an unforgeable signature. Your bank, school or government gives it to you, you keep it in an app on your phone and you show it when someone needs proof.
The clever part is that you can often show only the fact that is needed. A shop that sells wine needs to know that you are over eighteen, not your name, address or exact birthday. A good credential lets you prove just that, and the shop can check it is genuine without calling the office that issued it.
Seen in the real world
A graduate applies for an engineering job abroad. Instead of mailing certified copies of her diploma, she receives a signed degree credential from her university into a wallet app on her phone.
During the online application, the employer’s system asks for proof of a master’s degree in engineering. The wallet shows exactly which claims are requested, she approves, and the presentation reveals the degree title, field and graduation year but not her student number or grades. The employer’s software checks the university’s key against a national list of accredited institutions and confirms that the credential has not been revoked.
The verification takes a few seconds instead of several weeks, the university never learns which employer checked the diploma and the employer stores only the minimum it needed for the hiring file.