Who verifies the verifier? The new trust problem in digital identity
A digital credential can pass a cryptographic check and still come from an issuer with no authority to make the claim. A signature helps prove that data matches a particular key. Whether that key, and the institution behind it, deserves trust is a separate question.
- A valid signature proves integrity, not truth or authority.
- Issuer keys and credential status need ongoing management.
- A public ledger could help audit records, but cannot decide whom to trust.
Some identity checks involve inspecting a photo of a license or passport. A verifiable credential offers another option: a verifier can check a cryptographic proof instead of relying on an image alone. That can make tampering easier to detect, but it does not replace every part of identity verification.
A successful signature check shows that the signed data has not changed and that the proof matches a particular key. The verifier still needs to establish who controls that key, whether the issuer is authorized to make the claim, and whether the claim is true.
Three roles, and the question of authority
The World Wide Web Consortium’s Verifiable Credentials model defines three roles: an issuer makes a claim and issues a credential; a holder receives and presents it; and a verifier checks it. For example, a government authority might issue a digital driver’s license, which Alice then presents to a bank.
The bank needs a reliable way to connect the signature’s public key to the claimed government authority. It must also decide whether that authority is entitled to make this particular claim. A university might be trusted to attest to a medical degree, for example, but not authorized to issue a driver’s license. Trust depends on both the issuer and the purpose.
A verifier might rely on an existing relationship, a governed membership system, an issuer’s reputation, or a third-party service that vets issuers and publishes a trusted list. None settles the governance questions: who set the rules, who maintains the records, and how can others check that they are current?
The W3C Verifiable Credentials data model does not provide a universal trust list or decide which issuers have authority. Verifiers must follow the relevant law, policy or trust framework. A cryptographic proof can show that a key signed data. It cannot determine whether that key should be accepted for a particular purpose.
Keys can be compromised; credentials can go stale
A private key is the secret counterpart to a public key. The public key helps verify a signature, while the private key creates it. If an attacker gains control of an issuer’s private key, they may be able to produce credentials whose signatures pass verification. The cryptography can work exactly as designed, even when the person using the key is unauthorized.
That makes key protection, rotation and replacement core parts of identity security. Systems also need procedures to identify a compromised key and tell verifiers what to do. A status list alone cannot guarantee that a compromise will be detected or handled quickly. That depends on the system’s operations and governance.
Credentials can also change status after they are issued. A driver’s license might be suspended, or a professional qualification might expire. Checking only that a credential was valid when created does not show that it remains acceptable now.
The W3C Bitstring Status List specification distinguishes status purposes such as revocation and suspension. Revocation cancels a credential’s validity; suspension temporarily prevents acceptance and can be reversed. The specification also describes related mechanisms: a refresh signal can indicate that an updated credential is available, while a status message can provide other status information. These mechanisms do not all permanently cancel a credential.
The specification describes a status-list approach in which a credential can point to a verifiable credential containing status information. It also recommends privacy-conscious design, including randomly assigning list indexes to make some inferences harder. These features do not guarantee privacy in every deployment. How status information is fetched and what data is exposed still matter. The status-list explainer provides more context on the approach.
Who checks the verifier?
Trust in the issuer is only half the question. A bank or other verifier also makes consequential decisions: which trust framework to use, what evidence to accept, and what to do when a credential fails a check. A verifier might reject a valid credential because its records are outdated, its policy is unclear, or its system has made a mistake.
That makes verifier accountability part of the design. People need to understand the basis for a decision and have a way to challenge an incorrect rejection. Organizations that use credentials need clear policies, reliable processes for updating trust information, and appropriate oversight of the claims they assess. Cryptography can make some checks auditable. It cannot decide whether a verifier’s policy is fair or whether an appeal process works.
There is no universal answer to who should audit every verifier. The responsible authority may depend on the sector, jurisdiction and trust framework. But “the signature checked out” is not a complete explanation when someone is denied access or a credential is wrongly rejected. These challenges are part of the broader digital identity debate, including in blockchain gaming.
Could a public ledger help?
Digital credentials do not inherently require a blockchain. Credential status can be published in other ways, and the W3C Bitstring Status List approach does not require blockchain storage.
A public ledger could make a registry’s history easier to inspect. A system might record issuer-key changes, revocations or updates to trust records. It could also anchor cryptographic hashes of records so later changes can be detected. That differs from putting sensitive identity details directly on-chain, which could create serious privacy risks.
Even a well-maintained ledger cannot establish that its entries are true. It can help show what was recorded and when, but it cannot decide which university should certify a degree, who should govern a list of public agencies, or how disputes over issuer authority should be resolved. “Put it on-chain” is not a trust model.
Any ledger-based approach would still need rules for who can publish updates, how errors are corrected, how compromised keys are handled, and how users’ privacy is protected. A shared record may improve auditability, but governance remains the hard part.
Key questions about verifiable credentials
-
What does a valid credential signature prove?
It shows that the signed data matches a particular key and has not changed since it was signed. It does not, by itself, prove who controls that key, whether the issuer is authorized, or whether the claim is true.
-
Who decides whether an issuer is trustworthy?
The verifier applies the relevant policy, law or trust framework. The W3C data model does not provide one universal list of trusted issuers.
-
Why check a credential’s current status?
A credential may be suspended or revoked after issuance, and related status mechanisms may signal that an updated credential is available. A signature check alone does not tell a verifier whether the credential remains acceptable now.
-
Who holds a verifier accountable?
That depends on the sector, jurisdiction and trust framework. Systems should make verification policies understandable and provide a way to challenge decisions when a credential is wrongly rejected.
-
Does digital identity require a blockchain?
No. A public ledger could make some registry updates easier to audit, but other publication methods can support credential status. A ledger records information; it cannot determine whether the information or the authority behind it deserves trust.
Verifiable credentials can make identity checks more precise, but they do not remove the need for trust. They expose more of the machinery behind it. The essential questions are who issued the credential, who authorized that issuer, whether the credential is still valid, and how a person can challenge the verifier’s decision.
