留回执的例外：VOC 与可读的拒绝

2026-10-30 · RTTP · IQA

规范解读 · 第 21 篇 · 本文引证来源 · 地形帖（Karp 致 Larry Lewis，Cc 全列表；引文逐字）： W3C Agent Protocol CG · post 0097 · Alan Karp · 实验帖（Karp 致 Lee；引文逐字）： post 0098 · 我们的答复（Lee 致 Karp，已上墙）： post 0103 · 同一天的第一轮：规范解读 · 第 20 篇 · 本轮所建其上的那次更正：规范解读 · 第 19 篇 · 底层的租约语义： draft-li-rttp-iqa-addressing-01（全文） · 姊妹双柱： RTTP（rttp://，CRI 27）· IQA（iqa://，CRI 28）

产出第 15 到 19 篇的那场交流，没有停在那次更正上；它从画地图转向了做设计。同一个晚上连发的两帖里，同一位对话者——Alan Karp，其一连串提问自第 15 篇起一路驱动着本系列——先在致 Larry Lewis 的一帖中摆出了委托政策地形的实况，随后伸手去拿每一个委托系统都缺的那块。他指出的缺口，说起来容易，被忽视更容易：

墙上的地形原文（0097 号帖，Karp 致 Larry Lewis，中译） · Alan Karp · 墙上原件（原文为英文，引文逐字）
「据我所知，没有任何系统给委托政策留了位置。我所知道的系统会向调用方报告为什么被拒，但没有一个向委托人报告。（在 zcaps 里，向委托人报告可能违反一项隐私属性。）」

缺口周围的那份清单值得留着，因为它说明这个缺口是结构性的，不是偶然的。Zcaps 和 UCAN 都带着使用时政策——一个叫 caveat，一个叫 Policy，在权限被行使时核验。PIC 要求在接受委托之前先有显式的 Proof of Relationship。AAuth 在令牌交换时执行政策，但政策如何表达没有规范。它们没有一个把环路闭回委托人：写下那个「请」的人，永远不知道它何时被拒、为何被拒。下一帖提出了填补同一个洞的另一块的办法——不是向委托人报告，而是给委托人一个提前请求例外的通道。

墙上的实验原文（0098 号帖，中译） · Alan Karp · 墙上原件（原文为英文，引文逐字）
「我觉得最好的情况是，委托人可以用两个选项之一来表达自己的需求。『我不知道政策是什么，所以如果这次委托违反了它，就不要 honor。』对照『这次委托非常重要。这是为什么即便它违反政策你也应该 honor 的理由。顺便说一句，如果你们不 honor，我就把我的凭证共享出去。』（可以编码为『1』或『2』。）」
「很多年前我们在另一个语境里做过一个实验。通常，数据防泄漏（DLP）软件会阻断违反政策的传输，比如把机密材料送出防火墙。问题在于人们找到了变通办法——等价于共享凭证。我们试验过『温和的 DLP』。比如，一封发往公司之外的邮件带着机密附件，我们就弹一个框：『这次传输违反公司政策。请向你的经理解释为什么应该放行。』（『经理』这个词是关键。）大多数时候，用户取消了邮件；但有百分之几的时候，他们给出了说明。遇到这种情况我们就放行。我们把这个系统叫做 Voluntary Oblivious Compliance（VOC），因为它让你在并不知晓政策的情况下自愿服从政策。」

图 1：画成一个分叉的实验。硬阻断和可读的阻断拒绝的是同一次传输——差别在下游。一条路产出变通办法，什么也不留；另一条路产出一份说明，由问责层掂量，并留下它所放行的那个例外的记录。

另一个语境里的实验

那个 DLP 研究不止是一段轶事，因为它隔离出了真正要紧的变量。硬阻断部署和温和部署对同样的用户执行同样的政策；变的只有一件事——拒绝到来时，是否带着一个你能回答的东西。硬阻断之下，人们绕路——而绕过一道硬墙，就是换了名字的凭证共享。可读的阻断之下，多数人取消了，百分之几的人解释了，然后被放行——说明留了档。政策没有变弱；拒绝变得可读了。这就是全部发现，也正是我们草案里的拒绝设计从另一个方向出发所踩着的同一条发现。

经验孪生

我们的答复（0103 号帖）把 VOC 读作那套设计的经验孪生。「向你的经理解释为什么应该放行」就是可审计的拒绝买到的东西：阻断仍是阻断，而例外的理由变成了一份可读、可回应的记录，而不是一条变通办法。那百分之几给出说明的人，正是闭集拒绝理由和它的回执为之存在的用户。而「经理这个词是关键」那句插话，恰好落在本系列自第 15 篇以来一直在画的那条边界上：例外由问责层裁决，不由协议裁决——线格式的职责只是让裁决的输入和裁决的结果成为字节，而不是意见。

两个选项住在哪里

这两个选项是随委托旅行的委托人裁量，我们的答复把它们留在了那一层：委托上的一个 caveat——用 zcaps 自己的词汇——而不是验证层的新字段。选项一说，这次委托只在政策最终证明的范围内成立；选项二说，这次委托重要到值得自带一份请求例外的论证。两者都是加了结构的「请」——而本系列自第 15 篇以来，每个「请」都住在同一层：一层之上，不标准化。线格式不解析它们；从来就不解析。

图 2：一个被行使的例外的三层。Caveat 随委托旅行（委托人的层）；拒绝仍是拒绝，用闭集字节陈述（线格式的层）；回执把两者绑在一起——声明了哪个选项、给出了什么理由、决策是在什么状态上算出来的——事后由有权读取的人读取，无人推送。

线格式补上的那一半

如果选项住在一层之上，自然的反驳是线格式没什么可贡献的。它有另一半。当第二个选项被行使——当有人走了例外这条路——记录可以携带：声明了哪个选项、给出了什么理由、决策是在什么状态上算出来的。例外从此事后可审计，而这恰恰是变通办法从来不曾有的。委托人从回执中获知——在委托人选择去看的时候，而不是因为验证器推送——这也正是 Karp 为 zcaps 标出的那项隐私属性得以幸存的方式：没有任何东西被实时报告给任何人；字节只是存在，有地址，有封印，留给有权读取的人。

这一轮为什么有帮助

0097 号帖给了地形和缺口；0098 号帖给了那个证明填缺口值多少的实验；答复给了分工。委托人的两个选项与线格式的回执并不竞争，因为它们在不同的层回答不同的问题。如果委托人的选项将来在某处被写下，拒绝词表和授权引用就会自然地放在它们旁边——不需要谈判，只需要相邻的记录。

一句话：选项说委托人想要什么；回执说实际发生了什么，凭据何在。