A Verified Credential Is Not a Verdict on Its Claim

W3C’s latest data-integrity draft prompts a practical distinction: checking a digital proof and deciding whether a claim deserves reliance are different jobs.

Event / source date: W3C Working Draft published6November2026; supporting Data Model Recommendation15May2025. · Published 8 NOVEMBER 2026

A new draft, a separate question of trust

W3C published Verifiable Credential Data Integrity 1.1 as a Working Draft on 6 November. It describes cryptographic mechanisms for protecting the authenticity and integrity of credentials and related documents. The status is provisional: publication as a Working Draft does not imply endorsement, and the document can change. It should not be described as a completed new standard.

The practical issue examined here is the meaning of a successful check. W3C’s established Verifiable Credentials Data Model v2.0 explicitly distinguishes verifiability from the truth of a credential’s claims. A verifier applies its own policies before relying on a credential. The product analysis below asks how that distinction should appear to a person making a consequential choice, rather than treating a cryptographic result as a universal verdict.

Begin with the proposition being relied upon

Consider a hypothetical certificate stating that someone completed a course. A business deciding whether to appoint that person to a particular task has several questions. What exactly did the course cover? Who issued the certificate? Does completion meet the business’s requirement? Those questions do not disappear merely because a document can be checked successfully.

The organisation should state the proposition it needs to establish before choosing the credential that might support it. Otherwise, a technically impressive verification process can answer a narrower question than the decision-maker intended. The document might concern attendance when the decision requires demonstrated competence. That is a mismatch of meaning, not necessarily a defect in the document.

A successful check needs an intelligible label

An interface should identify what its success indicator means. “Document check completed” and “qualification accepted for this role” communicate different outcomes. A broad green label such as “verified” can leave the person to infer which judgment has been made. The design should avoid asking colour and a single word to carry several independent conclusions.

A useful result could separate the technical check, the relevant issuer policy and the organisation’s acceptance decision. The exact presentation should fit the real system and its users. The purpose is not to display every implementation detail. It is to prevent one completed operation from silently becoming permission to rely on everything the document might appear to say.

Issuer acceptance should be a deliberate policy

A hypothetical employer might accept a certificate from a particular professional body for one kind of task while requiring further evidence for another. That policy should have a responsible owner and a reason connected to the decision. It should not emerge accidentally from whichever credential happens to be easiest for the software to process.

Acceptance rules also need a route for exceptions. An unfamiliar issuer is not automatically illegitimate, and a familiar issuer does not settle every possible question. A reviewer should be able to explain which requirement remains unestablished and what additional information would help. That is more useful than treating every unrecognised document as a person’s failure.

Keep a failed check distinct from a false claim

A system may be unable to complete its check. Its message should describe the actual limitation without jumping to an accusation. An unavailable dependency, an unsupported format and a demonstrated inconsistency call for different next steps. The organisation should not present an operational inability as proof that someone supplied a dishonest account.

This is a proposed communication standard, not a description of any named product’s errors. The principle is fairness through precision. A person affected by the result should understand whether they need to provide another format, seek clarification from an issuer or challenge the organisation’s interpretation. A generic rejection can conceal those routes even when a practical resolution exists.

Record the policy applied to the decision

A decision record should make clear which credential was considered, what requirement it was used to assess and which policy governed acceptance. Retaining a bare success symbol would leave a later reviewer unable to tell why the organisation acted. The record should contain the information actually needed for accountability, with an appropriate limit on unnecessary personal data.

A later change in policy should not rewrite what the earlier decision meant. The organisation may need to review an ongoing authorisation, but it should explain that new action separately. This keeps the history intelligible: which evidence was available, which judgment was made and what has changed since then.

An acceptance decision should also identify its scope. Approval for one course requirement should not silently become approval for an unrelated role. A reviewer needs to see which question was answered and which remains open. Keeping that boundary explicit lets a useful credential support an appropriate decision without allowing its technical presentation to acquire a wider authority than anyone intended.

Trust remains a responsibility, not a decoration

The November draft is a reason to examine how technical assurance becomes an organisational promise. It does not establish that any particular credential ecosystem already meets the standard proposed in this essay. Nor does a specification remove the need to decide what evidence is appropriate for a particular purpose.

A well-designed service should let the reader distinguish a document’s technical result from the decision that follows it. Name the claim, define the acceptance rule and preserve a way to examine a contested result. Digital proof becomes more useful when its boundaries are understandable. Treating it as an all-purpose guarantee would make the surrounding judgment less visible at precisely the moment it should become more accountable.

Gabriel Nicolaev — CyGuru

Sources & further reading

W3C: Verifiable Credential Data Integrity 1.1 Working Draft, 6 November 2026 ↗

W3C: Verifiable Credentials Data Model v2.0 ↗

Editorial photograph for illustration.

FOLLOW THE CONNECTION

Another angle on this subject

Continue through related ideas, decisions and consequences.

Technology & AI

A Beautiful Interface Still Needs an Intelligible Name

W3C’s November accessible-name draft puts a practical design question in focus: can a person identify an action without relying on its appearance?

Technology & AI

A Rollback Plan Must Account for the Data Already Changed

Reversing a release is a proposed recovery action, not proof of recovery. The plan must explain what happens to records the newer version has already written.

Technology & AI

An AI Energy Claim Is Only as Clear as Its Measurement Boundary

Energy per request, total electricity demand and avoided emissions answer different questions. Comparing them requires visible assumptions and a defined useful output.