摘要

  • RFC 9796 中的 verified=true 表示插入该 Call-Info 字段的一方，成功验证了该字段所表达的信息；接收端仍需与这一方存在经过认证的信任关系。
  • 断言只属于对应字段，不会自动扩展到全部来电资料、通话理由、对话合法性或业务结果。没有该参数也不等于欺诈，只表示缺少规范定义的验证指示。
  • integrity 哈希可以证明取回的字节与声明值一致，却不能证明来源、时效、可用性、显示结果、用户注意或来电者的真实意图。

从来电者一侧看，这是一条签名链；从手机一侧看，它往往只是一个布尔值。两端之间发生了什么，决定“已验证”究竟是一份可追溯的判断，还是一个无法追问的图标。

RFC 9796 为 SIP Call-Info 定义了丰富来电资料的表达方式，包括 call-reason、verified、integrity 与 purpose=jcard。规范没有说 verified=true 证明整通电话真实。它说的是：把这个字段加入消息的一方，已经成功验证该字段所代表的信息；接收方能否信任这一结论，取决于它与发送该请求的一方之间的信任关系。

主语不能省略。验证者不是抽象的“网络”，对象也不是笼统的“来电”。这是一个具名主体对一个限定字段作出的下游断言。

终端收到的是验证结果的转述

RFC 9795 规定如何在 PASSporT 中保护丰富来电资料及引用资源的摘要。RFC 8225 定义 PASSporT，本身沿用 RFC 7519 的 JSON Web Token 结构；RFC 8224 则把 STIR 身份机制放入 SIP。

终接服务商可能具备验证签名、证书路径、声明和值摘要的能力，而用户终端没有。RFC 9796 允许服务商把已接受的结果转换成 Call-Info，交给受认证、受信任的用户—网络接口设备。这样做降低了终端实现门槛，也新增了一次证据保管交接。

终端不能再说“我验证了原始 PASSporT”。它只能说“我信任的服务商告诉我，这个字段通过了它的验证”。两句话都可能真实，但证据来源不同。

完整记录至少要把以下状态分开：候选 RCD 被提供；PASSporT 到达；签名和证书路径有效；声明与资源摘要匹配；本地政策接受；具名参与者生成特定 Call-Info 字段；终端认证该参与者；外部资源被取回；摘要相等；设备允许显示；用户真正看到；用户采取行动；后续事实证明来电者与目的；服务结果发生。

任何一步都不能借用下一步的结论。签名有效不是政策接受，政策接受不是终端显示，终端显示更不是对话合法。

一张卡片包含多个不同保管链的声明

RFC 3261 定义 SIP 与 Call-Info。普通 From 显示名并不天然可信，也可能沿信令路径被忽略或改写。RFC 9796 的价值，是让下游能够明确指出哪些选定信息经过谁的验证，而不是把所有屏幕元素混成一个身份事实。

jCard 由 RFC 7095 定义，JSON 语法遵循 RFC 8259。RCD 配置只容纳一个实体对象，并要求姓名、照片、徽标、From、P-Asserted-Identity 与图标等重叠表示保持一致。这条约束本身就说明来电卡片是组合物：姓名、图像和理由并非天然共享一份证明。

jCard 可以放在 data: URI 中，也可以放在由 RFC 2392 cid: 引用的 MIME 正文中，还可以通过能够验证来源完整性的途径取回，例如绑定到已验证域名的 HTTPS。内联、消息体引用与外部下载，对可用性、保管者与验证时点的影响不同。

规范甚至允许使用空 data: URI 加 purpose=jcard，只表达“显示名已验证”。即使没有庞大的卡片对象，断言也没有失去发行者。越是简短的语法，运营记录越应保存是谁插入了它。

哈希能固定图像，却不能替图像作证

integrity 参数把算法名和摘要绑定到 URI 所指资源，实现必须支持 SHA-256、SHA-384 与 SHA-512。取回资源后哈希相符，可以证明本地拿到的字节序列与声明值一致。这是一项清晰、重要的完整性收据。

它没有证明谁最初控制该资源、内容是否仍然有效、服务器是否在响铃期间可访问、终端政策是否允许显示、用户是否看见，也没有证明图像所暗示的人或机构真的参与这通电话。字节相等不是身份相等，更不是意图相等。

call-reason 也有相似边界。它是可选的，应当简短，可能被截断，也不能保证显示；来电者如何设置它不在规范范围内。“账户确认”可以是发送来的理由，却不能自动证明账户存在或后续请求安全。

RFC 7852 中的 SIP 资源优先级同样说明一个普遍原则：协议标记只有在相应授权与执行机制内才产生受限含义。不能因为字段名字显得权威，就把政策、身份与结果都装进字段。

中间网络不能继承并扩大上游判断

RFC 9796 要求 RCD 相关 Call-Info 呈现单一、一致的版本。后续参与者不得改写它，也不得再添加冲突的 RCD 字段。在没有 STIR 或其他保护机制时，跨越不受信任互联网络的修改不能假定可被发现。

这不是排版规则。若中间节点换了照片或姓名，屏幕上出现的对象就不再是前一验证者检查过的对象。必须转换时，应记录输入、验证政策、转换主体、输出字段、接收端以及时间。

公开资料能够证明规范状态，却不能证明具体部署。纯文本与规范 XML便于逐条核验；RFC Editor 信息页、勘误记录和 IETF 历史说明文档进程；IANA SIP 参数登记表记录标准化名称。它们都不能替任何运营商、网关或手机提供实现收据。

把规范落到现实，需要三个连续的检验。首先，运行代码要求指出究竟哪个组件执行了哪一次比较。其次，最低初始规范提供共同语义底线，本地政策可以更严格，却不能悄悄扩大公共字段的含义。最后，现实层次要求把协议登记、密码学验证、终端呈现、人的相信与最终结果分别描述。

因此，RFC 9796 最有价值的地方不是给手机增加一个绿色标记，而是给一次合理的信任委托划出边界。终端可以依赖服务商的判断，但证据系统必须记得它依赖的是谁。

来源