What Does a Verifiable Credential Actually Prove?
Can a machine verify a product certificate? What verifiable credentials and Digital Conformity Credentials prove, and what they do not.
Jump around this page
- In 60 seconds
- 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 claim
- Certificate state and certificate scope are separate checks
- Resolver discovery is not credential verification
- Role-based variants are not the same as cryptographic selective disclosure
- What is mature now and what is still emerging
- A practical trust rule
- What would change this page
- Sources
In 60 seconds
Can a machine verify a product certificate? Yes, when the certificate is issued as a verifiable credential. Software can check its cryptographic proof, the identifier associated with its issuer or controller and, where used, whether it is current, suspended or revoked under its status mechanism.
- W3C Verifiable Credentials Data Model 2.0 became a W3C Recommendation in May 2025.
- Strong cryptography can make a weak claim tamper-evident. It cannot make the claim stronger than the evidence behind it.
- A DID answers which identifier controls the keys, not which legal organisation is behind it. DIDs do not require blockchain.
- A first-party declaration does not become third-party certification because it is signed as a credential.
- As of 6 September 2026 the UNTP DCC, DIA and Identity Resolver profiles are emerging. UNTP graph validation is possible / draft.
It cannot check, on that alone, whether the claim is true, whether the issuer was entitled to certify that scope or whether the credential refers to the physical item in front of you.
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 doesn't, 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.
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
To avoid overclaiming, 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, authority and scope | Was the claim made through a competent process, and does it cover this subject? | A credential can carry criteria, assessment references, evidence, issuer metadata and the subject, certificate reference or scope it names | Competence, accreditation, scheme rules, test quality and legal sufficiency still need governance, and so does whether the scope is commercially or legally sufficient for the claim you want to make |
| 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 layers are cumulative, not interchangeable: passing the first doesn't pass the fifth. The editorial boundary that matters most 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. The related Verifiable Credential Data Integrity 1.0 Recommendation of 15 May 2025 defines a cryptographic proof model that can make compatible credential data tamper-evident and allow authorship or authenticity checks.
Version discipline matters too. W3C's VC Data Model publication family shows v2.1 as a Working Draft dated 16 August 2026, while v2.0 remains the Recommendation. Pin the normative version and profile you support rather than treating "VC" as one timeless specification.
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.
So 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 doesn't 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 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
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 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.
So who checks DPP information has to distinguish registry checks, evidence checks, conformity assessment, technical verification and market surveillance.
Certificate state and certificate scope are separate checks
Existing certification systems show why this is operational rather than theoretical. OEKO-TEX Label Check lets a third party enter a label number and check whether an OEKO-TEX label is official. GOTS' Certified Suppliers Database lets you search certified entities, their location and GOTS certified products. It is a directory, so a listing alone does not show that a particular product is certified. FSC provides public certificate-holder search. The EUDAMED Notified Bodies and Certificates module exposes current certificate state, with links to manufacturer and Basic UDI-DI references, in a regulated medical-device context. That shows regulator-run, machine-usable certificate-state infrastructure is possible in production. It does not create a generic certificate registry for every product category. The EU Ecolabel has a public-authority-backed catalogue, and catalogue presence still has to be read against the label's criteria and scope.
Those schemes are not equivalent. A machine can receive a technically valid credential from a real issuer and still need to ask:
- Is this issuer recognised for the relevant scheme?
- Is the certificate current for the relevant period?
- Does its scope cover this product, site, process or claim?
- Is the identifier in the credential bound to the subject being evaluated?
- Does the proposed product claim stay inside what the scheme certifies?
Join before verify
Verification has an order problem. First establish which product, batch, item or other subject the evidence is supposed to describe and which certificate claims to cover it. Then verify the artefact. A valid signature on the wrong certificate is still the wrong evidence for the target product.
A digital mill test certificate makes this concrete. Software may extract a heat number and validate the issuer, signature or credential status. That tells you useful things about the artefact and its integrity. It does not, by itself, prove that the certificate belongs to the material in front of you, that the underlying physical test result is true or that a document-level value has been interpreted at the correct heat, batch or sample scope. The steel-specific row and scope logic is in how mill-certificate facts become governed steel data.
A verification result worth exposing
Report the layers independently rather than collapsing them into one status. This is ActivateDigital architecture guidance, not a W3C requirement.
| Check | Example output | Interpretation |
|---|---|---|
| Credential integrity | PASS | The secured credential validates under the expected proof method |
| Issuer identity | PASS | The credential resolves to the expected issuer identity under the chosen trust method |
| Issuer authority | CHECK / UNKNOWN | Authority for this particular scheme or scope still needs policy evidence |
| Credential status | PASS | The compatible status source does not report suspension or revocation at the time checked |
| Product/scope binding | CHECK | The product, model, batch, site or other subject needs to match the certificate scope |
| Physical-item authenticity | UNKNOWN | No physical authentication conclusion follows from the credential alone |
Collapsing the subject join, the artefact check and the claim-and-scope decision into one "verified" state makes a technically successful check look stronger than it is. A valid credential can contribute to an agent's trust decision, but it is only one part of what has to be true before an AI agent can act on a specific product.
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. “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 |
| W3C Verifiable Credential Data Integrity 1.0 | Now: published Recommendation, 15 May 2025 |
| W3C VC Data Model v2.1 | Working Draft dated 16 August 2026; v2.0 remains the Recommendation |
| Product-specific credential profiles and explicit acceptance by regulators or certification schemes | Emerging |
| Wider use by software agents, once product binding and trusted-issuer semantics are standardised and interoperable | Possible |
| “Valid credential means true claim, compliant product or authentic physical object” | Not supported |
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 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.