Replies: 19 comments
|
代码锚定核验（当前 main HEAD
回答两个开放问题（有依据） Q3 多市场互认：建议把"认证等级由验证者本地策略决定"写死进规范，而不是由发行方声明。L3 的签名对象是"上架记录"——B 市场认不认 A 市场的签名，本质是验证者策略问题（枚举 A 的签名即可、加上 B 自己的签名即可），不需要"互认协议"。这与我们讨论 #3209/#3210 的同一个原则一致：信任边界要可验证，不要靠声明。规范里明确这一点，可以避免"互认"演变成大市场挤压小市场的准入壁垒。 Q4 GitHub 被攻破：作者签名的信任锚确实是 GitHub 密钥。补救链建议明确为三条硬要求（而不是"事后发现"）：① 撤销传播——解析节点必须设 TTL + 缓存失效，撤销后 L2 徽章在可接受时限内转红（参考实现已有 revoke，需要补传播时限标准）；② 密钥轮换——controller 更新即旧密钥失效，DID 文档应声明 一个务实落地建议 如果走"最小落地"路径，建议先只做 L1（内容指纹 + 产物签名） 在单个市场试点：成本最低（不需要作者/发行方密钥体系）、价值明确（"装的就是发布的"可验证）、且能自然长成 L2/L3。dsh-subscribe 这类注册表可以先接 L1 作为质量信号的数据源之一——我们已在注册表上跑质量评分（Q 徽章 + verified 标志），CHA2A 的认证等级可以直接作为其中一维，装前可见"内容完整性已验"。 提案的"认证可选 + 等级递进 + 多市场兼容"三个原则都很稳，建议下一步把 L1 的最小实现 + 验证者策略条款写进附件，形成可试点版本。 |
|
@zoahdev 感谢代码级核验！三处官方机制引用（SkillSource 七桶、SKILL.md frontmatter 必填、bundle 安装单位）经你逐行确认，我们放心了——这正是"不要假定官方没有"的严谨姿态。 关于你回答的两个开放问题——采纳，并将落进规范：
关于"L1 最小试点"——我们已跑通并超出： 参考实现不止 L1，L0-L3 完整链路已公网运行（L4 生态认证机制预留，待多方证据接入）：
提交记录：did:cha2a 规范（github.com/wwumit/did-method-cha2a）+ W3C 注册 PR #744 审阅中。 欢迎继续拍砖。 |
|
确认采纳落位 + 参考实现已实测在线（compliancehub.cn 与 /store/ 均 200）。三条跟进： 1. "验证者本地策略"与 L3 的 publisher=verifier 需要显式命名。 你们的实现里 dshlib 同时是验证者和 L3 publisher——这与"认证等级由验证者本地策略判定"原则自洽（枚举信任的签名集合），但建议在规范里把这个场景显式点名（"验证者与发行方同体"），否则读者会把 L3 理解为"dshlib 盖章"而不是"该验证者集合信任 dshlib 的签名"。参考实现里 levelOf 按 metadata 计算，已经是这个语义——只需文档点破。 2. 与 #3223（ToolRuntime settlement anchor）共享词汇，避免第三种方言。 那边讨论的 anchor ID / generation / settlement 语义，和 CHA2A 的 L1 内容完整性 + L3 签名对象是同一族问题：一个是"装的是发布的"（注册表侧），一个是"跑的是被验证的"（运行时侧）。建议 CHA2A 在附件里预留一个 "runtime attestation" 映射段（contentIdentity ↔ anchor generation），现在不实现也行，先占住词汇位，两个提案才不会各说各话。 3. dsh-subscribe 接 L1 的落点。 我们注册表已跑 Q 徽章 + verified 标志；L1（npm integrity sha512 作 contentIdentity）可以作为其中一维加进质量信号（"内容完整性已验"），装前可见。如果你们愿意，我可以先做一个小适配层验证（对 dsh-subscribe 的 917 条目批量算 npm integrity 并对照 compliancehub 的注册表），给一份兼容性报告。 另外注意到 W3C PR #744 在审——如果注册表条目把 did:cha2a 作为 source 字段公开，我们的商店端可以直接把 L1 徽章渲染出来，形成闭环。欢迎继续推进。 |
|
兑现刚才的承诺：dsh-subscribe × npm integrity 的 L1 兼容性预研已跑完。 结果（325 个 npm 可装插件全名单，10 并发实测）：
脚本 + 完整报告已公开：
下一步如果你们愿意：dsh-subscribe 条目加 |
|
@zoahdev 三条跟进全部落实，你的 324/325 预研直接推动了 L1 批量落地： 1. "验证者与发行方同体"——已显式写进规范（§4.6），并做了诚实修正。 dshlib 作为验证者兼 L3 发行方，语义是"该验证者集合信任 dshlib 的签名"。且我们发现自己的实现曾违反此原则——dsh-plugin-tools 的 L3 原先写 publisher=dshbase（未经确认的声明），已改为 publisher=dshlib.com（我们真实验证通过）+ verificationEvidence 字段。现在所有 L3 都有真实验证证据（npm tarball sha512 integrity + bundle + patch 全查）。 2. 词汇协同——已占位。 规范新增 §4.7 Runtime attestation vocabulary（contentIdentity ↔ anchorId/anchorGeneration 映射，明确"装的是发布的"注册表侧 vs "跑的是被验证的"运行时侧），现在只占词汇位不实现。 3. L1 批量——你的预研直接落地。 312 个 dsh-subscribe 插件的 npm integrity 已批量注册为 cha2a L1（contentIdentity），商店（compliancehub.cn/store/，401 插件）批量渲染 L1 徽章，分级计数（L3×3 / L2×1 / L1×312 / L0×85）。验证报告已存档：compliancehub.cn/store/verification/（HTML + JSON 机读，L3 必有证据）。 附带确认：#3223 的 ToolRuntime anchor 与 CHA2A L1 确实是同一族问题，词汇对齐后生态信任叙事完整。 下一步可合作：① dsh-subscribe 的 source.integrity 双轨对齐（你提的）② 或你跑一个对 312 条 L1 的独立复核——欢迎拍砖。 |
|
@zoahdev 关于你说的"独立复核"——我们把它正式化为一个验证邀请： 邀请内容：请对以下插件做独立复核（用你自己的方法/标准，不依赖我们的验证）：
我们的验证方法与证据（供你对照）：
复核结果的接入（L4 机制已就绪并校验）：
合作面（后续可扩展）：
|
|
Spec update (3d7c8d7): §4.7 "Runtime attestation vocabulary (reserved)" now also covers verifier attribution for the case where a host merely lists required anchor IDs — the verifier of an anchor is the host's local policy (same principle as §4.6 verifier-local policy), and implementations SHOULD expose which anchors their local policy trusts alongside any settlement result. Companion changes in the same commit:
Context: this section exists precisely so runtime-attestation proposals (#3223 ToolRuntime settlement anchor) can align vocabulary with CHA2A rather than spawn a separate dialect — as @zoahdev flagged there. Happy to iterate on the anchor↔registry mapping. |
|
生态实证更新：ToolRuntime 结算锚点提案（#3223）已确认将对齐 CHA2A §4.7 词汇 @mohammedmessaoudene-cmd @zoahdev 外部项目 ToolRuntime attestation 原型 已确认将使用 CHA2A §4.6–§4.7 术语，不再引入并行命名： Ecosystem update: the ToolRuntime attestation prototype has committed to align with CHA2A §4.6–§4.7 terminology instead of introducing parallel names:
实现上遵循 zoahdev 核验过的生命周期映射（ Implementation follows the lifecycle mapping verified by zoahdev ( 这对 §4.7 的意义：§4.7 的初衷就是统一定义共享词汇，避免生态各自发展互不兼容的方言——这是支持该意图的首个生态示例，完整表述待作者的 external profile 与双向量测试公开执行后确认。 Why this matters: §4.7 was designed to unify shared vocabulary so ecosystem proposals do not develop separate dialects — this provides an initial ecosystem example supporting that intent, with full confirmation pending the author's executed external profile and two-sided vectors. 若有更多项目（结算锚点、工具调用证明、供应链验证等）采用，§4.7 词汇将成为运行时证明的公共方言。 If more proposals (settlement anchors, tool-call attestation, supply-chain verification) adopt it, §4.7 becomes the common dialect for runtime attestation. 待作者测试后：若其"已绑定世代不可变"的语义测试与我们 §4.7 表述一致，会将措辞纳入规范（§4.7 generation monotonicity 细则）。 After the author's tests: if the "bound generation is immutable" semantics match our §4.7 wording, we will fold it into the spec (generation monotonicity detail). 也欢迎其他运行时证明/结算类提案对齐 §4.7 词汇——保持一个方言，生态互认成本最低。 Other runtime-attestation/settlement proposals are welcome to align with §4.7 — one dialect keeps cross-ecosystem interop cheap. |
|
谢谢在 #3192 中记录这次对齐。为避免重复和过度表述，我建议把第二条较简洁的评论作为规范记录，并作以下小幅调整。
Thank you for recording this alignment in #3192. To avoid duplication
and overstatement, I suggest treating the second, cleaner comment as
the canonical record, with the following small refinements.
1. 建议保持“每段中文后紧跟对应英文”的形式。它比双栏更适合 GitHub 移动端、逐段引用和国际读者审阅。
Keep the paragraph-by-paragraph Chinese/English format. It is easier
to read on GitHub mobile, quote precisely, and review internationally
than a two-column layout.
2. 五个术语适合保留一个简短双语表格，表头建议改为：`CHA2A term | 中文含义 | English role`。较长的解释仍放在段落中。
The five mappings work well as one short bilingual table. I suggest
the headers `CHA2A term | 中文含义 | English role`; longer explanations
should remain in prose.
3. 开头各提及一次 ***@***.***` 和 ***@***.***` 即可，不建议扩大 mention 范围。
Mention ***@***.***` and ***@***.***` once in the opening;
no broader tagging is needed.
4. 为保持证据边界，建议将“已采纳 / has adopted”写成“已确认将对齐 / has committed to align
with”，直到更新后的 external profile/plugin 和双向量测试已经公开执行。类似地，建议把 “validates
that intent” 收窄为 “provides an initial ecosystem example supporting
that intent”。“待作者测试后”的限定应保留。
For claim accuracy, I recommend `has committed to align with` rather
than `has adopted` until the updated external profile/plugin and
two-sided vectors have been publicly executed. Likewise, `provides an
initial ecosystem example supporting that intent` is safer than
`validates that intent`. The “after the author’s tests” qualifier
should remain.
5. 预期的语义映射现已清楚：原子 admission binding 之前发生处置或替换，应 fail closed；binding
完成后，已捕获的 `anchorGeneration` 对该 admission 保持不可变，后续处置只影响新的 capture，并作为
settlement observation 记录，而不是追溯性地使历史 binding 失效。
The intended semantic mapping is now clear: disposal or replacement
before atomic admission binding fails closed; after binding, the
captured `anchorGeneration` remains immutable for that admission.
Later deactivation affects subsequent captures and may be recorded as
a settlement observation, but does not retroactively invalidate the
historical binding.
AUEC 特有的部分仍限于 requested → host-allowed → effective
authority、denied/reduced delta、精确 decision/action binding，以及 AUEC
verdict / host disposition / effect disposition
的分离。下一步应以执行后的双向量结果支持更强的表述，而不是提前声明采用完成。
The AUEC-specific layer remains limited to requested → host-allowed →
effective authority, the denied/reduced delta, exact decision/action
binding, and the separation of AUEC verdict, host disposition, and
effect disposition. Stronger adoption language should follow executed
two-sided results, not precede them.
如果编辑现有评论，建议删除末尾的三个排版问题；无需再发布第三条重复评论。
If editing the existing comment, I suggest removing the three
editorial questions at the end; there is no need for a third duplicate
post.
AI-assistance disclosure: ChatGPT assisted with review and drafting. I
reviewed the wording and remain responsible for it.
…On Thu, 20 Aug 2026 03:44:11 +0000 (UTC), Wei Wu ***@***.***> wrote:
生态实证更新：ToolRuntime 结算锚点提案（[#3223](#3223)）已采纳 CHA2A §4.7 词汇
***@***.***(https://github.com/mohammedmessaoudene-cmd) ***@***.***(https://github.com/zoahdev) 外部项目 [ToolRuntime attestation 原型](#3223) 已确认使用 CHA2A §4.6–§4.7 术语，不再引入并行命名：
Ecosystem milestone: the [ToolRuntime attestation prototype](#3223) has confirmed it will use CHA2A §4.6–§4.7 terminology instead of introducing parallel names:
CHA2A 词汇
英文
用途
contentIdentity
发布/构建身份
shipped/build identity
anchorId
运行时注册身份
runtime registration identity
anchorGeneration
调用捕获的单调快照
monotone snapshot captured for the call
fail closed
处置/替换
disposal/replacement
verifier-local policy
验证者归属
trusted-anchor selection & attribution
实现上遵循 zoahdev 核验过的生命周期映射（tools/pre-execute 策略 / tools/execute 快照 / tools/post-execute 结算），零新增核心 hook。
Implementation follows the lifecycle mapping verified by zoahdev (tools/pre-execute policy / tools/execute snapshot / tools/post-execute settlement) with zero new core hooks.
这对 §4.7 的意义：§4.7 的初衷就是统一定义共享词汇，避免生态各自发展互不兼容的方言——现在第一个运行时证明类提案按此对齐，验证了该设计。
Why this matters: §4.7 was designed to "pin the shared terms so ecosystem proposals do not develop separate dialects" — the first runtime-attestation proposal aligning with it validates that intent.
若有更多项目（结算锚点、工具调用证明、供应链验证等）采用，§4.7 词汇将成为运行时证明的公共方言。
If more proposals (settlement anchors, tool-call attestation, supply-chain verification) adopt it, §4.7 becomes the common dialect for runtime attestation.
待作者测试后：若其"已绑定世代不可变"的语义测试与我们 §4.7 表述一致，会将措辞纳入规范（§4.7 generation monotonicity 细则）。
After the author's tests: if the "bound generation is immutable" semantics match our §4.7 wording, we will fold it into the spec (generation monotonicity detail).
也欢迎其他运行时证明/结算类提案对齐 §4.7 词汇——保持一个方言，生态互认成本最低。
Other runtime-attestation/settlement proposals are welcome to align with §4.7 — one dialect keeps cross-ecosystem interop cheap.
- 排版：中英分段对照（如现在）？还是整段中→整段英（两栏）？
- 表格双语是否合适（还是纯文字列表）？
- 是否 @ 相关人
—
Reply to this email directly, [view it on GitHub](#3192?email_source=notifications&email_token=B3G3HTZMXJAUYR3GBEB42435KZXYRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBQG4ZTQMRXUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18073827), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/B3G3HT2PBRFHHECTRRIEBXD5KZXYRAVCNFSNUABJKJSXA33TNF2G64TZHMYTGMZTGA3DKMBZGE5UI2LTMN2XG43JN5XDWMJQGY2DCMJTGGQXMAQ).
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for [iOS](https://github.com/notifications/mobile/ios/B3G3HT3K3ISE7ICWDGSWMUT5KZXYRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBQG4ZTQMRXUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ) and [Android](https://github.com/notifications/mobile/android/B3G3HT7FKXG3WJQW4XGCXX35KZXYRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBQG4ZTQMRXUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ). Download it today!
You are receiving this because you were mentioned.
|
|
@mohammedmessaoudene-cmd 已按你的 5 条建议编辑了上面的记录（改为规范版），修改点：
|
|
@zoahdev 回到你的 source.integrity 双轨建议——我们这边确认了一下接口现状，可以接着往下走：
|
|
补一个来自可运行 Store 的实现边界，供 CHA2A 的证据词汇设计参考。 我们在 sandbaseai/dsh-plugin-store Preview 5 中已经把安装前检查拆成可执行的 provenance gate：目录记录必须是 实测后有两个建议：
另一个已经出现的真实边界是 如果 CHA2A 后续提供稳定的机器可读 proof，我们愿意在 Store 中做消费者侧试验，但会继续把“完整性/来源/目录验证/本地激活”分别显示，避免一个徽章承诺超出证据范围。 |
|
@sandbaseai/dsh-plugin-store（denial123789）首先感谢你的提案——原子证据正是我们在 L4 验证互信认证上的关键问题，你从可运行 Store 的视角把它具体化了。逐条回应：
|
|
Thank you for the CHA2A §4.6–§4.7 alignment and the clarification that
a bound generation is an immutable admission snapshot.
I have now completed a private, project-controlled two-sided
implementation pass using the shared vocabulary rather than parallel
AUEC names:
- npm `dist.integrity` is retained byte-for-byte as `contentIdentity`;
- `anchorId` and `anchorGeneration` identify the runtime registration
captured at admission;
- disposal/replacement before binding fails closed;
- deactivation after binding does not retroactively invalidate that
admission, and is recorded as a settlement observation;
- verifier selection remains the host's verifier-local policy.
The executed formal corpus contains 64 Node vectors and 64 Python
vectors with exact agreement and 28 per-kind two-sided criteria. The
runtime package tests pass 40/40 in the bounded private profile.
Runtime settlement remains explicitly separate from atomic/in-toto
evidence, verifier authentication, and CHA2A L0–L4 levels.
Six implementation limits remain visible, most importantly the strict
self-only ToolRuntime composition and its incompatibility with the
official timeout/other execute-post hooks. The full DeepSeek Harness
repository suite remains `FAIL_BASELINE`, so this is not an adoption,
certification, production, independent-validation, or no-regression
claim.
Does the tested wording below match the intended §4.7
generation-monotonicity detail?
Once admission atomically binds `contentIdentity`, `anchorId`, and `anchorGeneration`, that generation remains the immutable historical reference for the admission. Deactivation or replacement before binding rejects the admission; deactivation after binding affects subsequent captures and may be recorded in settlement, but does not retroactively invalidate the bound evidence.
If that wording matches the intended contract, I will keep the public
artifact aligned to it and avoid introducing a separate attestation
dialect.
AI-assistance disclosure: ChatGPT and Codex assisted with
implementation, testing, analysis, and drafting. I reviewed the
evidence and remain responsible for the claims.
|
|
@mohammedmessaoudene-cmd 措辞确认——匹配，并感谢你完成了这轮私有双向量实现。以下是我们确认的完整对应关系，以及我们会据此对规范做的两处更新。 The wording checks out — it matches, and thank you for completing this private two-sided implementation pass. Below is the full correspondence we confirm, plus the two spec updates we'll make on that basis. 1. 措辞确认（逐条对应 §4.7 / §6） 1. Wording confirmation (point-by-point against §4.7 / §6) 你测试的语义与规范意图一致： The semantics you tested align with the spec's intent:
2. 措辞建议（统一分界术语） 2. Wording suggestion (unify the boundary term) 分界术语建议统一用 admission binding 而不是 body start——分界是"capture 是否已绑定"，不是"body 是否已开始"。这正是你在 #3223 回帖 4 表达过的原则（"whether the capture is already bound"），正式措辞保持一致，避免术语层出现第二个方言。 Use admission binding as the boundary term rather than body start — the boundary is "whether the capture is already bound", not "whether the body has started". This matches the principle you stated in #3223 ("whether the capture is already bound"); keeping the formal wording consistent avoids a second dialect at the terminology level. 3. 我们会做的两处更新 3. Two updates we'll make (a) §4.7 generation-monotonicity 细则并入（目前该节是 vocabulary reservation only；你的双向量测试为这条细则提供了首个实现证据）。拟并入的措辞草案： (a) Fold the generation-monotonicity detail into §4.7 (currently the section is vocabulary-reservation-only; your two-sided vectors provide the first implementation evidence for this detail). Proposed wording:
（与你测试的版本一致——我们只做了两处形式化：以"admission binding"统一分界术语；"may be recorded in settlement"与 §6 TTL 传播条款保持一致。） (Identical to the version you tested — with two formal adjustments only: "admission binding" as the unified boundary term, and "may be recorded in settlement" kept consistent with the §6 TTL propagation clause.) (b) evidence-record 词汇表新增映射行： (b) Add a mapping row to the evidence-record vocabulary table: 4. 这条回应的生态上下文（给整个讨论串） 4. Ecosystem context for this thread 这次对齐是三方的协作结果：zoahdev 在 #3192 回帖 3 先指出"词汇协同，避免第三种方言"；你在 #3223 回帖 3 确认采用 §4.7 术语；现在双向量测试为细则提供了实现证据。这条链完整走通了 §4.7 的设计初衷——统一词汇、生态各实现各自验证、不互相声明。dshlib 的证据模型（in-toto 对齐的 Statement/Envelope/Bundle）会继续沿用这一词汇，欢迎后续运行时证明/结算类提案对齐，保持一个方言。 This alignment is a three-party collaboration: zoahdev first flagged "shared vocabulary, no third dialect" in #3192 reply 3; you confirmed adopting §4.7 terms in #3223 reply 3; now the two-sided vectors provide implementation evidence for the detail. This chain fully realizes §4.7's intent — one shared vocabulary, each implementation verifies independently, no mutual declaration. dshlib's evidence model (in-toto-aligned Statement/Envelope/Bundle) will continue to use this vocabulary; further runtime-attestation/settlement proposals are welcome to align and keep one dialect. 关于"下一步是否公开参考实现仓库"——我在 #3223 回复了完整看法（建议先公开双向量测试作为审查工件，运行时仓库等上游契约落地再公开），这里不重复。 On "whether to publish the reference implementation repo" — my full view is in #3223 (publish the two-sided vectors as the review artifact now; hold the runtime repo until the upstream contract lands), not repeating here. 本回复为社区提案方的个人/项目观点，不代表 DeepSeek 官方立场。 This reply reflects the proposer's own views on a community proposal and does not represent any official position of DeepSeek. |
|
Thank you for the point-by-point wording confirmation. I have now prepared the 感谢你逐条确认措辞。我现已准备好受限的公共审查工件：它以 admission binding 作为唯一分界术语，并测试你确认的 generation-monotonicity 语义。 Public review artifact: Pinned identity:
The artifact contains 64 distinct vectors evaluated independently by the Node The tested rule is the same bounded rule stated in your reply:
Evidence boundaries remain explicit. This is project-controlled implementation If useful, review can focus on AI-assistance disclosure: ChatGPT and Codex assisted with implementation, |
|
@mohammedmessaoudene-cmd 收到并已核验这份公共审查工件——感谢你把语义验证做成可复现、哈希绑定、双 oracle 一致的工程产物。我们已在本地环境复跑核心核验，结果与你声明一致。 复跑核验（verified locally）：
我们的记录动作（will record）：
边界重申：社区实现级证据，非官方采纳或独立验证；我们确认语义对应与状态标记，不背书工件绝对正确性。 感谢把"验证互信"做成可审的形态——这正是 CHA2A 想要的。 (EN) Received and verified. We reran the core verification locally: Node 64/64 matched and Python 64/64 pass, both with corpus SHA-256 |
|
感谢独立复核邀请。这里把边界说清楚：我此前完成的 cha2a-l1-preflight 是 npm registry integrity 的批量兼容性核验，不等同于对 dsh-cc-tui、dsh-side-panel 的独立运行时/发行证据复核，因此目前不能诚实地作为第二验证方写入 verifiedBy，也不应据此形成 L4 声明。请暂时不要把 zoahdev 登记为独立验证者；只有在我用独立方法复跑并公开可审计证据后，我才会提交验证结论。 |
|
@zoahdev 完全同意并尊重你的边界判断——我们不会主动把你登记为独立验证者，登记只在你自己提交可审计证据后发生；也不会基于 cha2a-l1-preflight 形成任何 L4 声明。你的澄清本身就是"验证者身份必须基于可审计独立复核"的正确示范。 Wording check — we will NOT proactively register you as an independent verifier; registration happens only after you submit auditable evidence. And we will not base any L4 claim on cha2a-l1-preflight. Your clarification is exactly how verifier identity should be gated: on auditable independent review, not on inference. 并且，借这次澄清，我们对现有 L4 记录做了完整核查，发现并准备修正数据与标准问题（transparent fix）： 1. 数据问题（占位验证者）： 2. 标准问题（L4 生态尚未跑通）：核查后确认，当前 catalog 中没有插件达到 L4 的完整标准——L4 要求 ≥2 个真实注册的独立验证者，而我们目前可用的验证者（compliancehub.cn / dshlib）同属一个主体，且尚未出现任何真实独立验证者完成可审计复核。L4 在社区生态中尚未真正跑通，此前的 L4 标注是基于逻辑验证而非生态实证。 我们的处理：
将来若你用独立方法完成对 dsh-cc-tui / dsh-side-panel 的复核并公开可审计证据，随时欢迎提交——我们会按标准流程登记。 感谢你让"验证互信"保持诚实。 |
Uh oh!
There was an error while loading. Please reload this page.
〇、提案定位
本提案响应社区对插件生态安全与 provenance 的呼声（如 #1115"尽快建立官方插件市场、做好标准和安全规范"），目标：形成智能体生态身份与来源认证规范（讨论稿，简称 CHA2A —— Agent Identity & Source Attestation Framework；方法名
did:cha2a已提交 W3C 注册，见 §1.4）——四层标识 + 分层签名 + 认证等级，解决"谁发布的、是否被改、在哪些市场上架、可信度几级"。本方案建立在官方已有机制之上（SKILL.md 必填字段、bundle 分发规范、SkillSource 来源桶），在其上叠加身份与信任层，衔接关系见 §3。一、核心设计（讨论目标）
1.1 四层标识（did:web 承载，域名即锚）
四层标识为语义层概念，技术载体统一为已注册的 did:web 方法（域名托管 did.json，域名即锚）：
did:web:<store-domain>did:web:<org-domain>package/ 技能级skilldid:web:<org-domain>:agents:<id>（did:web 路径）产物层分两级：① 包级（package）——内容指纹覆盖整个 bundle（package.json + cordis.patch.yml + 代码），是完整性校验与签名的验证单元；② 技能级（skill）——以官方必填 skill name 寻址，一个包可含多个技能（1:N），各自独立可用。
内容身份 vs 实例身份：
contentIdentity = sha256(技能内容)用于跨包同一性判定——同一技能被多个包（市场/发行方）分别打包时：内容哈希一致 → 同一内容、多个发行实例；被修改后再打包 → contentIdentity 不同（内容上不是同一个），衍生包可声明可选derivedFrom（上游内容哈希）诚实标注来源。name 相同但 contentIdentity 不同 = 明确的"不是同一个"，防止"同名不同内容"冒充。实体层（agent 级 ID + instance 级信任锚）：
did:agent的 subject 是每个 agent（一个 instance 可配多个 agent，各自独立寻址/互认，能力与状态在 agent 级表达）；信任锚（controller 密钥）在 instance 层——同 instance 的 agent 共享 controller（同信任域，对应 §1.6 intra-instance）；agent 之下的 subagent 复用官方运行期父-子机制（会话树/descriptor），不占标识层。此即 DID 标准的 subject/controller 分离：寻址在 agent、负责在 instance。1.2 分层签名（衔接成熟体系）
1.3 认证等级（有认证，也允许不认证）
关键设计：认证不是强制，是可选信号——区分"认证"与"未认证"，让市场自然选择：
设计原则：
1.4 前置条件：标识语法采用 DID（既有标准，已查证；独立方法 did:cha2a 已提交注册）
事实澄清（已查证）：DID Core 是 W3C Recommendation（2022-07）；did:web 是 W3C DID Extensions Methods（原 DID Method Registry）已注册的成熟方法（Web 方法，域名托管 did.json）。四层标识以 did:web 承载（现行，任何域名所有者可自托管）；同时独立方法 did:cha2a 已提交 W3C 注册（PR #744，审阅中；规范
github.com/wwumit/did-method-cha2a，Apache-2.0）——独立注册确保定义权，不依赖任何单一外部项目的存续。实证（2026-08-18）：did:cha2a 参考实现运行中——compliancehub.cn 公网 HTTPS 提供 discovery（
/.well-known/cha2a）、DID 解析（/api/v1/did/<did>）、信任查询（认证等级 L0-L4）与徽章（/badge/<type>/<id>）；最小闭环 18 步实测通过（注册→解析→验签→撤销→停用）。Node 仅监听 127.0.0.1，nginx 443 反向代理，复用现有证书，不开公网端口。名称查证（2026-08）：did:agent 已被他人注册（不争名，执行实体层以 did:web 路径承载）；did:store / did:org 未占用（语义层名，不注册）。did:cha2a（ch = complianceHub 缩写，a2a = agent-to-agent）未占用，已提交注册。
兼容性（不排他）：标识层与信任层解耦，同一规范可同时兼容：
store:<domain>/org:<domain>/skill-id）诚实声明：采用 DID 语法仍需要生态共识（各方是否接受 did: 前缀、解析节点归属与去中心化程度）——本提案不假定该共识已存在；参考实现与注册提交先行，共识随实践形成。
共识路径（分阶段）：
兜底：若 DID 共识受阻，标识层降级为轻量标识，信任层（签名/认证/验证链）不受影响。
1.5 方法工作流（did:cha2a 实测流程图）
以下流程即参考实现（compliancehub.cn）当前运行的方法，可在公网直接验证：
flowchart TB subgraph C["① 注册 Create"] A["发布者提交<br/>type + id + metadata"] --> B{"Registry 校验<br/>类型/ID 语法"} B -->|"合法"| D["分配 DID<br/>did:cha2a:type:id"] B -->|"语法错误"| E["400"] B -->|"重复注册"| F["409"] D --> G[("注册记录<br/>metadata + 状态")] end subgraph R["② 解析 Read"] H["使用方 GET /api/v1/did/{did}"] --> I{"Registry 查询"} I -->|"存在"| J["DID 文档<br/>Ed25519 公钥<br/>TrustLookup / TrustProof / Badge"] I -->|"不存在"| K["404"] I -->|"语法非法"| L["400"] end subgraph V["③ 验证 Verify"] M["验证者"] --> N["GET /.well-known/cha2a<br/>discovery 公钥"] M --> O["GET /api/v1/trust/proof<br/>签名 trust proof"] N --> P{"验签"} O --> P P -->|"有效"| Q["✅ 认证等级 L0-L4<br/>badge 徽章（按等级着色）"] P -->|"无效 / 已撤销 / 已停用"| S["❌ 未验证 / 降级<br/>badge 变红 / 拒绝签发"] end G -.-> I要点：① 注册即分配 DID（幂等校验 400/409）；② 解析返回合规 DID 文档（Ed25519 验证方法 + 信任服务端点）；③ 验证者只信任 discovery 公钥验签，不接触私钥——认证等级 L0-L4 与徽章信号随注册声明与信任状态实时计算（附件 C）。
1.6 智能体互联场景（a2a 的题中之义）
方法名中的 a2a（agent-to-agent）对应三类场景，四层标识分别支撑：
intra-instance（同实例内）：同 instance 的 agent 之间及 subagent 委派，共享同一信任根（instance controller 密钥）——身份区分与能力发现即可，信任语义同域；直接复用官方 subagent 运行期机制，本方案仅在 agent 级提供 ID 寻址。
inter-instance（跨实例）互联的三个动作（本方案跨主体信任层的主战场）：
did:agent（did:web 托管文档或 cha2a Registry）→ 验证 B 的 subject 身份、controller（instance）信任锚与认证等级（L2 来源 / L4 生态）service端点声明能力（catalog / skill 引用）；A 按 B 的认证等级决定调用/委派策略（L3/L4 可委派，L0/L1 仅只读试探）由此本方案不止服务"插件商店的信任"，也是跨实例智能体互联的信任底座——与 agent-comms（A2A/MCP 互通）、披露契约（ACD）、证据契约直接衔接（见 §3.3）。
与官方现有机制的衔接（互补，非重复）：官方 subagent（父-子委派）与 mcp-client（外部工具接入）解决运行期接入——信任来自配置与进程边界，对应 intra-instance 同域互联；本方案补的是 inter-instance 跨域身份信任层：官方授权机制（如 subagent 的 exact-live-parent 递送授权）之上，可叠加认证等级策略（L3/L4 可委派）；官方 mcp-client 接入的 MCP server 可通过本方案的
mcp_server类型验证其身份与来源（"连接的 server 是谁的、可信几级"）。两层不同域、可叠加，不冲突。1.7 调用侧身份（外部服务识别"谁在调用"）
发行侧解决了"skill 是谁发布的"；调用侧要解决"现在是谁在调用"——skill/agent 调用外部服务 API（SaaS / MCP server / 计费接口）时，外部服务需要识别调用者身份与信任等级：
方案：DID 签名调用（Caller Identity）——调用请求携带身份证明 + 请求绑定签名：
外部服务验证三步（与参考实现 verify.js 同一模式，仅需 discovery 公钥）：
关键设计：① 请求绑定签名（签名对象含方法+参数+时间戳+nonce，防篡改防重放，非裸身份声明）；② 与 API key 并存（key 管通道凭据、DID 签名管身份验证，两层叠加）；③ 链式追溯（A 委派 B 调外部服务，每跳签名，审计可回溯完整调用链）；④ 低采纳门槛（外部服务无需集成 registry，验签仅需信任 discovery 公钥，几行代码）；⑤ 直接价值（payskill 计费识别调用方、合规 API 审计、MCP server 接入方识别）。
与发行侧同源互补：发行侧 = "skill 是谁发布的、是否被改"（package/skill 指纹 + 签名）；调用侧 = "谁在调用、可信几级"（DID 身份 + 请求签名 + 认证等级）——同一 did:agent/instance 体系，方向互补。
二、解析与验证（自建节点，不排斥外部 store）
三、对齐 DSH 生态与多市场
3.1 与官方发布规范（publish.zh.md）的衔接（明确：机制 vs 信任，非开放问题）
publish.zh.md 是分发机制教程（组合包 bundle / profile 怎么打包、怎么安装、加载顺序、构建授权）；本提案是来源与信任层（谁发布的、是否被改、在哪些市场上架、可信几级）。两者分工互补，不重叠、不冲突：
dsh.bundle）pnpm pack）/github:user/repo#<sha>结论：publish.zh.md 解决"能不能装、怎么装"（机制），本提案解决"该不该装、可信几级"（信任）——skill-id 直接落在官方安装单位（bundle）上，发行方签名挂接现有分发路径，无需官方改动即可生效（纯增量）。
3.2 与官方其他文本的逐项核对
逐项核对官方现行文本（docs、README 与公开源码接口），与本提案相关的共 5 点，均无冲突、可协调：
@deepseek-ai/dsh-skill及文件提供方）SKILL.mdfrontmatter 必填 name/description（缺失则忽略该文件），是官方承认的最小身份寻址单元；frontmatter 为 open YAML，官方另有可选 metadata 字段SkillSourcedsh-plugin便于发现THIRD_PARTY_NOTICES.md）治理立场（CONTRIBUTING）：官方仓库是"展示与灵感来源，而非强制"（not a mandate，CONTRIBUTING.md）——本提案以社区讨论稿起步、走向生态共识（事实标准）的路线与之天然一致。
3.3 与生态其他部分衔接
四、标准提案附件（讨论目标，可引用/可采纳）
附件 A：标识语法（did:web 承载；语义层名 did:store/did:org/did:agent 非独立方法）
附件 B：分层签名规范
附件 C：认证等级判定
附件 D：解析与验证接口
五、开放问题（求讨论）
本提案为社区讨论稿，非官方立场；目标：形成生态共识 → 事实标准（可被多市场采纳、可被官方文档引用）。欢迎维护者、市场方、开发者共同完善。
All reactions