去中心化标识符（DID）

DID 要解决的问题

传统标识符都依赖某个中央权威机构：

• email@company.com —— 由公司控制；如果你离职，就会失去它
• @username —— 由平台控制；如果账号被封，它就没了
• API key abc123 —— 由服务提供商签发，也可以被吊销

当 AI 智能体需要跨组织边界运作时，谁来签发它们的身份？ 如果 A 银行的智能体要与 B 银行的系统对话，B 银行不会信任由 A 银行控制的标识符——反之亦然。

**去中心化标识符（DID）**解决了这个问题：一种密钥由持有者本人掌控、而非由中央权威机构掌控的密码学标识符。

---

什么是 DID？

DID 是一个全局唯一的标识符，形式如下：

did:webvh:example.com:agent-42

拆解开来：

• did: —— 表明这是一个 DID
• webvh —— DID 方法（决定其解析方式）
• example.com:agent-42 —— 特定于该方法的标识符

关键属性：

1. 自我拥有 —— 你自己生成 DID 并持有私钥
2. 可验证 —— 任何人都能通过密码学方式验证你确实控制它
3. 可解析 —— DID 可解析为一个包含公钥和服务端点的 DID 文档
4. 持久性 —— 只要你持有密钥，无论使用哪个服务，它都能正常工作

---

DID 的工作原理

1. 创建 DID

// 生成密钥对
const keyPair = await generateKeyPair('Ed25519')

// 创建 DID（方法: webvh）
const did = `did:webvh:yourcompany.com:agent-${uuid()}`

// DID 文档（存储在一个公开可知的位置）
const didDocument = {
  "@context": "https://www.w3.org/ns/did/v1",
  "id": did,
  "verificationMethod": [{
    "id": `${did}#key-1`,
    "type": "Ed25519VerificationKey2020",
    "controller": did,
    "publicKeyMultibase": keyPair.publicKey
  }]
}

2. 解析 DID

任何人都可以解析 DID，获取其对应的 DID 文档：

// 解析器获取 DID 文档
const didDoc = await resolve('did:webvh:yourcompany.com:agent-42')

// 返回公钥、服务端点等信息
console.log(didDoc.verificationMethod[0].publicKeyMultibase)

3. 证明控制权

要证明你控制某个 DID，需要用你的私钥对一个挑战值（challenge）进行签名：

// 验证者发送挑战值
const challenge = 'prove-you-control-this-DID'

// 你用私钥对其签名
const signature = await sign(challenge, privateKey)

// 验证者根据你 DID 中的公钥校验签名
const isValid = await verify(signature, challenge, didDoc.verificationMethod[0].publicKeyMultibase)
// → true

---

DID 方法：did:webvh

DID 方法有很多种（web、key、ion、ethr 等）。Affinidi 主要使用 did:webvh（Web 可验证历史）：

为什么选择 did:webvh？

• 基于 Web —— 通过 HTTPS 解析，无需区块链
• 可验证历史 —— 在防篡改日志中追踪密钥轮换
• 可回溯——你可以解析出 DID 在历史任意时间点的状态
• 安全的密钥轮换 —— 若密钥泄露，可轮换为新密钥而不会丢失该 DID

工作原理：

1. DID 文档存储在 https://yourcompany.com/.well-known/did.json
2. 每次更新都会创建一条新的、带版本控制的记录
3. 哈希链确保历史记录不可被篡改重写
4. 即使密钥轮换后，旧签名依然可验证

示例：

did:webvh:affinidi.com:agent-gateway
→ 解析为 https://affinidi.com/.well-known/did.json
→ 返回包含当前公钥 + 版本历史的 DID 文档

---

DID 与传统标识符对比

维度	传统方式（例如 API 密钥）	去中心化标识符（DID）
所有权	由服务提供商控制	由你控制（私钥）
可移植性	绑定单一服务	可在任何支持 DID 的系统中使用
吊销	提供商可随时吊销	只有你能吊销（或轮换密钥）
验证	需要提供商确认	任何人都可通过密码学方式验证
跨组织信任	需要联合/SSO	原生支持——无需共享基础设施

---

真实应用场景

1. AI 智能体身份

问题： 智能体共享服务账户，日志只会显示”账户执行了操作”，而不是”哪个智能体执行了操作”。

解决方案： 每个智能体获得一个 DID。每次操作都用该智能体的私钥签名 → 审计追踪能显示是哪个智能体执行的。

const agent = {
  did: 'did:webvh:company.com:agent-42',
  privateKey: '...'
}

// 智能体为每个请求签名
const request = { action: 'access-PHI', patient: '12345' }
const signature = await sign(request, agent.privateKey)

// 日志记录: 智能体 Agent-42（DID + 签名）访问了 PHI

2. 跨组织智能体信任

问题： A 银行的智能体与 B 银行的系统对话——B 银行如何信任它？

解决方案： 智能体携带 DID + 签名过的 Mandate。B 银行验证 DID 签名并检查授权情况。

// A 银行的智能体
const agentDID = 'did:webvh:bankA.com:trading-agent-5'

// Mandate（由 A 银行签名）
const mandate = {
  agent: agentDID,
  authorizedBy: 'did:webvh:bankA.com:trader-alice',
  permissions: ['execute-trades'],
  expiry: '2026-12-31'
}

// B 银行验证:
// 1. 智能体的 DID 签名是否有效
// 2. A 银行对 Mandate 的签名是否有效
// 3. 智能体是否仍获授权 (检查信任注册表)

3. 按智能体归因

问题： 事件响应——“是哪个智能体修改了生产环境？”

解决方案： 每个智能体都有一个 DID，每次变更都记录 DID + 签名。

// 审计日志条目
{
  timestamp: '2026-07-21T19:15:00Z',
  action: 'modify-config',
  actor: 'did:webvh:company.com:agent-99',
  signature: '...',
  authorizer: 'did:webvh:company.com:engineer-bob'
}

// 即时归因——无需侦探式排查

---

Affinidi 技术栈中的 DID

Agent Gateway 为每个智能体签发 DID：

// 智能体入驻
const newAgent = await agentGateway.createAgent({
  name: 'Trading Agent 5',
  authorizedBy: 'trader-alice@bankA.com'
})

// 返回:
{
  did: 'did:webvh:bankA.com:agent-5',
  keyPair: { public, private },
  didDocument: { ... }
}

信任注册表 存储与 DID 关联的授权策略：

// 查询: 该 DID 是否获得授权？
const isAuthorized = await trustRegistry.query({
  agent: 'did:webvh:bankA.com:agent-5',
  action: 'execute-trades',
  resource: 'AAPL'
})
// → { authorized: true, authorizedBy: 'did:webvh:bankA.com:trader-alice' }

Elements Services 向 DID 签发可验证凭证：

// 签发一份 Mandate 凭证
const mandate = await elements.issueCredential({
  holder: 'did:webvh:bankA.com:agent-5',
  type: 'TradingMandate',
  claims: {
    authorizedBy: 'trader-alice',
    permissions: ['execute-trades'],
    expiry: '2026-12-31'
  }
})

---

快速上手

面向开发者

创建一个 DID：

npm install @affinidi/affinidi-tdk

import { DID } from '@affinidi/affinidi-tdk'

const did = await DID.create({
  method: 'webvh',
  domain: 'yourcompany.com'
})

console.log(did.id) // did:webvh:yourcompany.com:...
console.log(did.keyPair) // { public, private }

解析一个 DID：

const didDoc = await DID.resolve('did:webvh:affinidi.com:agent-gateway')
console.log(didDoc.verificationMethod)

面向架构师

何时应使用 DID：

• ✅ 智能体需要跨组织边界运作
• ✅ 审计追踪需要以密码学方式证明身份
• ✅ 避免共享凭据/服务账户
• ✅ 需要在密钥轮换后依然存续的长期智能体身份

何时不应使用 DID：

• ❌ 内部人类认证（使用 SSO/OIDC）
• ❌ 短生命周期的临时进程
• ❌ 密码学验证显得大材小用的系统

---

延伸阅读

W3C 规范：

• 去中心化标识符（DID）v1.0
• DID 方法: webvh

Affinidi 文档：

• Agent Gateway: DID 签发
• 信任注册表: DID 授权

相关深度解析：

• 可验证凭证 —— 签发给 DID 的密码学声明
• DIDComm 消息传递 —— 使用 DID 实现的加密智能体间通信

相关解决方案：

• 跨组织智能体信任 —— DID 让跨边界信任成为可能
• 按智能体归因 —— DID 让归因自动化