TL;DR: Cryptographic credentials can prove who issued an identity claim and whether it has been altered. However, they do not eliminate trust. Instead, they shift trust upstream to issuers, keys, revocation systems, and the infrastructure that determines which authorities to trust.
Key Takeaways:
Digital identity is changing. More specifically, it’s moving from recognition toward proof.
Instead of uploading a photograph of a driver’s license or passport and letting software determine whether it’s genuine, cryptographically verifiable credentials enable a system to verify that a trusted issuer created the document and that it hasn’t been altered.
The World Wide Web Consortium’s Verifiable Credentials standard formalizes this around three basic participants: an issuer makes claims, a holder receives and presents them, and a verifier checks them. Cryptographic methods can then establish the authenticity and integrity of the credential.
This is a major improvement in a world where AI-generated deepfakes are breaking the old way of doing things. However, cryptography does not eliminate trust. Instead, it moves it somewhere else.
Cryptography proves who signed, not whether they can be trusted
Imagine Alice presents a digital driver’s license to her bank. The bank verifies the cryptographic signature, confirming it was signed with a specific public key.
The bank has now mathematically verified that the credential corresponds to the holder of the matching private key and has not been altered.
However, it does not establish whose private key it is or whether or not they can be trusted.
W3C’s Verifiable Credentials specifications acknowledge this. It states that verifiers ultimately need to decide which issuers to trust and for what purposes. It also highlights that this decision is outside the scope of the credential standard itself.
A verifier might trust an issuer for various reasons, such as an existing relationship, membership in a governed system, reputation, or a third-party trust service that vets issuers and publishes a trusted list.
So, cryptography can prove that issuer A signed a credential. It can’t prove that issuer A is trustworthy or authorized to make this claim.
Every trust chain eventually reaches a root
Think about what actually happens when the bank verifies Alice’s driving license.
The bank verifies the credential’s signature. However, to do that, it needs the issuer’s public key.
Then it needs confidence that the public key belongs to the relevant government authority. This could require a trusted list, registry, or certificate authority.
So, the verifier follows a chain, but at some point it must reach something it already accepts as authoritative.
The trust problem has not disappeared; instead of trusting a JPEG, the verification system trusts a chain of cryptographic authorities.
Insight: One argument is that the government authority could publish its public key on its .gov domain. However, even this relies on the assumption that the domain has not been hacked or compromised.
The issuer becomes part of the security system
In this chain, the issuer becomes part of the security perimeter, and that creates a different attack surface. For example, the issuer’s private key could be stolen.
In this case, the attacker no longer needs to create a document that looks authentic. They can potentially create one that can be cryptographically verified as authentic. Yet, it would not actually be authentic. It would be issued and signed with a stolen key.
This means any such system would depend on key management as a critical part of the identity infrastructure. Issuers need ways to protect, rotate, and replace keys as well as identify hacks and compromises.
This means the trust stack has moved beyond the credential itself to other layers of control.
The ability to revoke credentials is necessary
There is another complication that any such system must allow for—credentials can cease to be valid.
A driver’s license can be suspended, a professional qualification can expire, a digital passport can be stolen, or, as mentioned above, an issuer’s private key can be stolen.
Verifying that a credential was valid at the time it was issued isn’t enough. Systems need to be able to confirm it’s valid now.
This turns digital identity into more than merely checking a signature once. The credential may be authentic, the issuer genuine, and the signature valid, but the credential may still not be acceptable.
This turns identity into a state management problem.
Who maintains the list of trusted issuers?
Eventually, this problem reaches governance.
If governments, banks, employers, educational institutions, and private companies all begin issuing cryptographically verifiable credentials, a verifier needs a way to determine which issuers can make which claims.
These organizations may be trusted to attest to certain things, but not others. For example, a university might be trusted to attest that someone holds a medical degree, but it shouldn’t automatically be trusted to issue a driver’s license. Likewise, the DMV may be trusted to vouch for a driver’s license, but it would make little sense for it to attest that someone holds a medical degree.
All of this means digital identity needs more than a list of public keys. It also needs context about what each issuer is trusted to attest.
The point should be clear by now—a cryptographic signature answers a technical question, but governance is still needed to determine whose signature counts.
Blockchain can make the trust infrastructure more transparent
Cryptographic identity systems don’t necessarily require blockchain technology, and blockchains can’t decide whether a government agency deserves to issue passports or whether universities should be trusted to issue degrees.
However, scalable public ledgers can provide a common, immutable, time-stamped record of information. This may include issuer identities, authorized public keys, credential status information, revocations, and changes to trust relationships.
Instead of every verifier maintaining its own records, multiple parties could independently verify a shared version of events.
Again, this doesn’t remove trust, but it does make trust infrastructure more transparent, auditable, and extremely difficult to alter.
In a world where digital identity is moving from trusting appearances to trusting chains of authority, the next question becomes obvious: who verifies the verifier?
FAQs:
What is a verifiable digital credential?
A verifiable digital credential is a digitally issued claim whose authenticity can be checked using cryptography. Examples include digital driver’s licenses, educational qualifications, or other credentials.
Does cryptographic verification eliminate trust?
No. Cryptography can prove that a particular key signed a credential and that it has not been altered, but the verifier still has to decide whether the issuer controlling the key can be trusted.
What happens if an issuer’s private key is compromised?
A compromised private key could allow an attacker to create credentials that appear cryptographically valid. Because of this, identity systems need secure key management, rotation, and revocation, as well as mechanisms that inform verifiers which keys remain trustworthy.
Why might digital credentials need revocation?
Credentials can become invalid for several reasons, such as suspension, expiry, theft, and changes in the holder’s circumstances. Verifiers need access to current status information, as well as being able to verify signatures.
Can blockchain tech be used in digital identity trust infrastructure?
Yes. A scalable public blockchain can provide a shared, tamper-evident record of issuer keys, current credential status, revocations, and other information. Decisions about which issuers should be trusted still depend on governance and real-world authority.
Watch: Digital identity is a core part of Web3—here’s why
Be the first to comment