摘要

  • 一份新的 IETF 个人草案让用户在服务自己的登录界面选定代理权限、有效期和可选的调用次数，再亲手交出一次性连接凭证。
  • 用户可以写下要办什么事，但那段话进入的是同意与审计记录。下一次调用能否放行，取决于勾选的权限和逐次核验。

愿望写得再漂亮，也拦不住一个大勾

你在表单里写：“只替我发送这张发票。”旁边的选项却是“编辑所有发票”。如果勾了它，系统放行时看的是选项，不是你写下的那句限定。Christopher Emerson 的新草案把这个尴尬摆到台面上：自然语言负责留下人的目的，结构化授权负责决定机器能做什么。授权界面如果故意把两者画得像一回事，用户拿到的就是一张印刷精美的愿望清单。

10月27日的草案公告确认了修订版 01；IETF 记录将它列为仍在讨论的个人 Internet-Draft，没有 RFC 审议轨道或 IETF 背书。提案的操作顺序很具体。用户先登录保存数据的服务，在该服务自己的连接管理页查看权限。服务按用户本身已有的权利给出上限；用户再选择代理可以访问什么、有效多久，以及是否对某类资源设定每期调用上限。已有授权也会摆出来，用户可以先撤掉旧授权，再开新的。

草案还设计了可选的在场验证：用户验证器对所选权限、期限、次数、服务声明的用途和用户自己写的目的形成的精确承诺签名。随后服务只展示一次短期、一次性连接凭证。用户把它交给代理，代理再换取有范围的访问令牌；代理不能自行续期。这个动作把“给谁开门、开多久”放在用户手里，也把凭证交付从代理可自动安排的通道移开。

两段文字随行，真正上锁的是另一套字段

修订版 01新增一节，专门讲服务声明的用途和用户写下的意图。这两段话会跟着授权进入同意记录、每次调用的核验记录、审计记录和撤销事件。它们不进入权限引擎。草案要求自由文本不得扩大授权，自动理解它也只能给人工复核提供线索。于是，“只寄一张发票”不会自动变成一个只有这张发票的权限。服务若没有提供足够细的选项，就得承认自己只有粗颗粒的门锁。

真正工作的门锁在后面。代理每次调 API，都要经过 introspection 核验已选范围和次数，并留下访问记录。对于转账、删记录、群发邮件一类服务标为“每次确认”的动作，核验先暂停调用，以请求摘要固定那一次的精确参数。用户在自己的界面上用验证器批准，代理拿到确认编号再重试。拒绝就是这次请求的终点；连接一经撤销，尚未消费的确认也失效。这里的批准对象从“某类工作”收紧到“这一次、这些参数”。

修订版 00已经提出由用户亲手交付凭证；新版补进调用上限、查看旧授权、在场验证、逐次批准、撤销收口，并明确把意图文字列为证据。它还报告作者经营着一个按此思路实现的服务。原始文件没有提供独立的符合性测试。草案自己点出另一个难题：若代理控制展示确认内容的设备，验证器签名只能证明有人完成了动作，不能证明这个人实际看见了什么。人这边的屏幕，和服务器那边的规则一样重要。

原始文件