---
title: "去中心化身份（DID）"
description: "去中心化标识符与可验证凭证实用指南：它们能证明什么、签发与出示如何运作，以及信任、隐私和恢复风险仍存在于何处。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 去中心化身份（DID）

> 仅供教育参考，不构成投资建议；投资可能产生损失。

<a id="answer"></a>

## 直接答案

去中心化身份是一种架构：主体可以跨服务使用标识符和受密码学保护的凭证，而不把某个平台账户当作身份的唯一通用来源。常见组成包括去中心化标识符（DID）、可验证凭证（VC）、钱包等持有者软件，以及规定验证者接受哪些签发者、证据和保证等级的规则。

DID 是类似 `did:example:123` 的 URI。其 DID 方法规定标识符如何创建、解析、更新和停用。解析结果可以是 DID 文档，其中包含验证方法、`authentication` 或 `assertionMethod` 等关系，以及可选的服务端点。控制相应密钥可以证明在该方法下对 DID 的控制权；它本身不能证明法定姓名、年龄、唯一性、雇佣关系或外部账户所有权。

可验证凭证承载签发者对一个或多个主体作出的声明。持有者保存凭证，并可为验证者创建可验证出示。密码学检查成功，说明受保护数据在所选证明机制下具有完整性并可确认作者。验证者仍须另行判断是否信任签发者、声明是否符合政策、凭证是否仍有效，以及出示者是否有权使用它。

因此，“去中心化”并不等于无需信任、匿名、基于区块链或没有中介。它意味着标识符、凭证、注册表、钱包和验证政策可以彼此分离，从而无需由单一登录提供商观察和控制所有关系。一套设计有多去中心化，取决于实际的签发者、DID 方法运营方、状态服务、钱包供应商、恢复管理员、治理密钥和验证者政策。

<a id="mechanism"></a>

## 运作方式

1. **定义声明和信任框架。** 明确主体、所需属性、可接受的签发者、身份核验流程、保证等级、保留政策、司法辖区和申诉路径。密码学格式无法决定大学、政府、雇主或社区是否是合适的权威。
2. **创建或取得标识符与密钥。** 签发者和持有者可以使用 DID、HTTPS URL 或其他受支持的标识符。使用 DID 时，其方法决定注册表和生命周期规则。控制者保护私钥；解析后的文档只公开用例所需的验证材料和端点。
3. **核验并绑定主体。** 签发者按政策检查证据，再把所得声明绑定到凭证主体。绑定对象可以是持有者控制的密钥、账户或其他标识符。签发者必须区分关于某人的证据与当前出示者控制某密钥的证据。
4. **签发凭证。** 签发者创建声明、有效日期、模式或类型信息及状态引用，再用受支持的证明保护凭证。在 Data Integrity 凭证中，`cryptosuite`、`verificationMethod`、`proofPurpose` 和 `proofValue` 等字段说明如何验证证明。
5. **存储并选择。** 持有者把凭证保存在本地或托管钱包软件中。钱包应解释验证者请求了什么，在凭证格式允许时仅披露必要数据，并避免在无关场景间悄然复用稳定标识符。
6. **以新鲜度和受众绑定方式出示。** 验证者发送包含自身身份、目的、随机数或挑战值及到期时间的请求。持有者返回绑定到该请求的凭证或派生出示。域和挑战值检查有助于防止截获的出示被重放给其他验证者或会话。
7. **验证密码学与政策。** 从经过认证的来源解析签发者验证材料；验证证明套件、目的、挑战值、域、日期、模式和状态，再应用业务规则。像 `verified: true` 这样的结果只是授权输入，不是准予访问的指令。
8. **运营生命周期。** 轮换受损密钥、暂停或撤销凭证、更新状态数据、提供恢复与申诉、保留所需审计证据，并公布迁移或停运计划。历史验证需要明确旧密钥、旧文档及凭证出示时点的规则。

三个主要角色是**签发者**、**持有者**和**验证者**；凭证主体可以与持有者不同。例如，家长可以持有关于孩子的凭证，公司代理人可以出示关于组织的凭证。除非凭证和协议建立了这种绑定，实现不得推断出示者就是主体。

DID 和 VC 相互独立。VC 可以使用非 DID 的签发者标识符，DID 也可以在没有任何 VC 时使用。同样，DID 方法可以采用区块链、分布式数据库、Web 域名或点对点交换。必须直接评估方法的安全与治理属性，不能从 `did:` 前缀推断。

<a id="example"></a>

## 实例

假设某服务必须确认客户至少 18 岁，但不收集出生日期。获认可的机构核验客户后，向钱包签发年龄凭证。凭证可能包含出生日期，也可能只含 `ageOver18` 声明；两种选择的披露和复用属性不同。

注册时，服务为 `merchant.example` 请求一份年满 18 岁的出示，挑战值为 `n-7f3a`，有效窗口为 5 分钟。钱包展示请求；如果凭证和证明套件支持，就派生只披露所需谓词的出示。服务检查机构的验证方法、证明、挑战值、域、时间窗口和凭证状态，再记录审计政策所需的最少结果。

这一流程减少了服务保留证件图像或完整出生日期的需要，但没有消除信任或风险。机构可能登记错人；钱包或设备可能受损；稳定的主体标识符或状态请求可能关联多次使用；服务可能索取过量数据；错误暂停可能拒绝合法访问。选择性披露缩小了出示中展示的数据范围，却不会隐藏签发者、钱包、网络和验证者可见的全部元数据。

密钥轮换展示了另一条边界。签发者替换受损密钥后，新凭证应使用新的验证方法。旧凭证能否继续验证，取决于 DID 方法历史、证明创建时间、验证者政策和凭证状态。仅从当前 DID 文档删除旧密钥，可能使合法历史检查失败，也可能掩盖创建证明时哪个密钥获得授权。

<a id="risks"></a>

## 风险与控制

- **虚假或过宽声明：** 有效签名保全签发者所说的话，却不会使声明变准确。应规定证据要求、签发者责任、保证等级、审计、到期与更正流程。
- **持有者绑定薄弱：** 如果出示未证明对预期密钥或认证器的控制，复制的凭证可能被他人使用。适当时把持有证明绑定到验证者、挑战值、目的和会话。
- **密钥与钱包受损：** 恶意软件、网络钓鱼、云钱包接管或不安全备份可能暴露凭证和签名密钥。采用抗钓鱼认证、适当的硬件保护、受损报告和范围严格的恢复。
- **恢复权力集中：** 单一恢复管理员可能成为真正的身份控制者。记录谁能替换密钥、需要什么证据、如何发现滥用，以及用户如何申诉或迁移。
- **关联：** 复用一个 DID、验证方法、签名模式、服务端点或状态查询路径，可能关联跨服务活动。采用成对标识符、域分离密钥或证明、保护隐私的状态机制和元数据测试。
- **公开个人数据：** DID 文档和账本历史可能被公开索引且难以擦除。不要把姓名、证件号、生物特征和其他个人声明放入公开 DID 文档或不可变注册表。
- **状态隐私与可用性：** 验证者每次检查状态都联系签发者，会暴露凭证使用地点；服务中断又会阻挡合法用户。优先采用保护隐私、可缓存的状态设计，并设新鲜度限制、认证更新及明确的开放失败或关闭失败行为。
- **撤销滥用：** 签发者或管理员可通过暂停凭证或更改状态数据审查持有者。限制权限、记录变更、公开理由和申诉流程，并尽可能支持替换或其他签发者。
- **解析和方法风险：** 解析器可能返回过期或恶意 DID 文档，DID 方法也可能依赖集中式基础设施或可变治理。认证解析结果，并逐方法评估最终性、更新授权、可用性、治理和版本控制。
- **语义不匹配：** 两套系统可以解析相同字段，却对声明、单位、司法辖区或保证等级作不同解释。使用稳定模式与词汇表，验证上下文和类型，并为政策语义设版本。
- **重放与验证者混淆攻击：** 未绑定随机数、受众、域、操作和到期时间的出示可以被复用或重定向。验证出示协议要求的每项绑定。
- **过度披露：** 钱包即使技术上支持选择性披露，验证者仍可能索取完整凭证。通过政策和界面设计执行数据最小化、记录用途，并防止可选字段惯性变成必填字段。
- **生态锁定：** 专有钱包、证明格式、注册表或恢复流程会使凭证无法携带。部署前测试标准符合性、导出、多钱包使用、密码敏捷性和迁移。
- **治理俘获：** 如果某供应商决定签发者、软件更新、模式和状态规则，多重签名或账本也不能保证广泛控制。逐组件标示运营权限并公布变更控制。

<a id="misconceptions"></a>

## 常见误区

- **“DID 能证明某人是谁。”** DID 标识主体并可公开验证方法；身份属性还需要额外声明、证据和信任决策。
- **“有效凭证意味着声明为真。”** 验证表明受保护数据具有预期证明且未被篡改，并不验证签发者最初的调查或判断。
- **“持有者总是凭证主体。”** 两种角色可以不同，因此用例需要时，验证者必须取得明确的主体至出示者绑定。
- **“所有内容都应上链。”** 公开不可变存储会放大隐私、关联、删除和治理风险。许多系统把凭证留在链下，只发布必要的验证或状态材料。
- **“选择性披露保证匿名。”** 已披露属性、稳定标识符、证明指纹、状态查询、时序、IP 地址和签发者日志仍可关联出示。
- **“去中心化意味着没有可信签发者或管理员。”** 信任被分散并显式化，而非消除。签发、核验、钱包分发、恢复、状态和验证者接受仍是受治理流程。
- **“一个 DID 等于一个人。”** 一个人可以控制多个 DID，DID 也可标识组织、设备、数据集、角色或其他主体。唯一性和真人性需要独立机制。
- **“钱包签名足以完成认证。”** 它在规定条件下证明密钥控制权。应用仍需抗钓鱼、新鲜度、受众绑定、授权和账户恢复规则。

<a id="related"></a>

## 相关主题

- [密码学累加器](/crypto/cryptographic-accumulator/)
- [真人证明](/crypto/proof-of-personhood/)
- [女巫攻击](/crypto/sybil-attack/)
- [钱包签名](/crypto/wallet-signature/)
- [零知识证明](/crypto/zero-knowledge-proof/)

<a id="sources"></a>

## 来源

- [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-1.0/) - W3C（访问于：2026-08-20）
- [Verifiable Credentials Data Model v2.0](https://www.w3.org/TR/vc-data-model-2.0/) - W3C（访问于：2026-08-20）
- [Verifiable Credential Data Integrity 1.0](https://www.w3.org/TR/vc-data-integrity/) - W3C（访问于：2026-08-20）
- [Bitstring Status List v1.0](https://www.w3.org/TR/vc-bitstring-status-list/) - W3C（访问于：2026-08-20）
- [NIST SP 800-63 Digital Identity Guidelines](https://pages.nist.gov/800-63-4/) - NIST（访问于：2026-08-20）

Source: https://wiki.fcontext.com/zh-cn/crypto/decentralized-identity/index.mdx