What Should Appear on the Report QR Verification Page?

Short answer: what is the verification page's job?

The page must show the report identity, current revision, publication status, signature and integrity result, and verification time; it must not expose unnecessary personal data or the full report content to everyone.

The QR code is only a carrier that leads to the correct address. What creates trust is that the opened page matches the canonical report record live, does not treat an ambiguous result as valid, and clearly explains to the user what was verified.

Which information must be mandatory on the verification page?

Short answer: the user must first see the result, then which report and version that result was reached for. Technical details must explain the result; they must not overshadow the main message.

BTK's electronic signature statement notes that a secure electronic signature enables identification of the signer and determination of whether the signed data was subsequently altered. Therefore "record found" and "signature and content integrity verified" are not the same state.

How should valid, invalid and could-not-be-verified be distinguished?

The three states must be separated by clear lines. A service error or missing evidence is not a successful verification.

• Valid: The requested report version was found, the publication status is appropriate, and the signature and integrity checks completed successfully under the defined policy.
• Invalid: The content has been altered, the signature has cryptographically failed, or the record is explicitly in a cancelled/invalid state.
• Could not be verified: The certificate status could not be retrieved, the verification service did not respond, evidence is missing, or no decision could be produced about the record's integrity.

ETSI TS 119 102-2 provides for a structured trace in the validation report alongside the result, covering the validators and the validation objects used. The technical counterpart in the VizyonTech implementation is to show the end user a plain result while preserving the associated validators, policy/version and technical evidence references in the audit record.

An unexpected error screen must not show a stack trace, database identity, certificate path or internal service name. Following OWASP's deny-by-default approach, when the system fails the result must remain "could not be verified" and the user must be given a secure support reference.

How detailed should the e-signature result be displayed?

Short answer: rather than a badge making legal findings, a plain and verifiable summary of the technical checks actually performed should be shown.

The presence of a signature alone does not mean the report is current or operationally authorized. The screen must separate at least the signature integrity result, the signature time, when the certificate was checked, and, if present, the timestamp result. If the signer's identity is shown, only the fields necessary for the verification purpose should be used.

eIDAS Article 32 addresses checks such as the certificate's qualities and validity at the time of signing, signature validation data, signer data, and the detectability of security-related issues, as separate conditions. In practice in Türkiye, the applicable legislation and organizational policy must also be assessed; based on technical checks alone, the page must not produce a legal certainty claim beyond its scope.

To design the report flow before signing, see the e-signature workflow guide for inspection reports . The QR page is the controlled verification face of that chain opened to external users.

Which information must not be public?

Short answer: do not display personal, commercial and technical details not needed for verification on the public page; move the detailed report behind authorized access.

KVKK's core principles require personal data to be processed in connection with the purpose, limited and proportionate. It must be assumed that the QR link can be shared with third parties; the public view must be designed for that risk.

• Do not display direct personal data such as Turkish ID number, address, phone and e-mail.
• Do not publish the wet-ink signature image, unnecessary certificate details and the full serial number.
• Do not expose the customer's confidential facility data, measurement annexes and the full report PDF by default.
• If the signer's name is not required, use a role or masked name; document the requirement against the data processing purpose.
• Protect detailed file download with authentication, authorization and a transaction log.

How should revision and cancellation information be displayed?

Rather than silently making an old report disappear, clearly state its status and provide a secure link to the current version. This way, distributed old PDFs can be checked retroactively.

The states "current", "superseded by a new revision", "cancelled" and "pending publication" must be separate. If the cancellation reason contains sensitive information, only the general class should be shown; the detail should be left to authorized users. A new revision must not overwrite the old record's URL or history; the relationship between the two records must be preserved in the audit trail.

What should the mobile and accessible verification experience be like?

The result must be understandable on a single screen, quickly, and not dependent on color alone. Since the QR will mostly be opened on a phone, the first view must show the report identity and the result together.

• Provide the status with text, icon and sufficient contrast together.
• Announce status changes to assistive technologies with an appropriate live region or status role.
• Keep touch targets comfortably selectable; do not force the table into horizontal scrolling.
• Make it visible that the link is on the real VizyonTech domain and over HTTPS.
• If the QR cannot be read, provide an alternative query with the report number and a secure verification code.

WCAG 2.2 requires text alternatives, understandable content and programmatic determination of status messages. Therefore green/red color or a tick/cross alone is not sufficient.

How should the VizyonTech verification flow be piloted?

the Vizyon Periyodik solution When evaluating, try at least these scenarios with realistic but de-identified samples: a current and valid report, an old revision, a cancelled record, a modified file, a verification service timeout and unauthorized full-report access.

The success criterion is not merely that the QR opens. Does the user understand which report they checked, does the system stay closed on ambiguous states, is unnecessary data leaking, is the result readable on a mobile screen, and can the support team track the incident with the secure reference code? The pilot must produce evidence for these questions.