Verifiable credential

The problem it solves

Traditional credentials are verified by asking the issuer. An employer receives a certificate, emails the university, and waits. That works, slowly, while the issuer still exists, still answers email, and still has records going back far enough. The rest of the time it fails quietly, which is most of the time, and which is why most certificates on most CVs have never been checked by anybody.

A verifiable credential moves the proof into the credential. Instead of trusting a document because of where it appears to come from, you check it against mathematics that only the genuine issuer could have produced. The issuer does not have to be contacted, or available, or even still operating.

What makes a credential verifiable

Three things have to be true together.

• It states a claim. A named subject, a named issuer, an achievement, a date. Vague credentials cannot be verified because there is nothing definite to check.
• It carries a cryptographic proof. Usually a digital signature over the exact claim, made with a key only the issuer holds.
• The proof is checkable by a third party. Anyone holding the issuer's public key can confirm the signature. If checking requires the issuer's cooperation, nothing has actually changed.

The third point is the one that gets lost. A credential stored in a vendor's database and displayed behind that vendor's login is not verifiable in this sense. It is a lookup. The distinction becomes obvious the day the vendor turns off the service.

The W3C standard, and the ordinary adjective

Verifiable Credentials with capital letters is a W3C specification: a data model defining how a credential is structured, how proofs attach to it, and how issuers, holders, and verifiers exchange it. It is what Open Badges 3.0 was rebuilt on top of, and it is the direction the standards world is heading.

Verifiable credential in lower case is the property described above: this credential can be checked without asking anyone. A credential can have the property without conforming to the specification. Less obviously, a system can claim conformance while being awkward enough to check in practice that nobody bothers.

Being precise about which one a vendor means is worth the question. It is a common place for marketing to outrun implementation.

What we do

Credentials issued here are signed with Ed25519 at the moment of issuance, over a canonical representation of the recipient, award, issuing organisation, and issue date. The signature is checked when anyone opens the credential page, and it fails if any of those details have changed since signing.

In the terms above: the property, yes; the W3C data model, not yet. That is a deliberate statement rather than an omission. The security page sets out the scheme in full, including what it does not cover.

What verification does not tell you

A valid signature proves that these details were signed by the holder of that key, and that nothing has been altered since. It does not prove the issuer is reputable, that the assessment behind the credential was rigorous, or that the person who sent you the link is the person named on it. Verification answers "is this record authentic?", which is a narrower and more useful question than it first appears. Checking a certificate online covers what to do with the answer.