specification.website ARD采纳实录为什么我们放弃了签名同源trustManifest签名的信任陷阱ai-catalog.json全解析【免费下载链接】specification.websiteWebsite specification — HTML, accessibility, security, SEO, agent-readiness. Platform-agnostic, sourced, MIT.项目地址: https://gitcode.com/gh_mirrors/sp/specification.website这篇文章完整复盘 specification.website 采纳 ARDAgentic Resource Discovery的全流程我们如何在/.well-known/ai-catalog.json发布 AI Catalog为trustManifest加上 ES256 签名又在 42 天后亲手撕掉签名——因为同源的 JWK 让信任验证变成了自己证明自己。适合想了解 AI Agent 发现机制agent-readiness的 Web 开发者。ARD 是什么一次请求发现整个站点的能力ARD 是 Linux Foundation 与 Google 于 2026 年 6 月发布的发现层草案v0.9Apache 2.0。它的定位很克制不是运行时而是一个目录catalogue。核心机制一句话站点在/.well-known/ai-catalog.json发布一份 JSON 清单用entries[]列出自己提供的所有 Agent 能力MCP 服务器、A2A 智能体、Agent Skill、知识库包等每条带 URN 标识符、媒体类型和真实地址。Agent 只需一次抓取就能回答这里有什么、去哪用、能不能信三个问题。我们的采纳格外顺手ARD 条目引用的两类工件——MCP 服务器卡片和 A2A 智能体卡片——网站上早已存在。采纳 ARD 本质上只是给已有能力建索引而不是造新东西。ai-catalog.json 全解析4 个条目一份契约以下是线上实际发布结构位于public/.well-known/ai-catalog.json块字段作用hostdisplayName/identifier/documentationUrl站点身份标识identifier 域名entries[]identifierURN 形式发布方段必须与 host 域名一致entries[]url指向真实工件不复制内容单一事实源entries[]mediaTypetype同一值写两个字段名原因见下entries[]representativeQueries2–5 句自然语言问句帮注册表做意图匹配我们列了 4 个条目MCP 服务器→application/mcp-server-cardjsonA2A 智能体→application/a2a-agent-cardjsonAgent Skill→text/markdown如实标注不谎报 zip 类型OKF 知识包→application/okf-bundlegzip临时未注册类型已在上游提案一个真实踩坑基础规范AI Catalog和上层 ARD 规范对同一个字段起了两个名字——一个叫mediaType一个叫type。两份规范都要求消费者保留未知键所以我们的做法是双字段同值输出在任一份规范下都能通过校验。早期采纳的常态同时实现两份还在磨合的标准并让它们礼貌地共存。四条发现通道让 Agent 不用猜路径仅发布文件不够还要广播。我们同时启用了全部四条机制HTTPLink响应头/.well-known/ai-catalog.json; relai-catalog; typeapplication/ai-catalogjson见public/_headersHTMLlink relai-catalog全局注入head见src/components/HeadMeta.astrorobots.txt的Agentmap:指令与Sitemap:对称指向目录文件DNS_catalog._agents记录与 DNS-AID 共用_agents命名空间四重保险不是过度设计——每条通道覆盖不同的客户端能力缺失任何一条都不应阻断发现。第一步的签名我们做对了一半起初我们为host.trustManifest实现了完整的密码学层算法ES256P-256kid用 RFC 7638 JWK 指纹流程移除signature字段 → RFC 8785 JCS 规范化 → 生成分离式 JWSpayload 不入紧凑形式私钥不出本地离线签名公钥以 JWK Set 形式发布在/.well-known/jwks.jsonCI 零密钥暴露诚实边界跳过attestations/provenance——没有真实第三方背书就不造假上密码学不上表演签名只覆盖trustManifest不覆盖entries。这带来一个当时觉得是优点的分离改目录条目不用重签。信任陷阱同源签名如何自我瓦解2026 年 7 月 31 日我们把签名删了。完整推理见src/content/changelog/2026-07-31-ard-catalog-unsigned.md。核心论证只有三句话第一文档和公钥同命相连。验证用的 JWK Set 就放在与目录同源的/.well-known/jwks.json。任何能篡改ai-catalog.json的攻击者在同一个操作里就能换掉jwks.json的公钥——签名对它本要检测的那种入侵完全折叠失效。密钥签名指向密钥形成循环信任。第二签名保护的是没人攻击的字段。JWS 只覆盖trustManifest的 3 个静态字段而攻击者真正会改的是entries里每条的url。把某个条目的url改写为恶意 MCP 端点签名依然有效——值得保护的字段恰好都没被保护。第三HTTPS 已经提供了等价保证。对一份静态 JSONTLS 本身已证明字节确实来自该域名。签名唯一增值的场景是公钥可独立于被签文档解析——DNSSEC 签名记录、验证方带外固定的公钥、或攻击者触及不到的基础设施。没有其中任何一个裸 JSON HTTPS 就是正确答案。给早期采纳者的清单把这次加上又拆掉的往返压缩成 5 条经验签名前先问公钥能否脱离目录被独立验证不能就别签签名覆盖范围要和威胁模型对齐——签了没用的字段、漏了要害字段等于没签只列真实存在的端点——目录是契约不是愿望清单字段名分歧时用双写兜底等标准收敛后再删冗余发现层是目录不是运行时——ARD 的价值在索引已有能力别为采纳而造能力 完整复盘含 OKF 捆绑包、上游 issue 等细节沉淀在仓库ops/notes/ard-adoption.md规范页在src/content/spec/agent-readiness/agentic-resource-discovery.md签名拆除决策见src/content/changelog/2026-07-31-ard-catalog-unsigned.md。一句话总结在规范未定时发布我们为什么放弃签名的说明比一枚能验证但不证明任何事的签名更有价值。【免费下载链接】specification.websiteWebsite specification — HTML, accessibility, security, SEO, agent-readiness. Platform-agnostic, sourced, MIT.项目地址: https://gitcode.com/gh_mirrors/sp/specification.website创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考