How Verifiable Credentials Work
Verifiable credentials work through three roles. An issuer, such as a university or employer, digitally signs a claim about someone. The holder stores it in a digital wallet and shares it when needed. A verifier checks the signature and the credential's status cryptographically, without contacting the issuer, to confirm the claim is authentic and unaltered.
The trust triangle
Verifiable credentials are built on a relationship between issuer, holder, and verifier. The issuer makes a claim and signs it. The holder receives and keeps it. The verifier decides whether to trust it, based on who the issuer is and whether the cryptographic checks pass. The verifier trusts the issuer, not the holder's word.
Step 1: issuance
An issuer creates a credential containing claims about a subject, such as a degree, a certification, or a period of employment. The credential includes metadata like the issuer's identifier, issue date, optional expiry, and a reference to status information. The issuer signs it with a private key, producing a proof attached to the credential.
Step 2: holding
The holder stores the credential in a digital wallet, an app or service that manages credentials and keys. Holders can keep many credentials from different issuers and decide what to share. The credential does not live on the issuer's server, so it remains usable even if the holder changes jobs or the issuer's systems change.
Step 3: presentation
When asked to prove something, the holder creates a verifiable presentation, packaging one or more credentials and often signing the package to prove they control it. Some formats support selective disclosure, letting holders reveal only certain claims, such as that a degree exists without sharing grades.
Step 4: verification
Verification is four questions asked in order, and all four are local: does the signature match the issuer's published key, has anything in the payload changed since signing, is the credential inside its validity window, and does its status entry say it is still good. Only the last may require a network call, to a status list rather than to the issuer, which is what keeps the issuer from learning where the credential is being used. A pass means the document is intact and the issuer said it; whether that issuer is worth trusting is a separate judgement the verifier makes.
Decentralized identifiers
Issuers and holders are often identified with decentralized identifiers (DIDs), which resolve to documents containing public keys. DIDs let verifiers find the keys needed to check signatures without relying on a single central directory. Other identifier methods, including web domains, are also used.
Revocation and status
Credentials sometimes need to be withdrawn, for example when a certification lapses. Issuers publish status information, often as compact status lists, that verifiers check. Status lists are designed so verifiers can check status without revealing to the issuer which credential they are checking.
Data formats and standards
The W3C Verifiable Credentials Data Model defines the structure of credentials and presentations; version 2.0 became a W3C Recommendation in 2025. Credentials can be secured with different proof formats, such as Data Integrity proofs or JOSE and COSE based signatures. Related specifications cover status lists and exchange protocols.
Privacy features
Because holders present credentials directly, issuers do not need to be contacted for each check, which reduces tracking. Selective disclosure and zero-knowledge techniques in some formats let holders prove facts, such as being over a certain age, without revealing underlying data.
Uses in hiring
Verifiable credentials can prove degrees, certifications, licences, and employment history without manual reference checks or calls to registrars. For employers, verification becomes faster and harder to fake. For candidates, credentials become portable records they control across job changes and borders.
Onchain and offchain credentials
Verifiable credentials are usually stored offchain in wallets, with blockchains sometimes used for identifiers, keys, or status registries. Some onchain reputation systems record attestations directly on a blockchain. The approaches can complement each other, but storing personal data onchain raises privacy concerns.
Limits to understand
A valid signature proves who issued a credential, not that the claim is true. Verifiers must decide which issuers they trust, and ecosystems need governance for that trust. Wallet usability, key recovery, and adoption by issuers remain practical challenges.
Getting started as an employer
Employers can begin by accepting credentials from issuers that already support them, such as some universities and certification bodies, and by piloting verification tools that check standard formats. Issuing employment credentials to departing staff is a further step that helps former employees prove their history.
Getting started as a candidate
Candidates can ask universities, bootcamps, and certification providers whether they issue digital credentials, store them in a reputable wallet, and keep backups of recovery information. Sharing verifiable credentials can shorten background checks when employers support them.
A worked example
A university issues a graduate a signed degree credential, which the graduate stores in a wallet app. Years later, an employer asks for proof of the degree. The graduate presents the credential, the employer's verification software resolves the university's public key, checks the signature and status list, and confirms the degree in seconds, without emailing the registrar.
What a credential contains
A typical credential includes a type, such as a degree or employment record, the issuer's identifier, the subject's identifier, the claims themselves, validity dates, a status reference, and the cryptographic proof. Context definitions make the meaning of each field machine-readable, so different systems interpret the claims consistently.
Wallets and key recovery
Holders need secure wallets and a way to recover access if a device is lost. Some wallets back up keys to the cloud or use social recovery, while enterprise systems may manage keys on behalf of users. Recovery design is one of the most important practical choices in any credential deployment.
Frequently asked questions
- What are the three roles in verifiable credentials?
- Issuers create and sign credentials, holders store them and choose when to share them, and verifiers check signatures and status to confirm authenticity. The verifier trusts the issuer's signature rather than the holder's word, and does not need to contact the issuer to verify a credential.
- Can verifiable credentials be revoked?
- Yes. Issuers publish status information, often as status lists, that verifiers check during verification. If a credential is revoked or suspended, for example because a certification lapsed, the verifier sees the updated status and can reject it even though the signature remains valid.
- Are verifiable credentials stored on a blockchain?
- Usually not. Credentials are typically stored in the holder's digital wallet. Blockchains are sometimes used for decentralized identifiers, public keys, or status registries, but the W3C standard does not require a blockchain, and putting personal data onchain raises privacy concerns.