Verifiable credentials are reaching more and more areas: driver’s licenses in digital wallets, university degrees, professional licenses and age checks. Many solutions highlight the same property: the credential carries a digital signature that proves its content has not been altered.
It is a fundamental property, and it does not answer everything the recipient of a credential needs to know.
A verifier also has to know who controls the key that signed the document, whether that entity was authorized to issue it, and whether the credential is still valid. To answer those questions it has to consult information that lives outside the credential: the issuer’s public key, obtained from its decentralized identifier (DID), the trusted issuer registry and the credential’s status list.
That raises a design question as important as the signature: where those records live, who controls them and who can consult them.
A system can issue standards-compliant credentials and verify them within its own platform. That does not necessarily mean any institution can run the same checks on its own, without depending on whoever operates it.
Verifying outside the issuing platform
The W3C Verifiable Credentials Data Model 2.0 defines how to represent and verify digital credentials. Meeting that standard is the foundation, and on its own it does not guarantee that different institutions can verify credentials independently.
In many systems, issuer keys and status lists are published on servers run by the issuer or the platform. With did:web, for example, the keys are a file on the issuer’s domain, and the Bitstring Status List is downloaded from the address each credential points to. Anyone can fetch them over the internet, and the model works. Verification, however, stays tied to those servers being available, to whoever controls them, and to what they show at the moment of the check: a did:web document reflects the current keys, and the history of changes depends on the issuer keeping it.
When a credential leaves its original ecosystem, another verifier may need to call specific services or integrate with the same platform. The credential is verifiable inside that system, and outside it, checking it takes shared infrastructure.
What a public registry changes
One alternative is to keep the records verification needs on public, auditable infrastructure. The W3C data model itself expects that registry to be tamper-evident, and names a blockchain among the ways to achieve it.
This lets different verifiers consult a common source to check issuer keys, their authorizations and the status of credentials. Every key rotation and every status change is recorded in order, so a signature from 2021 is checked against the key the issuer used in 2021, and any past verification can be audited. Since the verifier reads the public registry, verification keeps working when the issuer’s server is down.
Governance is still needed: someone has to define who may issue each type of credential and under what conditions. What changes is how those decisions are recorded and how third parties can check them. We covered that side in Propia’s three registries.
Privacy matters too. The registries hold public keys, authorizations and statuses, without publishing the credentials or their holders’ personal data. Each status list covers at least 131,072 credentials, so consulting one does not reveal which credential is being verified.
How we do it at Sovra
SovraChain is an Ethereum Layer 2 running in validium mode: transactions execute off Ethereum and validity proofs settle on Ethereum (data availability modes). It runs on Ethrex, the execution client developed by LambdaClass, and already holds more than 10 million anchors.
On it we record issuers’ DID documents and their operation history, the trusted issuer registry, status lists and credential schemas.
We use did:sovra, compatible with W3C DID Core, and Bitstring Status List v1.0 to publish credential status through a standardized mechanism.
The components work together:
SovraID lets institutions issue and verify credentials.
SovraWallet lets people store and present their credentials from their phone, with private keys kept on the device.
SovraChain keeps the shared records that back verification.
Credentials and personal data are not published on the chain.
The goal is for verification not to depend solely on the platform that issued a credential. Institutions can rely on open standards and shared registries to check the information they need, under the applicable trust rules.
You can watch a credential issued and verified live.
What to ask when evaluating a solution
Before choosing a verifiable credentials platform, it is worth asking:
Can an independent institution verify the credentials without depending on the provider?
Where are the keys and status lists published?
Is there an auditable history of key and status changes?
How is it determined which issuers are trusted?
What information is published, and what stays private?
A valid signature is indispensable, and interoperability also depends on the infrastructure that lets institutions check it and share trust with one another.
Further reading
Verifiable Credentials Data Model 2.0 (W3C): the standard that defines what a verifiable credential is and how it is verified.
Bitstring Status List v1.0 (W3C): the standard mechanism for publishing whether a credential was revoked or suspended.
The full lifecycle of a verifiable credential: issuance, storage and verification, step by step.
How a Country Verifies an Identity Issued by Another: the checks a government runs before accepting a foreign credential.
Continue the conversation
Our knowledge hub at sovra.io/knowledge explains DIDs, verifiable credentials and status lists in plain language.
What other question would you ask a credentials platform before choosing it? Reply and tell us. We read every response, and if a colleague is evaluating identity solutions, forward this edition to them.
Subscribe to The Identity Brief, published weekly.