Sync: add identity and trust notes

2026-04-25 07:45:03 +08:00
parent fdb657965e
commit aa980f8da2
26 changed files with 2087 additions and 192 deletions
--- a/wiki/concepts/Algorithm-Agility.md
+++ b/wiki/concepts/Algorithm-Agility.md
@@ -0,0 +1,48 @@
+---
+title: "Algorithm-Agility"
+type: concept
+tags: [cryptography, post-quantum, future-proof]
+sources: [agentic-identity-trust.md]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Algorithm-Agility（算法敏捷性）是一种密码学系统设计原则——将密码学算法作为可替换参数抽象，而非硬编码选择，从而使系统能够在不破坏现有身份链的前提下完成算法升级（如从经典加密迁移到后量子加密）。
+
+## Motivation
+
+当前使用的 Ed25519/ECDSA 等经典签名算法面临量子计算威胁。当 NIST 后量子标准（ML-DSA、ML-KEM、SLH-DSA）成熟并部署时，需要确保：
+- 历史签名的身份链仍可验证
+- 无需重新颁发所有现有凭证
+- 迁移过程平滑，无需停机
+
+## Design Pattern
+
+```python
+# 差的实践：硬编码算法
+signature = ed25519.sign(private_key, payload)
+
+# 好的实践：算法作为参数
+class IdentityVerifier:
+    def verify(self, payload, signature, algorithm="Ed25519"):
+        impl = self._get_implementation(algorithm)
+        return impl.verify(self.public_key, payload, signature)
+```
+
+## Hybrid Scheme（过渡期策略）
+
+在经典算法向量子安全算法迁移期间，使用混合签名：
+```
+hybrid_signature = concat(
+    classical_signature(Ed25519, payload),
+    post_quantum_signature(ML-DSA, payload)
+)
+```
+
+## Relationships
+- [[Zero-Trust]]：Algorithm-Agility 确保 Zero-Trust 基础设施在后量子时代仍可用
+- [[Evidence-Chain]]：历史 Evidence-Chain 记录必须在新算法体系下仍可独立验证
+
+## Sources
+- [[agentic-identity-trust.md]]
--- a/wiki/concepts/Blocking.md
+++ b/wiki/concepts/Blocking.md
@@ -0,0 +1,46 @@
+---
+title: "Blocking"
+type: concept
+tags: ["identity-resolution", "performance", "algorithm", "entity-matching"]
+sources: ["identity-graph-operator"]
+last_updated: 2026-04-25
+---
+
+# Blocking（阻塞/分块）
+
+## Definition
+身份解析中的候选对筛选技术——通过预计算的 **blocking key** 将全量 O(n²) 记录对比较减少为可控规模候选集的 O(n×k) 操作，是大规模实体解析的性能关键。
+
+## Blocking Key Types
+
+| 类型 | 示例 | 适用场景 |
+|------|------|----------|
+| Email Domain | `acme.com` | 同一公司账号 |
+| Phone Prefix | `+1555` | 同一地区号码 |
+| Name Soundex | `S530` | 语音相似姓名（Williams→W452） |
+| Postal Code | `94105` | 同一地理区域 |
+| Composite | email_domain + name_soundex | 联合分块，减少假阳性 |
+
+## Workflow
+
+```
+全量记录
+    ↓
+为每条记录生成 blocking key(s)
+    ↓
+按 blocking key 分组（分块）
+    ↓
+仅对同组记录对进行 pairwise scoring
+    ↓
+跨块记录对被阻塞（不比较）
+```
+
+## Design Considerations
+- **召回率 vs 性能**：blocking key 越宽松 → 更多候选对 → 更高召回率但更慢；越严格 → 更少候选对但可能遗漏真匹配
+- **假阴性风险**：两个同实体但 blocking key 不同（如 "gmail.com" vs "googlemail.com"）会跨块遗漏
+- **假阳性成本**：同块内异实体（如同名不同人的 "John Smith"）需靠 scoring 层排除
+
+## Relationship to Related Concepts
+- [[Blocking]] 是 [[Identity Resolution]] 的性能优化组件，通过牺牲少量召回率换取大规模场景可接受的计算成本
+- [[Fuzzy-Matching]] 在 Blocking 筛选出的候选对上执行细粒度评分
+- [[Confidence-Score]] 综合 Blocking + Scoring 的结果给出最终合并决策
--- a/wiki/concepts/Confidence-Score.md
+++ b/wiki/concepts/Confidence-Score.md
@@ -0,0 +1,52 @@
+---
+title: "Confidence Score"
+type: concept
+tags: ["identity-resolution", "decision-making", "threshold", "multi-agent"]
+sources: ["identity-graph-operator"]
+last_updated: 2026-04-25
+---
+
+# Confidence Score（置信度评分）
+
+## Definition
+身份解析决策的核心度量——综合所有字段级匹配证据，通过加权求和得出的合并置信度。是决定"自动合并 / 提案审查 / 创建新实体"三类决策的分界指标。
+
+## Calculation
+
+```
+confidence = Σ(score_i × weight_i) / Σ(weight_i)
+```
+
+其中 `score_i` 是字段级 fuzzy/exact match 分数（0–1），`weight_i` 是字段可靠性权重。
+
+### 示例（来自 Identity Graph Operator 源码）
+| 字段 | 记录A值 | 记录B值 | Normalizer | Comparator | Score | Weight |
+|------|---------|---------|-----------|------------|-------|--------|
+| email | wsmith@acme.com | wsmith@acme.com | email | exact | 1.0 | 高 |
+| last_name | Smith | Smith | name | exact | 1.0 | 高 |
+| first_name | William | Bill | name | nickname | 0.82 | 中 |
+| phone | +155****0142 | +155****0142 | phone | exact | 1.0 | 高 |
+
+综合置信度 = `1.0×0.3 + 1.0×0.3 + 0.82×0.2 + 1.0×0.2` ≈ **0.96**
+
+## Decision Thresholds
+
+```
+confidence > 0.95  →  自动合并（单 Agent 高置信）
+0.60 ≤ confidence ≤ 0.95  →  提案审查（多 Agent 协作）
+confidence < 0.60  →  创建新实体
+```
+
+## Field Reliability Weights
+
+| 字段 | 权重 | 原因 |
+|------|------|------|
+| Email | 高 | 几乎唯一，变更需主动操作 |
+| Phone | 高 | 需验证，变更成本高 |
+| Name | 中 | 常见同名不同人，需结合其他字段 |
+| Address | 低 | 常见地址变更（搬家） |
+
+## Why Thresholds Matter
+- **防止假阳性**（False Merge）：将两个不同人（如同名"John Smith"）错误合并——高阈值 + 字段级证据防止
+- **防止假阴性**（Missed Match）：将同一人（如"Bill Smith"/"William Smith"）遗漏为不同实体——中等阈值触发提案审查而非直接拒绝
+- **可解释性**：per-field evidence 使决策可被其他 Agent 和人类审计
--- a/wiki/concepts/Delegation-Chain.md
+++ b/wiki/concepts/Delegation-Chain.md
@@ -0,0 +1,40 @@
+---
+title: "Delegation-Chain"
+type: concept
+tags: [authorization, delegation, multi-hop]
+sources: [agentic-identity-trust.md]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Delegation-Chain（委托链）是一种多跳授权链机制——当 Agent A 授权 Agent B 代表其行事，Agent B 可以进一步授权 Agent C，但每一跳都必须满足：签名有效 + 作用域不扩大 + 时间未过期。
+
+## Chain Structure
+
+```
+Agent A ──signs──> Agent B (scope: trade.execute)
+                       │
+                       └──signs──> Agent C (scope: trade.execute, audit.write)  ❌ scope_escalation
+```
+
+## Verification Rules
+
+每条委托链必须通过三项验证：
+1. **签名有效性**：当前 Agent 的签名必须可被其公钥验证
+2. **作用域不扩大**：本跳授权的作用域不得宽于上一跳
+3. **时间有效性**：委托链中任意节点过期，则整链失效
+
+## Fail-Closed Behavior
+
+- 委托链的任意链节断裂 → **整链无效**
+- 委托链的任意节点过期 → **整链无效**
+- 无法验证某节点签名 → **整链无效**
+
+## Relationships
+- [[Zero-Trust]]：Delegation-Chain 是 Zero-Trust 授权验证的核心机制
+- [[Fail-Closed]]：委托链验证采用 Fail-Closed 策略（任意断裂则整链失效）
+- [[Peer-Verification]]：Peer-Verification 协议在有委托时必须验证 Delegation-Chain
+
+## Sources
+- [[agentic-identity-trust.md]]
--- a/wiki/concepts/Dengbao-2.0.md
+++ b/wiki/concepts/Dengbao-2.0.md
@@ -0,0 +1,50 @@
+---
+title: "Dengbao 2.0"
+type: concept
+tags: [China, cybersecurity, compliance, ToG, government]
+sources: [government-digital-presales-consultant]
+last_updated: 2026-04-25
+---
+
+# Dengbao 2.0（网络安全等级保护）
+
+网络安全等级保护制度（Classified Protection of Cybersecurity），是中国政府强制性的网络安全合规框架，要求所有政府信息系统按照安全等级进行保护和评估。
+
+## 基本概念
+
+- **等级划分**：1级（自主保护）→ 2级（指导保护）→ 3级（监督保护）→ 4级（强制保护）→ 5级（专控保护）
+- **政府系统要求**：通常要求**等保三级**，核心系统可能要求**等保四级**
+- **强制性质**：等保不是加分项，而是**投标入围的强制性前置条件**
+
+## 等保三级核心控制域
+
+| 安全域 | 控制要求 | Proposed Measure |
+|--------|---------|-----------------|
+| 安全通信网络 | 网络架构安全 | 安全域划分、VLAN 隔离 |
+| 安全通信网络 | 传输安全 | SM4 加密传输，国密 VPN 网关 |
+| 安全边界 | 边界防护 | 下一代防火墙访问控制策略 |
+| 安全边界 | 入侵防范 | IDS/IPS 部署 |
+| 安全计算环境 | 身份鉴别 | 双因素认证，国密 CA + 动态令牌 |
+| 安全计算环境 | 数据完整性 | SM3 校验，国密中间件 |
+| 安全计算环境 | 数据备份恢复 | 本地 + 异地备份 |
+| 安全管理中心 | 集中管理 | 统一安全管理平台，SIEM/SOC |
+| 安全管理中心 | 审计管理 | 日志集中采集分析 |
+
+## 实施时间线
+
+- **关键里程碑**：系统上线前必须完成等保评估
+- **整改周期**：通常需要 **2-3 个月**进行整改
+- **评估流程**：系统建设 → 差距分析 → 整改加固 → 正式评估 → 备案
+
+## 与信创的关系
+
+等保三级与[[Xinchuang]]（信创）结合是政府项目的标准合规要求：
+- 信创适配产品（国产 CPU/OS/数据库/中间件）需提供兼容测试报告
+- 等保三级安全架构设计需在信创平台上重新验证
+- 两者共同构成政府 IT 项目投标的技术门槛
+
+## Aliases
+- 网络安全等级保护
+- 等保 2.0
+- Classified Protection of Cybersecurity
+- Wangluo Anquan Dengji Baohu
--- a/wiki/concepts/Evidence-Chain.md
+++ b/wiki/concepts/Evidence-Chain.md
@@ -0,0 +1,42 @@
+---
+title: "Evidence-Chain"
+type: concept
+tags: [audit, security, tamper-detection]
+sources: [agentic-identity-trust.md]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Evidence-Chain（证据链）是一种仅追加（append-only）、链式哈希、防篡改的操作记录系统。每个证据记录包含：意图（intent）、决策（decision）、结果（outcome），并通过哈希链指向前一记录，形成完整操作审计链。
+
+## Core Properties
+
+- **仅追加**：历史记录不可修改，只能添加新记录
+- **链式哈希**：每个记录包含前一条记录的哈希值，篡改任意记录都会破坏链的完整性
+- **独立可验证**：任何第三方可以在不信任记录系统的前提下验证链的完整性
+- **防篡改检测**：链中任意记录被修改，后续所有哈希校验将失败
+
+## Structure
+
+```python
+{
+    "agent_id": "trading-agent-prod-7a3f",
+    "action_type": "trade.execute",
+    "intent": {"symbol": "AAPL", "quantity": 100, "side": "buy"},
+    "decision": "approved: scope verified, trust score 0.94",
+    "outcome": {"filled": true, "price": 182.50, "order_id": "ord-xyz"},
+    "timestamp_utc": "2026-03-01T14:30:00Z",
+    "prev_record_hash": "0"*64,
+    "record_hash": "sha256(...)",
+    "signature": "Ed25519(agent_private_key, record_hash)"
+}
+```
+
+## Relationships
+- [[Zero-Trust]]：Evidence-Chain 是 Zero-Trust 日志完整性的核心机制
+- [[Trust-Scoring]]：Trust-Scoring 的评分依据来源于 Evidence-Chain 的可验证结果
+- [[Algorithm-Agility]]：算法升级时需要保证历史证据链的可验证性
+
+## Sources
+- [[agentic-identity-trust.md]]
--- a/wiki/concepts/Evidence-based-Merge-Proposal.md
+++ b/wiki/concepts/Evidence-based-Merge-Proposal.md
@@ -0,0 +1,49 @@
+---
+title: "Evidence-based Merge Proposal"
+type: concept
+tags: ["multi-agent", "identity", "coordination", "decision-making"]
+sources: ["identity-graph-operator"]
+last_updated: 2026-04-25
+---
+
+# Evidence-based Merge Proposal（证据驱动合并提案）
+
+## Definition
+多 Agent 身份协调中的标准提案协议——当发现两个实体应合并时，不直接执行 merge 操作，而是构造包含完整 per-field evidence 的提案，供其他 Agent 审查后再执行。
+
+## Structure
+
+```json
+{
+  "entity_a_id": "a1b2c3d4-...",
+  "entity_b_id": "e5f6g7h8-...",
+  "confidence": 0.87,
+  "evidence": {
+    "email_match": { "score": 1.0, "values": ["wsmith@acme.com", "wsmith@acme.com"] },
+    "name_match": { "score": 0.82, "values": ["William Smith", "Bill Smith"] },
+    "phone_match": { "score": 1.0, "values": ["+155****0142", "+155****0142"] },
+    "reasoning": "Same email and phone. Name differs but 'Bill' is a known nickname for 'William'."
+  }
+}
+```
+
+## When to Propose vs. Direct Merge
+
+| 场景 | 动作 | 原因 |
+|------|------|------|
+| 单 Agent，置信度 > 0.95 | 直接合并 | 无歧义，无其他 Agent 需协商 |
+| 多 Agent，置信度中等 | 提案合并 | 让其他 Agent 审查证据 |
+| Agent 不同意既有合并 | 提案拆分（含 member_ids） | 不直接撤销，由多方验证 |
+| 修正数据字段 | 带 expected_version 的直接变更 | 字段更新无需多 Agent 审查 |
+
+## Core Principles
+- **永远不带证据不合并**："These look similar" 不是证据，per-field comparison scores + confidence thresholds 才是证据
+- **提案优于断言**：提出 merge（带证据）而非直接执行，让对方 Agent 有机会审查
+- **反压不覆盖**：当 Agent 间存在冲突（一个提出 merge，另一个提出 split），不直接覆盖另一方证据，而是呈现反证据让最强证据胜出
+
+## Conflict Resolution
+当两个 Agent 对同一对实体给出矛盾提案时：
+1. 标记为 `conflict` 状态
+2. 双方添加评论讨论证据
+3. 等待人类或仲裁 Agent 最终裁决
+4. 永不通过"强行覆盖"解决冲突
--- a/wiki/concepts/Fail-Closed.md
+++ b/wiki/concepts/Fail-Closed.md
@@ -0,0 +1,36 @@
+---
+title: "Fail-Closed"
+type: concept
+tags: [authorization, security, default-deny]
+sources: [agentic-identity-trust.md]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Fail-Closed（故障关闭）是一种安全授权策略——当验证系统无法完成验证时，默认结果为**拒绝**，而非**允许**。这是 Zero-Trust 架构的必然推论。
+
+## Fail-Closed Rules
+
+| 验证失败场景 | 默认行为 |
+|------------|---------|
+| 身份无法验证 | 拒绝操作 |
+| 委托链存在断裂 | 拒绝操作 |
+| 证据无法写入 | 拒绝操作 |
+| 信任评分低于阈值 | 要求重新验证，拒绝操作 |
+| 凭证已过期 | 拒绝操作 |
+
+## vs. Fail-Open
+
+| 策略 | 无法验证时的行为 | 适用场景 |
+|------|----------------|---------|
+| **Fail-Closed**（本文档） | 拒绝操作 | 高风险操作（金融交易、基础设施部署、物理控制） |
+| **Fail-Open** | 允许操作 | 低风险操作（读操作、内部服务调用） |
+
+## Relationships
+- [[Zero-Trust]]：Fail-Closed 是 Zero-Trust 默认不信任原则的具体化
+- [[Delegation-Chain]]：委托链验证采用 Fail-Closed 策略
+- [[Peer-Verification]]：Peer 验证的所有检查均采用 Fail-Closed
+
+## Sources
+- [[agentic-identity-trust.md]]
--- a/wiki/concepts/Fuzzy-Matching.md
+++ b/wiki/concepts/Fuzzy-Matching.md
@@ -0,0 +1,57 @@
+---
+title: "Fuzzy Matching"
+type: concept
+tags: ["identity-resolution", "string-similarity", "normalization", "entity-matching"]
+sources: ["identity-graph-operator"]
+last_updated: 2026-04-25
+---
+
+# Fuzzy Matching（模糊匹配）
+
+## Definition
+处理"相同实体但文本表达不同"记录的能力——通过规范化（Normalization）和相似度算法，将表面不同的记录识别为同一实体。是身份解析的核心挑战之一。
+
+## Core Techniques
+
+### 1. Nickname Normalization
+```python
+nicknames = {
+    "bill": "william", "bob": "robert", "jim": "james",
+    "mike": "michael", "dave": "david", "joe": "joseph",
+    "tom": "thomas", "dick": "richard", "jack": "john",
+}
+# "Bill Smith" → "william smith"
+```
+
+### 2. String Similarity
+| 算法 | 适用场景 |
+|------|----------|
+| Levenshtein Distance | 字符级编辑距离 |
+| Jaro-Winkler | 人名高权重前缀匹配 |
+| Soundex / Metaphone | 语音相似性（"Jon" = "John"） |
+| Token-based（TF-IDF） | 多词短语 |
+
+### 3. Field-specific Normalization
+| 字段类型 | 规范化规则 |
+|----------|------------|
+| Email | `lower().strip()` |
+| Phone | `re.sub(r"[^\d+]", "", value)` → E.164 格式 |
+| Name | Nickname expansion + lowercase |
+| Address | Street abbreviation（St→Street）、directionals（NE→Northeast） |
+
+## Example
+```
+记录A: "Bill Smith", wsmith@acme.com, +1-555-0142
+记录B: "William Smith", wsmith@acme.com, +15550142
+        ↓ Normalize + Score
+Email:     1.0（exact match）
+Name:      0.82（Bill→William nickname expansion）
+Phone:     1.0（E.164 normalized）
+────────────────────────────────
+Total:     0.94 confidence → 触发自动 merge（> 0.95 阈值接近）
+```
+
+## Relationship to Related Concepts
+- [[Fuzzy-Matching]] 是 [[Identity-Resolution]] scoring 层的核心技术
+- [[Blocking]] 筛选候选对后，[[Fuzzy-Matching]] 执行细粒度字段比较
+- [[Confidence-Score]] 综合所有字段的 fuzzy match scores 得出最终决策
--- a/wiki/concepts/Identity-Resolution.md
+++ b/wiki/concepts/Identity-Resolution.md
@@ -0,0 +1,43 @@
+---
+title: "Identity Resolution"
+type: concept
+tags: ["identity", "entity-resolution", "multi-agent", "data-matching"]
+sources: ["identity-graph-operator"]
+last_updated: 2026-04-25
+---
+
+# Identity Resolution（身份解析）
+
+## Definition
+将来自不同来源的多条记录归一化为同一 **canonical entity_id** 的过程——确保同一个真实世界实体（人/公司/产品）在系统中只对应一个唯一标识符，所有 Agent 共享这一规范视图。
+
+## Core Workflow
+
+```
+原始记录 → 规范化(Normalize) → 阻塞(Blocking) → 评分(Scoring) → 聚类(Clustering) → Canonical Entity
+```
+
+1. **规范化**：邮箱小写、电话 E.164 格式、昵称扩展（Bill→William）
+2. **阻塞**：用 blocking key（email domain / phone prefix / name soundex）快速筛选候选对，避免 O(n²) 全图扫描
+3. **评分**：字段级加权相似度（email exact match = 1.0，name fuzzy = 0.82）
+4. **聚类**：高置信度候选归入同一 cluster，生成 canonical entity_id
+
+## Key Properties
+- **确定性**：相同输入必须返回相同 entity_id（由 Identity Graph Operator 强制执行）
+- **证据驱动**：每条合并决策必须有 per-field evidence，拒绝"看起来相似"断言
+- **并发安全**：通过乐观锁（version field）防止并发写入冲突
+- **可审计**：完整事件历史（entity.created / merged / split / updated）
+
+## Confidence Thresholds
+| 置信度 | 操作 |
+|--------|------|
+| > 0.95 | 直接合并（单 Agent 高置信） |
+| 0.60–0.95 | 提案审查（多 Agent 协作） |
+| < 0.60 | 创建新实体 |
+
+## Relationship to Related Concepts
+- [[Identity Resolution]] ⊂ [[Master-Data-Management]]（MDM）：身份解析是 MDM 在多 Agent 系统中的分布式实现，增加了并发协调维度
+- [[Identity Resolution]] 应用层：[[Personal CRM]] 联系人去重、[[Identity-Graph-Operator]] 企业级多 Agent 协调
+
+## Related Agents
+- [[identity-graph-operator]]：Identity Resolution 能力在多 Agent 系统中的 Agent 化封装
--- a/wiki/concepts/Miping.md
+++ b/wiki/concepts/Miping.md
@@ -0,0 +1,54 @@
+---
+title: "Miping"
+type: concept
+tags: [China, cryptography, compliance, ToG, government, SM2, SM3, SM4]
+sources: [government-digital-presales-consultant]
+last_updated: 2026-04-25
+---
+
+# Miping（商用密码应用安全性评估）
+
+商用密码应用安全性评估（Commercial Cryptographic Application Security Assessment），是中国政府对涉及密码使用的信息系统进行强制性安全评估的合规制度。
+
+## 基本概念
+
+- **全称**：商用密码应用安全性评估
+- **拼音缩写**：密评（Mìpíng）
+- **主管机构**：国家密码管理局
+- **强制性质**：政府系统涉及密码应用的上线**前置条件**，验收必须提供密评报告
+
+## 强制使用场景
+
+涉及以下场景的政府系统**必须使用国密算法**：
+1. **身份认证**：用户身份鉴别、单点登录
+2. **数据传输**：系统间 API 通信、数据同步
+3. **数据存储**：敏感数据加密存储
+4. **电子签章**：电子印章、CA 证书
+
+## 国密算法体系
+
+| 算法类型 | 算法名称 | 用途 |
+|---------|---------|------|
+| 非对称加密 | SM2 | 密钥交换、数字签名 |
+| 哈希算法 | SM3 | 数据完整性校验 |
+| 对称加密 | SM4 | 数据加密传输和存储 |
+
+## 密评要求
+
+- 电子印章和 CA 证书必须使用**国密证书**
+- 密码产品必须通过国家密码管理局审批
+- 密评报告是系统验收的**必要文件**
+
+## 与等保的关系
+
+- [[Dengbao-2.0]]（等保）和 Miping 是政府 IT 系统的两项**并列合规要求**
+- 等保关注整体安全架构，Miping 专注于密码应用正确性
+- 两者在投标时通常作为独立章节分别论述
+
+## Aliases
+- 商用密码应用安全性评估
+- 密评
+- Shangmi Yingyong Anquan Xing Pinggu
+- Commercial Cryptographic Application Security Assessment
+- 国密算法（SM2/SM3/SM4）
+- Guomi Algorithms
--- a/wiki/concepts/Peer-Verification.md
+++ b/wiki/concepts/Peer-Verification.md
@@ -0,0 +1,58 @@
+---
+title: "Peer-Verification"
+type: concept
+tags: [verification, authentication, protocol]
+sources: [agentic-identity-trust.md]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Peer-Verification（对等验证）是一种 Agent 间在接受委托工作前互相验证身份和授权的安全协议。在 Agent 接受来自其他 Agent 的工作请求前，必须完成五项独立验证——全部通过才接受工作。
+
+## Verification Checks
+
+```python
+checks = {
+    "identity_valid":         # 1. 密码学身份证明是否有效
+    "credential_current":     # 2. 凭证是否在有效期内
+    "scope_sufficient":       # 3. 授权范围是否覆盖请求的操作
+    "trust_above_threshold":  # 4. 信任评分是否 ≥ 0.5
+    "delegation_chain_valid": # 5. 委托链是否完整（如涉及委托）
+}
+# 全部通过才接受工作（Fail-Closed）
+```
+
+## Protocol Flow
+
+```
+Agent A                     Agent B
+   │                           │
+   │──── request_work ─────────>│
+   │                           │
+   │<--- identity_proof -------│ (Agent B 提供公钥 + 签名)
+   │<--- credential -----------│ (Agent B 提供凭证 + 过期时间)
+   │<--- delegation_chain -----│ (如为委托工作)
+   │                           │
+   │ 验证身份 → 验证凭证 → 验证作用域 → 验证信任分 → 验证委托链
+   │                           │
+   │<--- verification_result --│
+   │                           │
+   if all_passed:
+       Agent A 接受 Agent B 的工作
+   else:
+       Agent A 拒绝 Agent B 的工作
+```
+
+## Performance Requirement
+
+- **P99 延迟 < 50ms**：验证过程不得成为系统性能瓶颈
+
+## Relationships
+- [[Zero-Trust]]：Peer-Verification 是 Zero-Trust 在 Agent 间交互中的实现
+- [[Trust-Scoring]]：Trust-Scoring 提供 Peer-Verification 的决策依据
+- [[Delegation-Chain]]：当 Agent 间存在委托关系时，Peer-Verification 必须验证 Delegation-Chain
+- [[Fail-Closed]]：所有检查项均采用 Fail-Closed 策略
+
+## Sources
+- [[agentic-identity-trust.md]]
--- a/wiki/concepts/Trust-Scoring.md
+++ b/wiki/concepts/Trust-Scoring.md
@@ -0,0 +1,54 @@
+---
+title: "Trust-Scoring"
+type: concept
+tags: [trust, scoring, agent-reliability]
+sources: [agentic-identity-trust.md]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Trust-Scoring 是一种基于**可验证结果**的惩罚型信任量化模型。Agent 从初始分数 1.0 开始，仅通过可客观验证的问题进行扣分；Agent 不得自我报告信号来提高信任分。
+
+## Scoring Model
+
+```python
+score = 1.0
+
+# 证据链损坏（最高惩罚）
+if not check_chain_integrity(agent_id):
+    score -= 0.5
+
+# 结果验证（失败率 × 0.4）
+outcomes = get_verified_outcomes(agent_id)
+if outcomes.total > 0:
+    failure_rate = 1.0 - (outcomes.achieved / outcomes.total)
+    score -= failure_rate * 0.4
+
+# 凭证新鲜度
+if credential_age_days(agent_id) > 90:
+    score -= 0.1
+```
+
+## Trust Levels
+
+| 分数区间 | 信任等级 | 说明 |
+|---------|---------|------|
+| ≥ 0.9 | HIGH | 完全可信任，可执行高风险操作 |
+| ≥ 0.5 | MODERATE | 有限信任，需额外验证 |
+| > 0.0 | LOW | 高度谨慎，需全面验证 |
+| 0.0 | NONE | 不可信，拒绝所有操作请求 |
+
+## Key Properties
+
+- **无自我报告**：Agent 不能声称自己是可信的——信任来自客观可验证的证据
+- **信任衰减**：长期未活动的 Agent 或过期凭证自动降低信任分
+- **证据驱动**：评分基于 [[Evidence-Chain]] 中的实际执行结果，而非声誉或声明
+
+## Relationships
+- [[Zero-Trust]]：Trust-Scoring 是 Zero-Trust 可量化验证的实现
+- [[Evidence-Chain]]：Trust-Scoring 的评分依据来源
+- [[Peer-Verification]]：Peer-Verification 协议使用 Trust-Scoring 作为决策依据之一
+
+## Sources
+- [[agentic-identity-trust.md]]
--- a/wiki/concepts/Xinchuang.md
+++ b/wiki/concepts/Xinchuang.md
@@ -0,0 +1,65 @@
+---
+title: "Xinchuang"
+type: concept
+tags: [China, domestic-IT, localization, ToG, government, Kunpeng, Phytium, UOS]
+sources: [government-digital-presales-consultant]
+last_updated: 2026-04-25
+---
+
+# Xinchuang（信息技术应用创新）
+
+信息技术应用创新（Xìnxì Jìshù Yìngyòng Chuàngxīn），是中国政府推动的 IT 基础设施国产化替代战略，旨在用国产技术和产品替代国外产品，确保关键信息系统的自主可控。
+
+## 全称
+
+- **中文**：信息技术应用创新
+- **拼音**：Xinchuang / Xìnchuàng
+- **英文**：Innovation in Information Technology
+
+## 核心替代领域
+
+| 层级 | 国外产品 | 国产替代 |
+|-----|---------|---------|
+| CPU 芯片 | Intel Xeon / AMD EPYC | 鲲鹏（Kunpeng 920）/ 飞腾（Phytium S2500）/ 海光 / 龙芯 |
+| 操作系统 | Windows Server / CentOS | 统信 UOS / 银河麒麟（Kylin） |
+| 数据库 | Oracle / MySQL / PostgreSQL | 达梦（DM）/ 人大金仓（KingbaseES）/ GaussDB |
+| 中间件 | Tomcat / JBoss / WebLogic | 东方通（TongWeb）/ 宝兰德（BES） |
+| 办公软件 | MS Office | WPS Office / 永中 Office |
+
+## 适配策略
+
+- **优先采用目录内产品**：选择进入信创产品目录的主流产品
+- **兼容性测试矩阵**：建立完整的产品兼容测试矩阵（CPU×OS×数据库×中间件）
+- **分阶段替代**：并非所有组件都需要立即替代，分阶段替代是被接受的
+- **信创适配认证**：需提供适配认证报告和兼容性测试证明
+
+## 信创适配检查清单
+
+| 层级 | 组件 | 当前产品 | 信创替代方案 | 兼容性测试 | 优先级 |
+|-----|-----|---------|------------|-----------|-------|
+| Chip | CPU | Intel Xeon | Kunpeng 920 / Phytium S2500 | | P0 |
+| OS | 服务器 OS | CentOS 7 | UnionTech UOS V20 / Kylin V10 | | P0 |
+| Database | RDBMS | MySQL / Oracle | DM8 / KingbaseES | | P0 |
+| Middleware | 应用服务器 | Tomcat | TongWeb / BES | | P1 |
+| Middleware | 消息队列 | RabbitMQ | 国产替代方案 | | P2 |
+| Office | 办公套件 | MS Office | WPS / Yozo Office | | P1 |
+
+## 实施原则
+
+1. **不是加分项，而是必选项**：信创是政府 IT 项目的强制性要求
+2. **不是一步到位**：允许分阶段实施，优先替换核心组件
+3. **必须提供测试报告**：兼容性测试报告是投标文件的必要附件
+4. **与等保协同**：信创平台需重新进行 [[Dengbao-2.0]] 安全架构验证
+
+## Aliases
+- 信创
+- 信息技术应用创新
+- Xinchuang
+- Xìnchuàng
+- 国产化替代
+- Domestic IT Substitution
+- IT Localization
+- Kunpeng（鲲鹏）
+- Phytium（飞腾）
+- UnionTech UOS（统信 UOS）
+- DM Database（达梦数据库）
--- a/wiki/concepts/Zero-Trust.md
+++ b/wiki/concepts/Zero-Trust.md
@@ -0,0 +1,35 @@
+---
+title: "Zero-Trust"
+type: concept
+tags: [security, identity, authorization]
+sources: [agentic-identity-trust.md]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Zero-Trust 是一种安全架构范式——**永不信任，必须验证**（Never Trust, Always Verify）。在多 Agent 系统中，该原则要求每个 Agent 在执行操作前必须提供密码学可验证的身份证明，而非依赖自我声明。
+
+## Core Principles
+
+- **身份与授权分离**：证明"我是谁"（身份验证）与证明"我被允许做这个"（授权验证）是两个独立步骤。
+- **最小权限原则**：Agent 仅被授予完成特定任务所需的最小权限范围。
+- **假设已失陷**：设计时假设网络中至少有一个 Agent 已失陷或被错误配置。
+- **显式验证**：每次交互都必须进行验证，不能依赖先前交互的信任状态。
+
+## Application in Multi-Agent Systems
+
+| 层面 | Zero-Trust 要求 |
+|------|----------------|
+| 身份验证 | Agent 必须提供密码学签名证明，而非声称身份 |
+| 授权验证 | 必须提供可验证的委托链，而非声称"我被授权了" |
+| 日志完整性 | 日志写入者不得同时具备修改日志的能力 |
+| 跨框架互操作 | 每个框架的信任模型必须可被其他框架独立验证 |
+
+## Relationships
+- [[Evidence-Chain]]：Zero-Trust 日志层的实现机制
+- [[Trust-Scoring]]：Zero-Trust 信任评估的量化手段
+- [[Fail-Closed]]：Zero-Trust 失败时的默认行为
+
+## Sources
+- [[agentic-identity-trust.md]]