摘要

  • 2026 年 10 月 28 日的个人草案提出 HTTPS 路径 /.well-known/sustainability-data，让网站按对象和期间发布结构化的耗能与碳足迹声明。
  • 草案把每个数值都定为发布者的自述。签名在可信密钥条件下能证明内容完整、作者延续；仪表读数、分摊方法和上游数据的可靠性仍需独立核查。

先把抽屉做出来，再问里面是什么

一家服务商今天可以把排放数字写在年度报告第 78 页，明天放进图片，后天埋进一个需要手动登录的表格。采购方的机器很难比较。草案提出一个简单的公共抽屉：网站的固定 HTTPS 路径、明确的媒体类型、JSON 字段，以及所指对象、计量方法、期间和方法说明。最基础的版本甚至可以是一份静态文件。机器终于知道去哪儿敲门。

敲开门之后，判断不能交给门牌。草案第 5.1 节写得直白：文件里的所有值，是提供最终响应的网站发布者的主张。文件存在，只证明网站发布了这些文字。它没有替网站检查电表，也没有替客户检查碳换算系数。倘若一个采购看板把抓取结果直接标为“已核实排放”，看板运营者已做出额外的权威判断，却没有展示完成这一判断的工作。

measurement-method 至少让数据的来历露出轮廓。草案列出四种方法：硬件计量、根据硬件计数器估算、云服务账单、第三方模型。混合方法的数字要采用其中最不直接的标签。一栋机房的总电量可能来自仪表；分摊到单个服务的份额可能靠模型。给服务贴上“硬件计量”就把两道不同的工序塞进一张标签。方法说明链接应解释测到了什么、估了什么、怎样分摊共享基础设施、一个功能单位代表什么。链接是让人追问的入口，不是答案本身。

印章认得笔迹，认不得数字

草案允许每个声明对象带一个 signed 成员，用 JWS 签署不含该成员的对象，并要求非对称签名算法和内容类型标记。验证的关键不在于印章有多亮，而在于读者为何相信公钥。如果公钥也由同一份文件提供，发布者同时掌握声明和钥匙。读者从独立渠道取得、先前固定或用既有信任链验证过的钥匙，才能对完整性和作者延续作出更强判断。即使如此，签名仍不能证明能源数字正确，也不能凭 provider 字段的文字确认名称就是持钥者的身份。

这不是密码学的缺点，而是把工具放回它能负责的位置。签名可以帮助发现篡改；它不能去机房看抄表记录，也不能决定该把哪些租户算进边界。草案还允许附上披露材料、第三方证明和上游供应商声明。第三方证明只有在读者取回、核实签发方，并核对对象与期间之后，才与这个数字有关。一个指向证书的蓝色链接，连证书是否针对本年度都不会自动回答。

上游声明可能戳破漂亮数字。假如云供应商披露给某个客户的能源量，而客户所称的统计边界确实覆盖这份供应，客户总量却比供应商记录更低，就该查原因。但草案并未替双方定义边界归属，也没有逐个上游供应商的分摊份额。单位要换算，期间要对齐，碳会计口径要兼容。这个测试揭示两份声明之间的冲突，不会凭空制造一个全链条真值。

时间也是容易被做成戏法的一栏。一年总量与十二个月的数据是同一段时间的两种视图，把两者相加会把一年变成两年。缓存响应有新鲜度期限，声明对象有自己的统计期间。一份签名完好的旧文件，仍然可能被看板误标成“当前”。旧数字不会因为签名没坏就变新。

草案第 12 版是一份面向 Independent Submission 的个人 Internet-Draft。它的修改记录说明本版只作编辑删改，没有新增线上格式或规则。这里值得讨论的不是某个突然获批的碳标准，而是一种可发现的声明格式会怎样进入别人的决策系统。

官方原始文件