NPS

English Version 中文版

RFC 编号：NPS-RFC-0003 标题：Agent 身份三级保证等级（反爬 / 信任分流） 状态：Active（Phase 1–2 已在六 SDK 落地） 作者：Ori Lynn iamzerolin@gmail.com（LabAcacia） Shepherd：Ori Lynn（1.0 之前快速通道，见 spec/cr/README.cn.md） 创建日期：2026-04-21 最后更新：2026-09-05 接受日期：2026-04-25（1.0 之前快速通道；见 spec/cr/README.cn.md） 激活日期：2026-04-25（.NET 参考类型/verifier；六 SDK Phase 1–2 parity 已成为当前状态） 取代：无 被取代于：无 影响的规范：NPS-3 NIP、NPS-2 NWP、spec/services/NPS-AaaS-Profile.md、spec/error-codes.md、spec/status-codes.md 影响的 SDK：.NET、Python、TypeScript、Java、Rust、Go —

NPS-RFC-0003：Agent 身份三级保证等级（反爬 / 信任分流）

1. 摘要

为 Agent 身份引入三个 保证等级——anonymous（L0）、attested （L1）、verified（L2），Node 可以在 NWM 里声明 min_assurance_level。 等级随 IdentFrame 传输，并作为 X.509 critical 扩展承载（见 NPS-RFC-0002 §4.1）。本 RFC 是 NPS 对 “我怎么知道来的请求是 Agent 不是爬虫” 的回答——协议不直接拦爬虫，但给 Node 一个原语： 要求可验证的 Agent 来源，然后可以按等级 计费 / 限速 / 拒绝。

2. 动机

本 RFC 回应 2026-04-20 的评审意见：

最核心的，如果我要接这套协议，最关心的反而是怎么做反爬？我怎么 知道来个请求不是爬虫而是 Agent 访问？

评论是对的：NPS 今天回答了 “这个 Agent 是谁”（NIP），但没回答 “这个 Agent 的身份有多可信”。NID 只是一个公钥——任何人，包括 爬虫农场，都可以生成一个 NID 并用它签请求。没有信任等级这个原语， Node 要么收所有匿名流量（对爬虫友好），要么手工维护白名单（运维 负担）。

X.509 世界用 EV / OV / DV + CA/B Forum baseline 解决了同类问题； 身份验真世界用 NIST SP 800-63 的 IAL1/2/3 解决了同类问题。我们 借用等级形状，不照搬人类身份的具体流程。

这带来的商业模型空间：AaaS 运营商可以把 L2 认证流量定价高于 L0；审计方可以要求受监管集成强制 L2；被爬虫困扰的站点可以在 热点 endpoint 上设 min_assurance_level: attested，同时不误伤 把 NID 升级过的合法 Agent。

3. 非目标

4. 详细设计

4.1 保证等级

等级 枚举 最低标准 典型用途
anonymous 0 自签名 NID；或 CA 签名但不绑身份 业余 Agent、开发/测试、”给我一个免费报价” 只读 endpoint
attested 1 被合规（RFC-0002）CA 签发的 NID；CA 已通过 ACME agent-01 证明私钥持有；CA 验证过联系邮箱 / 域名 大多数生产 Agent；限速分层默认
verified 2 L1 标准 + CA 核实了运营者法律身份：组织 NID 要公司注册，托管 Agent 要已知 AaaS 运营商的签字声明 受监管集成（金融、医疗）、付费高级档、高信任编排

“attested” 对 Node 真正的意义：CA 证明了有人既控制 NID 私钥 又可以通过带外通道（ACME 账号邮箱、域名等）联系到——Agent 跑飞 时 CA 至少能邮件提醒运营者，最多直接吊销证书。L0 两个都给不了。

“verified” 再往上加的：CA 把 NID 和法律实体绑定。Node 可以 开发票、可以起诉、可以做合同级别的主张。

4.2 Wire 格式 / 帧变更

IdentFrame 新增一个字段：

字段 类型 必填 描述
assurance_level enum { anonymous, attested, verified } 是 当 NID 证书携带 id-nid-assurance-level 扩展（NPS-RFC-0002 §4.1）时，本字段 MUST 与之保持一致。Phase gate：Phase 1–2（当前）强制可选（SHOULD 检查并记录不匹配，MAY 强制执行）；Phase 3 flag day（见 §8.1）起强制变为 MUST，违规返回 NIP-ASSURANCE-MISMATCH。

证书是事实源；IdentFrame.assurance_level 是给不想解析证书就路由请求的服务端的冗余便利。

Phase 1–2（当前）：Verifier SHOULD 校验证书扩展并记录不匹配，但 MAY 跳过强制执行。选择执行的实现 MUST 以 NIP-ASSURANCE-MISMATCH 关闭连接。

Phase 3（flag day，见 §8.1）：Verifier MUST 校验证书扩展，若两者不一致 MUST 以 NIP-ASSURANCE-MISMATCH 关闭连接。这是完成升级的硬性截止点。

X.509 扩展升级（Phase 3 — 尚未生效）：NPS-RFC-0002 定义 id-nid-assurance-level（1.3.6.1.4.1.<PEN>.2.1）为非 critical。从 Phase 3 flag day 起，本 RFC 将其升级为 critical——旧 verifier MUST 拒绝带 critical 扩展的证书直到升级。这是故意的：一个启用了 min_assurance_level 的 Node MUST NOT 静默接收一个解析不了该扩展的 verifier。该升级在 Phase 1–2 尚未生效。

4.3 Manifest / NWM 变更

NWM 新增一个顶层可选字段：

# /.nwm 片段
min_assurance_level: attested   # 默认：anonymous
auth:
  required_scopes: [...]
  min_assurance_level: verified  # per-action 覆盖（可选）

4.4 错误码

spec/error-codes.md 新增：

错误码 NPS 状态 说明
NIP-ASSURANCE-MISMATCH NPS-CLIENT-BAD-FRAME IdentFrame.assurance_level 与证书扩展不一致
NWP-AUTH-ASSURANCE-TOO-LOW NPS-AUTH-FORBIDDEN 请求的保证等级 < Node 的 min_assurance_level
NIP-ASSURANCE-UNKNOWN NPS-CLIENT-BAD-FRAME 证书扩展里的值超出已定义枚举

4.5 状态机 / 流程

拒绝路径（Node 启用 min_assurance_level: attested）：

Agent (L0)                         Node
   │                                 │
   │── HelloFrame ─────────────────→ │
   │── IdentFrame (assurance=0) ───→ │
   │                                 │  check: 0 < 1 (attested)
   │ ←── ErrorFrame ──────────────── │  code: NWP-AUTH-ASSURANCE-TOO-LOW
   │     hint: "https://ca.../acme"  │  status: NPS-AUTH-FORBIDDEN
   │ ←── close                       │

升级路径是带外的：Agent 去合规（RFC-0002）CA 重新注册，拿到带 id-nid-assurance-level=attested 扩展的新证书，重试连接。

4.6 向后兼容性

5. 备选方案

5.1 二分 “认证 / 不认证”（两级）

砍掉 attested；只保留 unverified / verified。

5.2 仅用声誉（跳过等级）

不要等级，直接让 Node 依赖 NPS-RFC-0004 声誉日志。

5.3 自由形式 CA 策略 OID

让 CA 按 X.509 certificatePolicies 自定义 OID，Node 在 NWM 里 枚举接受哪些 OID。

5.4 不动

6. 缺陷与风险

7. 安全性考量

8. 实施计划

8.1 阶段划分

阶段 范围 出口条件
1 .NET NIP 解析证书扩展；IdentFrame 带字段；NWM 解析 min_assurance_level；强制可选 单测绿；默认行为不变
2 6 SDK + 6 CA Server 全部支持；CA Server 通过 ACME 签 L1 证书；每家 CA 的 L2 签发流程出文档 跨 SDK interop：L0/L1/L2 矩阵绿
3 NWM 里设了 min_assurance_level 时默认启用强制；id-nid-assurance-level 扩展升级为 critical。Flag day：提前 ≥ 21 日历天在 NPS-Dev GitHub Discussions 公告；激活后，NIP-ASSURANCE-MISMATCH 强制为 MUST，不合规实现 MUST NOT 声称任何 NPS 合规级别 无回归；全 6 SDK 通过不匹配强制测试
4 启用了更严默认的 Node 移除 L0 默认 fast path N/A——运营方决定

8.2 SDK 覆盖矩阵

SDK 负责人 状态 备注
.NET NPS SDK maintainers 已实现 — Phase 1–2 类型、CA 签发、verifier 与 opt-in enforcement 测试
Python NPS SDK maintainers 已实现 — Phase 1–2 类型、CA 签发、verifier 与 opt-in enforcement 测试
TypeScript NPS SDK maintainers 已实现 — Phase 1–2 类型、CA 签发、verifier 与 opt-in enforcement 测试
Java NPS SDK maintainers 已实现 — Phase 1–2 类型、CA 签发、verifier 与 opt-in enforcement 测试
Rust NPS SDK maintainers 已实现 — Phase 1–2 类型、CA 签发、verifier 与 opt-in enforcement 测试
Go NPS SDK maintainers 已实现 — Phase 1–2 类型、CA 签发、verifier 与 opt-in enforcement 测试

Phase 3 仍明确未激活：alpha.19 不执行 critical-extension/default-enforcement flag day，也不移除 L0-default 兼容路径。

8.3 测试计划

  1. L0 Agent 对 min_assurance_level: attested 的 Node → NWP-AUTH-ASSURANCE-TOO-LOW 拒绝。
  2. L2 Agent 对 min_assurance_level: anonymous 的 Node → 接受。
  3. 等级不一致（IdentFrame 说 L2，证书扩展说 L0）→ NIP-ASSURANCE-MISMATCH。
  4. Per-action 覆盖：全局 L1、orders.create 要 L2 → L1 Agent 的 /invoke:orders.create 被拒，其他 action 通过。
  5. 证书无扩展对启用强制的 Node（Phase 3 后）→ 视为 L0， 等级 > 0 时拒绝。
  6. 证书里枚举值未知 → NIP-ASSURANCE-UNKNOWN。

8.4 基准

9. 实测数据

暂无。在 Accepted 前提交：

指标 基线 提议 差值 方法
NWM 体积 无此字段 +~40 B +~40 B JSON 字节数
每请求开销 未启用 ~1 µs +1 µs BenchmarkDotNet

10. 已决问题

11. 未来工作

12. 参考

附录 A. 修订记录

日期 作者 变更
2026-04-21 Ori Lynn 初稿
2026-04-25 Ori Lynn 走 1.0 之前快速通道 Accept。已落地 spec：NPS-3 §5.1.1 保证等级 + IdentFrame assurance_level 字段、NPS-2 NWM min_assurance_level 字段、错误码 NIP-ASSURANCE-MISMATCH / NIP-ASSURANCE-UNKNOWN / NWP-AUTH-ASSURANCE-TOO-LOW。Phase 1 .NET 参考类型（NPS.NIP.AssuranceLevel 枚举、IdentFrame.AssuranceLevel、NipVerifyContext.MinAssuranceLevel、NeuralWebManifest.MinAssuranceLevel、相关错误/状态码常量）同时落地；verifier 主动强制保留为 opt-in（按 RFC §8.1：Phase 1 仅 parse，默认行为不变）。Phase 2（其余 5 SDK + 6 个 CA Server 通过 ACME 颁发 L1 证书 —— 依赖 RFC-0002）推迟到 v1.0-alpha.4。X.509 critical extension 翻转（§4.2）需与 RFC-0002 协调，尚未生效。AaaS-Profile §10 OQ-3（Gateway 强制 vs 后端节点强制）随 CR-0001 后续处理。
2026-09-05 NPS maintainers 状态对账为 Active 并记录六 SDK Phase 1–2 coverage；解决 OQ-1..03。Phase 3 critical-extension/default-enforcement 激活仍明确属于未来。
This site is open source. Improve this page.