Thesis. A successful verification proves a bounded set of properties about a record — usually that its bytes are intact and that a particular key signed them — and every further property a relying party cares about, from the signer's authority to the claim's applicability to this purchase, is a separate check with its own failure modes.

Research question. What exactly is verified when a record, credential or signature is valid?

The standards already say this

This is not a new observation, and Tinor did not invent the mechanisms involved. The W3C Verifiable Credentials Data Model v2.0 states it directly: "Verifiability of a credential does not imply the truth of claims encoded therein." Instead, after establishing authenticity and currency, "a verifier validates the included claims using their own business rules before relying on them", and "verifiers trust certain issuers for certain claims" (W3C VC 2.0).

The same model names three roles — issuer (asserts claims), holder (possesses and presents credentials), verifier (receives and evaluates them) — and gives credentials an explicit validity period (validFrom, validUntil), a status mechanism for revocation or suspension (for example the Bitstring Status List), and an optional evidence property the issuer can use to describe what it checked. Provenance vocabularies such as W3C PROV-O separately describe which agent was associated with which activity that produced which entity. X.509 public-key infrastructure has long separated certificate validity from revocation (RFC 5280), and trusted timestamping is its own protocol (RFC 3161).

What these standards provide is a vocabulary of distinct checks. The practical failure is collapsing them into one green tick.

Six things that "verified" can mean

Check	What passing shows	What it does not show
Integrity	the bytes match a committed hash	that the content is accurate
Signature validity	a holder of key K signed these bytes	who controls K; when it was signed (that needs a trusted time source such as RFC 3161)
Signer identity	K is bound to a named party (via a DID document, certificate chain, registry)	that the party may make this claim
Authority for the claim	the named party is recognised — by the verifier's policy — as entitled to assert this kind of claim	that the claim is true
Status and validity	not revoked or suspended as of the check; inside its validity window	that it will remain so; that the issuer's status service is itself correct
Scope and applicability	the claim covers the subject, site, product and purpose at hand	anything outside that scope

Integrity versus content truth

A hash proves that bytes have not changed. A perfectly intact file can contain a false statement. Tinor's own proof model states this explicitly: an evidence hash, a signature and a proof structure are three different things, and a content hash establishes integrity, not the truth of what the content says.

Signer identity versus authority for this specific claim

A valid signature from a known company proves the company signed. Whether the company may attest that a third party is certified is a question about authority, which belongs to the verifier's trust policy: a certification body is a recognized authority for its own certificates; a supplier is an authority for its own statements about itself; a distributor is neither for someone else's certificate.

Self-declaration, third-party attestation, authority-based evidence

These are different evidence classes, even when all three are signed:

Self-declaration — the subject asserts something about itself ("we hold certificate Q-0001").
Third-party attestation — another party asserts it ("our auditor reviewed Q-0001").
Authority-based evidence — the party with recognized authority over the claim asserts it (the certification body's register lists Q-0001 as valid).

A signature upgrades none of these into another. Tinor's protocol, for example, records hosted platform signatures as platform-attested — the platform vouches that the event came from an authenticated account and was not altered — and explicitly not as issuer-signed.

Revocation, validity, scope and recipient policy

A credential can be authentic, signed by the right authority, and still be the wrong basis for a decision because it was revoked yesterday, expires before delivery, covers another site, or does not meet the recipient's policy (for instance, the buyer requires accreditation of the certification body). Status is also time-bound: "not revoked" is a statement as of a particular status check.

Why a verifiable record can still be wrong or fraudulent

The issuer erred: the audit missed a non-conformity.
The issuer was deceived: forged documentation was presented before issuance.
The key was compromised, or the signer acted outside their mandate.
The record is genuine but stale: superseded by a later one that the verifier has not seen.
The record is genuine but about something else: a sister company, a different site, a narrower scope.

Verifiability makes each of these failures investigable — you know whose statement it was and can trace what it rested on. It does not prevent them.

Case: one factory certificate, six checks (hypothetical)

A buyer's agent evaluates certificate Q-0001 for a purchase of injection-moulded housings from supplier S's Ningbo site, delivery in four months. All parties are fictional.

#	Check	Result	Basis
1	File untampered	pass	PDF hash matches the hash committed when S uploaded it
2	Signature valid	pass	the event recording the upload carries a valid platform signature
3	Signer identity clear	pass, but	the signature is platform-attested on behalf of S's authenticated account — it identifies S as the submitter, not CB as the signer of the certificate
4	Scope matches	partial	certificate scope: "design and manufacture of injection-moulded components" at the Ningbo site — matches the product; the purchase also includes assembly, which is not covered
5	Not currently revoked	unknown → pass after check	no status information in the PDF; a dated lookup on CB's public register shows "valid" today
6	Applicable to this purchase	needs decision	validity ends in 5 months, after delivery; buyer policy requires accredited certification bodies — CB's accreditation not yet checked

Checks 1–2 are cryptographic and passed. That establishes almost nothing about checks 4–6, which are where the purchase decision actually turns. A system that reports "certificate verified ✓" after checks 1–2 is not lying about the cryptography; it is misleading about the decision.

The useful output is the table itself, per check, with dates and sources — and an escalation for check 6.

Counterarguments and limits

"Fully signed credentials from the issuer solve this." They improve checks 2–3 and, with a status list, check 5. They do not decide scope or applicability, and they still depend on the verifier's trust in the issuer.
Granularity costs. Six results are harder to display than one tick. The answer is to aggregate for display while keeping per-check results available — not to discard them.
Some checks are not automatable. Applicability often depends on contract terms and judgment; the right system behaviour is to route it to a person with authority, with the other checks already done.

Where Tinor stands

Tinor's proof model already separates evidence, signature and proof, derives assurance levels from independent facets rather than storing a single trust level, and labels hosted signatures as platform-attested. It does not claim to establish content truth, and the existing mechanisms referenced above — verifiable credentials, status lists, X.509, timestamping — are external standards, not Tinor inventions. Authority recognition and applicability remain recipient policy.

References

W3C (2025). Verifiable Credentials Data Model v2.0. W3C Recommendation, 15 May 2025. w3.org
W3C. Bitstring Status List v1.0. w3.org
W3C (2013). PROV-O: The PROV Ontology. w3.org/TR/prov-o
W3C (2022). Decentralized Identifiers (DIDs) v1.0. w3.org/TR/did-core
Cooper, D. et al. (2008). RFC 5280: Internet X.509 PKI Certificate and CRL Profile. rfc-editor.org
Adams, C. et al. (2001). RFC 3161: Time-Stamp Protocol (TSP). rfc-editor.org

Proof Is Not Truth