摘要

  • 9月29日更新的个人互联网草案《Agent Registry Protocol》第04版，新增了较完整的授权评估结果结构：结论、原因代码、评估时间、适用政策，以及在相关情况下的条件、证据来源和时效信息。
  • 新增条款要求，肯定授权不能被HTTP缓存延长到关键证据的有效期之外；事件流若出现影响授权的缺口，使用方必须从权威快照重新同步，或给出非肯定结论。这不是IETF批准的标准或已部署系统的证明。

设想一家服务在中午查到某个软件代理的固定标识，便让它继续执行任务。但其委托在上午已被暂停，服务读到的只是旧缓存。标识解析正确，授权判断却可能错误。Sankarshan Mukhopadhyay提出的Agent Registry Protocol（ARPA）第04版，把这种错位从抽象警告推进到可检查的答复与消费规则。该稿在IETF Datatracker上是活跃的个人提交Internet-Draft。封面写着拟议的“Standards Track”，不等于工作组采纳、IETF背书、RFC发布或实地采用。

不能把所有原则都算作新版发明。第03版已区分身份识别、认证、能力声明和实际授权，也要求考虑关键状态的时效与不确定性。第04版的独立新闻事实，是加入整章互操作与安全加固要求。其第29.1.7节为“授权评估结果”列出机器可读字段：决定、至少一个稳定原因代码、评估时刻、所用政策的标识和版本以及适用性。若是附带条件的允许，条件必须出现；若衍生、历史或预测资料实质影响判断，需要能追溯来源的检查点；若新旧程度会改变结论，还要提供时效界限或稳定的时效政策引用。

字段有用，是因为草案进一步限定如何解释它们。第29.3节仅把allow和allow_with_conditions视为肯定结果；deny、indeterminate与not_applicable各有意义，不可压成一个模糊的“失败”。第29.4节要求未知、过时、相互冲突或不受支持的关键状态保持非肯定；限制性状态也不得悄悄被读成有效。这里的“MUST”是个人草案内部提出的规范用语，并非现行普遍义务。它提示使用方：绿灯不仅需要一个仍在册的名字，还需要说明此刻依据哪一版政策、哪一份状态给出的许可。

缓存界限最容易被运营人员验证。新增第29.7节并没有禁止HTTP缓存，而是要求缓存寿命不超过授权评估所依赖的关键有效期或新鲜度界限。代理的身份记录可以长期存在，但一个肯定的行动许可不能靠缓存获得额外寿命。关键资料的新鲜度若无法确定，提案要求返回非肯定结果。草案未提供实际事故、故障频率或部署普及率；上述中午情景只是解释机制的假设。

事件流则检验同一原则的另一侧。如果注册机构宣称提供ARPA事件端点，第29.10节要求稳定事件标识及足以发现来源序列缺口的位置或检查点。若漏掉可能改变授权的事件，使用方不能只凭不完整流继续断言允许；应从权威快照或检查点重新同步，否则给出非肯定答复。这不是永久封禁，补齐可信状态后仍可重新评估。第29.11节另将写入默认为拒绝，明确“运营方”或“控制方”身份本身不授权改动无关的问责、委托或许可记录。

新版还要求未来声称符合协议的实现注明承担的角色，并把新增要求对应到正常与敌对测试用例。这只是拟议的合格性路径，不能冒充已有独立实现或通过的测试。真正的切口，是草案尝试让“授权有效”变成有政策、有来源、有时间窗口的结论，而非一张登记卡永久携带的属性。

资料来源