What does ‘verifiable’ mean in a digital credential or blockchain record?

Short answer: “Verifiable” usually means that software can check a cryptographic proof and detect whether the protected data has been changed. In a digital credential, that may show that a particular key signed the credential and that the credential passes technical checks. In a blockchain record, it may show that a transaction or piece of data is part of the accepted history of that network.

Neither result, on its own, proves that the issuer is a trustworthy organisation, that the credential belongs to a particular person, that it has not been revoked, or that its claims are true today. Those questions need separate identity, policy and status checks.

That distinction matters because “verified” can sound like a much broader guarantee than the underlying test provides. The W3C Verifiable Credentials Data Model 2.0 makes the same point: verifiability does not imply the truth of the claims in a credential. A verifier still has to assess the issuer, proof, subject, claims and relevant policy.[4]

What cryptographic verification can establish

A digital signature is made with a private key and checked with a corresponding public key. If the check succeeds, the verifier has evidence that:

• the signed data has not changed since it was signed;
• the signature was made with the private key corresponding to the public key used for the check; and
• the signing key was associated with the protected data under the system’s rules.

This is often described as integrity and authorship. “Authorship” here means authorship by a key, not necessarily by a known person or legitimate institution.

For example, GOV.UK Wallet’s technical documentation says a credential is signed with the issuer’s private signing key. A verifier can use the published verification material to check that signature. The check is useful, but it does not answer every question a relying organisation may have about the issuer or the claim.[3]

A blockchain adds a different kind of check. Depending on the network and its design, a verifier may be able to confirm that a transaction was validly signed, included in a block, and accepted into the chain’s current history. A later reader can independently recalculate hashes and verify the chain’s structure. That supports tamper detection and auditability. It does not turn the data into an independently confirmed fact about the physical world.

For a related explanation of the hash step, see our guide to what a blockchain hash does. For the network question, see what blockchain finality means.

Four questions that “verifiable” does not answer by itself

1. Who is the issuer?

A valid signature proves control of a private key. It does not, by itself, prove who controls that key or whether the organisation is authorised to make the claim.

A verifier therefore needs a trust decision. It may check the issuer’s identifier, public keys, certification, register entry, contractual relationship or other governance information. GOV.UK’s Digital Verification Services (DVS) Trust Framework describes certification as a way to set rules for services that want to be certified as trustworthy digital verification services. It also distinguishes the service’s role and level of confidence from the cryptographic mechanics used to secure a message.[1]

GOV.UK Wallet uses trusted lists for consumers of credentials. Outside government, its documentation says credentials and attributes are released to a digital verification service that is certified against the trust framework and appears on the DVS register.[2] That is a governance and access control decision around verification. It is not something a signature can supply by itself.

2. Does the credential belong to this person?

A credential can be bound to a key, device or wallet without that key being conclusively bound to a human being. The strength of the person-binding process depends on how the person was identified, how the account was authenticated and how the holder is protected from takeover.

GOV.UK Wallet provides a useful example of the separate checks. Its issuance flow uses proof of possession to verify that the wallet controls the private key to which the credential will be bound. The issuer also compares a wallet subject identifier with the identifier stored for the user who authenticated through GOV.UK One Login. The documentation says a mismatch means the wallet does not belong to the person who logged in, so issuance must stop.[3]

That is more precise than saying “the signature proves the person.” The proof shows control of a key. The account and identity checks provide the person-binding evidence. In the Wallet design, the credential is bound to a specific wallet instance using a did:key; that is a technical binding to a key and device, not a universal guarantee about the human using the device.[3]

The DVS Trust Framework also treats binding as a distinct property. It requires holder services to be able to tell relying parties whether an identity or attribute has been reliably linked to a person, where that information is available.[1]

3. Has it been revoked, suspended or replaced?

Signature verification is not the same as a status check. A credential can have a valid signature and still be expired, revoked, suspended or superseded.

A verifier needs a status mechanism or a fresh response from an authoritative service, plus rules for what to do when the status cannot be checked. The W3C model includes status information as part of the broader credential model and describes verification as including a status check when one is present.[4]

GOV.UK’s DVS framework says holder services must make clear whether an identity or attribute has expired and whether it has been lost, stolen or revoked, if that information is available. It also requires processes for revoking, suspending, closing, recovering and changing a holder-service account.[1]

GOV.UK Wallet gives a simpler expiry example. Its validUntil value sets the technical expiry of the digital credential, and consumers must reject it after that time even if a separate physical-document expiry date is later.[3] A verifier should not treat an old but correctly signed copy as automatically current.

4. Are the claims true now?

Cryptography protects the statement that was signed. It does not independently observe the world described by that statement.

A credential might accurately record what an issuer asserted on a particular date. A blockchain might accurately preserve what a system recorded. Neither fact establishes that the underlying event happened as described, that a person still meets a condition, or that an attribute has not changed since issuance.

The verifier must apply the rules for the use case. Those rules might include checking the issuer, subject binding, dates, status, evidence, permitted purpose and any required live source. The W3C standard calls this validation: deciding whether a claim from a specific issuer meets the verifier’s business requirements for the particular use.[4]

This is why a credential can be technically verifiable but unsuitable for a particular decision. It may be issued by the wrong authority, cover the wrong person, be outside its validity period, or make a claim that is not enough for the verifier’s policy.

Digital credential and blockchain record compared

Question	Digital credential	Blockchain record
What is normally checked?	Signature or other proof, structure, dates and status where available	Transaction signature, data format, hash links and network acceptance
What does the proof protect?	The issuer’s signed claims and, in some systems, the holder’s presentation	The recorded transaction or data and its place in the network history
Does it identify the issuer?	Only if the verification key is reliably linked to an issuer	Only if the account or key is linked to a known entity outside the signature check
Does it identify a person?	Only if the identity and holder-binding process supports that conclusion	Not from a blockchain address alone
Does it prove current truth?	No. Check expiry, revocation, source data and policy	No. The chain preserves a record; it does not validate every real-world input
What can change the result?	Key rotation, expiry, revocation, suspension or a change in verifier policy	Network rules, reorganisations or finality assumptions, plus changes in the real world

The table is a guide, not a universal protocol rule. Different systems use different proof formats, trust registries, status methods and finality models. Read the system’s verification policy before treating a “valid” result as permission to act.

A practical reading of verification results

When a service reports that a credential or record is “verified”, ask what its result actually covers:

1. Proof: Did the cryptographic check pass, and was the data unchanged?
2. Issuer: Why is this key or identifier trusted for this claim?
3. Subject: What links the credential to the person, account, device or wallet presenting it?
4. Status: Was expiry, revocation, suspension or replacement checked?
5. Use: Does the claim meet the rules for this particular decision?

A clear service should expose these distinctions in words, not rely only on a green tick, colour or technical label. Interfaces should work with keyboard navigation and assistive technology, and important status should not be communicated by colour alone. Any diagram should have a text alternative that names the issuer, holder and verifier and describes the direction of the data flow.

For the privacy trade-offs around identifiers and sharing, see our guide to privacy in digital identity and blockchain systems. For storage and presentation basics, see what a crypto wallet is. The crypto glossary can provide a shorter definition of related terms.

Sources

[1] https://www.gov.uk/government/publications/uk-digital-verification-services-trust-framework-1-0/uk-digital-verification-services-trust-framework-1-0-pre-release — UK digital verification services trust framework (1.0)
[2] https://docs.wallet.service.gov.uk/verify-credentials — Consuming and verifying credentials in GOV.UK Wallet
[3] https://docs.wallet.service.gov.uk/issue-credentials/credential — Issue a credential – Wallet technical documentation
[4] https://www.w3.org/TR/vc-data-model — Verifiable Credentials Data Model v2.0