报告二维码验证页面应显示哪些内容？

简要回答：验证页面的职责是什么？

页面应显示报告标识、当前修订、发布状态、签名与完整性结果以及验证时间；不应向所有人开放不必要的个人数据和完整报告内容。

二维码只是引导至正确地址的载体。真正建立信任的是：打开的页面能够实时对应权威报告主记录，不把无法确定的结果视为有效，并向用户清楚说明已验证的内容。

验证页面应包含哪些必要信息？

简要回答：用户应先看到结果，再看到该结果对应的报告和版本。技术细节应解释结果，而不是掩盖主要信息。

BTK 对电子签名的说明指出，安全电子签名支持身份识别，并可判断已签署数据事后是否被修改。因此，“找到记录”与“签名及内容完整性已验证”并不是同一状态。

如何区分有效、无效和无法验证？

这三种状态应明确区分。服务错误或证据缺失，并不代表验证成功。

• 有效： 已找到指定报告版本，发布状态符合要求，签名与完整性检查依据规定策略成功完成。
• 无效： 内容已改变、签名未通过密码学验证，或记录明确处于已取消或无效状态。
• 无法验证： 无法获取证书状态、验证服务未响应、证据缺失，或无法对记录完整性作出判断。

ETSI TS 119 102-2 要求在验证报告中，除结果外，还提供有关验证方及所用验证对象的结构化记录。对 VizyonTech 应用而言，相应做法是向最终用户展示简明结果，同时在审核记录中保留相关验证方、策略及其版本，以及技术证据引用。

发生意外错误时，不应在页面上展示堆栈轨迹、数据库标识、证书路径或内部服务名称。按照 OWASP 的默认拒绝原则，系统出错时，结果应保持为“无法验证”，并向用户提供安全的支持引用编号。

电子签名结果应展示到什么程度？

简要回答：应展示已执行技术检查的简明、可核验摘要，而不是使用仿佛能作出法律裁定的徽标。

签名的存在，本身并不意味着报告是当前版本或已获得业务授权。界面至少应分别展示签名完整性结果、签署时间、证书检查时间，以及存在时间戳时的验证结果。如需显示签署者身份，应仅使用验证目的所必需的字段。

eIDAS 第 32 条将签署时证书的资格与有效性、签名验证数据、签署者数据以及安全问题的可检测性等检查，列为独立条件。在土耳其的应用中，还应另行评估适用法规和机构政策；页面不应仅凭技术检查，就作出超出其范围的法律确定性声明。

如需设计签署前的报告流程， 检验报告电子签名工作流程指南 可供参考。二维码页面是该链条向外部用户开放的受控验证界面。

哪些信息不应公开？

简要回答：不要在公开页面展示验证不需要的个人、商业和技术细节；详细报告应仅供授权访问。

KVKK 的基本原则要求，个人数据处理应与目的相关、限于必要范围并符合比例原则。应假设第三方可能分享二维码链接，并据此设计公开视图。

• 不要展示土耳其公民身份号码、地址、电话和电子邮箱等直接个人信息。
• 不要发布手写签名图像、证书的不必要细节或完整序列号。
• 不要默认开放客户的机密设施数据、测量附件和完整报告 PDF。
• 签署者姓名并非必要时，应使用角色或脱敏姓名；确需显示时，应结合数据处理目的记录其必要性。
• 通过身份验证、权限控制和操作记录保护详细文件下载。

如何展示修订与取消信息？

应明确标注旧报告状态，并提供指向当前版本的安全链接，而不是悄然删除旧报告。这样，已分发的旧 PDF 仍可回溯核查。

应区分“当前版本”“已有新修订替代”“已取消”和“待发布”等状态。取消理由涉及敏感信息时，应仅显示一般类别，将细节留给授权用户。新修订不应覆盖旧记录的 URL 或历史；两条记录的关系应保留在审核轨迹中。

移动端和无障碍验证体验应如何设计？

结果应能在一个界面上快速理解，且不能只依赖颜色。二维码通常由手机打开，因此首屏应同时显示报告标识与结果。

• 通过文字、图标和足够的对比度共同表达状态。
• 通过适当的实时区域或状态角色，将状态变化告知辅助技术。
• 让触控目标易于选中；不要迫使用户横向滚动表格。
• 清楚显示链接使用真实的 VizyonTech 域名及 HTTPS。
• 二维码无法读取时，应提供使用报告编号和安全验证码的替代查询方式。

WCAG 2.2 要求提供文本替代、可理解的内容，以及可由程序识别的状态消息。因此，仅用绿色或红色、勾号或叉号并不够。

如何试运行 VizyonTech 验证流程？

Vizyon Periyodik 解决方案 评估时，应使用真实可信但已去除个人数据的样本，至少测试以下场景：当前且有效的报告、旧修订、取消记录、被修改的文件、验证服务超时，以及未授权访问完整报告。

成功标准不仅是二维码能够打开。用户是否清楚自己正在核查哪份报告？结果不明确时，系统是否仍阻止放行？是否泄露不必要的数据？移动屏幕上的结果是否可读？支持团队能否通过安全引用编号追踪事件？试点应为这些问题提供证据。