一份签名回执是一项精确而且范围有限的声明。本文将审慎而细致地说明一份有效的 Trustvice 回执所能确立的三件事、它所不能确立的诸多事情、您仍然需要在哪些方面信任我们，以及在实际使用中应当如何向他人出示回执，才能确保没有任何人夸大它的作用。
作者：The Trustvice team阅读需 5 分钟
密码学证据总是很容易引得人们夸大其词。“已签名”听起来像是“真实的”，“可发现篡改”听起来又像是“已认证的”。然而这两种理解都是不对的。如果您要在一次审计、一份合同或者一场争议中使用 Trustvice 回执，那么您所能做的最有价值的一件事，就是准确无误地描述它们：既不超出它们实际所能证明的范围，也不低于这个范围。
本文就是这样一份尽可能准确的描述。这是我们希望一位审慎的律师、审计师或者交易对手，在决定依赖一份回执之前能够认真读到的页面，其中也有意重复了我们的文档中早已说明过的一些内容。
智能体、证据、治理、商务和披露都在 Trustvice 360 中。免费注册，在一个仪表板中打开所有套件。
一份能够通过某一把已经公开发布的 Trustvice 密钥验证的回执，可以确切地证明以下三件事情。
来源。 这个信封是由与 signatureKeyId 相匹配的那一把私钥的持有者进行签名的，而这把私钥是一把 Trustvice 签名密钥。除此之外的任何人，包括您自己在内，都不可能制作出一份能够通过这把密钥验证的回执。
完整性。 除了 signature 之外，信封中的每一个成员都与签名时完全一致：类型、回执正文、issuedAt 时间以及密钥 ID。哪怕只修改了其中的一个字符，验证也都会立即失败。
一个经过签名的时间。 Trustvice 声明这份回执是在 issuedAt 这一时间创建的。这个时间来自签发方自己的时钟，而不是来自任何外部来源。
任何人都可以离线检查这三项内容，既不需要注册账户，也不需要事先询问我们。而且这项检查是完全确定性的：给定同一份回执和同一把密钥，两个相互独立的实现会得出完全相同的答案。这正是一份回执真正的力量所在，而且这种力量是实实在在、真实存在的。
在逐一列出各项局限之前，有一个重要的区别，决定了任何一份具体的回执究竟具有多大的分量。
一份回执所陈述的，可以是某一方提供给 Trustvice 的事实（经签名以表明这些事实曾被出示），也可以是关于 Trustvice 自己执行过或看到过的事情的事实。关于报告事实的回执，证明这些事实在 issuedAt 之前已被出示；关于观察事实的回执，证明 Trustvice 所看到的内容。两种情况下回执看起来完全一样，因此请查看回执类型，以了解您手中的是哪一种。
以下这些并不是产品的缺陷。它们是这项声明本身所固有的边界。
一份针对哈希的回执所涵盖的是一个哈希值。一份虚假文档的哈希，与一份真实文档的哈希，在验证时的表现完全一样。一份针对所报告的交互（例如一个提示词和一个响应）的回执，证明的是这次交互在某一时间被出示过，而不是它确实按照所描述的方式发生过。
不过，一份报告事实类的回执所能给您的东西，依然非常值得拥有：它把这项声明牢牢地固定在了某一个时间点上，因此无法被人悄悄地倒填日期，而之后对它所做的任何修改，也都必然能够被发现。
信封之中并不包含任何工作区或者账户的标识符，也不包含任何个人的签名。任何一个持有这份 JSON 的人，都可以随时出示它。一个哈希所标识的是字节，而不是所有者：它并不能表明其他人没有持有完全相同的内容。如果作者身份很重要，请把您自己的签名放进内容之中。
回执中保存的是一个哈希值。要证明某一份文档与之相符，请对这份文档计算哈希，并将结果与回执正文进行比较。只有当您把内容保存在了某个能够随时拿出来的地方时，这份回执才能真正地派上用场；否则它几乎无法帮到您。
issuedAt 是我们在签名时的时钟时间。对于一项报告的事实，事件本身发生在回执生成之前的某一个时间。在任何法律制度下，一份回执都不是一个合格的时间戳。因此，请不要声称任何比事件与回执之间的时间间隔更为精细的精度。如果您确实需要一个外部的时间锚点，请把这份回执的签名发布到某个拥有自己可信时钟的地方。
一份回执证明的是它所说的内容，而不是它没有说出的内容。回执中的空缺并不能证明什么都没有发生，无论这对您有利还是不利。
目前并不存在任何撤销机制。一份在签发时能够通过验证的回执，只要它的签名密钥还保持着发布状态，就会一直能够通过验证。同样，目前也不存在任何密钥撤销列表。一把泄露的签名密钥，会让它的持有者能够制作出可以通过验证的回执，而仅仅凭借签名检查本身，是完全无法把它们与真正的回执区分开来的。
验证让您在很多方面都不再需要去信任我们：您不需要由我们来告诉您一份回执是否被篡改过、是哪把密钥签的名，或者其中的密钥是否被调换过。剩下需要信任的，只是一小组被明确列出的事项：
Trustvice 360x 值，然后始终使用这份副本来进行验证。若要在争议中处于最有利的位置，请将回执与您自己掌控的记录结合起来使用。
当一份回执离开您的手中、交给他人时，附上一段简短的说明，就可以避免绝大多数的误解。一段好的说明，通常会做到以下这五件事：
4d9a…7d62。”trustvice.com 获取密钥，这样他们就不必依赖您所提供的密钥文件。我们的指南用于争议的证据详细展示了完整的做法：在争议发生之前就确定您将需要哪些声明，在事情发生的那一刻就获取回执，并整理出一份对方无需信任您、即可自行验证的证据包。
一份回执在某个特定的法庭、监管或合同场景中是否可以被采纳，或者是否足够充分，取决于所在的司法管辖区以及具体的案件。一份回执是一条技术记录，记录了向某个签名服务出示了什么，或者某个签名服务观察到了什么。它不是法律建议，不是一项认证，也不是任何形式的合规性证明。请咨询您自己的法律顾问的意见，并且可以考虑在您的合同中写明：双方都接受经已公开发布的密钥验证过的回执，作为其所陈述事实的证据。
一项被坦率说明的局限，往往比一项宣传声明更能建立起真正的信任，因为一份回执的用处，取决于人们描述它时的精确程度。如果您发现我们自己的页面有夸大回执证明内容的地方，请通过 /contact 告诉我们，我们会加以修正。
Trustvice 的回执基于 SHA-256 哈希值和元数据，而不是您的文档、提示词或响应正文。本文将详细介绍这一选择背后的隐私设计、它所保护的内容，以及仅靠它本身无法为您提供保护的地方。
阅读需 3 分钟
逐个字段地为您详细介绍 Trustvice 的回执信封，说明我们为什么要对 RFC 8785 规范化形式签名、而不是对线路上传输的字节签名，密钥 ID 是如何从密钥本身推导出来的，以及那个已公开发布的密钥集合究竟向您作出了哪些承诺。
阅读需 6 分钟
Two correct RFC 8785 implementations can still disagree on key order, big numbers and unpaired surrogates. We walk through each edge case in JavaScript and Python, what our canonicalizers do, and how shared test vectors catch drift.
阅读需 8 分钟
将任意 Trustvice 回执粘贴到验证工具中。它会在您的浏览器中使用我们公布的公钥检查签名，无需账户。
Trustvice 360：用签名、可验证的证据来信任并治理您的 AI 智能体。
Digital Trust. On the Record.
面向软件即服务（Software‑as‑a‑Service）的
创新平台。