在保持签名完整性的前提下进行公开

数字产品护照向不同对象展示的内容并不相同。普通消费者只能看到公开数据；维修商或翻新商能看到更多信息；而市场监管机构则能看到全部内容。这一点已明确，且欧洲标准现已对此作出明确规定。

真正值得深思的问题则更为微妙：如果某人获知了超出公开数据范围的受保护字段，他能否证明恰恰是这些字段的真实性？还是说他必须相信平台已准确筛选并原样传递了这些信息？

对于大多数平台而言，诚实的答案是：信任。而我们构建的平台则确保答案是“证明” - - 不仅针对公开字段，还包括在披露时新增的每一个字段。为什么这种差异至关重要，以及我们为何为此选择了更为费力的途径。

所有平台都同样满足访问规则

EN 18239（关于DPP中访问权限、安全性和保密性的欧洲标准）要求对每个数据元素进行访问控制：每个字段都有一条规则，规定谁可以查看它。这是正确的要求，而且并不难满足。 关于这些标准究竟具有何种地位，我们已在协调标准一文中进行了详细分析。

实现这一目标的常规方法是服务器端过滤。服务器会识别请求者身份，查询该用户被授权查看的内容，并仅返回该部分数据。访问控制：完成。标准仅此要求。

但这其中存在一个标准未涉及的隐患： 接收到的数据片段未附带签名。读者获得的是为其量身定制的视图，只能相信服务器是诚实地进行筛选的，且传输过程中未作任何篡改。对于一份公开的技术指南来说，这尚可接受。但对于处理者据此直接确定二手电池价格的情况而言，这需要过多的信任。

单个签名何时会遇到局限

显而易见的解决方案是对数据进行签名。对于数据范围的两端，常规签名都能很好地发挥作用：对公开视图进行签名，对完整数据集进行签名，然后两者都通过公钥进行验证，无需服务器作为中间环节。 具体操作流程详见DPP中的签名与证书。

问题出在中间环节。对整个文档的签名仅覆盖一组字段，即签名时存在的字段。 如果向授权读者额外公开一个受保护的字段，该字段将超出已签名范围，因此该读者收到的数据中该字段将处于未受保护状态。反之，如果一开始就对完整数据集进行签名，虽然签名覆盖了所有内容，但这就意味着必须向所有人展示所有内容。

因此，中间的环节 - - 维修商、保险公司、回收商 - - 便落入了监管漏洞。如果想要预先对“谁能查看什么”的每种可能组合进行签名，就需要为每种组合准备一份独立的签名文档，而随着访问组的增加，组合数量会呈指数级增长。 没有人会这么做。人们只能退而求其次，使用未签名的服务器过滤器，而中间环节又不得不依赖信任。

逐个字段签名

有一种更好的设计方案，我们的平台正是基于此构建的。 发行者不再将完成的文档作为一个整体进行签名，而是通过单次签名过程对每个字段分别进行签名（对于熟悉标准的人士：W3C 规范 ecdsa-sd-2023 用于选择性披露）。

每个视图都从公共核心开始

每个视图 ### 都从相同的### 公共字段### 开始。读者在此之外所看到的內容，是逐个字段添加的，而每个字段都可追溯至签发者的公钥 - - 在离线状态下，无需重新签名，也无需信任组装该视图的机构。 没有权限的字段则直接缺失。并非被遮盖，而是根本不存在，也不会泄露任何相关信息。

一个示例：维修厂

通过一个示例，我们可以具体了解其运作方式。 某维修企业针对一块电池申报了“正当利益”，这是《电池条例》明确规定的访问级别之一。该企业的维修系统使用其API密钥登录我们的接口，并调取该电池的通行证。

响应内容是与购买者所见完全相同的公开凭证，只是多了一个字段：拆解说明，该字段仅向授权读者公开。没有第二份文档，没有特殊版本，只是同一份凭证多了一个字段。

在企业依赖该字段之前，其软件会将随附的证明文件与签发方的公钥进行比对验证。如果验证通过 - - 包括对新增字段的验证 - - 企业便确信：该说明书的每个字符都完全来自制造商，无论是我们还是中间的任何环节，都没有对其进行任何修改。 如果验证失败，它同样能确信这一点，并会将整个文档搁置一旁。

我们在此过程中的参与程度是刻意保持在最低水平的。确保它仅接收应得的字段，这是我们访问控制的职责；每个服务器过滤器都能做到这一点。 真正的新变化在于后续步骤：他会自行验证收到的内容是否真实，而无需征询我们的意见。

为何“完好无损”是关键所在

试想一位公证人，他并非对整封信件进行公证，而是逐段单独公证。这封公开信会分发给每个人。 有权获得更多内容的人，会收到额外的段落，而每个段落都继续带有同一位公证人的印章。

为什么 “完整无缺”至关重要，值得再多说一句。一个完好的印章并不意味着内容是真实的。 它表明：这正是签发人所写的内容，且自那时起无人对其进行过任何修改。因此，任何仅将文件转交他人的人 - - 无论是中间存储器、网络、档案库，还是我们 - - 都与信任问题无关。谁将护照交给了你，已不再重要。

而且印章是二进制的。它要么有效，要么无效，不存在“半破损”的状态。一旦印章失效，您无法得知具体哪句话被篡改，只能确定整份文件已不可信。因此，附加字段是带着印章还是没有印章送达您手中，这绝非程度上的差异： 没有印章，这些字段并非证据效力稍弱，而是根本没有证据。

两种查看方式

任何人都可以亲自验证。Transpareo Time Machine是我们用于 ### 查看产品护照的开源展示应用： 它可浏览产品护照的版本历史，并在查看者的浏览器中重新计算每个签名，无需向我们的服务器查询。其中有两个示例护照对公众开放。一件T恤的产品护照带有覆盖整个文档的签名，而一块电池的产品护照则采用逐字段披露的方式。

这两者都是开放的 W3C 规范：eddsa-jcs-2022 用于全文档签名，ecdsa-sd-2023 用于字段级披露。任何有兴趣的人都可以实现这些功能。 工作量是许多人不会这么做的原因：全文档签名在构建和运营上明显更经济，而且如果只提供公开数据，仅使用全文档签名就足够了。

Time Machine 同时支持这两种方法是刻意为之，且将保持如此。它不隶属于任何平台。 如果验证方只接受成本更高的方法，那它就只会成为我们的工具，而对其他人毫无用处。

受保护字段的披露对象

值得探讨的是，除了公开数据之外，究竟 ## 会向谁披露其他信息。 绝不是那位顺道购物的顾客 - - 她只会获得公开数据。真正需要这些信息的是：评估二手电池组价值的处理商、为风险定价的保险公司、对化学成分进行分类的回收商，以及负责立案调查的监管机构。 这些才是决策直接关系到金钱或安全的读者群体。

而恰恰是这些字段，在常规方法中往往处于未公开状态。那些最有必要获得加密证明的人，却偏偏无法获得支撑其决策所需的字段信息。

我们认为，认证标识对所有人而言都应具有相同的含义。维修店扩展视图中显示的 “经Transpareo认证”与购买者公开证书上的标识具有同等效力：所展示的每个字段均来自签发方，且自签发以来未被篡改。 仅针对公共字段颁发的认证标识，只是半吊子的认证。

超越标准的要求

我们直言不讳：上述内容均非强制要求。EN 18239标准仅要求对访问进行控制，而服务器端的过滤器已能完美实现这一控制。 即使对公开字段进行加密验证，也是我们额外采取的措施，而非法规要求我们必须勾选的选项。

正因如此，这一点值得特别说明。签名护照的全部意义在于，任何人都不必信任该平台。 若将中间层作为例外剔除，恰恰会重新引入签名本应消除的信任。

同样的原则使得某个字段被忽略

对每个字段逐一作出规定，会带来第二个特性，而这实际上正是欧洲法律所要求的。 《通用数据保护条例》（https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679）赋予个人要求删除其个人数据的权利。 作为整体签署的数据集若要满足这一要求，就必须破坏其自身的签名。

由于每个字段都是独立存在的，因此可以删除单个字段，而其余部分仍可继续通过验证。如果个人数据意外被记录在护照中，它们可以被干净地移除，且护照仍然有效：无需重新签发，历史记录也不会中断。 法律要求保留的监管字段将保持不变；可删除的内容可应要求删除，即使在数年之后亦然。

尽管如此，它仍是一本再普通不过的护照

上述任何特性都不会使该护照成为仅能被我们的工具打开的特殊对象。它仍然是JSON-LD格式的可验证凭证，这是全球网络标准正趋向采用的格式，也是联合国透明度协议（UN Transparency Protocol）及W3C生态系统所采用的格式。

因此，购买者在浏览器中扫描的护照，与数据室合作伙伴能够读取的对象完全相同，任何符合标准的验证者（而不仅仅是我们的）都可以对其进行验证。这种额外的安全性对读者而言无需任何成本，也不会将任何人与我们绑定。

为什么这在技术上很难

首先，为了避免产生误解：该方法并非由我们发明。ecdsa-sd-2023是一项公开的W3C规范，其背后的密码学技术并非出自我们之手，任何希望实现该规范的人都可以查阅相关资料。 难点不在于构思这个想法，而在于如何构建它，以确保十年后该证书仍能通过验证。真正的挑战就在于此，而这正是值得深入探讨的。

这一区别看似微小，却改变了基础原理：普通签名是基于文档的字节进行计算的。 而选择性披露则是基于其陈述内容进行计算的。护照在签名之前会被转换为一种标准化形式，其中每项信息都作为独立的、自成一体的句子存在。只有这样，才能省略其中一个句子，而不会影响其余部分。

这便带来了一个字节签名所不具备的问题：十年后，同一规范化格式必须能被精确还原。不是近似，而是字符对字符地还原，否则证明将不再有效。有三件事阻碍了这一点，而且这三件事都看似微不足道。

数字会丢失其类型。如果将一个数字仅作为纯JSON写入，其原本的数值类型会在传输过程中丢失。例如，值2.0经过JSON转换后会以2的形式返回。这对人来说是相同的，但对标准化形式而言却是另一条语句，从而导致验证失败。

名称本身并不代表含义。要形成标准化形式，每个字段名都必须解析为一个唯一的含义。如果缺少其中一个，该字段在转换时会悄无声息地消失。它虽然仍出现在护照中，但证明文件并未涵盖该字段，而且没人会注意到这一点。

含义通常存储在网络上。这种映射关系记录在一个词汇表中，大多数工具在验证时会通过网络重新加载该词汇表。这样做的人，其护照的可验证性就取决于一个外部地址在十年后能否仍能响应，且内容保持不变。

我们的解决方案

我们从源头 ## 就解决了这三个问题，而不是事后再去补救。

类型。每个值都与其类型一同写入，一旦规范格式中出现哪怕一个无类型的数字，发布过程就会立即中止。 这样，错误就会在导致一行代码被废弃时被发现，而不是在数年后以无法解释的验证失败形式出现。

词汇表。护照引用的每个词汇表都存储在我们的本地，绝不会通过网络获取。 遇到未知地址时，签名过程会直接终止，而非悄无声息地退回到空结果。

标识符。文档中的每个节点都带有稳定的标识符，以确保规范化形式的可重现性，而不是在每次处理时都分配新的辅助名称。

最棘手的部分在于“自带密钥”（Bring Your Own Key）。每次签发都需要一个额外的、短效密钥，用于对可公开字段逐一进行签名。该密钥由签发者自行生成并废弃。 如果该密钥由我们保管，我们便可能事后捏造某些字段，而发行方签名的独立性也就仅是口头承诺。在信任返回的证明之前，我们会将其与存储的公钥进行比对验证。

每份通行证都包含两份此类证明：一份来自签发者，另一份来自Transpareo，且在读者看来，这两份证明都是独立生成的。即使对于单个公开字段，也存在两个签名、两个相互独立的权威机构。

对我们而言，这种投入是恰到好处的。 我们并非事后才添加可验证性功能；该平台从首个版本开始就围绕这一核心构建。每本护照在发布时都会被签名，并与前一版本建立链式关联。一旦护照在欧盟DPP注册处 注册后即刻生效。对每个字段进行签名而非整个区块，是对这一核心机制的扩展，而非在原本未为此设计的架构上附加功能。

当前进展

我们决定为每位读者提供证明，因为无论谁查看，一个印章都应具有相同的含义。若想亲眼见证其运作：上文链接的两个演示程序可在浏览器中直接验证，无需查询服务器。