2026年4月29日，欧盟委员会发布了《数字产品护照（DPP）注册处实施条例草案》 并同时开启为期四周的意见征集期。 截至2026年5月27日，欧盟境内及境外的任何个人和组织均可通过“Have Your Say”门户网站提交反馈意见。这些意见将公开展示，每条意见均附有姓名或组织名称，并将正式纳入该条例的最终版本。
我们已在本博客中对该草案进行了详细讨论。本文将重点介绍我们向欧盟委员会提交的反馈内容。
为何提交了四份独立意见
该门户网站每条意见的字数上限为4 000字符。我们本可以将所有观点压缩成一篇长文。 但对于5月份需要处理数十份意见的委员会工作人员来说，这样既难以阅读，也难以引用。四份独立的意见在公开列表中各自独立，每份意见都可以单独予以答复 - - 或驳回 - - 而不会影响其他要点。
我们提交了以下四个议题：
1. 明确DPP服务提供商的最低要求
该条例草案正确 界定了去中心化模式： DPP数据由经济主体或其DPP服务提供商保存，欧盟委员会登记册仅存储相关引用信息。对于DPP服务提供商（《ESPR》第2条第32项），拟制定一份经批准的提供商官方名单。
但目前尚缺对服务提供商必须满足哪些要求才能被列入该名单并保持在名单上的具体规定。预计实质性义务将根据《ESPR主条例》第4条通过一项授权法规予以规定。然而，该登记册将在该授权法规公布之前启动。
我们的建议是：要么直接在本实施条例中明确规定服务提供商的最低标准，要么设定一个具有约束力的期限，规定授权法规最迟应在何时提交。建议的最低要求包括：
- DPP 公共读取接口的月度可用性至少达到 99.5%
- 制定服务级别协议，规定新版 DPP 必须在多长时间内同步到备份中（建议：24 小时内，或在技术可行的情况下实时同步）
- 服务提供商必须对收到的版本进行加密验证
- 通过标准化路径（RFC 8615，建议使用
/.well-known/dpp-keys/）发布经济主体的公钥 - 制定明确的供应商更换和破产处理流程，确保在某家供应商发生故障时，DPP数据能有序迁移至另一家供应商
这些义务对一家信誉良好的服务提供商而言无需额外成本 - - 他们本就会履行这些义务 - - 但能有效防止低价服务提供商之间的恶性竞争，从而避免最终导致注册名录的信誉受损。
2. 已注册 DPP 的长期可验证性
第 9(4) 条将注册证明的有效期上限设定为 90 个日历日。在此期限内，注册机构应请求重新生成该证明。 这对日常运营来说没有问题，但与背后DPP义务的生命周期并不相符：第10条第3款规定，标准保存期限为自注册之日起10年，行业法规可能要求更长的保存期限。
2032年的市场监管机构、海关官员、回收商或研究人员应当能够核实2026年注册的DPP是否确实已注册，而不必依赖原始经济主体是否仍然存在且能否申请新的证明。
我们的两项建议便于实施：
- 明确规定，经欧盟委员会合格加盖印章的证明字节可由经济主体或服务提供商进行临时存储、归档和分发。 根据《eIDAS条例》第35(2)条的规定，无论这些字节存储于何处，经合格认证的电子印章均具有完整性和来源推定效力。
- 在注册处设立一个公开的、无需身份认证的验证端点，该端点可针对注册ID提供经签名的响应。目前，任何第三方核查都要求经济主体主动采取行动 - - 对于一份必须比签发者存续更久的证明文件而言，这种形式是不恰当的。
此外，我们建议 确定性地规定哈希生成规则： 使用 SHA-256 作为哈希函数，JSON 规范化方案 (RFC 8785) 作为序列化方式，且位于签名块之外。 在 W3C 生态系统中，这对应于加密套件 eddsa-jcs-2022，Transpareo 正是使用该套件进行直接签名。 如果没有这种固定设置，两个服务提供商将把同一个 DPP 序列化为不同的哈希值，导致注册证明中的哈希字段无法复现。
3. 第 17 条不得限制对公共 DPP 数据的访问
第17条将“大规模数据下载”列为可能滥用注册表的行为。对于存储在注册表本身中的管理元数据（身份信息、日志、审计轨迹）而言，这一点是正确的 - - 这些数据不应被纳入大规模下载范围。
然而 ，制造商或服务提供商持有的公开DPP数据，恰恰是ESPR希望广泛开放的领域。回收商对产品系列进行成分数据分析；研究人员对可持续性声明进行横向评估； 以及开展比较分析的市场监管 - - 这些都是针对公共DPP层进行的“大规模数据下载”形式，且均属于该条例制定时所预期的用途。
我们的建议是在第17条中增加一句澄清性表述，将适用范围限定于注册数据，并就DPP数据援引相应的行业特定授权法规。 否则，服务提供商在启动时将面临两难选择：要么出于安全考虑对公共访问设置严格的请求限制 - - 从而破坏用户体验 - - 要么保持开放，但冒着日后被认定为第17条所指“滥用”的风险。
4. 在上线前发布 OpenAPI 规范和沙箱
第 3(b) 条要求提供用于注册的 API。第 8(5) 条将其列为注册的两个渠道之一。但该条例并未规定何时应发布 API 规范。
任何希望实现注册工作流自动化的主体 - - 包括所有服务提供商以及拥有较大产品目录的经济参与者 - - 都需要在启动前相当长的时间内获得 API 规范，以便进行实施并针对真实的端点进行测试。 如果在条例生效前一周才获得规范，将把集成风险转嫁给生态系统中的所有服务提供商。
因此，我们提出以下建议：
- 至少 在法规生效前八周发布OpenAPI 3.1 规范 - - 若生效日期为 2026 年 7 月 19 日，则最迟应于 2026 年 5 月 24 日发布
- 同步 提供沙箱环境，以便服务提供商和制造商能够在此环境中进行集成，并测试第8条第6款规定的自动验证功能
- 采用Semver 版本控制策略，停用通知期不少于18个月
其他设计建议：注册调用中采用幂等键、针对大型目录的批量注册、通过 Webhook 回调实现异步注册，以及为自动验证中的错误情况提供机器可读的错误代码。
我们为何这样做
咨询并非一场积攒积分的游戏。如果每一条意见都能让最终版本中的某一句表述更加精准，那么它就达到了目的。 委员会确实会阅读这些意见 - - ESPR流程本身的经验表明，具有技术依据的意见往往会在最终文本中留下痕迹。
无论如何，一旦入选程序公布，我们就会申请加入DPP服务提供商名单。 因此，确保我们参与竞争的规则精准明确并界定公平的竞争环境，这直接关乎我们的切身利益。这四份意见正是我们确保该名单不沦为单纯营销标签的具体举措。
谁可以参与
意见征集期将持续至2026年5月27日。意见可使用欧盟任何一种官方语言提交，提交前需在门户网站注册，且提交内容将公开展示。 任何将要签发或验证数字产品护照（DPP）的机构 - - 包括制造商、服务提供商、回收商及政府部门 - - 都应至少通过Have Your Say 上浏览该倡议的内容。即使是简短且专业准确的意见，也能有所助益。
我们的验证工具 Transpareo Time Machine 实际上已经在开源实践中解决了第2点中提到的验证需求：任何希望对Transpareo-DPP进行独立验证的人，现在就可以使用该工具进行操作，无需等待欧盟委员会注册簿中正式设立的验证端点。