What Does a Verifiable Credential Actually Prove? Digital Conformity Credentials and Product Trust
Learn what verifiable credentials and Digital Conformity Credentials prove, what they do not prove and how issuer, evidence and physical trust differ.
A verifiable credential can make a digital record much easier for software to check. It can show whether the record has been altered, identify the cryptographic issuer and expose status information. That is valuable, but it is not the same as proving that every claim in the credential is true.
Direct answer
A verifiable credential lets software check properties of a digital credential: its cryptographic proof, the identifier associated with its issuer or controller and, where used, whether the credential is current, suspended or revoked under its status mechanism.
A Digital Conformity Credential can go further by carrying structured evidence that an identified conformity-assessment body assessed a product, facility or other subject against stated criteria.
But machine-verifiable does not mean factually true. A valid credential does not, by itself, prove that the issuer was competent to make the claim, that the evidence was sufficient, that the assessment method was sound or that the digital record is bound to the physical product in front of you. Those are separate trust layers.
Navigate this page
- Overview
- Direct answer
- What “verifiable” actually means
- The five trust layers
- What W3C Verifiable Credentials 2.0 proves
- What a DID proves, and what it does not
- What a Digital Conformity Credential adds
- Why a valid credential can still contain a false or weak cla
- Resolver discovery is not credential verification
- Role-based variants are not the same as cryptographic select
- What is mature now and what is still emerging
- A practical trust rule
- What would change this page
- Sources
What “verifiable” actually means
In ordinary language, “verified” often means “someone checked this and confirmed it is correct”. In digital credentials, the word is narrower.
The W3C Verifiable Credentials Data Model defines a way to express claims about a subject in a credential that can carry cryptographic proof. Verification can establish that the credential satisfies the relevant proof checks and has not been altered in a way that invalidates them.
Depending on the credential design, a verifier can also check issuer identifiers and credential status.
That is a big improvement over receiving a detached PDF with no machine-readable issuer, no status endpoint and no reliable way to tell whether the file has changed. But it does not remove the need to ask what the claim means and why the issuer should be trusted to make it.
The five trust layers
A useful way to avoid overclaiming is to separate five questions.
| Trust layer | The question | What a machine check can help establish | What still sits outside that check |
|---|---|---|---|
| 1. Record integrity | Has this digital credential changed? | Cryptographic proof can make alteration detectable | Whether the original claim was correct |
| 2. Issuer or controller | Which digital identifier controlled the issuing key? | Proof verification and identifier resolution can connect the credential to a controller | Whether that controller is the legal organisation you think it is |
| 3. Credential status | Is the credential still accepted by its status mechanism? | Status lists can show valid, suspended or revoked states | Whether the underlying evidence remains substantively sufficient in every context |
| 4. Evidence and authority | Was the claim made through a competent process? | A credential can carry criteria, assessment references, evidence and issuer metadata | Competence, accreditation, scheme rules, test quality and legal sufficiency still need governance |
| 5. Physical binding | Is this digital record about this physical object? | A credential can name a product identifier | The secure physical link between code, identifier and object requires its own controls |
The most important editorial boundary is between layers one to three and layers four to five. Strong cryptography can make a weak claim tamper-evident. It cannot make the claim stronger than the evidence behind it.
What W3C Verifiable Credentials 2.0 proves
W3C Verifiable Credentials Data Model 2.0 became a W3C Recommendation in May 2025. It provides the mature data model on which emerging profiles such as UNTP can build.
A credential normally involves three conceptual roles:
- an issuer creates a credential containing claims
- a holder can store or present the credential
- a verifier checks the credential for a purpose.
The verification process can test whether the proof is valid according to the chosen cryptographic suite or envelope. W3C has also published supporting standards for JOSE/COSE securing mechanisms and Bitstring Status List credential status.
Those standards make the digital object more reliable to process. They do not tell the verifier that the issuer's business process was good, that an audit happened competently or that a product met a legal requirement.
That is why the gap a signature does not close still exists when the signed object becomes a credential.
What a DID proves, and what it does not
A decentralised identifier, or DID, is an identifier that can resolve to a DID document containing information such as verification methods and service endpoints. W3C DID Core is a published Recommendation.
A DID can help answer a cryptographic control question: which identifier controls the keys or services associated with this DID?
It does not automatically answer the real-world identity question: which legally registered company, certification body or public authority is behind that identifier?
That binding has to come from an authoritative identity process. UNTP's emerging Digital Identity Anchor pattern is intended to connect decentralised identifiers with authoritative identity evidence rather than pretending the DID itself is the evidence.
This distinction also means DIDs do not require blockchain. DID Core supports multiple DID methods and architectures. A ledger can be used by a method, but it is not a universal requirement of a verifiable credential or UNTP deployment.
For the physical-object boundary, see identity, authentication and ownership.
What a Digital Conformity Credential adds
UNTP's Digital Conformity Credential, or DCC, is an emerging profile for representing conformity-assessment information as a verifiable credential.
Its value is not that it makes conformity “cryptographic”. Its value is that the credential can carry the assessment context in a structured form: the subject assessed, the criteria, the assessment result, relevant evidence and the issuing conformity-assessment body.
That can be materially better than stripping a rich assessment record down to a PDF certificate number and an expiry date.
But the evidential hierarchy does not change just because the envelope is machine-verifiable. A first-party declaration does not become third-party certification because it is signed as a credential. A poor test method does not become a good one because its result is cryptographically protected.
Conformity assessment is also broader than certification. Testing, inspection, validation, verification and certification can all sit within conformity assessment, depending on the scheme and legal context. A credential should preserve what actually happened rather than upgrade it to a stronger category.
For that document hierarchy, see certificates, declarations and test reports.
Why a valid credential can still contain a false or weak claim
Consider a simple example.
A supplier issues a perfectly formed credential stating that a fabric contains 80% recycled fibre. The proof verifies. The issuer DID resolves. The status list says the credential has not been revoked.
Software can now say, with much more confidence, “this is the credential that the controller of this issuer identifier issued, it has not been altered and its recorded status is current”.
Software still cannot infer, from those facts alone, that the fabric genuinely contains 80% recycled fibre.
That depends on questions such as:
- What evidence did the supplier use?
- Was the figure measured, calculated or declared?
- Does the evidence apply to this batch, model or item?
- Was a competent independent body involved?
- Is the issuer authorised or accredited for the assessment it claims to have performed?
- Has the physical product been securely bound to the identifier referenced in the credential?
The credential improves provenance and machine-checkability. It does not abolish epistemology.
This is why who checks DPP information has to distinguish registry checks, evidence checks, conformity assessment, technical verification and market surveillance.
Resolver discovery is not credential verification
UNTP also separates finding a credential from verifying it.
An Identity Resolver can help software discover service links associated with an identifier. That is useful infrastructure, but resolution only tells you where the publisher says relevant data or services can be found.
The receiving system must still retrieve the credential and apply its own verification and trust policy. It may need to check the proof, status, issuer identity anchor, conformity-body authority and claim-specific evidence.
This separation prevents a common architectural mistake: treating “the URL resolved” as equivalent to “the claim was verified”.
The same principle applies to automated graph validation. UNTP has draft design guidance for validating relationships across linked credentials, but it should currently be treated as possible / emerging, not as a finished production compliance engine.
Role-based variants are not the same as cryptographic selective disclosure
UNTP also describes variant-based disclosure, where different complete credential variants can be routed to different roles or audiences.
That is not the same as cryptographic selective disclosure, where a holder can prove selected claims from one credential without revealing the rest using specialised cryptographic techniques. The distinction matters because “different people see different data” can be implemented in several ways, with different security and governance properties.
Neither pattern decides who has a legal right to see EU DPP data. The law and applicable product rules still own that question.
What is mature now and what is still emerging
| Layer | Position as of 6 September 2026 |
|---|---|
| W3C Verifiable Credentials Data Model 2.0 | Now: published Recommendation |
| W3C DID Core 1.0 | Now: published Recommendation |
| W3C Bitstring Status List | Now: published Recommendation |
| W3C VC JOSE/COSE | Now: published Recommendation |
| UNTP DCC, DIA and Identity Resolver profiles | Emerging: concrete specification, still within a work-in-progress UNTP release line |
| UNTP graph validation | Possible / draft: useful design guidance, not a finished conformance regime |
| “Valid credential means true claim, compliant product or authentic physical object” | Not supported |
The mixed status is important. Teams can use mature credential standards today while being conservative about claims that depend on a still-emerging UNTP profile.
A practical trust rule
When a system says “verified”, ask it to finish the sentence.
- The record was verified means the proof and integrity checks passed.
- The issuer was verified means the digital issuer was tied to an identity through a defined process.
- The credential status was verified means the relevant status mechanism was checked.
- The evidence was verified means somebody assessed whether the evidence supports the claim.
- The product was authenticated means the digital identity was securely bound to the physical object.
Those statements are related, but none is a synonym for another.
A good product-trust system records which layer has actually been established rather than collapsing all five into a green tick.
For the wider UNTP architecture, see what UNTP is and how it works. For the regulatory comparison, see EU DPP vs UNTP DPP.
What would change this page
This page should be rechecked when UNTP publishes a stable DCC, Digital Identity Anchor or Identity Resolver profile, when graph-validation tooling moves from draft guidance into an observed conformance regime or when new authoritative standards materially change the verification boundary described here.
The core distinction is unlikely to change: cryptographic verification can establish properties of a digital credential, but substantive truth, authority and physical binding remain separate trust questions.
Where this connects
Related resources this page depends on.
Sources
Does this reach your products?
Give ActivateDigital one product and it works out which obligations apply from the product's own character, and says which it cannot decide.