Verifiable Credentials Explained

Most product data travels as an assertion in a spreadsheet. A supplier states a recycled content figure, it is copied into a system, and by the time it reaches a passport nobody can say who originally claimed it or when.

A Verifiable Credential fixes that by keeping the claim, the claimant and a cryptographic proof together as one object. The W3C Verifiable Credentials data model is the specification, and its central property is that checking a credential does not require trusting whoever handed it to you.

The three parts

Every credential has the same structure, and understanding the three parts explains most of what follows.

The proof is what changes the economics of trust. Without it, verifying a claim means contacting the party who made it. With it, verification is a local computation using the issuer’s public key, which works offline and does not depend on anyone answering.

Why passports need this specifically

A passport is expected to remain meaningful for the life of the product, which for construction materials or industrial equipment can exceed a decade. Over that period the platform serving it may change, the supplier may cease trading, and the brand may be acquired.

A claim that can only be checked by asking the original system is worthless in that scenario. A signed credential remains checkable as long as the issuer’s key is resolvable, which is a much weaker dependency than an operating company.

The blockchain misconception

The most persistent misunderstanding in this area is that Verifiable Credentials require a distributed ledger. They do not, and the confusion causes real architectural harm.

Verifying a credential requires the issuer’s public key. That key is resolved through a Decentralized Identifier method, and the methods differ in where they publish it. Some use a ledger. The most widely used in industry, did:web, resolves over DNS and HTTPS at a domain the issuer already controls.

• did:web — the key is published at the issuer’s own domain. No ledger, no token, and the issuer already proves domain control every day.
• did:key — the identifier contains the key. Self-contained, suitable for short-lived credentials with no rotation requirement.
• Ledger-based methods — publish key history to a distributed ledger, useful where key rotation must be independently auditable.
• The credential does not care. The data model is indifferent to the method, which is why a chain is an option rather than a requirement.

Revocation is where implementations fail

A credential is signed at a point in time and remains cryptographically valid forever. If a certification is withdrawn — a laboratory loses accreditation, a supplier’s certificate is cancelled — the signature is still good.

That is why status checking matters, and why it is the part most often skipped. A verifier that checks the signature but not the status will happily accept a claim the issuer revoked two years ago, and will do so with complete confidence.

Published status lists solve this by letting an issuer mark a credential withdrawn in a way a verifier can check without contacting them directly. The operational requirement is simply that verification checks status every time rather than caching a result indefinitely.

What this looks like in a passport

In practice a passport attribute carries a pointer to the credential backing it, and the credential carries the issuer and proof. The reader sees a figure; a verifier can see who stands behind it.

What to ask a vendor

Because the term is used loosely, three questions separate an implementation from a description of one.

Ask to see a raw credential, not a rendering of one. Ask which DID methods are supported and whether the default requires a ledger. Ask how revocation status is checked and how often, because an implementation that verifies signatures without checking status has built the easy half.

A fourth question is worth adding: whether credentials your suppliers issue remain verifiable if you leave the platform. If the answer involves the vendor’s continued cooperation, the credentials are not doing the job the standard exists to do.