本章说明符合性配置文件如何把每项要求落实为“测试对象、输入、步骤、判据、证据和结论”，不把未经测试的能力宣称标为合格。当前可直接复用的离线材料是 oan-third-party-node-admission-test-kit/fixtures/v1-alpha，其中 manifest、case matrix、expected fixtures 和 requirement checks 形成可审计基线；真实根平台、内容分发平台、链上治理和生产恢复应单独标明。

profile 的适用范围应在报告开头明确写出，例如“资源提供方—资源包生成”“注册服务节点—注册接口”“发现服务节点—查询和索引”。同一测试资源可以贯穿多个 profile，但每个角色只对自己产生或验证的事实负责；测试资源在注册、发布、分发和发现阶段的状态应通过 DID、版本、摘要和请求标识关联，而不能只凭名称关联。

23.1 资源提供方符合性配置文件

资源提供方应能生成或导入本地身份，创建资源 DID，形成合法 DID 文档、资源元数据和资源包，并用本地控制密钥签名。验收测试覆盖四类资源的必填字段、能力标签、用例、端点、版本和摘要；合格证据是可验证的签名材料、结构化输入和错误输入的拒绝结果，私钥不得出现在上传请求或日志中。

验收顺序应固定为“身份可用 → DID 文档生成 → 元数据校验 → 资源包摘要和签名 → 提交材料检查”。任一步失败都不得继续把材料标记为可发布；测试记录应关联资源 DID、测试向量和规范版本。

资源提供方的通过条件不是“网页能够下载一个文件”，而是能够在本地重建同一份材料并验证控制关系。测试人员至少应保存一份合法材料、一份缺少必填字段的材料和一份签名或摘要被修改的材料，分别核对生成结果、明确错误和无副作用结果。

23.2 注册节点符合性配置文件

以隔离测试身份提交合法、缺字段、错误签名、越权节点、重复和过期材料，检查注册节点的状态码、错误结构、登记记录、幂等结果、VC（如有）和上游提交。合格条件是只受理授权范围内的有效请求，拒绝请求不改变有效资源状态，并能用日志和关联标识复核处理路径。

注册节点验收至少覆盖以下请求序列：

1. 提交合法材料，确认返回结构、登记状态和关联请求标识。
2. 重复提交同一 DID、版本和摘要，确认结果幂等，不产生第二个有效登记事实。
3. 替换控制签名、节点授权或资源摘要，确认请求被拒绝且原登记不变。
4. 提交过期或超出授权范围的材料，确认拒绝原因可区分。
5. 在上游暂时不可用时检查失败状态、重试边界和待处理记录。

每个请求都应保存发送端的规范化请求摘要和注册节点返回的关联标识；对于异步上游调用，还应把“注册服务节点已受理”和“根平台已处理”作为两条独立记录。成功响应中没有注册 VC 时，应记录字段缺失或未返回，而不能在验收材料中补造凭证。

23.3 根平台符合性配置文件

使用合法和篡改后的资源包、控制证明、注册节点授权、版本序列和摘要进行验证。根平台只有在控制关系、节点授权、内容完整性和治理条件均满足时才形成根平台可信发布证明；重复发布应幂等，拒绝和异步失败不得产生可被发现节点当作有效版本的发布事实。

根平台验收采用“验证输入、判断资格、形成发布事实、再次读取结果”四步检查：

• [ ] 控制签名能够绑定资源 DID、版本和待发布内容。
• [ ] 注册服务节点授权有效，且提交范围与授权范围一致。
• [ ] 资源包、DID 文档和摘要能够相互校验。
• [ ] 版本序列没有倒退、跳跃或无法解释的分叉。
• [ ] 根平台可信发布证明的签发者、主体、覆盖内容和状态可验证。
• [ ] 拒绝、重复和异步失败不会生成有效发布记录。

验收证据应同时保存首次处理结果和随后查询到的发布状态，用于区分“请求已接收”“验证已通过”“发布事实已形成”和“可被发现节点索引”这几个不同阶段。

根平台 profile 的关键判据是“拒绝输入不会形成可传播的有效发布事实”。因此，测试人员除检查接口响应外，还应重新读取发布记录、内容分发清单或发布序列，确认错误摘要、错误控制签名和越权注册服务节点没有进入后续队列；这类检查应使用独立的测试资源和请求标识。

23.4 内容分发服务符合性配置文件

向内容分发平台投递完整包、缺包、错误摘要、重复批次、断点游标和旧版本，检查清单、响应、接收游标、完整性和审计记录。合格条件是只交付根平台允许的材料，重复和断点不丢失或重复改变事实，接收方可以用摘要和证明核验内容。

测试结束时应用清单和摘要重新核对接收端内容，并记录投递批次、游标、响应时间、重试次数和最终状态。分发成功只表示内容可取得并可校验，不替代根平台发布证明。

断点和重复测试应在接收端重启或网络中断后再次执行，检查持久化游标是否仍指向最后一个已确认批次。若接收端已经保存内容但没有保存对应证明或游标，应将其视为未完成的分发状态，不能直接交给发现服务节点建立可信索引。

23.5 发现节点符合性配置文件

先执行全量和增量同步，再用已发布测试资源执行 DID、结构化和语义查询，并加入重复材料、旧版本、撤销状态、序列缺口和过期数据。合格条件是验证后索引、同 DID 默认选择最新有效版本、结果不重复、返回来源和新鲜度，相关性不覆盖控制或治理检查。

发现服务节点测试顺序如下：

1. 检查全量同步后的资源数量、版本和摘要。
2. 注入一个增量发布，确认仅新增或更新对应索引记录。
3. 分别执行 DID 精确查询、结构化条件查询和语义查询。
4. 加入重复材料、旧版本、撤销资源和过期快照，检查过滤与去重。
5. 核对结果中的来源节点、版本、新鲜度和发布证据引用。

同一 DID 的多条记录应按版本和发布状态进行确定性选择；无法确认新鲜度、治理状态或发布证据时，应标注不确定并交给调用方复核。

发现节点 profile 的查询验收应使用同一组已发布资源覆盖“精确命中、结构化命中、语义命中、重复记录、旧版本和不可见资源”六类结果。报告中应同时记录查询输入、过滤条件、返回的资源 DID、版本、来源、索引时间和重复数量，避免只记录返回总数。

23.6 信任索引器符合性配置文件

提供按序治理事件、断点、重复事件、缺失事件和暂时不可用的上游数据，检查授权状态读模型、事件游标、延迟和错误状态。合格条件是顺序和幂等性正确，重启后可从游标恢复，不能把未读事件或人工展示当作链上事实；证据包括事件位置、游标和投影记录。

链下信任索引器的“状态已更新”必须能够回指治理事件或明确的上游证明；数据库中存在一条投影记录，不能单独作为治理事实。

当测试事件连续到达时，应分别检查事件顺序、重复事件和序列缺口；当 latest_sequence 暂时不增长时，应结合最近成功读取时间和错误状态判断是“没有新事件”还是“同步停滞”。只有游标、事件位置和授权状态读模型相互对应，才能把该次测试记为通过。

23.7 解析器与客户端符合性配置文件

使用合法 DID、未知 DID、方法不支持、结构无效、控制签名错误、状态异常、历史版本和证明缺失的输入，检查结果类型和停止行为。合格条件是错误可区分、无效材料不被静默接受、历史版本不冒充当前版本，且原始文档、摘要和错误信息可供复核。

验收还要检查错误路径不会把部分解析结果误标为可信资源，也不会因自动重试而绕过控制权、凭证状态或治理状态检查。

23.8 SDK 符合性配置文件

SDK 应覆盖本地身份、资源 DID、元数据、控制签名、注册、DID 精确发现、语义发现、VC 和发布证明验证。使用 oan-sdk-ts 的测试输入检查序列化、错误映射和跨环境端点配置；合格条件是 SDK 不上传私钥、不丢失版本和证据字段，并能让调用方区分登记成功与可发现。

SDK 验收清单：

• [ ] 新建和导入本地身份的结果可复核，私钥不进入网络请求。
• [ ] 生成资源 DID、DID 文档和签名时，字段与 Rust 协议类型一致。
• [ ] 注册成功、注册失败和“尚未可发现”能够映射为不同结果。
• [ ] DID 精确查询和语义查询保留来源、版本和新鲜度信息。
• [ ] VC、根平台可信发布证明和治理状态的验证结果不被合并为单一布尔值。
• [ ] 网络错误、服务端错误和格式错误能够被调用方区分。

跨环境测试应使用固定节点端点配置和测试向量，不能以某个线上地址或某次成功请求作为 SDK 永久兼容性的证明。 测试报告还应把 SDK 的单元测试、节点联调和官网实际请求分开记录，避免把本地对象测试结果误写成端到端互操作结果。验收结论至少应关联 SDK 提交、协议公共类型版本、测试向量、目标端点和响应摘要。

23.9 安全与密钥保管验收标准

测试主体、资源和节点密钥的生成、保存、备份、恢复、轮换及权限边界，检查签名、VC 和根平台可信发布证明的验签。合格条件是私钥只在控制方边界内使用，备份可恢复且受保护，错误密钥和越权签名被拒绝；证据应脱敏，不能提交私钥原文。 安全验收任务清单：

• [ ] 证明主体私钥、资源控制私钥和节点运行凭据的使用边界。
• [ ] 检查备份文件的生成、导入、权限和恢复结果，不把私钥写入日志或请求体。
• [ ] 使用错误公钥、错误签名和其他主体签名执行拒绝测试。
• [ ] 验证 VC 和根平台可信发布证明的签发者、主体、签名覆盖范围和状态。
• [ ] 检查异常、调试日志和证据包中的敏感字段是否已脱敏。

测试报告应明确“控制方能够签名”与“服务节点能够验证”是两个不同事实；后者不意味着节点取得前者的私钥。 安全验收应把客户端、注册服务节点、根平台、发现服务节点和证据存储分别作为观察边界，逐项记录私钥是否出现在请求体、日志、临时文件、错误堆栈或测试归档中。控制签名、注册 VC 和根平台可信发布证明应分别验证其签发者、主体、签名覆盖范围和状态。

23.10 互操作与兼容性验收标准

使用 Rust 协议类型、TypeScript SDK、官网 API、注册服务节点、发现服务节点及 A2A/MCP 映射的同一组向量，比较 DID 文档、资源包、摘要、签名、错误和版本结果。合格条件是跨语言规范化和字段语义一致，映射保留来源，不能因适配而削弱 OAN 的控制和治理验证。

跨语言对照必须使用同一版本、同一输入和同一规范化规则；只比较最终页面文本，不能证明协议互操作。 互操作结论还应区分“同一输入产生同一对象”“不同实现能够解析对象”和“跨节点端到端流程成功”三个层次，分别记录对应证据，不能只凭最终页面显示相同就判定互操作通过。

跨语言验收可以采用“同一夹具、三次核对”的方式：先比较 Rust 协议类型和 TypeScript 对象的规范化结果，再比较 SDK 或官网发出的 HTTP 请求与节点实际解析结果，最后比较注册、发布和发现链路中的资源 DID、版本和摘要。任一层出现差异，都应记录差异字段和适用版本，不能只把失败归因于网络问题。

23.11 性能与可用性验收标准

在明确并发量、资源规模、网络条件和统计窗口的测试环境中测量注册、发布、同步、查询和治理读取的成功率、延迟、积压、恢复时间和资源消耗。阈值应在 profile 或部署验收记录中事先定义；没有测量数据时只能标为未测，不得把一次演示表现写成通用性能承诺。

报告至少区分冷启动、稳定运行、故障恢复三个窗口，并同时给出环境、数据规模、并发量和统计方法。

性能结果应注明是否包含网络往返、数据库写入、语义检索和异步传播等待；注册接口延迟不能直接当作资源全网可见延迟，查询命中率也不能直接当作语义质量。出现超时、重试或部分失败时，应同时报告请求数量、失败分类和恢复后的最终状态。 证据包的最小目录可以固定为：

evidence/
  manifest.json
  spec-and-profile/
  fixtures/
  requests-and-responses/
  logs-and-metrics/
  deployment/
  review-and-result/

manifest.json 应列出每份材料的摘要、来源、生成时间、测试环境和对应条款；目录结构只规定证据组织方式，不要求公开生产配置或敏感数据。

证据清单可以采用如下不含秘密的记录形式：

{
  "profile": "discovery-node",
  "profileVersion": "v1-alpha",
  "implementationCommit": "<git-commit>",
  "fixtureId": "valid-resource-v1",
  "environment": "isolated-test",
  "result": "PASS",
  "artifacts": [
    {"path": "requests-and-responses/query.json", "sha256": "<digest>"},
    {"path": "logs-and-metrics/discovery.log", "sha256": "<digest>"}
  ],
  "reviewedAt": "<timestamp>"
}

尖括号内容是证据清单模板中的占位值；正式报告应替换为真实提交、摘要和时间，但不能写入私钥、数据库凭据或未脱敏的内部端点。

23.12 符合性实现所需证据

审查材料至少包括规范和协议版本、代码提交、配置摘要、测试向量、接口请求响应、日志、指标、部署记录和失败处置。敏感内容使用摘要、脱敏片段或受控阅览方式提交；证据必须标明测试时间、环境、操作者、工具版本和覆盖条款。

23.12.1 协议和数据结构证据

提供 DID、DID 文档、资源元数据、资源包、VC、发布证明和 API 响应样例，标明 schema、规范化、版本和内容摘要，并说明合法、缺失和非法样例的预期结果。每个数据样例至少标注 fixtureId、对象类型、schema/profile 版本、规范化方式、内容摘要、预期结论和覆盖条款；合法样例与负向样例应成对保存。

协议证据还应覆盖 HTTP 方法和路径、请求 JSON 的反序列化类型、响应类型或动态字段、错误状态和关键校验结果。对注册、根平台验证发布、内容分发和发现查询，至少分别保存一份合法请求、一份关键失败请求及其响应；共享类型应能追溯到 oan-protocol-common，节点本地类型和动态 JSON 应能追溯到对应 handler。仅保存接口地址或一份成功截图，不能证明输入输出契约完整。

23.12.2 密码学和身份证据

提供公钥、签名、验证方法、控制关系、凭证签发者和验证结果，私钥只提供受控测试环境中的存在性或摘要证据。材料应能证明签名覆盖对象和目标 DID，而非只展示签名字符串。密码学证据应能够复算签名覆盖的规范化对象和用于验证的公钥来源，并分别记录控制签名、注册 VC、根平台可信发布证明的验证结果。

23.12.3 节点行为证据

提供注册、根平台发布、分发、发现、治理同步和错误处理的请求响应、事件、游标、日志及时间线，关联资源 DID、版本和请求标识。对异步流程还要记录“已接收、已验证、已发布、已索引”等阶段，不能只保留最后一次成功响应。

23.12.4 部署和烟测证据

提供源码提交、构建产物、配置摘要、服务健康、数据库状态、注册和发现烟测结果及失败处理记录。公开材料脱敏，生产密钥和内部管理端点不纳入证据。部署证据至少能把源码提交、构建产物、运行配置和烟测结果串联起来；烟测应包含一个成功路径和一个预期失败路径。

23.12.5 版本和来源证据

提供代码提交、锁文件、schema/协议版本、资源包和证明摘要、产物哈希及发布记录，使审查者能够确认测试对象与部署对象是同一来源。来源核对至少比较代码提交、依赖锁定文件、构建产物摘要和运行时版本标识；对象不一致时不得认定为同一测试结论。

23.13 测试向量与互操作夹具

测试夹具应固定合法 DID、DID 文档、资源元数据、资源包、哈希、控制签名、注册 VC、根平台可信发布证明、治理事件和错误输入，并提供 Rust、TypeScript 或 JSON 可读取形式。每个向量标注预期成功/失败、版本、摘要和覆盖条款，避免依赖实时公网数据。

推荐的固定夹具记录形态如下：

{
  "fixtureId": "valid-resource-v1",
  "input": "resource-package.json",
  "expected": "PASS",
  "schemaVersion": "<version>",
  "contentHash": "sha256:<value>",
  "covers": ["23.1", "23.3", "23.10"]
}

同一 fixtureId 在 Rust、TypeScript 和 HTTP 测试中应指向相同的原始输入；若适配层必须转换，应同时保存转换前后的摘要和转换规则。

23.14 负向测试与拒绝行为

负向测试覆盖非法 DID、字段缺失、错误签名、越权节点、过期或吊销凭证、旧版本、重复请求、错误摘要、恶意端点和序列缺口。验收不仅看返回错误，还要确认没有写入无效索引、生成错误发布证明、推进游标或泄露秘密等副作用。

每项负向测试都要同时检查响应、数据库或索引变化、事件游标、日志敏感信息和后续查询结果。

23.15 符合性证据留存与审查

证据按规范版本、代码提交、环境、时间、操作者和测试夹具归档，变更影响协议、schema、签名、治理、节点行为或部署路径时必须重测相关 profile。审查结论应注明通过、失败、未测和条件通过，不用单一总分掩盖关键失败。

审查结论还应区分“节点 profile 合格”“端到端链路合格”和“生产部署合格”，避免一个局部测试结果被扩大解释为整个网络符合性。

参考来源