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

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

真正值得深思的问题则更为微妙：如果有人能够查看公开数据之外的受保护字段，他能否证明恰恰是这些字段是真实的？还是说他必须相信平台已正确筛选并原样传递了这些信息？

试想一位公证人，他不是对整封信件进行公证，而是对每个段落分别公证。公开信件人人皆可获得。有权获取更多内容的人将获得额外的段落，而每个段落都继续带有同一位公证人的印章。这就是我们构建平台的方式。 对于大多数平台而言，对上述问题的诚实回答是：信任。而我们的答案是：证据 - 对于每个在披露时才添加的字段，都必须提供证据。本文将解释这一差异为何至关重要，以及我们为何为此选择了更费力的方式。

访问规则对所有人一视同仁

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

实现这一目标的常规方法是在服务器端设置过滤器。服务器会识别请求者身份，查询该用户被授权查看的内容，并仅返回相应的数据片段。该标准仅此要求。读者必须相信服务器已如实筛选数据，且在传输过程中未作任何篡改。对于一份公开的技术指南而言，这已足够。 但对于一个数据处理者据此来确定二手电池价格的数值而言，这需要太多的信任。

这里有一个标准未涉及的隐患：该数据片段在传输时并未附带任何认证标识。

显而易见的解决方案是对数据进行签名。对于数据范围的两端，常规签名方式效果良好：对公开视图进行签名，对完整数据集进行签名。具体操作流程详见《DPP中的签名与证书》。但问题出在中间环节。 对整个文档的签名仅覆盖签名时存在的字段。如果向授权读者额外公开一个受保护的字段，该字段将超出已签名范围，因此会以未受保护的状态呈现在读者面前。 没有人会预先对所有“谁能看到什么”的可能组合进行签名，因为组合数量会呈指数级增长。人们只能退而求其次，采用无印章的过滤机制，而中间层又回到了基于信任的模式。

对每个字段单独签名

有一种更好的设计方案，我们的平台正是基于此构建的。制造商不再将完成的文档作为一个整体进行签名，而是通过单次操作逐个确定每个字段（对于熟悉标准的人来说：即 W3C 规范 ecdsa-sd-2023）。

每个视图都从相同的公共字段开始。读者所看到的其他内容将逐个字段添加，且每个字段都可追溯至制造商的公钥 - 这在离线状态下即可实现，无需重新签名，也无需信任组装该视图的机构。 没有授权的字段则直接缺失。并非被遮盖，而是根本不存在，也不会泄露任何相关信息。

一个示例：维修企业

一家维修企业针对某块电池申报了“正当利益”，这是《电池法规》明确规定的访问级别之一。该企业的维修系统使用其密钥登录我们的接口，并调取该电池的通行证。 系统返回的正是购买者所看到的同一份公开凭证，但多了一个字段：拆卸说明，该信息仅向授权读者公开。没有第二份文档，也没有特殊版本。

在企业依赖该字段之前，其软件会将随附的签名与制造商的公钥进行比对验证。如果签名验证通过 - 包括对该附加字段的验证 - 企业便能确定：这份说明书的每个字符都完全来自制造商，且在传输过程中无人对其进行过任何篡改。 如果验证失败，系统会将该视图整体搁置。确保系统仅接收其有权访问的字段，仍是我们的访问控制机制的任务。接下来这一步是全新的：系统会自行验证接收到的内容是否真实，而无需征询我们的意见。

为什么“完好无损”才是关键

完好的封条并不意味着内容真实。 它表明：这正是制造商所写的内容，且自那时起无人对其进行过任何修改。因此，所有仅负责传递该文档的环节 - 缓存、网络、档案库，以及我们 - 都无需参与信任验证。

谁将护照交给您，已不再重要。

而且印章是二进制的。它要么有效，要么无效，不存在“半破损”的情况。因此，附加字段是带着印章还是没有印章到达您手中，并不是一个程度上的差异：没有印章时，这些字段并非“稍弱”地被填入，而是根本没有被填入。

两种查看方式

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

这两者都是开放的W3C标准，任何人都可以实现。 对整份文档进行签名在构建和运营成本上明显更低，而且仅提供公开数据的用户仅需采用此方法即可。Transpareo Time Machine 同时支持这两种方法是出于刻意设计：该通行证仍采用常规标准格式，任何兼容的工具均可对其进行验证，而不仅仅是我们自己的工具。

这对谁有益，以及标准的要求

除了公共数据之外，还有谁会获得其他信息披露？绝不是那位偶然路过的女顾客。 而是那些评估二手电池组价值的数据处理者、为风险定价的保险公司、对化学物质进行分类的回收商，以及负责立案调查的政府部门。这些读者的决策直接关系到金钱或安全。 而在通常的做法下，恰恰是这些读者，对于其决策所依据的字段，却无法获得认证标识。我们认为，一个认证标识对所有人而言都应具有相同的含义：所显示的每个字段均来自制造商，且此后未被篡改。 仅针对公开字段的认证标识，只是半吊子的认证标识。

我们直言不讳：上述内容均非强制要求。EN 18239标准要求对访问进行控制，而服务器端的过滤器完全能够胜任这一任务。 我们将公开字段设为可验证，这只是额外举措，因为签名通行证的全部意义在于：任何人都不必信任该平台。若将中间层作为例外剔除，恰恰会重新引入签名本应消除的那种信任。

同样的原则也会导致某个字段被忽略

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

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

为什么这很难，以及我们是如何解决的

该方法并非我们首创，而是W3C的公开标准。想出这个点子并不难，难的是将其构建得让护照在十年后仍能通过验证。 普通的签名是针对文档的字节进行计算的。而按字段签名的做法则是针对文档中的单个数据项进行计算，为此，在签名之前，护照会被转换为一种固定的格式，其中每项数据都作为独立的句子呈现。 这种格式必须在十年后能逐字符完整还原，否则任何印章都将无法匹配。有三个不起眼的问题阻碍了这一点，而我们已从根源上解决了这三个问题。

数字会丢失其类型。像 2.0 这样的值，经过常规数据格式的处理后，会以 2 的形式返回。对人来说这没区别，但对固定格式而言却是另一回事。在我们这里，每个值都会连同其类型一起存储，一旦出现哪怕一个没有类型的数字，发布过程就会立即中止。

名称本身并不代表含义。每个字段名都必须能追溯到词典中一个唯一的含义，否则该字段在转换时会悄然消失，且签名也不会覆盖它。在我们这里，每个词典都存储在本地，绝不会通过网络获取； 遇到未知字段名时，系统会停止签名，而非默默返回一个空结果。

条目需要固定名称。在我们这里，文档中的每个条目都带有固定标识符，以确保每次处理时的写法保持一致，而不是每次都分配新的辅助名称。

最棘手的部分在于制造商的专属密钥。每次签发都需要一个额外的、短效密钥，用于对可公开字段逐一进行签名。该密钥由制造商自行生成并销毁。如果该密钥由我们持有，我们便可能事后随意添加单个字段。 每本护照都带有两个此类印章，一个来自制造商，一个来自Transpareo，即使是单独公开的字段也是如此。

对我们而言，这番努力是值得的。借助Transpareo Proofchain ，每份护照在发布时都会被签名，并与前一版本建立链式关联；而Transpareo Vault - 这个不可篡改的十年存档 - 会在护照于欧盟注册系统完成登记后立即生效。 对每个字段进行签名而非对整个区块进行签名，是对这一核心机制的扩展，而非附加功能。

当前进展

我们决定采用这种验证方式，是为了让每位读者都能理解 - 因为无论谁查看，一个认证标记都应代表同一层含义。如果您想亲眼见证其运作原理：上述两个链接中的示例通行证可在浏览器中直接验证，无需查询服务器。