Verifiable credentials are tamper-evident, cryptographically signed digital statements about identity attributes, issued by a trusted party and presented by the holder. A relying party can confirm an attribute without contacting the issuer live, and the holder can disclose only what a given interaction needs.
What are verifiable credentials, in plain English?
A verifiable credential is a digital claim about someone, a degree, a date of birth, a KYC status, that has been cryptographically signed by the party that issued it. Because it is signed, anyone who receives it can check that it is genuine and unaltered using the issuer's public key, without phoning the issuer or querying a central database in real time.
Two properties make them powerful. They are tamper-evident: change a single field and the signature breaks. And they support selective disclosure: the holder can reveal just the attribute needed, proving they are over 18 without exposing their full birth record. They are the building block of self-sovereign identity and decentralized identity wallets.
For fraud and AML teams, the trust question is precise. A verifiable credential proves the issuer signed this claim and it has not been changed. It does not, by itself, prove the credential is still valid, or that the person presenting it is its rightful subject. Those gaps, revocation and holder binding, are exactly where you have to add controls.
Who is involved?
Who | Their role |
Issuer | Vouches for an attribute and signs the credential; the root of its trust. |
Holder | Stores the credential in a wallet and chooses what to present and when. |
Verifier (relying party) | Checks the signature, the status, and the holder binding, then decides to trust it. |
Revocation registry | The source that says whether a credential is still valid or has been withdrawn. |
What it looks like in practice
In practice
A payroll platform lets contractors prove employment eligibility with a verifiable credential issued by a background-check provider. A contractor presents the credential, and the platform validates the issuer signature instantly: the claim is authentic and unaltered, no live call to the issuer required.
The risk team adds two checks the signature alone cannot cover. It queries the revocation registry to confirm the credential has not been withdrawn since issuance, and it runs a holder-binding step, a liveness check tied to the credential's subject, to confirm the presenter is the real person and not someone replaying a stolen credential. Only with signature, status, and binding all green does it accept the claim.
Why it matters to operators
Verifiable credentials promise reusable, privacy-preserving proof: a customer verifies once and reuses the result, sharing only what each service needs, while you hold less sensitive data. That cuts onboarding friction and shrinks your breach surface, which is a genuine operational win as digital identity wallets spread.
The failure mode is trusting the wrong thing. A valid signature proves origin and integrity, not that the credential is current or that the presenter is its subject. So verify the issuer's reputation and standards, always check revocation status, and pair the credential with a holder-binding or liveness check. Possession is not proof of identity, and a stolen credential replayed by an impostor is the attack you are guarding against.
What to watch for
- Unknown issuers. A perfect signature from a party you do not trust proves nothing useful; vet the issuer.
- Skipped revocation. A credential can be genuine yet revoked; always check current status, not just the signature.
- Missing holder binding. Without proving the presenter is the subject, a stolen credential can be replayed.
- Wallet takeover. Compromising the holder's wallet exposes every credential inside it at once.
- Over-disclosure requests. Asking for more attributes than needed undercuts the privacy benefit and grows your data risk.
Quick questions
How is a verifiable credential different from a scanned document?
A scanned document is just an image that can be forged or edited; a verifiable credential is cryptographically signed, so any tampering breaks the signature and the issuer can be confirmed mathematically. It also supports revealing only selected attributes rather than the whole document.
Do I still need to contact the issuer?
Not to validate the signature; that is checked offline with the issuer's public key. You do, however, need to check the revocation registry to confirm the credential has not been withdrawn since it was issued.
What is selective disclosure?
It is the holder revealing only the specific attribute a verifier needs, such as a yes-or-no age claim, instead of the full underlying record. It reduces how much personal data the verifier collects and stores.
Why is holder binding necessary?
Because a credential proves a claim, not who is presenting it. Without a binding check like liveness, a fraudster who obtains someone else's credential could present it as their own, so binding ties the credential to the live subject.
How do verifiable credentials relate to SSI?
Verifiable credentials are the core data format; self-sovereign identity is the broader model in which users hold and control those credentials in their own wallets. The credentials are the pieces, SSI is the system that moves them.
Go deeper
- NIST Digital Identity Guidelines (SP 800-63) ↗ — The US standard for identity proofing and authentication assurance levels.
- FATF ↗ — The global standard-setter for AML, counter-terrorist-financing, and counter-proliferation. Recommendations, guidance, and jurisdiction lists.