摘要

  • /.well-known/knowledge-linkset 可以让来源站点公布带类型的知识制品地图，但受保护的目标并不意味着其名称、存在性、更新频率和摘要值适合公开。
  • 发现、字节校验、发布者身份、内容可信度与代理行动授权必须分别决策；看见一个链接，不等于有权读取，更不等于有权照做。

外部访问者没有拿到受限报告。服务器正确返回了认证要求，正文一字未泄露。可公开的发现清单却告诉他：该报告存在，属于哪一种关系，最近何时更换过摘要值，并且与一个尚未发布的“当前状态”节点相连。访问控制守住了门，门牌、房间数量和换锁时间却全部写在大厅里。

这正是 The 'knowledge-linkset' Well-Known URI for Publishing Knowledge Artefacts 值得认真讨论的原因。Paul Besleaga 在 2026 年 9 月 30 日提交的 00 版个人草案，建议来源站点在 /.well-known/knowledge-linkset 提供 JSON 发现文档，用带类型的链接指向上下文、图谱、本体、技能、界面、账本、当前状态、协作入口和对等节点等知识制品。它试图把原本分散在私有约定里的入口变成机器可发现的公共机制。

这是一项早期提案，而不是已经获得 IETF 共识的标准。草案目前属于活跃的个人提交，目标状态为 Informational，没有工作组、负责 AD 或正式的 IETF 流程地位；knowledge-linkset well-known 名称仍是临时申请，配置文件 URI 另有注册路径。明确这些状态不是贬低方案，而是避免把 IETF 托管页面误读成对每个实现或每份被发现内容的背书。

公开入口不等于公开库存

RFC 8615 让客户端能够在一个来源下预测 well-known URI 的位置。RFC 8288 和 RFC 9264 提供链接关系与 linkset 的表达方式。对运维者而言，这种组合很有吸引力：客户端不必猜测目录，不必依赖搜索引擎，也不必为每个站点编写适配器。

但“可发现”从来不是一个单一状态。至少应区分四层：清单是否可见，目标的存在性是否可披露，目标内容是否可读取，以及读取者是否有权据此行动。一个组织可以允许匿名用户知道文档入口，却要求认证后读取；也可以认为连文档存在性都属于内部信息。发现协议必须容纳这两种政策。

公开清单的泄露面不限于标题。关系类型可以暴露组织如何分类工作；媒体类型可以透露内部工具链；稳定 URL 可以暴露产品代号；更新频率可以显示事件节奏；同一摘要值可以让观察者判断两个站点是否持有相同材料。若攻击者已猜到某个文档内容，公开摘要还可能成为存在性探针。即使目标始终返回 401，这些元数据也可能有商业和安全价值。

因此，合格实现需要“视图”概念。匿名访问得到经过削减的公共视图，认证主体依据权限得到更完整的视图，某些关系和摘要值永不对外公布。服务器还应明确视图可能不完整，避免客户端把未出现的节点解释为不存在。不同视图可以共享一个逻辑来源，却不能假装所有访问者看见同一张全景图。

摘要值只约束字节

草案允许为目标附加摘要。RFC 9530 与 RFC 9651 提供现代 HTTP 内容摘要语义；某些配置文件也可以借助 RFC 8785 规定 JSON 规范化。摘要匹配有重要价值：客户端可以确认取回的表示与清单中声明的字节值一致。

它回答不了更大的问题。摘要不证明材料真实、完整、合法、安全或仍然适用，也不证明某个人是作者。若攻击者同时控制清单与目标，他可以替换二者并发布新的匹配摘要。HTTPS 与 DNS帮助确认实际响应的来源，但来源控制不等于编辑身份。共享托管、账号接管、供应商迁移和内部权限滥用都会让两者分离。

实现还必须精确定义摘要覆盖什么：传输编码前后的字节、解压后的实体，还是规范化对象。内容协商和中间转换会让“同一文档”出现不同表示。没有摘要应标为“未由该机制校验”，不能直接标为恶意；摘要不匹配应拒绝该表示并调查，却不能仅凭差异判定责任人。

HTTP Message Signatures（RFC 9421）能够让密钥持有者对选定组件签名，从而加强归属证据。但签名仍需外部信任规则：谁控制密钥，密钥在哪段时间有效，签名者被授权发布哪类制品，以及该身份是否有权要求某种操作。密码学身份不会自动生成业务授权。

被发现的文本仍是不可信输入

链接关系为客户端提供分类，不为目标正文赋予指令权限。名为 skills、contribute 或 now 的关系可能帮助选择材料，但正文里的命令、密钥索取、越权要求和“忽略先前规则”仍属于外部数据。代理可以索引、摘要或比较这些内容，不能因为入口位于 well-known URI 下就把它们放进系统指令层。

工程上应保留一条结构化证据链：初始 URL、最终 URL、重定向路径、实际连接地址、关系类型、媒体类型、清单版本、获取时间、摘要结果、发布者信任判断和所请求的能力。执行服务接收的是一项明确的能力申请，而不是把系统政策、操作者要求与外部文章揉成同一种文本。

发现器本身也是网络客户端。对等关系和重定向可以把它引向回环、私网、链路本地地址或云元数据服务。DNS rebinding 可能在检查后、连接前改变解析结果。实现应限制协议，先规范化 URL，通过受控解析器获得地址，阻止未获授权的内部地址范围，并在每次重定向与实际连接时重新核验。只检查原始字符串不足以建立边界。

对等遍历还应设置深度、节点数、字节、时长、并发和单来源请求上限，并检测环路。预算用尽后的结果是“在本次有限遍历中未找到”，不是“世界上不存在”。公开视图的缺失、权限不足的缺失和遍历预算造成的缺失，更不能合并成一个布尔值。

时间不会替信任作决定

RFC 9111 的缓存与 ETag 等验证器可以减少重复传输。304 Not Modified 表示服务器认为所选表示相对于验证器未变化，并不重新证明作者或授权。敏感决策应保存当时使用的发现文档、缓存年龄、验证器和政策版本。否则，目标文件可能还在缓存中，而指向它的关系早已被删除。

草案中的 tombstone 与 successor 关系可以表达节点结束和后继位置，却不能把身份、托管责任、许可证或信任自动转移给后继者。客户端应保留旧节点的终止状态，把后继链接记录为一项声明，然后对新节点重新发现与评估。便利的重定向不应抹掉主体变化。

账本或当前状态指针也只能提供时间证据。记住旧的账本头，有助于发现回滚或替换；出现两条历史时，账本本身无法决定哪条应被信任。还需要命名权威、独立存档、法定流程或其他治理规则。

回到开头的受限报告：真正的问题不是服务器为何没有公开正文，而是团队是否曾对发现元数据做过数据分类。一个安全方案不会简单地把所有链接删掉，也不会假装公共清单完整。它会根据主体发布恰当视图，省略高风险摘要和关系，把“不可见”保留为有意义的政策结果。

knowledge-linkset 的价值在于降低知识入口的摩擦。它若想成为可靠基础设施，就必须让限制与能力一样清晰：来源能够声明一张地图，摘要能够绑定一组字节，客户端能够在预算内遍历；没有任何一步单独证明作者、真相、许可或行动权。门后内容没有公开时，门外的元数据也应经过同等级的判断。

Sources