"「Please」之问：委托人的政策住在哪里"
规范解读 · 第 15 篇 · 本文引证来源 · 问题原文（引文逐字）： W3C Agent Protocol CG · post 0058 · 我们的同线程答复： post 0062 · 问题所触及词表的草案全文： draft-li-rttp-iqa-addressing-01（全文） · 系列页： datatracker · 姊妹双柱： RTTP（rttp://，CRI 27）· IQA（iqa://，CRI 28）
10 月 27 日，W3C Agent Protocol Community Group 列表上来了一问，提问者是一位深耕能力安全（object-capability）传统数十年的资深参与者——这个学派几十年来研究的问题与此次讨论正属同族：授权如何被委托、携带与撤销。问题直邮给我们，而且值得全文读一遍，因为它把整个智能体授权领域人人在绕着走的那个缺口，作了一次最锋利的表述：
“Knowing why a request was rejected is useful. More useful is knowing the policy the delegator would like you to follow, e.g., only within the company. Most people (and agents) would obey your wishes if only they knew what they were. I have yet to see a system that has a place to put this information. As an aside, that policy is stated as a “Please.” Blocking a delegation that violates it leads to credential sharing, which means you'd also like a place to say why the policy is being violated.”（知道一个请求为什么被拒是有用的。更有用的是知道委托人希望你遵循什么政策——例如「仅限公司内部」。大多数人（以及大多数智能体）只要知道你的意愿就会照办，问题只是他们无从知道。我至今没有见过任何一个系统为这条信息留了位置。顺带一句，这类政策是以一个「Please」来陈述的。拦截一条违反政策的委托会导致凭证共享，所以你还会想要一个地方，能说明违反的究竟是哪条政策。）
缺口是真的——而且这个 omission 是刻意的
我们的答复做的第一件事是认下前提：就我们所知，没有任何已部署系统把委托人的常设政策作为依赖方可以读取的数据来承载——我们的双柱也不填这个槽位。这一点值得明说，因为公开往来的诱惑就是宣称这缺口早已被你发运的某件东西填上了。它没有，装作填了只会让这轮往来失去价值。
但认下缺口不等于认下它该在提问所假设的那一层被填上。我们的草案 draft-li-rttp-iqa-addressing-01 第 8 节的拒绝原因是一个带固定优先序的五值闭集，其中每个值都是权威事实：证据不匹配、证据过期、权威无法判定、权威已吊销、操作不被允许。「仅限公司内部」不是权威事实。它是授权的条款，或委托人的偏好——它住在委托人递交的授权令里，而不住在验证方算出的线格式应答里。
为什么我们不给「Please」列表
草案对政策文本执行与对动作动词相同的规则。同一草案的第 7.1.1 节论 ACTION 字段：“this document deliberately defines no enumeration of verbs, because enumerating an open set would close it.”（本文档刻意不为动词列表，因为列举一个开放集合就等于把它关上。）一个冻结在起草者当时所能想到的动词上的动作词表，发布当天就不再是开放集——每个用了委员会没预料到的动词的部署，从此按定义都成了非标准。一个标准化的「Please」词表会死于同一种死法：被标准化之时，恰好就是被我们最先想到的那几条关死之日。
这不是固执，这是地板与天花板的区别。五个拒绝值能当地板，是因为权威事实是有限的——验证失败的方式就那么几种，集合把它们全部命名了。政策不是有限的。委托人总会想要没人想象过的约束，而服务他们的架构，是那个刻意让政策层保持开放的架构。
凭证共享的论证反倒帮了闭集
提问的收尾一步——拦截违反政策的委托导致凭证共享，所以还需要一个地方说明违反了哪条政策——在我们看来，是词表既有纪律的独立佐证。草案要求实现不得发放集合之外的值、不得重新解释集合之内的值，并用一句话陈述了原则：“a response that reports an outcome without its reason is not conformant: the reason is what makes a refusal auditable.”（报告结果却不报原因的应答是不合规的：原因正是让拒绝可被审计的东西。）一个可陈述的拒绝给被拦方留下可读、可改的东西；一次静默拦截只给他们留下可以绕路的东西。在这一点上，往来双方完全一致——而这恰恰是答复该划出一致终止线的地方。
诚实的缺口
线程中没有任何工件——包括我们的——承载了提问点名的第二个槽位：为「违反了哪条具体政策的原因」设立的标准位置。政策词表是各部署自己的、开放无界的，归调用层所有——与行动时授权同一层，而草案明文不主张那一层。把它作为一个开放问题命名出来，是正确的第一步；把它标准化则是比一轮线程更大的工程，我们的答复对此未作任何承诺。缺口是真实的，它现在已入册在案——而诚实填槽的第一步，是先就槽位在哪达成一致。
一句话：「Please」是真的，它的槽位刻意不属于我们——权威事实进闭集，政策不标准化地住上一层，「违反了哪条具体政策的原因」保持为一个已命名、未回答的诚实开放问题。