@agentunion/fastaun-browser 0.5.20 → 0.5.21

package/_packed_docs/agent.md/working/AID/347/261/273/345/236/213-owner/345/205/263/347/263/273/345/256/214/346/225/264/350/256/276/350/256/241/344/270/216/345/256/236/346/226/275/350/256/241/345/210/222.md

@@ -0,0 +1,685 @@
+# AID 类型、owner 关系与 agent.md 签发/换 owner 完整设计与实施计划
+
+本文为历史 working 草案；现行字段与验证规则以 [Ownership 协议定义 2.1](../../protocol/Ownership协议定义2.1.md) 为准。当前 Group/Org 创建自动绑定、解散自动解绑、专属转移强制 rekey；名片 owner 必填，必须省略 ownership、ownership_proof、ownership_release，仅 owner 本人尾签并以 V2 授权代上传。本草案的统一 proof/注册/转移流程不得套用于此实体分支。
+
+> 状态：working 设计；Phase 0 策略已确认，正式 wire/RPC/schema/golden-vector 契约仍需落稿冻结。
+>
+> 日期：2026-10-02
+>
+> 关联讨论：[Schema 与签发/验签流程澄清记录](agent.md-schema与签发验签流程澄清.md)、[AID 类型、owner 关系与换 owner 编排方案](AID类型-owner关系与换owner编排方案.md)
+
+## 1. 目标与范围
+
+本设计把 AID 的 `type`、`owner`、所有权证明、agent.md 发布、owner 变更，以及 owner-side 备份空间纳入一个可验证、可恢复的端到端流程。应用把创建参数交给 SDK，由 SDK 编排；服务端负责权威校验和状态提交，不能把 SDK 的验签结果当作信任依据。
+
+本轮只产出设计与实施计划，不修改 SDK、服务端或正式协议。实施前仍需把已确认策略落成正式 wire schema、RPC/错误码/事件封套和跨端 golden vectors；本版不再另行设计旧 owner 不可用时的恢复流程。
+
+## 2. 讨论结论与推荐基线
+
+### 2.1 已明确的约束
+
+- AID 有八种预设 `type`：`human`、`agent`、`group`、`service`、`device`、`host`、`org`、`custom`。当前 agent.md Schema 允许扩展类型；新 SDK 注册必须传 type，除 `human` 外还必须传 owner；旧 `auth.create_aid` 不增加这两个必传参数；`human` 不得指定 owner。所有新建、返回、持久化、事件、proof 和 Storage 路径中的 AID 都使用现有创建规则校验后的 ASCII 小写规范值。
+- 新增的 `owner` 与 `ownership_proof` 在 Schema 中都保持可选，以兼容旧 agent.md；字段缺省表示没有可验证的 owner 关系，旧非 human 身份映射为 `legacy_unbound`。字段出现时必须满足完整格式及交叉一致性，不能接受只有 owner 或只有 proof 的半成品。Schema 可选不代表新建非 human AID 可省略 owner。
+- owner 必须是有效 AID，其已发布 agent.md 必须有效且 `type` 为 `human` 或 `agent`。只检查直接 owner，不递归检查 owner 的 owner。
+- `agent` 可将 owner 指向自身，表示自主运行；该关系不把自身 agent.md 再作为 owner profile 回源验证，但仍须验证 subject 证书、agent.md 和 self-owner 关系证明。self-owner 只保留一份 subject 签名，不重复保存 owner 签名。其他 type 不允许 self-owner。
+- `group` 的 subject 签名由 group identity 证书对应的 group 服务私钥产生；群主只负责现有群服务的上传授权，不能代替 group identity 签署 subject 内容。`org` 同样使用 CA 登记的 org identity 证书；群主/组织管理者关系必须与 Auth owner 台账对齐，群主或组织管理者转让同步进入 owner-change 流程。
+- 设置外部 owner 时，subject 与 owner 都要签署关系证明。subject 先签，owner 后签。owner 仅返回 detached 签名，不接收 subject 私钥，不修改 subject 的 agent.md。
+- owner 与证明都放在 agent.md frontmatter：顶层 `owner` 表示当前关系指针；`ownership_proof` 是包含关系声明及所需签名的对象。普通名片字段变化不改变 owner proof，只需 subject 重新签署整个 agent.md 文件。
+- subject 与 owner 私钥必须由各自主体分开控制；owner 私钥不得交给 subject SDK/agent。签名只能证明对应私钥签过，无法区分合法持有人与私钥被共享/窃取的情形。
+- 创建 AID 与换 owner 都是 SDK 编排流程；双方不必同时在线。owner 可以从服务端 pending inbox 获取请求，也可离线导入签名请求并导出签名回执。
+- owner 关系建立后，换 owner 必须由 Auth 当前 active owner 发起并签署转移授权；subject 不能自行发起有效改绑。所有关系写入都由 Auth 协调，Auth 台账是唯一权威状态。
+- `agent.md` 中的 owner 与 ownership proof 是公开可验证声明；大多数读取、展示和普通验签场景可直接信任验签通过的声明。只有创建、替换或撤销 owner 关系需要 Auth 验证并提交；不改变关系的名片内容更新不触发 owner 关系审批。
+- owner 的 AID Storage 下为每个 subject 保留一个协议定义的目录。关系撤销时撤销该关系 ACL 和访问凭据，但不删除目录及数据。
+- 2026-10-02 22:08 确认：旧 `auth.create_aid` 与新注册流程都签发正常可用证书，不因 owner 未绑定标记证书 pending。证书有效且 AID 未停用时，legacy 与注册中身份均保留基本登录和通信；仅依赖已验证 owner 关系的具体场景受限，不能全局拒绝服务。
+- 2026-10-02 23:16 确认：owner 关系是否用于某个具体业务场景由应用层决定；AUN/Auth 只报告可验证的关系状态，不因关系未绑定或不可用破坏基本登录、通信等能力。owner 证书/profile 失效时关系报告为不可用，不新增专门恢复流程。
+- 解绑后的关系状态为 `unbound`；基本登录和通信不受限，依赖 owner 的场景由应用层按状态决定是否降级。AID 状态变化沿用 agent.md 观察机制：上线拉取一次，在线时每次状态变化推送一次。
+- type 变更只有在该 AID 不是其它 AID 的未解绑 owner 时才允许；相关 owner 关系仍未解绑时拒绝 type 变更。Storage subject 根目录不可移动或删除，但目录内部对象允许按 ACL 删除、移动和重命名；公开 RPC 继续遵循现有 RPC 惯例。
+- Auth 写入关系前检查 owner 图，禁止非 self-edge 成环；“只验证直接 owner、不递归验证 owner 的 agent.md”只约束 profile 验证深度，不取消关系图成环检查。
+
+### 2.2 本设计采用的推荐基线
+
+| 项目 | 推荐基线 | 状态 |
+| --- | --- | --- |
+| 新建 `human` | 不设置 owner，不生成 ownership proof；显式 owner 拒绝 | 已确认 |
+| 新建非 `human` | 必须设置 owner；缺失即拒绝 | 与讨论一致 |
+| `agent.owner == agent.aid` | self-owner；只保留 subject 自签；不回源 owner agent.md | 已确认 |
+| 外部 owner | 仅允许有效 `human` 或 `agent` AID；owner proof 双签；group/org 的 subject 签名分别使用 group/org identity 证书 | 与讨论一致 |
+| 普通 agent.md 更新 | 保留 active proof；只重签完整文件 | 与讨论一致 |
+| owner/type 变化 | owner 使用专用关系编排；type 变更需检查该 AID 是否仍是其它 AID 的 owner，满足条件后使用现有 RPC 惯例提交 | 2026-10-02 确认 |
+| owner-side 目录 | `<owner_aid>:/.aun/subjects/<canonical_subject_aid>/`，每对 owner/subject 唯一 | 已确认 |
+| 撤销/换 owner | 立即失去 subject 访问权；保留旧目录数据；不自动跨 owner 复制 | 与讨论一致 |
+| owner 变更签署者 | 当前 owner 发起并签转移授权；subject 确认新关系；new owner 接受 | 本轮讨论已确认；由 Auth 强制执行 |
+
+## 3. 权威状态与服务边界
+
+关系状态必须只有一个权威来源，避免 agent.md、Auth 数据库和 Storage ACL 分别成为互相矛盾的关系真相。由 Auth 的持久化身份台账保存当前 `type`、`owner`、owner relation status、active proof 和 `relation_version`；证书状态由 CA 维护，AID lifecycle 由 Auth/身份台账维护；agent.md 是可公开读取的签名快照，Storage ACL 是关系权限的派生状态。每个 subject 只有一个 active owner，且最多有一个未完成的 owner-change operation。Auth 在关系绑定提交、解绑、type 变更和 agent.md 激活发布时都必须原子检查该 subject 是否已有未解除的 active 关系或 pending operation，以及它是否仍是其它 AID 的未解绑 owner。
+
+| 组件 | 责任 | 不负责 |
+| --- | --- | --- |
+| Auth | AID 生命周期、唯一 type/owner 台账、proof/operation 状态、签名复验、关系版本 CAS、owner-change 发起方校验、登录准入、协议冲突裁定与审计 | 不直接改写 subject agent.md，不替代 issuer 对密钥争议的治理政策 |
+| CA | 按 Auth 已验证流程签发/查询证书，维持证书链和撤销状态；维护 `aid_type/key_purpose` 映射 | 不成为 owner 关系的第二个数据源 |
+| Name Service | 解析及验签 agent.md、存储快照/ETag、支持受限注册发布；依赖 Auth 的台账和激活回执，Auth 不反向依赖 Name Service | 不允许普通 agent.md PUT 变更关系，也不要求普通内容验签实时访问 Auth |
+| Storage | 保护固定目录、执行由 Auth 验证关系操作生成的 owner/subject ACL、撤销访问并保留数据 | 不从客户端路径推断 owner 关系；普通数据访问不要求逐次调用 Auth |
+| Gateway | 路由 RPC、传递认证上下文 | 不实现 owner 规则或维护关系状态 |
+| Python / TS / JS / Go SDK | 创建、签署、转交审批、恢复、上传和换 owner 的客户端编排 | 不作为最终信任根，不代签远端 owner |
+
+Auth 在这里可类比为信任域内的登记机构。双方签署共同事实，Auth 作为见证者校验双方签名、证书、策略、operation 和版本，并在 proof ledger 中登记已验证证据；它不代替任何一方签署关系事实。Auth 应为登记结果签发可验证回执，绑定 proof、事实/完整声明摘要、双方 AID、relation version、状态和服务端登记时间。原始 canonical bytes、detached 签名、证书引用、operation 和回执可由 Auth 受保护托管，便于审计、撤销和状态查询；subject/owner 私钥永不上传或托管。
+
+登记不要求 Auth 在线参与双方交换。双方可离线完成签名，Auth 在最终提交时见证并原子登记。`ownership_proof` 仍随 agent.md 公开携带，支持不依赖 Auth 的事实与签名验证；Auth 回执/状态另外证明该 proof 已登记以及当前是否 `active`、`unbound`、`unusable`、`superseded` 或 `revoked`。Name Service、Storage 只消费 Auth 的已验证关系状态，不自行登记或改写 owner 台账。状态观察沿用现有 agent.md 变更观察机制：主体上线时拉取一次当前状态，主体在线且状态发生变化时推送一次。
+
+服务之间只通过已有服务 RPC / 约定的 JSON-RPC 边界交换状态，不增加共享代码依赖。具体的内部 RPC、公开 `auth.*` 方法和 Name Service 注册发布入口在协议冻结阶段确定。
+
+服务依赖方向固定为 `CA -> Auth -> Name Service`（Storage 消费 Auth 关系事件/ACL）。Auth 校验关系时不调用 Name Service；需要 owner profile 证据时由调用方提交已签名快照或由 Auth/CA 的懒注册资料验证。未在 Auth registry 注册的 AID 查询返回 `registered=false`、`owner_relation_status=unbound`（或 `legacy_unbound`），不作为服务故障；需要已验证 owner 的写入仍返回 `owner_not_verified`。
+
+## 4. agent.md Schema 与签名模型
+
+### 4.1 字段结构
+
+`type` 已存在于 Schema；新增的只有顶层 `owner` 与 `ownership_proof` 两个字段。两字段在 Schema 中均可选，以兼容旧文档；若出现，必须组成完整、合法且相互匹配的关系信息。签名封套属于 `ownership_proof` 对象的内部结构，不再增加平行的顶层签名字段。
+
+```yaml
+owner: "alice.agentid.pub"
+ownership_proof:
+  proof_id: "550e8400-e29b-41d4-a716-446655440000"
+  subject_aid: "sensor.agentid.pub"
+  owner_aid: "alice.agentid.pub"
+  subject_signature: { cert_fingerprint: "sha256:...", signature: "..." }
+  owner_signature: { cert_fingerprint: "sha256:...", signature: "..." }
+```
+
+上面的 proof 对象已按 P0-A03、P0-A04、P0-A07 确认：关系声明的最小业务字段为 `owner_aid`、`subject_aid`、`proof_id`，并保存 detached 签名封套；proof 外层不增加格式版本、nonce、时间或关系编排字段，封套只允许 `cert_fingerprint` 和 `signature`。proof ID 使用 Auth 生成的小写 UUID v4。proof 与签名封套合计必须适配现有 agent.md 的 4 KiB payload/2 KiB 尾部签名块限制；Schema 验证器应拒绝超限对象。`mode` 可由 `subject_aid == owner_aid` 推导，`subject_type` 由 agent.md 与 Auth registry 校验，`relation_version` 由 Auth 台账/响应提供，不放进公开 proof。self-owner 只保留 `subject_signature`，外部 owner 才要求 `owner_signature`。
+
+必须成立：`owner == ownership_proof.owner_aid`、`aid == subject_aid`；`type` 由 agent.md 与 Auth registry 交叉校验，不写入双方共同签署声明。公开验签可独立验证声明内字段和相应签名；创建、替换或撤销 owner 关系时，Auth 还要把 `proof_id`、`relation_version` 与当前权威关系逐项比较，`relation_version` 留在 Auth 台账/operation 元数据。完整 agent.md 由 subject 自己签名，`group`/`org` 文件主体例外使用对应 identity 证书。self/delegated 可由 subject 与 owner AID 是否相同推导；self-owner 只验 subject 签名。
+
+关系字段的组合规则：`owner` 与 `ownership_proof` 同时缺省时可读取为无 proof 的旧/未绑定文档；两者同时存在时必须通过格式、字段关联和签名验证；只出现其中一个视为无效。`human` AID 不得出现 `owner` 或 ownership proof。新建非 human AID 虽可通过 Schema 解析缺省字段的旧文档，但注册流程必须要求完整 owner 关系。
+
+### 4.2 双方签名的内容
+
+关系证明不签整个 agent.md。关系声明包含双方 AID 与同一 `proof_id`；subject 与 owner 分别独立签署自己的声明，self-owner 仅由 subject 签名。声明的角色、签署时间和按需扩展以当前 SCHEMA.md 为准，不再携带关系或声明摘要字段。
+
+```text
+"AUN-AID-OWNER-RELATION-V1;" + canonical_json({
+  "proof_id": "550e8400-e29b-41d4-a716-446655440000",
+  "subject_aid": "sensor.agentid.pub",
+  "owner_aid": "alice.agentid.pub"
+})
+```
+
+- subject 先签这组字节，并把原 statement 和签名交给 owner；owner 校验 subject 签名后，对完全相同的字节独立签名。双方签名值不同，但签名输入必须逐字节相同。
+- 双方签名封套仅携带各自的证书指纹和签名值；owner 不签 subject 签名的摘要，不需要不同的 approval payload 或 `subject_signature_hash`。
+- 传输包通过 `operation_id` 或 `proof_id` 关联原始声明及签名；当前 P2P 方案只使用 SDK 请求关联，不依赖服务端 ownership operation。
+- 双方封套不带各自填写的时间戳。operation 的开始/截止时间由服务端统一记录，签名必须在有效期内提交；服务端接收时间用于审计，不能伪称为实际签名时间。离线审批过期后重新 prepare 并重新签署。
+- 服务端按证书链验证签名者证书、签名用途与 AID 绑定；新写入签名必须是 `active_signing`，历史 proof 只读验签按指纹和签名时有效性验证；外部 owner 验证两份签名，self-owner 只验证 subject 签名。共同声明的最小业务字段、AID 规则复用、canonical JSON、可见分号域分隔符、哈希算法和 DER/Base64 签名载体已按 P0-A01 至 P0-A07 确认，并由四端共享测试向量覆盖。
+- 新生成的关系签名、agent.md 文件签名、E2EE 发送签名和其它写链路签名只允许 `active_signing` 证书。只读验签按签名中的证书指纹定位对应历史证书；只要签名时间位于该证书有效期内且签名当时证书有效，即使证书后来变为 `verify_only`、自然过期或被吊销，历史签名仍可验签通过，并另行报告当前证书状态。证书状态不满足写入要求时不得生成新凭证。
+- agent.md 尾部既有签名仍覆盖完整 YAML frontmatter 与 Markdown payload。普通内容更新复用 `ownership_proof`，但 subject 必须重签文件尾部签名；`group`/`org` 文件主体由对应 identity 证书重签。
+
+因此 owner 与 subject 认可的是同一关系事实，不是某一版名片文件。只要 owner、subject 和 proof 关系不变，展示字段变化不需要 owner 再签。
+
+## 5. AID 创建与审批流程
+
+### 5.1 状态机
+
+以下是注册 operation 的阶段，不是证书状态或 AID 登录状态：
+
+```text
+reserved -> proof_pending -> agent_md_pending -> active
+     |             |                 |
+     +-------------+-----------------+-> expired / cancelled
+```
+
+`proof_pending` 内部可报告 `awaiting_subject_signature` 或 `awaiting_owner_signature`，不把签名等待再扩展为独立生命周期状态。
+
+证书有效性、AID 生命周期、owner 关系和能力判定必须分开；下列名称描述设计分层，不表示本轮新增 agent.md 字段或冻结新的 RPC 字段：
+
+| 维度 | 状态/含义 | 准入影响 |
+| --- | --- | --- |
+| certificate_status | `active_signing`、`verify_only`、expired、revoked | 写入/新签名只接受 `active_signing`；只读历史验签按证书指纹和签名时有效性处理；owner 未绑定不产生 pending 证书 |
+| aid_lifecycle | active、disabled 等身份启停状态 | 按现有身份启停规则处理，与 owner operation 是否完成分离 |
+| owner_relation_status | legacy_unbound、pending、active、unbound、unusable 等关系状态；human 无 owner，不适用 | AUN/Auth 只报告可验证状态；具体业务是否要求 active owner 由应用层决定，不作为全局登录或通信门槛 |
+| capability_profile | basic、owner_verified，按具体操作及目标关系推导 | basic 保留现有非 owner 依赖能力；owner_verified 还须满足该关系的 registered 校验和既有权限 |
+
+旧 SDK 创建的未绑定身份为 `legacy_unbound`；新非 human 注册在绑定完成前为关系 `pending`。两者在证书已签发且有效、AID 未停用时都可以正常登录、获取基本 access token、连接 Gateway 和收发消息。新流程仍须提交合法 type/owner，基本能力不等于关系已登记，也不能用普通 agent.md 更新绕过 Auth 绑定。
+
+`basic` 不是仅保留两个 RPC 的白名单，也不因 owner 缺省统一撤销既有能力；原有证书、ACL 和业务权限检查照常执行。AUN/Auth 只返回 proof、relation status 和新鲜度，具体业务是否要求 `owner_verified` 由应用层决定。human 合法无 owner，不应因此被降级。关系绑定、审批提交和 operation 恢复入口必须能在关系未激活时使用。
+
+服务端持久化 operation ID、幂等键、有效期和最近成功阶段，SDK 可通过 operation status 恢复。首次绑定 operation 过期、取消或失败，不自动吊销证书、停用 AID 或断开基本会话；关系状态准确报告为未绑定或不可用，允许对同一 AID 用新 operation/proof 重试。换 owner 的 operation 尚未提交或失败时，原 active 关系继续有效。
+
+### 5.2 高层输入与准备
+
+建议高层 SDK 接受 `aid`、`type`、`owner?`、agent.md 初始内容和 `idempotency_key`。新入口缺少 `type` 时拒绝；不隐式猜测为 `agent`。human 不要求 owner；非 human 新建要求 owner；兼容入口只能显式产生 `legacy_unbound`。
+
+1. SDK 本地验证 AID/type/owner 组合，生成 subject 密钥并持久化；注册 operation 的 pending 状态与可用于认证的本地身份状态分开保存。
+2. SDK 调用服务端 prepare，提交 AID、公钥、type、owner 和幂等键。
+3. Auth 校验 AID 唯一性、type/owner 规则、owner 是否有效及其已验证 agent.md type、self-owner 规则和 operation 幂等性；返回服务端生成的 `operation_id`、`proof_id`、`relation_version`、过期时间和冻结的 canonical statement。
+4. Auth/CA 签发正常可用的 subject 证书，SDK 收到后即持久化并允许按现有规则登录和通信，不等待 proof 或 agent.md 激活。不增加 provisional/pending 证书状态，也不以 owner pending 拒绝基本 access token。Name Service 的关系注册快照仍使用绑定 AID + operation 的一次性发布凭据；该凭据与基本 access token 分离。
+
+### 5.3 关系证明与离线审批
+
+1. human 无 owner：不创建所有权证明，进入待 agent.md 发布状态；显式提供 owner 或 ownership proof 均拒绝。
+2. 自主 agent：subject 对最小关系 statement 签名；self/delegated 由 subject 与 owner AID 是否相同推导，不在 statement 中增加 mode；不读取自身 agent.md 作为 owner profile；self-owner 只保留一份 `subject_signature`。
+3. 外部 owner：subject 先签自己的 statement，并产生 detached 签名请求。请求包包含 proof、关系声明、subject 签名与 owner 目标，接收方验证原始声明及实际签名。
+4. owner SDK 校验请求的目标、期限、AID/type、statement 与 subject 签名后，对同一 statement 独立签名，生成 detached `owner_signature`。owner 可经 pending inbox 在线领取/提交，也可离线导入请求包、导出回执；subject SDK 导入回执后校验 operation、proof、statement hash 和 owner 签名。该步仅适用于 delegated 外部 owner。
+5. 服务端按关系模式重新验所需签名与证书，并保存不可变 proof 记录；外部 owner 关系须验证 subject/owner 两份独立签名，self-owner 只验证 subject 签名。服务端允许任一方转交 owner 回执，但不因收到回执就假定 owner 已在线。
+
+### 5.4 agent.md 发布与激活
+
+1. subject SDK 写入 `type`、`owner` 和完整 `ownership_proof`，由 subject 当前 `active_signing` 证书签署整份 agent.md；`group`/`org` 的文件主体签名分别改由对应的 group/org identity 证书完成，管理者只提供上传授权。
+2. SDK 使用绑定当前注册 operation 的一次性发布凭据向 Name Service 上传。该凭据自身只能发布指定 AID 的 agent.md，不能代替基本 access token；subject 仍可另外用正常证书和基本 access token 登录、通信。
+3. Name Service 验证 UTF-8/schema/大小、尾部文件签名、proof 所需签名及其与 Auth registry/operation 一致性（外部 owner 双签，self-owner 仅 subject 单签）；先幂等保存为待激活快照。
+4. Name Service 将内容摘要和持久化回执提交给 Auth；Auth 校验后原子登记关系并写入状态 outbox，Name Service 消费 Auth 的激活状态后才将对应快照对外可见。Auth 不同步调用或回调 Name Service。这里的 active 表示注册 operation 完成及关系生效，不是首次允许登录，也不改变证书状态。若调用中断，operation/outbox 必须幂等恢复；不能提前公开待激活关系快照或错误授予 owner 依赖能力，也不能阻断基本通信。
+5. SDK 收到 active 确认后标记本地注册/关系完成，保留先前已可认证的身份和证书，不重新签发或替换证书。崩溃或超时用 operation ID 查询结果，不重新生成另一把密钥或重复创建 AID。
+
+## 6. 换 owner 流程
+
+换 owner 不使用普通 `PUT /agent.md` 修改 `owner`，而是由 Auth 当前 active owner 发起专用 operation、建立新 proof，再由 Auth 以 relation version CAS 提交。subject 自己、new owner 或普通 agent.md 上传都不能单独发起有效换绑。
+
+1. 当前 owner SDK 调用 `owner_change_prepare(subject_aid, new_owner_aid, expected_relation_version, idempotency_key)`。Auth 校验调用主体等于台账中的 active owner；self-owner 时 subject 与 current owner 是同一 AID，允许该主体按当前 owner 身份发起；其它 subject 直接调用必须拒绝。
+2. Auth 对该 subject 创建唯一 pending operation，锁定当前 proof/version，并生成冻结的转移授权 challenge。challenge 绑定 subject AID、old owner AID、指定 new owner AID、当前 relation version、operation/proof nonce 和有效期。同一 subject 已有未完成 operation 时，重复幂等请求返回原 operation，其它请求返回 pending conflict。
+3. old owner 对 challenge 签署 detached `owner_transfer_authorization` 并提交 Auth。Auth 验证证书主体确为当前 owner、签名目标/版本/operation 与台账一致、授权未过期且 nonce 未消费。该转移授权和新关系 statement 是不同用途的签名材料。
+4. Auth 为新关系生成最小 canonical statement；subject 与 new owner 分别独立签署同一 statement。subject 确认接受新 owner，new owner 确认接受关系。双方不必同时在线，可经 Auth pending inbox 或离线文件交换。
+5. subject SDK 验证回执，更新 agent.md 的 `owner` 与 `ownership_proof`，再用 subject 密钥签署整份新文件。subject 的文件签名不能代替 old owner 的转移授权。
+6. Auth/Name Service 验证转移授权、新关系双签、文件签名和当前 relation version。Auth 在单个事务中再次确认 old owner 仍为 active owner、operation 唯一且有效，然后 CAS 废止旧 proof、激活新 proof 并递增 relation version；重复、并发、旧版本或目标被替换均拒绝。
+7. Name Service 只公开与 Auth active registry 一致的快照。关系变更后 subject 失去旧 owner 目录访问权，旧目录保留；新 owner 下建立新目录且不自动复制数据。Storage ACL provision 尚未完成时 fail closed。
+
+普通转让必须有 old owner、subject、new owner 三方授权，但不是三方签同一内容：old owner 签署指定目标和版本的转移授权，subject/new owner 双签新关系 statement。old owner 私钥失联、丢失或疑似失窃时不启动专门恢复流程；原关系在 owner 验证材料失效后报告为不可用，基本登录和通信仍按证书/AID 状态处理。
+
+## 7. Owner-side 备份命名空间与 ACL
+
+推荐固定目录为：
+
+```text
+<owner_aid>:/.aun/subjects/<canonical_subject_aid>/
+```
+
+- `/.aun/subjects/` 是 Storage 保留目录；bucket 固定为 `default`。每个 owner/subject 一条路径，与 proof ID / relation version 无关。
+- 外部 owner 的关系激活后由服务端幂等创建目录并配置受保护关系 ACL；客户端不得自行创建另一别名目录。
+- owner 保留 Storage owner 权限。当前 active subject 获得该 subject 专属目录的备份读写权限；其他 AID 无访问权且不能通过父目录枚举 subject。
+- ACL 来源标记为关系授权。普通 `set_acl/remove_acl`、visibility、分享链接、token、mount 等入口不能覆盖或恢复关系 ACL。每次访问需满足固定 owner/subject/path 与服务端已验证的关系 ACL；普通数据访问不要求逐次查询 Auth，不能仅信任客户端传入 owner AID。
+- 撤销、换 owner、过期或关系变为非 active 时，先由关系状态立即拒绝 subject，再通过幂等服务 operation/outbox 撤销 ACL 和已有访问票据；保留目录及数据，不递归删除、不自动迁移。
+- 同一对 owner/subject 之后重建关系可以复用保留目录，但必须有新的 proof/version，并先恢复新 ACL 才允许访问。
+- subject 上传的密钥等关键材料建议在客户端加密；Storage 只存不透明字节。备份数据格式和密钥恢复格式不属于本轮关系协议。
+
+`rw` 允许列出、读、创建、覆盖、删除、移动和重命名目录内部对象；subject 不能删除或移动 subject 根目录本身，也不能修改 ACL、公开可见性、签发 token 或挂载该目录。owner 可自行管理其 Storage 数据，但不能通过普通 ACL API 改写关系 ACL。撤销 ACL 但保留目录和对象数据是本设计的硬验收条件。
+
+## 8. 服务端调整清单
+
+### 8.1 Auth
+
+- 在 Auth 持久化层增加 AID 身份台账、ownership proof、关系 operation 和审计/outbox 记录；以 AID 当前记录为关系状态唯一权威源。至少记录 `aid/type/owner/mode/relation_version/active_proof_id/pending_owner_change_id/lifecycle_state`，区分 AID 生命周期、owner 关系状态与 operation 阶段；证书状态仍归 CA。每个 subject 至多一个 active owner 和一个 pending 转移。
+- 保留当前直接执行 `ca.issue_cert` 的 `auth.create_aid` 兼容入口及正常可用证书、登录通信语义，不追加 type/owner 必传要求；新增 prepare、签名提交/审批、commit、operation status、owner change prepare/commit、metadata 查询等方法。名称是候选，不是冻结契约。
+- 每个 operation 使用幂等键、稳定 operation ID、状态迁移约束、过期时间和 CAS；重复请求不得重复签证书、proof、目录或事件。
+- 对成功登记生成 Auth 签名的 registration receipt，绑定原始 fact/statement 摘要、proof ID、subject/owner、relation version、登记状态和服务端登记时间；回执用于证明“已按 Auth 策略登记”，不代替双方关系签名。
+- 在关系绑定 prepare/commit 和 agent.md 激活发布时，对 subject 的 `active`/pending 关系做同一事务内的唯一性检查：相同 owner/proof/operation 允许幂等重试，不同 owner、proof 或 operation 返回关系冲突；只有 `superseded`、`revoked`、`expired`、`cancelled` 等终态关系解除后才允许新建关系。
+- 所有关系创建、转移、解除和撤销写入均由 Auth 专用 operation 完成；普通 `auth.create_aid` 兼容入口不得建立已验证 owner 关系或变更 active owner。operation 状态恢复只重放已持久化结果，不构成新的 owner recovery。owner-change prepare 必须验证调用者是 Auth 台账中的当前 owner；只有该 owner 可获得并签署绑定 subject、指定 new owner、当前 relation version、operation nonce 和有效期的转移授权。
+- Auth 串行处理同一 subject 的 owner-change：第二个不同 pending operation 冲突；commit 在同一事务/行锁内复核当前 owner、proof/version 和签名，以 CAS 只允许一个转移生效。解绑也只能经 Auth，结果为 `unbound`；`unbound` 不限制基本登录和通信，是否限制具体业务由应用层依据状态决定。非 human 新建仍必须有 owner，不能把未完成注册伪装成已验证关系。
+- 对 canonical statement 上 subject 与 owner 的独立签名做服务端验签；必须确认双方签名输入字节相同。外部 owner 要求两份签名，self-owner 只验 subject 签名，并检查证书主体、指纹、信任链、用途、吊销状态及 proof/operation 绑定。
+- 校验 owner 必须有效且 agent.md 有效、类型仅为 human/agent；只验证直接 owner。self-owner 只对 `agent` 放行并跳过 owner profile 回源。
+- 登录/token 签发按现有证书和 AID 生命周期检查，legacy/关系 pending/unbound/unusable 不阻止基本 token 和会话。协议操作只在自身定义需要已登记关系时检查 registered 状态，普通业务是否要求 owner 由应用层决定。支持独立的一次性、scope 收窄的 agent.md 发布凭据。
+- 持久化旧客户端未绑定关系为 `legacy_unbound`，提供显式 `aid_bind` 流程，不推断 type/owner；首次绑定 operation 过期、取消或失败不自动吊销证书或停用 AID。
+- owner profile/证书失效时把当前关系状态更新为 `unusable` 并记录原因，不触发专门恢复或自动改绑；上线拉取一次，在线状态变化推送一次。
+- type 变更必须走专用 Auth operation，并在同一事务中确认该 AID 不是其它 AID 的未解绑 owner；所有下属关系均为 `unbound` 时允许变更，否则返回关系冲突。普通 agent.md PUT 仍不得改变 type。
+- 对关系提交、换 owner、proof supersede、回执拒绝/过期和目录 ACL 结果写审计；必要时发布关系状态变更事件，Gateway 只转发。
+- Auth 按台账、签名与 CAS 规则自动裁定协议冲突；密钥失窃/遗失或主体争议不触发本版专门恢复，owner 验证材料失效时关系进入 `unusable`，不能在规则外覆盖关系。
+
+Auth 关系唯一性检查矩阵（同一 subject 的台账记录必须在行锁/事务/CAS 内检查并写入）：
+
+| 入口 | 必须检查 | 允许结果 |
+| --- | --- | --- |
+| 绑定 `prepare` | active proof、未完成 pending operation、type/owner 矩阵和 AID 唯一性 | 无未解除关系时创建 pending；相同 owner/proof/operation 的幂等重试返回原 operation；不同 owner/proof/operation 返回关系冲突 |
+| 绑定 `commit` | operation、三字段 statement、所需签名、proof、当前 relation version 和台账状态 | 仅当前 operation 可激活；重复提交返回原结果；并发或旧版本拒绝 |
+| pending `agent.md` 激活 | 一次性发布凭据是否绑定 AID、operation、proof、owner；pending 是否仍属于该 operation | 只保存不可见快照；关系和文件均一致后才转 active；缺省/改写关系字段拒绝 |
+| 普通 `agent.md` 更新 | 文件 owner/proof 是否与当前 active 快照完全相同 | 只更新展示内容；不创建新关系；缺 proof、改 owner 或伪造 proof 转专用关系错误 |
+| `owner_change_prepare` | 调用者是否为当前 active owner、expected relation version 是否匹配、是否已有其它 pending | 创建唯一转移 operation；同一幂等键返回原 operation；其它请求返回 pending/version conflict |
+| `owner_change_submit` | old owner 转移授权、新关系签名、当前 owner/proof/version 和 operation 有效性 | 持久化分批签名；未齐全时保持 pending，重复提交幂等 |
+| `owner_change_activate` | operation、pending agent.md、Name Service 回执和当前 owner/proof/version | 单事务 CAS 废止旧 proof、激活新 proof；并发仅一个成功 |
+| 终态关系后重新绑定 | 旧记录是否为 `superseded`、`revoked`、`expired` 或 `cancelled` | 终态不阻塞新关系，但必须使用新的 proof/version；不得复用旧 proof |
+
+因此，提交 `agent.md` 和绑定 owner 都要检查是否存在未解除关系；普通内容更新只做当前 active proof 一致性检查，不借普通 PUT 创建第二条关系。SDK、Name Service 或客户端的“已验证”标记不能替代 Auth 台账检查。
+
+### 8.2 Name Service
+
+- 扩展 agent.md schema parser，识别 owner/proof 对象并校验字段类型、关联一致性和大小边界；四端 SDK 与服务端使用同一规范。
+- 普通 agent.md PUT 只能更新展示内容：普通 subject 请求者必须是 subject，文件尾签名必须使用 `active_signing`；`aid/type/owner/ownership_proof` 与 Name Service 已接受的关系快照一致；它不能更新权威 owner 状态。对已有 active 关系，Auth/Name Service 必须确认 proof 与当前 active proof 完全一致，但 proof 内部历史签名按证书指纹和签名时有效性验签；对 pending 注册，只接受绑定 operation 的一次性发布凭据；省略或改变关系字段必须转入 Auth 关系操作并在唯一性检查中处理。
+- `type=group` 是现有群服务上传路径的明确例外：群主可作为上传授权方，但 agent.md 尾部主体签名必须来自 group identity 证书；普通主体不得借 PUT 冒充 group identity。`type=org` 对应 org identity。群主/组织管理者与 Auth owner 不一致时拒绝激活，转让必须走 owner-change。
+- 大多数场景可依据公开可验证的 agent.md owner 声明；Auth 台账是关系写入和冲突裁定的权威状态。AUN 通过现有 agent.md 观察机制提供状态：上线拉取一次，在线状态变化推送一次；具体业务是否要求最新/active 状态由应用层决定，不要求每次读取或普通通信实时调用 Auth。
+- 为 pending 注册提供 operation-bound 一次性发布路径/凭据；只接受对应 AID、statement、proof 和 operation 的签名文档，token TTL 为 15 分钟，过期后重新申请，不续用旧 token；先保存为不可见 pending 快照，再按 Auth activation 回执公开。
+- 换 owner 经专用关系提交流程写入新快照；更新缓存和 ETag；失败/重试具有 operation 幂等性，不能只更新一边。
+- 对 owner profile 验证采用已验证、已发布的签名 agent.md；owner type 以有效签名 profile 与 Auth registry 对齐，不递归验证其 owner。
+- Name Service 启动和发布依赖 Auth；Auth 不回调 Name Service。发布时 Auth 未登记的 AID 可先懒注册为未绑定状态并返回 `registered=false`/`unbound`，不会被当作 Name Service 故障；需要 owner verified 的激活仍必须提交可验证的 owner 证据。
+- 更新 Name Service module 文档与 Schema/上传验收说明，记录 pending/active 的可见性与错误语义。
+
+### 8.3 Storage
+
+- 将 `/.aun/subjects/` 纳入服务端系统目录保护，创建固定目录并阻止普通创建、删除、移动、重命名、ACL、visibility、share、token、mount 逃逸。
+- 增加关系服务专用、可审计且幂等的目录 provision/revoke 接口或等价内部调用；普通调用方不能伪造可信内部调用标记。
+- 在所有读写、列表、ticket 和数据面下载授权入口检查服务端维护的关系 ACL generation；不能只在 SDK facade 检查，也不要求每次请求实时调用 Auth。
+- ACL 只能由 Auth 验证的关系创建/撤销操作授予或撤销，并通过可恢复 outbox 执行；关系撤销后的缓存/票据按状态变化通知和现有新鲜度机制失效，不能由未验证的客户端更新关系 ACL。
+- 保留目录与对象并按 owner 配额计量；owner 换出后旧数据仍归旧 owner，不能自动复制给新 owner。
+- 更新 Storage 协议和系统目录保护文档，明确固定路径、ACL 操作集、枚举限制及“撤权不删数据”。
+
+### 8.4 CA、Gateway 与模块边界
+
+- CA 继续做证书签发/证书链，不保存 owner 关系。扩展 `aid_type/key_purpose`：`group -> group/group_identity`、`org -> org/org_identity`，`human/agent/service/device/host/custom -> normal/signing`；未来 group-like 类型只能通过 CA 映射表扩展。证书状态与 Auth 的关系 operation 分开；未完成 owner 绑定不把证书标记为 pending。Auth/Gateway 仅在具体 owner-sensitive 入口检查已登记关系，不能因关系 pending 阻断基本登录和通信。
+- Gateway 保持路由职责。仅在现有方法路由或鉴权机制确实需要时增加配置/契约，不能把 owner 校验逻辑搬入 Gateway。
+- Auth、Name Service、Storage 之间仅新增 JSON-RPC 服务契约，不共享模块代码；依赖方向为 CA -> Auth -> Name Service，Storage 消费 Auth 的关系事件/ACL。对应 module manifest、服务依赖、权限签名和运行状态需在实现阶段一并更新，禁止形成 Auth 与 Name Service 的循环依赖。
+
+## 9. 四端 SDK 调整清单
+
+| SDK | 主要入口/实现面 | 必须对齐的能力 |
+| --- | --- | --- |
+| Python | `python/src/aun_core/aid_store.py`、`aid.py`、`agent_md.py`、`agent_md_schema.py` | 高层创建编排、pending identity 持久化/恢复、proof 生成验签、owner 请求/回执导入导出、换 owner、受限发布与结构化错误 |
+| TypeScript | `ts/src/aid-store.ts`、`aid.ts`、`agent-md.ts`、`agent-md-schema.ts`、keystore | 与 Python 同一状态机和 wire contract；保存 pending operation 与签名材料，不保存 owner 私钥 |
+| 浏览器/Node JavaScript | `js/src/aid-store.ts`、`aid.ts`、`agent-md.ts`、`agent-md-schema.ts` | 浏览器用 IndexedDB 保存可恢复 operation；WebCrypto/Node 签名行为与共享向量一致；owner 离线包可导入导出 |
+| Go | `go/aid_store.go`、`aid.go`、`agent_md_manager.go`、`agent_md_schema.go`、keystore | context/cancellation、Result 错误、pending 状态持久化、proof 和上传恢复与其他 SDK 一致 |
+
+四端公共 API 至少覆盖：
+
+- `register/create({type, owner?, agentMd?, idempotencyKey})` 的新编排入口；低层直接 AID 注册仅保留兼容语义。
+- `getOwnershipOperation/status`、owner signature request/reply export/import、pending inbox 拉取/提交及取消/过期结果。
+- `changeOwner(...)`、`verifyOwnershipProof(...)` 与下载/resolve 的 `ownership_status`、owner、proof ID、relation version。
+- 普通 agent.md 更新保留 proof、仅重签文件；更改 type/owner 必须转入关系操作。
+- 本地恢复不得重生成已预留 operation 的密钥；owner 签名始终使用 owner SDK 本地私钥。
+- 四端 SDK 在 prepare 取得证书后即暴露可认证身份和可恢复 operation 状态，不能以高层注册尚未完成或 pending keystore 为由阻止登录通信；关系完成只提升相应能力，不替换证书。中间结果的具体 API 在接口冻结时确定。
+- canonical relation statement、传输 request/reply 和旧关系解除声明共用测试向量；RPC 字段、数字、大小写、错误码和幂等重试在 Python/TS/JS/Go 一致。
+
+## 10. 文档改动清单
+
+正式文档在接口和状态机冻结后修改；下列是目标范围，不在本轮直接改写。
+
+| 文档 | 计划内容 |
+| --- | --- |
+| `docs/agent.md/SCHEMA.md` | owner/proof Schema、签名对象、兼容状态、内容签名与关系签名边界 |
+| `docs/protocol/agent.md/SCHEMA.md` | 对齐旧协议 Schema，移除与当前实现冲突的字段/type 约束 |
+| `docs/protocol/01-身份与凭证协议-auth.md` | 创建/换 owner RPC、状态机、operation 恢复、基本认证与 owner 关系能力分层、旧 create_aid 兼容 |
+| `docs/protocol/02-证书与信任体系.md`、`09-安全考虑.md` | 正常证书与 pending 关系分离、签名证书/吊销与历史 proof 验证规则（若证书策略有变化） |
+| `docs/protocol/07-错误码与状态机.md` | operation 过期、签名拒绝、proof mismatch、CAS 冲突、backup pending 等错误/状态 |
+| `docs/protocol/11-Storage-子协议.md`、`16-系统目录保护方案.md` | 保留目录路径、访问范围、关系 ACL、票据撤销、保留数据语义 |
+| `docs/sdk/04-连接与认证.md`、`06-API手册.md`、`07-错误处理.md` | 四端公开方法、owner 审批离线包、恢复/变更流程、返回状态及错误处理 |
+| SDK Auth RPC 手册（若冻结后 RPC 数量/细节足够，新增 `09-auth-rpc-manual.md`） | RPC 参数/响应、错误码、签名包、幂等键和 operation 示例 |
+| `extensions/services/auth/module.md`、`nameservice/module.md`、`storage/module.md` | 服务 RPC、数据责任、服务调用关系与运行依赖 |
+| `docs/protocol/index.md`、`docs/protocol/aun-docs-guide.md`、`docs/sdk/INDEX.md`、`docs/sdk/AUN_DOCS_GUIDE.md` | 正式协议/SDK 主题索引和行号引用 |
+| `docs/INDEX.md`、`docs/KITE_DOCS_GUIDE.md` | 总文档目录、主题交叉索引和文档行区间 |
+
+agent.md examples、SDK changelog 和测试运行指南在功能实现及发布窗口再更新；历史草案不能无说明地覆盖当前签名实现。
+
+## 11. 兼容、绑定与发布策略
+
+1. 服务端先支持读取旧 AID/agent.md；所有未证明的旧非 human 身份显式映射为 `legacy_unbound`，绝不自动生成伪 owner proof。
+2. 低层旧 `auth.create_aid` 保留原接口和正常可用证书，未绑定关系记为 legacy；新 SDK 注册必须传 type，非 human 必须传 owner。两条路径都保留基本登录通信，应用层根据协议报告的关系状态决定具体场景是否降级。
+3. 已有 AID 通过显式 `aid_bind` 建立 type/owner 绑定；human 可保持无 owner。绑定不能从普通 agent.md PUT 隐式完成。
+4. 服务端先部署 registry、读取兼容、operation API 和受限发布能力；再部署 Name Service、Storage 支持；随后发布 SDK。未实现新能力的 SDK 不能创建新 delegated identity。
+5. feature gate 控制新注册/绑定/换 owner，逐步开启；监控 pending 超时、签名拒绝、CAS 冲突、NS publish 和 ACL outbox 延迟。回滚关闭新编排入口，不删除 proof、operation、目录或备份数据。
+6. active relation 的普通名片更新必须携带原 proof；旧 SDK 若剥除 proof，Name Service 拒绝关系字段变化并返回可识别的兼容错误，不能静默清除关系。
+
+### 11.1 旧 AID 绑定的 SDK Facade 与服务端边界
+
+旧 AID 绑定不复用创建入口，也不改变旧 `auth.create_aid` 的返回和认证语义。四端 SDK 只提供同一组高层语义入口，具体方法名按语言风格映射：
+
+| Facade | 作用 |
+| --- | --- |
+| `bindAid({ aid, type, owner?, agentMd?, idempotencyKey? })` | 对已存在 AID 建立 type/owner 绑定，串联 `aid_bind_prepare`、签名提交、绑定快照发布和激活 |
+| `getAidBindingStatus(aid)` | 返回 type/owner、证书和 AID 生命周期、绑定状态、operation、relation version 及 capability；不把绑定状态作为登录通信总开关 |
+| `resumeAidBinding(operationId)` | 进程重启后查询并继续原 operation；重试复用同一 operation/proof，不生成第二份证明 |
+| `exportBindingRequest(operationId)` / `importBindingApproval(package)` | 外部 owner 离线签名包导出/导入；只传冻结 statement、摘要、签名和证书引用 |
+| `verifyAgentMdOwnership(agentMd)` | 本地验证公开 proof；需要判断当前 active 时再读取 Auth 的可验证状态 |
+
+Auth 侧新增 `auth.aid_bind_prepare`、`auth.aid_bind_submit`、`auth.aid_bind_activate`（服务间）和 `auth.aid_bind_status`。prepare 只接受显式 type/owner 或与已有登记完全一致的值，检查 subject 当前是否存在未解除关系/未完成 operation，并以 CAS 保护唯一绑定；submit 可分批接收 subject/owner 签名；activate 只接受与绑定 operation、AID、agent.md 摘要一致的发布回执。Auth 不重新签发证书，Name Service 不允许普通 `PUT /agent.md` 借机写入关系字段。
+
+旧 AID 在绑定 pending、失败或未发起绑定时均保持 `legacy_unbound` 和原有基本登录、Gateway、消息能力；应用层根据返回状态限制 owner-sensitive 场景。绑定成功后 human 进入 `not_applicable`，非 human 进入 `active`；任何状态变化通过现有上线拉取和在线单次 push 机制传播。
+
+## 12. 测试总验收矩阵
+
+- type 矩阵：八种预设类型及扩展 type；human 无 owner、新 SDK 非 human 注册缺 owner 拒绝、旧 create_aid 不增加 type/owner 必传要求、外部 owner 只允许 human/agent、self-owner 只允许 agent。
+- owner 可用性：无效 AID、缺证书/无效链、agent.md 缺失/验签失败/type 不匹配均拒绝；self-owner 不发生自身 owner-profile 递归请求。
+- proof：双方必须签完全相同的 canonical statement；篡改 subject/owner/proof ID、证书主体不符、跨 operation 重放或 operation 过期均拒绝；普通名片变化 proof 不变且文件重签成功。
+- 创建流程：一方离线、在线 inbox、导入/导出回执、请求超时/拒绝、重复 prepare/commit、SDK 崩溃后恢复；取得正常证书后的 pending/legacy 可登录、连 Gateway、收发消息和恢复 operation，但不能把未登记关系用于 owner 授权或访问 owner 备份目录。关系 active 只在有效 agent.md 发布流程提交后发生，不改变证书状态。
+- 换 owner：非当前 owner 发起、old owner 缺失或签名目标/version/operation 被替换、subject/new owner 未确认、同一 subject 第二个 pending operation、并发 CAS、operation 过期、重放旧授权/proof、普通 PUT 绕过均拒绝；正常流程的三方签名可异步完成。
+- 唯一性：每个 subject 至多一条 Auth active owner；竞争转移至多一个 CAS 成功；公开验签可验证 owner 声明，但只有 Auth 验证提交关系变更，外部文件不能改写 Auth 权威状态。
+- 独立验证：SDK、Name Service 与 Storage 可在不实时访问 Auth 时验证公开 agent.md 的 owner proof；普通内容更新保留 owner proof 且不调用关系变更流程；owner 创建、替换、解绑/撤销必须经过 Auth，冲突由 Auth 按台账和 CAS 仲裁。
+- 解绑/仲裁：已登记的 owner 不能由 subject 单方抹除；解绑经 Auth 转为 `unbound`，基本登录通信不受限，应用层依据状态决定 owner 依赖场景。owner 验证材料失效时关系转为 `unusable`，本版不提供专门恢复。
+- Storage：subject 只访问自己的目录，不能枚举其他 subject；普通 ACL/visibility/share/token/mount 不能绕过关系；目录内部对象允许删除、移动和重命名，但 subject 根目录不可移动或删除；关系撤销后既有访问凭据失效，目录/对象/配额仍保留；换 owner 不复制旧目录。
+- 跨端：同一 relation statement 与解除声明向量在 Python、TS、JS、Go 和服务端得到相同字节/哈希/验签结果；证书轮换和吊销按冻结策略得到相同 proof 状态。
+- 兼容：旧 agent.md 可读取为 legacy；旧 SDK create_aid 的返回字段、正常证书、基本登录通信不变；新 SDK 在离线审批、首次绑定超时/取消/失败及进程恢复前后仍可基本通信。非 owner 依赖的既有权限检查不因 owner 缺省新增限制；显式 aid_bind 后 relation version/proof 可验证。
+
+## 12A. Phase 0 协议冻结备选方案（P0-A）
+
+> 状态：P0-A01 至 P0-A12 及本轮关系状态、传播、type 变更、Storage 和 RPC 边界已确认；正常证书、legacy/绑定中基本登录通信和应用层按状态决定场景于 2026-10-02 22:08-23:16 确认。Phase 0 的剩余工作是生成向量、落实正式 wire 文档和实现验收，不再有待 owner 决定的策略项。
+>
+> 目标：在不改变当前 agent.md 尾部签名、四端 v2 canonical JSON、auth.create_aid 证书签发能力和 Name Service PUT /agent.md 基本语义的前提下，冻结 owner 关系所需的最小 wire contract。Phase 0 只冻结可互操作的字节、字段、状态和错误边界，不实现 SDK 或服务端。
+
+### 12A.0 现有实现基线
+
+| 现有入口 | 当前能力 | P0-A 的处理 |
+| --- | --- | --- |
+| python/src/aun_core/agent_md_schema.py、ts/src/agent-md-schema.ts、js/src/agent-md-schema.ts、go/agent_md_schema.go | 四端解析 agent.md frontmatter、尾部签名和大小/证书约束 | 在现有解析器上增加 owner/ownership_proof 结构校验，不改尾部文件签名覆盖范围 |
+| python/src/aun_core/v2/crypto/canonical.py、ts/src/v2/crypto/canonical.ts、js/src/v2/crypto/canonical.ts、go/v2/crypto/canonical.go | 已有跨端 canonical JSON 规则和向量 | 直接复用，关系 statement 不另造序列化器 |
+| ../extensions/services/auth/go/internal/service/service.go 的 auth.create_aid | 校验 AID、调用 ca.issue_cert、返回证书链，当前没有 owner 台账 | 保留兼容语义；新高层注册走 `auth.aid_register_*` operation，已有 AID 绑定走 `auth.aid_bind_*` operation |
+| ../extensions/services/nameservice/go/internal/httpserver/agentmd.go 与 agent_md_schema.go | Bearer/AID 校验、完整签名验证、ETag/Last-Modified、CAS 上传 | 普通 PUT 只更新展示内容；新增 pending snapshot 和 Auth activation 边界 |
+| python/src/aun_core/aid_store.py、ts/src/aid-store.ts、js/src/aid-store.ts、go/aid_store.go | AID/agent.md 上传、下载和本地缓存编排 | 增加 pending operation、离线签名包和崩溃恢复，但保持各端 wire payload 对齐 |
+
+### 12A.1 候选决策总表
+
+| 编号 | 候选决策 | 选择理由 | 复核点 |
+| --- | --- | --- | --- |
+| P0-A01（已确认） | 关系字段复用现有创建 AID 代码的 AID 校验/规范化结果；验证后强制转换 ASCII 小写并以小写返回、保存；ownership proof 不新增第二套规范化器 | 沿用现有 AID 规则，避免创建、agent.md 和 ownership proof 出现三套判断 | 所有 registry、proof、事件和 Storage 路径只保存规范小写；legacy 读取可兼容大小写输入但不得写回非小写 |
+| P0-A02（已确认，分号分隔） | 关系声明不增加 schema 字段；版本由固定可见域分隔符 AUN-AID-OWNER-RELATION-V1; 表达 | 保持共同事实只有 proof_id、subject_aid、owner_aid 三个业务字段；可见分隔符避免 0x00 被截断 | 不兼容升级使用新的可见域分隔符版本 |
+| P0-A03（已确认） | proof_id 由 Auth prepare 生成 RFC 9562 UUID v4，小写、36 个 ASCII 字符；客户端不可自选或复用 | 绑定一次登记/换绑 operation，阻止旧签名挪用到新 operation | 新建关系或换 owner 必须生成新的 proof_id；operation 重试复用原 proof_id |
+| P0-A04（已确认） | ownership_proof 只包含关系声明和签名封套，不放 nonce、时间、operation、relation version | 关系事实与编排上下文分层；双方签的是同一不变事实 | 普通 agent.md 内容更新只需 subject 重签文件，不要求 owner 重签 proof |
+| P0-A05（已确认） | 直接复用现有 v2 canonical JSON：递归按 Unicode code point 排键、紧凑无空格、非 ASCII UTF-8 直出、数组保序 | 四端已有实现和 golden vector，不引入第二套序列化 | 关系 statement 只含字符串字段，仍纳入四端共享向量 |
+| P0-A06（已修订） | 关系证明仅传双方声明及实际签名，不携带关系或声明摘要字段 | 验证双方 AID、proof、角色和签署时间 | 以当前 SCHEMA.md 的独立 v2 声明为准 |
+| P0-A07（已确认） | proof 签名固定 ECDSA P-256 / SHA-256 / ASN.1 DER / 标准 Base64；封套只含 cert_fingerprint、signature；写链路只允许 active_signing，读链路按指纹定位证书并按签名时有效性验签 | 与当前 agent.md 签名格式一致，签名随机 nonce 不要求双方相同；历史凭证可在证书后续 verify_only/过期/吊销时继续验签 | P0 不接入 P-384/Ed25519 新关系；算法扩展另行版本化 |
+| P0-A08（已确认） | 登记/换绑 operation、离线 request/reply 和 pending inbox 的业务有效期统一 7 天；operation-bound 发布凭据 15 分钟；同一幂等键记录保留 30 天 | 支持离线审批，同时限制 pending 状态和重放窗口 | 业务审批过期或 token 过期后分别新建 operation/request 或重新申请 token，不续期、不复用旧签名/token |
+| P0-A09（已确认） | Auth 签发 registration receipt；receipt 证明“已按台账登记”，不代替 subject/owner 关系签名；关系状态观察复用现有 agent.md 机制 | 公开 proof 可独立验签，依赖最新状态的场景有权威回执 | receipt body 绑定 operation、proof/hash、relation version 和 agent.md 摘要，由 Auth 服务证书签名；上线拉取一次，在线状态变化推送一次 |
+| P0-A10（已确认） | Auth 对每个 subject 强制一个 active owner 和一个 pending operation；普通 proof-only 验证不声称唯一，registered 验证必须检查 Auth receipt/status | 只有台账/CAS 能提供唯一性和最新性，密码学签名本身不能排除多份有效 proof | 当前 owner 授权、Storage ACL、换 owner 和冲突判断使用 registered；展示/离线验签可用 proof_only |
+| P0-A11（已确认） | 保留服务端原有创建 AID RPC；新 owner/type 编排使用新的 RPC，普通 PUT /agent.md 不得改变 owner | 兼容现有客户端，同时把关系事务放入可恢复的新流程 | 原 create AID RPC 不创建 owner relationship、不写 active owner 台账；新 SDK 不通过旧 RPC 附加字段绕过新流程 |
+| P0-A12（已确认） | owner 备份目录固定为 owner_aid:/.aun/subjects/canonical_subject_aid/；ACL 由 Auth 关系事件驱动，撤销只撤权不删数据 | 路径和生命周期跨 SDK/Storage 一致，且不允许客户端伪造关系 | subject 可列出、读取、创建、覆盖、删除、移动和重命名目录内部对象；不得移动或删除 subject 根目录本身 |
+
+P0-A01 至 P0-A12 的策略已完成逐项确认；Phase 0 的剩余工作是把这些结论整理成正式 wire schema、RPC/错误码/事件封套并生成 Phase 1 的跨端 golden vectors，不再新增本轮未确认的业务策略。
+
+### 12A.2 AID、type 与 owner 组合
+
+1. 关系字段中的 AID 先复用现有创建 AID 代码的语法校验，再把 ASCII A 到 Z 映射为小写；规范化值不得包含 Unicode 等价变体、尾部点或路径分隔符。SDK/API 返回值、Auth registry、proof、事件和 Storage 路径一律使用该小写值。
+2. 新协议 proof 中的 subject_aid、owner_aid 必须等于其规范化值；legacy 读取可兼容大小写输入，但任何新写入、返回或持久化结果不得保留大写。
+3. human 不得出现 owner 或 ownership_proof。新 SDK 注册的其它 type（包括未知扩展 type）必须提供 owner；旧 create_aid 保留缺省兼容；只有 agent 允许 owner_aid == subject_aid 的 self-owner。
+4. 外部 owner 的 Auth registry 记录必须是有效 AID，直接 owner 的已验证 type 只能是 human 或 agent。不递归读取 owner 的 owner；self-owner 不回源验证自己的 agent.md。
+5. type 不进入共同关系 statement。Auth 在 prepare/commit 时把 type 写入 AID 台账并与 agent.md 交叉检查；改变 type 必须另走 type-change operation，并原子确认该 AID 不是其它 AID 的未解绑 owner；其下属关系全部为 `unbound` 时允许变更，否则拒绝。普通 PUT /agent.md 只能保留原值。
+
+### 12A.3 精确的公开 proof 结构
+
+候选 wire 结构如下。对象字段顺序不参与 YAML 解析语义；关系签名只使用下节定义的 canonical JSON，不直接签 YAML 文本。
+
+~~~
+owner: "alice.agentid.pub"
+ownership_proof:
+  proof_id: "550e8400-e29b-41d4-a716-446655440000"
+  subject_aid: "sensor.agentid.pub"
+  owner_aid: "alice.agentid.pub"
+  subject_signature:
+    cert_fingerprint: "sha256:<64位小写hex>"
+    signature: "<标准Base64编码的ECDSA DER>"
+  owner_signature:
+    cert_fingerprint: "sha256:<64位小写hex>"
+    signature: "<标准Base64编码的ECDSA DER>"
+~~~
+
+- owner 与 ownership_proof 要么同时缺省（legacy/未绑定读取），要么同时存在；只出现一个、出现 null 或出现空字符串均拒绝。
+- ownership_proof 只允许 proof_id、subject_aid、owner_aid、subject_signature、owner_signature 五个字段；签名封套只允许 cert_fingerprint、signature 两个字段。未知字段、重复 YAML key、错误类型和额外并行签名字段均拒绝。
+- proof_id 为 Auth 生成的小写 UUID v4。它是 opaque 标识，不编码时间、AID、nonce 或 relation version。
+- 必须满足 agent.md.aid == subject_aid、owner == owner_aid（AID 比较按规范化值）；外部 owner 必须有两份签名，self-owner 省略 owner_signature 且 subject_aid == owner_aid。
+- cert_fingerprint 固定为证书 DER 的完整 SHA-256 指纹，格式 sha256:<64位小写hex>；签名必须是严格标准 Base64 的 ECDSA DER 字节。
+- proof 关系签名首版只接受 NIST P-256 证书和 ECDSA/SHA-256。已有 P-384/Ed25519 证书可继续用于现有兼容登录或 legacy agent.md，但不能创建新的 P0 owner proof，除非另行批准算法扩展。`group`/`org` 的 agent.md 主体文件签名分别必须使用 CA 映射的 `group_identity`/`org_identity` 证书；外部 owner 关系签名仍按 owner 的 `signing` 用途验证。
+- proof 中不放双方签名时间、nonce、operation ID、relation version、有效期或 Auth receipt。关系不变而名片展示内容变化时，只需 subject 重新签整个 agent.md；`group`/`org` 文件主体使用对应 identity 证书重签，owner 不需重签 proof。
+
+### 12A.4 Canonical bytes、事实摘要和签名
+
+候选定义 D = ASCII("AUN-AID-OWNER-RELATION-V1;")，末尾分号是域分隔符的一部分；D 后不追加换行。
+
+~~~
+statement = {
+  "proof_id": "550e8400-e29b-41d4-a716-446655440000",
+  "subject_aid": "sensor.agentid.pub",
+  "owner_aid": "alice.agentid.pub"
+}
+fact = {
+  "subject_aid": "sensor.agentid.pub",
+  "owner_aid": "alice.agentid.pub"
+}
+
+statement_bytes = D || canonical_json(statement)
+fact_bytes      = canonical_json(fact)
+~~~
+
+按现有 v2 canonical JSON，以上 statement 的字节对象键顺序会是 owner_aid、proof_id、subject_aid；示意形式为：
+
+~~~
+AUN-AID-OWNER-RELATION-V1;{"owner_aid":"alice.agentid.pub","proof_id":"550e8400-e29b-41d4-a716-446655440000","subject_aid":"sensor.agentid.pub"}
+~~~
+
+签名输入是 statement_bytes；subject 和 owner 对各自声明独立签名。验收比较声明的关系字段并做跨端互验，不比较签名字符串相等。
+
+双方封套中的证书指纹用于选取证书和校验 AID/CN/信任链。关系证明不再携带额外摘要字段，接收方直接验证原始声明和签名。只有 `cert_fingerprint` 使用 `sha256:<64位hex>`。
+
+### 12A.5 验证等级与唯一性边界
+
+候选定义两个明确的验证等级：
+
+| 等级 | 可验证内容 | 是否需要实时 Auth |
+| --- | --- | --- |
+| proof_only | 规范化 AID、statement bytes/hash、证书指纹、subject/owner 签名、self/delegated 结构 | 否；只能说明双方曾签署该关系声明，不能声称它是当前唯一关系 |
+| registered | proof_only 全部内容，加 Auth registration receipt 或 relation_status 返回的当前 active proof、relation version 和状态新鲜度 | 是或使用在约定新鲜度内的 Auth 签名快照；可用于“当前 owner”授权判断 |
+
+因此，agent.md 的公开 owner 字段在普通展示、缓存和离线验签场景可按 proof_only 使用；AUN/Auth 返回 `active`、`unbound`、`unusable` 等关系状态及其新鲜度，具体业务是否要求 registered/active 由应用层决定。协议自身的关系写入、换绑、关系 ACL 等操作仍按其定义检查 registered 状态；基本消息收发不因关系状态被全局阻断。检查对象是当前操作依赖的目标关系，不额外要求 owner 自己也绑定 owner；human 合法无 owner。单靠 subject 自签一个新 agent.md，密码学上无法消除“同时存在两份都能验过的 proof”；Auth 的每 subject 唯一 active 约束和 CAS 才是排他性来源。
+
+### 12A.6 Auth operation 与 RPC 候选
+
+以下名称是 P0-A 候选名，参数字段是 wire 候选；现有 auth.create_aid 返回的证书字段保持兼容。
+
+| RPC | 关键请求字段 | 关键响应/状态 |
+| --- | --- | --- |
+| auth.aid_register_prepare（历史草案） | aid、type、owner_aid?、public_key、curve=P-256、idempotency_key | operation_id、证书/链、proof_id?、statement?、relation_version、expires_at、state |
+| auth.aid_register_submit | operation_id、关系 statement（可选，必须与 prepare 相同）、subject_signature、owner_signature? | 验证后的 state=agent_md_pending 或等待另一签名；重复提交返回同一结果 |
+| auth.aid_register_activate（服务间） | operation_id、agent_md_sha256、Name Service pending receipt | 单事务提交已登记关系/发布结果，返回 Auth registration receipt；不更改正常证书或基本登录状态 |
+| auth.aid_bind_prepare | 已存在的 subject_aid、显式 type、owner_aid?、idempotency_key | operation_id、已有/新 relation version、proof_id?、冻结 statement?、hash、expires_at、state；不重新签发证书 |
+| auth.aid_bind_submit | operation_id、statement、subject_signature、owner_signature? | 绑定签名校验结果；可返回等待另一签名的 pending 状态，重复提交返回同一结果 |
+| auth.aid_bind_activate（服务间） | operation_id、agent_md_sha256、Name Service binding receipt | 单事务登记缺失 type/owner 和 proof，返回 Auth registration receipt；不改变证书或基本登录状态 |
+| auth.aid_bind_status | operation_id 或 subject_aid | legacy/pending/not_applicable/active 等绑定状态、type/owner、proof/hash、relation version、错误/结果；用于恢复 |
+| auth.aid_operation_get | operation_id | 当前 state、proof/hash、relation version、过期时间、错误/结果；用于崩溃恢复 |
+| auth.owner_change_prepare | 当前 owner 身份、subject_aid、new_owner_aid、expected_relation_version、idempotency_key | operation_id、旧关系 version、new_proof_id、新 statement/hash、transfer payload、expires_at |
+| auth.owner_change_submit | operation_id，可分批提交 old_owner_signature、subject_signature、new_owner_signature | 持久化已收签名，未齐时返回等待状态；齐全后进入 agent_md_pending |
+| auth.owner_change_activate（服务间） | operation_id、新 agent_md_sha256、Name Service pending receipt | 在当前 owner/version CAS 成功后 supersede 旧 proof、激活新 proof 并返回 receipt |
+| auth.owner_relation_status | subject_aid、可选 min_relation_version | 当前 state、type、owner_aid?、proof_id?、relation_version、receipt/新鲜度信息 |
+| auth.owner_relation_unbind | subject_aid、expected_relation_version、idempotency_key | Auth 原子将当前关系置为 `unbound`、递增 relation version、撤销关系 ACL/outbox；不删除目录或数据，不影响基本登录通信 |
+| auth.aid_type_change | subject_aid、new_type、expected_relation_version、idempotency_key | Auth 检查 subject 不是其它 AID 的未解绑 owner 后更新 type；同时生成绑定 agent.md 的 operation-bound 发布凭据 |
+| storage.relation_backup_status | subject_aid、owner_aid? | 返回固定关系备份目录、ACL 版本、状态和数据保留标志；不返回目录内容 |
+
+auth.create_aid 仍可被旧 SDK 直接调用，正常签发证书并保留基本登录通信，不增加 type/owner 必传要求，也不自动产生已验证 owner 关系。已有 AID 的绑定必须走 `aid_bind_prepare/submit/activate/status`，不能通过普通 PUT 或把 type、owner 附加到旧 RPC 来绕过关系台账。新 SDK 的高层 register/create 必须走 aid_register_prepare，type 必传、非 human 的 owner 必传；新 prepare 取得证书后同样可在绑定完成前登录和通信。所有公开 RPC、错误码、事件和结果封套遵循现有 auth.* JSON-RPC 惯例，不另造调用风格。
+
+### 12A.7 创建、离线审批和激活状态
+
+以下集合只描述注册 operation 阶段和 proof 终态；证书、AID 生命周期、owner 关系及能力分层以 5.1 节为准，不能用同一个 active/pending 控制全部准入：
+
+~~~
+reserved
+  -> proof_pending
+  -> agent_md_pending
+  -> active
+
+reserved/proof_pending/agent_md_pending
+  -> expired | cancelled
+
+active -> superseded | revoked
+~~~
+
+- human 跳过 proof，reserved -> agent_md_pending；显式提供 owner/proof 立即返回 human_owner_forbidden。`group`/`org` 的 pending 快照必须由对应 identity 证书签署，群主/组织管理者只提供上传授权。
+- self-owner 只需 subject 对 statement 签名；外部 owner 需要 subject 与 owner 对同一 statement 的两份独立签名。双方不必同时在线，owner 可导入 statement 和 subject 签名后离线导出 detached 回执。
+- auth.aid_register_submit 可接收部分签名并幂等保存；owner 回执不携带 subject 私钥，也不替 subject 修改 agent.md。只有 subject SDK 生成含 proof 的完整 agent.md 并用自身 `active_signing` 证书签尾部文件签名；`group`/`org` 文件主体使用对应 identity 证书。
+- Name Service 通过 operation-bound 一次性发布凭据接收 pending agent.md；建议 Authorization: Bearer <publish_token> 配合 X-AUN-Operation-Id。凭据只能写指定 AID、指定 operation/proof 的一个快照，TTL 已确认为 15 分钟；过期后重新申请，不续用旧 token。它自身不能登录、发消息或调用其它 RPC，但不限制 subject 用基本 access token 执行这些操作。
+- pending snapshot 返回 202/待激活状态且公开 GET 视为 404；Auth 收到 Name Service 的内容摘要和持久化回执后才原子提交关系/发布结果。快照未公开不得成为基本登录通信的阻断条件；关系完成不重新签发证书。服务重启由 operation ID、outbox 和相同幂等键恢复，不能生成第二个 proof/key；首次绑定过期、取消或失败只限制 owner 依赖能力，换绑未提交则维持原 active 关系。
+- 历史激活回执包含 subject_aid、owner_aid?、proof_id?、relation_version、agent_md_sha256、operation_id、登记时间和 receipt ID；当前 SDK P2P ownership 编排不需要 Auth 登记回执。
+
+### 12A.8 换 owner 的转移授权与事务边界
+
+auth.owner_change_prepare 返回的 old-owner transfer payload 候选为：
+
+~~~
+{
+  "operation_id": "...",
+  "subject_aid": "sensor.agentid.pub",
+  "old_owner_aid": "alice.agentid.pub",
+  "new_owner_aid": "bob.agentid.pub",
+  "new_proof_id": "...",
+  "relation_version": 3,
+  "challenge_nonce": "<服务端生成的一次性可见 ASCII token>",
+  "expires_at": "2026-10-02T10:00:00Z"
+}
+~~~
+
+old owner 签名输入为 `AUN-AID-OWNER-TRANSFER-V1;` || canonical_json(payload)。这份授权只表达“当前 version 的关系允许转向指定 new owner”，不替代新 proof 的三字段共同 statement。`challenge_nonce` 和 `expires_at` 由 Auth 生成并纳入 old owner 授权，不能由客户端自报或复用。Auth 只接受当前 active owner 发起、operation/version/目标完全匹配且未过期的授权；subject 直接发起或普通 agent.md PUT 均不能创造有效换绑。
+
+换绑提交按以下事务边界执行：
+
+1. Auth 在 owner_change_prepare 对 subject 行/记录做 CAS，确保 active owner/version 匹配且没有其它 pending operation。
+2. old owner、subject、new owner 的 detached 签名可分批到达；同一 operation 只允许填充缺失角色，不允许替换已验证签名。
+3. Auth 在 activate 前再次检查 old owner transfer authorization、新 statement 三字段、证书和当前 active version；任一不匹配均不写 active 状态。
+4. 单个 Auth 事务中把旧 proof 标记 superseded、递增 relation version、写入新 active proof/receipt、追加 Storage/Name Service outbox。并发 operation 只有一个 CAS 成功。
+5. Name Service 只在新快照被 Auth 激活后公开；Storage 先按新状态 fail closed，再异步撤销旧 ACL、建立新 owner 目录 ACL。旧目录和数据保留，不自动复制。
+
+从 self-owner 换到外部 owner 时，old owner 与 subject 是同一 AID，但仍对 transfer payload 和新 relation statement 分别签名；不能用一个签名字节冒充两个不同 payload 的签名。换到 self-owner 时，新 proof 省略 owner_signature，但 old owner transfer authorization 仍然必须存在。
+
+### 12A.9 Name Service、Storage 和错误契约
+
+- Name Service 普通 PUT /agent.md 继续使用当前 subject Bearer token、`active_signing` 文件签名和 CAS。若 owner/proof 与已 active 快照不同，返回 HTTP 409 / owner_relation_change_requires_auth；不在普通 PUT 中创建第二条关系。group/org 上传例外必须带对应 identity 授权，主体签名仍不能被群主/组织管理者证书替代。
+- 普通内容更新必须保留当前 active proof；缺少 proof、只改 owner、伪造 proof 或把 active 关系改成 legacy 均拒绝。pending 注册只能使用 operation-bound token，快照未激活前不可 GET/HEAD 公开。
+- Auth/Name Service 写路径必须检查 subject 是否已有 active proof 或其它 pending operation；同 owner/proof/operation 的重放返回原结果，不同关系返回冲突。公开读取不要求每次实时访问 Auth，但需要当前关系的授权必须用 registered 等级。
+- Storage 关系目录固定为 owner_aid:/.aun/subjects/canonical_subject_aid/。关系激活/撤销事件带 operation_id、relation_version、acl_generation，通过 durable outbox 重试；状态不明或撤销传播未确认时数据面 fail closed。撤销只撤 ACL 和访问票据，不清理数据。
+
+P0-A 建议冻结的稳定错误码：invalid_aid_type、owner_required、human_owner_forbidden、owner_type_forbidden、self_owner_not_allowed、owner_not_verified、owner_relation_conflict、pending_operation_exists、idempotency_key_reuse、proof_statement_mismatch、signature_invalid、proof_expired、relation_version_conflict、operation_not_found、operation_expired、owner_relation_change_requires_auth、aid_binding_required、type_change_blocked、identity_signer_mismatch。HTTP/RPC 映射可由服务文档另列，但错误 code 本身跨 SDK 不变。
+
+### 12A.10 证书生命周期、恢复和解绑边界
+
+- 新 proof、转移授权、agent.md 文件、E2EE 消息和其它写链路签名提交时证书必须处于 `active_signing`，CN/AID、证书指纹、信任链和 P-256 算法必须一致。只读验签按签名中的证书指纹定位证书；只要签名时间位于证书有效期内且签名当时证书有效，即使证书后来变为 `verify_only`、自然过期或被吊销，历史 proof/agent.md 签名仍可验签通过，并单独报告当前证书状态。关系激活后证书自然过期不自动使 proof 失效；Auth receipt 记录登记时刻。
+- 证书显式吊销、AID key compromise、owner 失联/丢失或疑似泄露时，本版不提供专门 recovery、争议恢复或自动换绑；owner 验证材料失效时关系报告为 `unusable`。不得仅凭新 agent.md 或单方声明强行换 owner，基本登录和通信仍按证书/AID 状态处理。
+- 已登记 owner 关系不能通过普通上传或 subject 单方声明抹除；解绑必须经 Auth 进入 `unbound`。`unbound` 不限制基本登录和通信，具体 owner 依赖场景由应用层依据状态决定。owner 证书/profile 失效时关系进入 `unusable`，不启动专门恢复流程。
+- legacy_unbound 旧 AID 和新流程的关系 pending AID 均使用正常可用证书，保留基本登录通信及既有能力。显式 `aid_bind` 必须生成新的 proof/version（如需要 owner proof），不能复用旧 proof；operation 过期、取消或失败不自动使已签发证书失效。
+
+### 12A.11 Phase 0 通过标准与四端向量
+
+P0-A 只有在以下材料逐项确定后才可进入实现：
+
+1. 对所有 P0-A 编号给出接受、修改或删除结论；未决定项不能由实现者自行补字段。
+2. 生成至少一组固定 statement、canonical bytes 和签名封套向量：self-owner、external owner、错误 proof/错误大小写。
+3. Python、TypeScript、JavaScript、Go、Auth 和 Name Service 对向量产生完全相同的 bytes/hash；任一端生成的 DER/Base64 签名可由其它端和服务端验证，但不要求签名字符串相同。
+4. 历史 operation 正反例仅作旧方案背景；当前关系验证以原始声明及签名为准。
+5. 将冻结后的字段、错误码、状态和向量分别同步到 agent.md Schema、Auth RPC 手册、四端 SDK API 手册、Name Service/Storage module 文档；在此之前不修改生产代码。
+
+## 13. 分阶段实施计划与验收 Checklist
+
+### Phase 0：冻结协议决策
+
+Checklist：
+
+- [x] 确认 owner 业务规则：`human` 不得有 owner；新 SDK 注册的其它 type（包括扩展 type）必须传 owner，旧 create_aid 不增加 type/owner 必传参数。Schema 中 `owner` / `ownership_proof` 可选以兼容旧文档，但关系字段必须成对且出现时合法。
+- [x] 冻结共同签署声明的最小业务字段集合：`proof_id`、`subject_aid`、`owner_aid`；self-owner 只保留 subject 签名，`subject_type`、`relation_version` 和 operation 元数据不进入共同声明。
+- [x] 冻结 `owner` / `ownership_proof` 对象的精确字段、类型/必填约束、签名封套、proof_id 格式和 self/delegated 表达方式（P0-A03、P0-A04、P0-A07）。
+- [x] 冻结签名输入：四端 `v2` canonical JSON、`AUN-AID-OWNER-RELATION-V1;` 可见域分隔符、ECDSA-P256-SHA256 DER + 标准 Base64；验收声明关系字段及跨端签名互验。
+- [x] owner 变更须由当前 old owner 发起并签署转移授权，subject 确认新关系、new owner 接受；Auth 是唯一关系写入口。
+- [x] owner 证书/profile 失效时关系报告为 `unusable`；本版不提供专门 recovery/争议恢复，不影响证书/AID 仍有效时的基本登录通信。
+- [x] 解绑经 Auth 进入 `unbound`；基本登录通信不受限，应用层依据状态决定 owner 依赖场景；不把未完成首次绑定当成解绑。
+- [x] Auth 状态传播复用现有 agent.md 观察机制：上线拉取一次，在线状态变化推送一次；具体业务新鲜度由应用层决定。
+- [x] 冻结 operation、离线 request/reply 和 pending inbox 有效期统一 7 天；发布 token 15 分钟，过期重新申请；幂等记录保留 30 天。
+- [x] 确认旧 create_aid、新注册和已有 AID 的 `aid_bind` 均使用正常可用证书；legacy/绑定中保留基本登录通信，绑定 operation 过期/取消/失败不自动停用身份；仅依赖已验证目标 owner 关系的场景降级（2026-10-03 10:23）。
+- [x] 冻结 Name Service 一次性发布凭据：operation-bound、TTL 15 分钟，过期重新申请；与基本 access token 分离。
+- [x] 冻结 Auth registration receipt 的字段、签名密钥/验证方式、proof ledger 托管和状态观察语义（P0-A09）。
+- [x] 冻结 Storage 路径与 subject ACL 初始操作集（P0-A12）：目录内部对象可删除/移动/重命名，subject 根目录不可移动/删除；撤权不删数据。
+- [x] 确认服务端原有创建 AID RPC 保留、新 owner/type 编排使用新 RPC；公开接口遵循既有 RPC 惯例（P0-A11）。
+- [x] 确认所有新写入/返回/持久化的 AID 强制使用 ASCII 小写；legacy 读取可兼容大小写但不得写回非小写。
+- [x] 确认证书读写链路分离：写入/新签名只允许 `active_signing`；只读按证书指纹定位历史证书并按签名时有效性验签，单独报告当前证书状态。
+- [x] 确认 CA 的 `aid_type/key_purpose` 扩展及 group/org identity 映射，群主/组织管理者上传授权不替代主体 identity 签名。
+- [x] 确认服务依赖方向为 Auth -> Name Service，Auth 不依赖 Name Service；未注册 AID 可懒注册并返回未绑定状态，不视为服务故障。
+
+P0-A01 至 P0-A12 的策略已完成逐项确认；下一步是将其落成正式 wire schema、RPC/错误码/事件封套并生成 Phase 1 的跨端 golden vectors。
+
+验收标准：上述契约形成一份可版本化的协议表；canonical statement 和签名封套无未定义字段/编码；开放决策有明确结论或明确排除在首版范围外。未达成前不进入跨端实现。
+
+### Phase 1：协议 Schema 与共享测试向量
+
+Checklist：
+
+- [ ] 更新 agent.md Schema 与 Auth / Storage 协议草案，保留旧实现和旧文档差异说明。
+- [ ] 建立 canonical relation statement、proof、旧关系解除声明和传输 request/reply 的正反例向量。
+- [ ] 为 type/owner/schema 字段及 type-change 的“未解绑下属 owner 拒绝、全部 unbound 后允许”规则编写服务端和四 SDK 测试，再实现解析器。
+- [ ] 固定文件签名与 proof 签名的独立覆盖范围。
+
+验收标准：Python、TS、JS、Go、Auth、Name Service 对每个向量产生完全相同的 canonical bytes/hash；所有负例被一致拒绝；旧无 owner 文件仍可读并映射 legacy，而不被伪装为有效 proof。
+
+### Phase 2：Auth 身份台账与 operation API
+
+Checklist：
+
+- [ ] 先增加 repository contract/unit tests，再实现 AID registry、proof、operation、idempotency 和审计持久化。
+- [ ] 实现创建 prepare/审批提交/状态查询/commit 及已有 AID 的 aid_bind 入口。
+- [ ] 实现 owner prepare/subject+owner(+new owner) detached 签名验证和 relation version CAS。
+- [ ] 实现登记回执生成、验签、状态/版本查询和 proof ledger 证据托管；不得保存 subject/owner 私钥。
+- [ ] 将证书与 AID 生命周期用于基本登录/token 准入，准确返回 `legacy_unbound`、`pending`、`active`、`unbound`、`unusable` 状态；应用层按场景决定是否要求 registered，不全局禁用。
+- [ ] 实现一条 operation 只能发布指定 AID 的短期注册凭据和状态恢复。
+- [ ] 明确 CA 签发/证书状态的衔接；旧 create_aid 和新注册都签发正常证书，首次绑定未完成、过期/取消/失败不自动改变证书或 AID 生命周期。
+
+验收标准：服务重启后 operation 状态可恢复；幂等重放返回相同 operation 结果；错误 proof 不激活关系；并发换 owner 只有一个 CAS 成功；legacy/关系 pending 在证书有效、AID 未停用时可获取基本 access token、登录和通信，但不能获得未验证关系的权限；绑定成功不重签证书，首次绑定过期/取消/失败不损害基本能力。
+
+### Phase 3：Name Service agent.md 校验和可见性
+
+Checklist：
+
+- [ ] 扩展 server schema、owner/proof relation 校验和 owner profile/type 检查。
+- [ ] 普通 PUT 对 active relation 做只读比对，关系字段变化交给 Auth 流程。
+- [ ] 实现 operation-bound 一次性注册发布与 pending snapshot staging。
+- [ ] 接入 Auth finalization 回执/outbox，保证 GET、ETag、缓存只暴露 active 快照。
+- [ ] 为创建、普通内容更新、换 owner、状态拉取/push、失败重试补齐 handler/repository tests。
+
+验收标准：仅签名文件有效且 proof 与 registry 一致的文档可发布；普通 PUT 篡改 owner/type/proof 被拒绝；pending agent.md 不可 GET；提交重试不重复快照/事件；激活后 GET/HEAD/ETag 一致。
+
+### Phase 4：Storage 关系目录和授权撤销
+
+Checklist：
+
+- [ ] 先为 `/.aun/subjects/` 的禁止操作、访问边界和数据保留添加 service tests。
+- [ ] 实现内部幂等 namespace provision/revoke、ACL source 标记和 ACL generation。
+- [ ] 将 relation/ACL 状态检查加到对象、列表、upload/download ticket、share/token 等入口；允许目录内部对象删除/移动/重命名，但保护 subject 根目录。
+- [ ] 增加 durable retry/outbox；关系撤销先 fail closed，再异步移除 ACL/票据。
+- [ ] 覆盖目录复用、关系重建、换 owner 两个 owner namespace 分离和配额归属。
+
+验收标准：subject 仅能访问自己的目录并管理目录内部对象；普通 ACL API 不可改系统 ACL，subject 根目录不可删除/移动；非 active subject 和旧 ticket 被拒绝；撤销不删除目录/对象、不迁移数据；重复 provision/revoke 稳定幂等。
+
+### Phase 5：Python SDK 编排参考实现
+
+Checklist：
+
+- [ ] 为 AIDStore 新流程、身份与 pending operation 分离持久化、签名向量和恢复先写单元测试。
+- [ ] 实现 create/prepare、subject proof、在线/离线 owner request-response、publish/finalize。
+- [ ] 实现 proof verify、active/legacy 元数据返回、普通 agent.md 更新保留 proof。
+- [ ] 实现 change owner、relation version conflict 和 operation status 恢复。
+
+验收标准：Python 可在 subject/owner 不同时在线的条件下完成从创建到关系 active；prepare 取得证书后即可在等待审批/发布时登录通信；owner 私钥不出本地；进程中断后保留可认证身份并从 operation ID 恢复；Python 所有共享向量与 Phase 1 一致。
+
+### Phase 6：TypeScript、JavaScript、Go SDK 对齐
+
+Checklist：
+
+- [ ] 将 Python 端状态机和错误映射按冻结 wire contract 移植，不各自增加字段或 RPC 语义。
+- [ ] 分别增加 pending operation 持久化、owner 回执导入导出、换 owner 和 proof 验证。
+- [ ] 覆盖浏览器 IndexedDB 与 Node/Go 文件 keystore 的崩溃恢复边界。
+- [ ] 对每个共享向量跑跨端签名与验签 parity 测试。
+
+验收标准：四端公开 API 名称按语言风格一致，参数/Result/Error/wire payload 对齐；任一语言生成的签名可由其余三端与服务端验证；取消、超时、重试不丢失或重复执行 operation，不因注册/关系未完成阻止已取得证书的身份登录通信。
+
+### Phase 7：集成、绑定、文档和发布门
+
+Checklist：
+
+- [ ] 单域覆盖创建、人类无 owner、自主 agent、外部 owner、离线审批、普通更新、换 owner、解绑/unusable 与崩溃恢复。
+- [ ] 双域覆盖 owner/subject 跨 issuer 的 profile 与证书链验证、离线回执转交和错误恢复。
+- [ ] 对旧 AID 执行只标记 legacy 与显式 aid_bind 测试；确认旧 create_aid 证书/返回字段和基本登录通信不变，不自动猜 type/owner；覆盖状态上线拉取、在线单次 push、unbound/unusable 报告、type-change 条件、Storage 内部对象操作和新注册/绑定失败后的通信。
+- [ ] 更新 SDK RPC 手册、Auth/NS/Storage module 文档、协议索引、SDK 索引和 changelog。
+- [ ] 完成 feature gate、指标/审计检查和回滚演练；回滚不能删除关系证明与保留目录。
+
+验收标准：单域和双域矩阵通过；所有失败测试按断点续跑修复后继续；四端 SDK 与服务端结果相同；文档中的 API、错误码和状态与实现逐项对应；回滚关闭新流程后旧数据和既有关系不丢失。
+
+## 14. Phase 0 冻结结论与实现前提
+
+本轮已确认此前列出的策略项：
+
+1. 应用层决定具体场景是否要求 owner；AUN/Auth 只报告准确关系状态，不破坏基本登录和通信。
+2. owner 证书/profile 失效时关系进入 `unusable`；本版不特别处理 recovery、密钥争议或自动换绑。
+3. 解绑进入 `unbound`；基本登录和通信不受限，应用层依据状态决定 owner 依赖场景。
+4. 状态观察复用 agent.md 机制：上线拉取一次，在线状态变化推送一次。
+5. type 变更要求该 AID 不是其它 AID 的未解绑 owner；其下属关系全部 `unbound` 时允许变更。
+6. operation、离线 request/reply 和 pending inbox 有效期统一 7 天；Name Service 一次性发布 token TTL 15 分钟，过期重新申请。
+7. subject 可管理 owner 目录内部对象（含删除、移动、重命名），但不能移动或删除 subject 根目录本身。
+8. 公开 RPC、错误码、事件和结果封套遵循既有 RPC 惯例。
+
+上述结论不替代 Phase 1 的 golden vectors、正式 Schema/RPC 手册和实现测试；它们是进入实现时不可自行改变的协议边界。
+
+## 15. 当前文档验证状态
+
+- 本文是设计与计划，不包含代码或正式协议契约变更。
+- 计划中的验收矩阵需在各实现阶段执行；本轮只需验证文档链接、索引和 diff 格式，不运行 SDK/服务端测试。