去中心化身份与可验证凭证

2026-08-24

去中心化身份把身份识别、凭证签发、保存和验证分开，使任何一个登录提供方都不必永久成为所有互动的唯一入口。去中心化标识符 DID 可以帮助实体证明自己控制某个标识符；可验证凭证 VC 则携带由签发者签名的声明。更准确的理解不是钱包拥有一种神奇身份，而是一条信任流程：签发者提出声明，持有者保存并展示，验证者检查证明、状态、上下文和政策。本文说明这条流程、区块链可以放在哪里，以及密钥管理、撤销、选择性披露和数据保护为什么仍然重要。

去中心化身份解释：标识符不是凭证

搜索 decentralized identity explained 时，最容易的方法是把身份拆成层。DID 可以通过 DID 方法解析到 DID 文档或相关资源；文档可以描述验证方法、服务，以及某把密钥可用于什么关系。VC 不同，它是签发者对主体作出的声明，并以验证者可以检查作者和完整性的方式封装。DID 可以标识人、组织、设备或服务，但 DID 本身不能证明年龄、学历、工作或法律身份。

这种区分可以避免一个常见的夸大。去中心化并不等于匿名、不可追踪或处于监管之外。凭证可以与现实世界的身份核验流程紧密绑定，验证者也可能仍被要求执行自己的资格、欺诈、制裁或访问规则。DID 方法本身也可以依赖中心化服务、联邦式系统、数据库、分布式账本或另一个注册表。真正的设计问题是：谁控制标识符，谁提出声明，谁可以更新相关联的密钥，以及哪一方被允许依赖这个结果。

DID、签发者、持有者与验证者的信任流程

这四个词描述的是不同的工作。签发者是提出声明并创建凭证的权威机构或组织。持有者拥有这份凭证，通常放在钱包或其他受保护的存储库里，并决定何时出示它。验证者接收凭证或可验证展示，检查保护机制、签发者、主体、有效期、状态，以及这次请求的业务目的。主体是声明所描述的那个实体。持有者与主体往往是同一个人，但家长可以持有关于孩子的凭证，组织也可以持有关于设备的凭证。

DID 文档可以帮助验证者发现与签发者或持有者相关联的公开验证材料。数据完整性证明可以把一份证明绑定到某个验证方法和一个明确声明的用途，但签名检查通过并不等同于接受其中的每一条声明。验证者仍然需要作出信任判断：这个签发者在这类声明上是否被认可，凭证模式是否合适，展示是否足够新鲜，所要求的披露是否与目的相称？NIST 把这一点描述为：把密码学验证与对声明的确认和评估分开。

VC 从身份核验到展示的生命周期

生命周期在密码学之前就已经开始。在登记或身份核验阶段，签发者决定什么证据是充分的，以及这个用例需要什么样的保证等级。随后它创建关于主体的声明，加入类型和有效期等元数据，并用兼容的机制保护这份凭证。钱包或存储库负责保护持有者手上的那份副本。展示时，持有者为某个特定验证者创建一份展示，可以使用一张凭证或一组凭证，也可以只披露其中选定的声明。

验证是一连串步骤，而不是一个绿色对勾。验证者解析文档，检查数据模型和保护机制，解析出相关的验证材料，确认证明用途和任何持有者绑定，检查凭证的有效期，并在状态机制存在或政策要求时执行一次状态检查。之后它才评估签发者和这些声明是否满足业务规则。一份凭证在密码学上可以是真实的，却仍然可能因为已过期、已撤销、由不受信任的机构签发、指向错误的主体，或者不适合本次请求的用途而失败。续期、更新、暂停、撤销以及最终的删除都是生命周期事件，而不是区块链会自动管理的属性。

密钥、DID 文档与撤销是不同控制项

私钥或密钥本身就是签名权限。公钥或其他验证方法让验证者可以检验一份证明，却不能让验证者制造出一份新的有效证明。签发者必须保护自己的签名密钥，定义每把密钥支持哪一种验证关系，持续监测是否被攻破，并准备好轮换与恢复方案。持有者同样需要安全的设备访问、备份或恢复流程，以及一种把凭证展示请求和索要钱包秘密的请求区分开来的办法。丢失密钥会影响访问；泄露私钥则可能让他人冒名顶替，直到整个生态发现并作出响应。

有三个时钟不能混为一谈。证明可以有创建时间和过期时间，凭证可以有 validFrom 与 validUntil，验证方法则可能因为密钥被攻破而被轮换、被撤销或任其过期。凭证状态是另一种信号：它可以表明凭证所代表的权限或声明已经不再当前有效。因此验证者需要检查状态机制本身以及它的新鲜度，而不只是看签名在数学上能否通过。状态列表、注册表或签发者端点可以改善运营层面的控制，但它们同样需要可用性、隐私、完整性和治理方面的保障。

选择性披露与数据最小化边界

选择性披露意味着持有者可以对分享哪些信息作出细粒度的决定。如果一个服务只需要知道某人是否超过某个门槛，完整的出生日期可能就是不必要的。展示有时可以携带一条抽象声明或一份零知识证明，而不是原始属性。另一些配置文件则使用选择性披露令牌或证明套件。确切的隐私性质取决于凭证格式、密码学套件、钱包、验证者的请求，以及重复展示之间是否可能被关联起来。

重要的边界在于，DID 和 VC 并不会自动提供隐私。一个稳定的标识符、一次重复的签名、一次状态查询、一条钱包遥测事件，或者公开账本上的一条记录，都可能造成关联。因此数据最小化要从验证者的提问开始：这个决定最少需要哪一条声明，需要多久，谁必须看到它？设计者应当避免把个人数据放进不可变的公开注册表，在受支持的场合优先使用成对的或与场景相称的标识符，减少留存，保护日志，并让用户在分享之前理解对方是谁、用途是什么。隐私是架构带来的结果，而不是贴在钱包上的一个标签。

区块链在 self sovereign identity blockchain 中的位置

搜索 self sovereign identity blockchain，容易误以为每条身份记录都必须上链。DID Core 并不要求这样做。DID 方法可以使用分布式账本、数据库、去中心化文件系统或其他可信系统来创建、解析、更新和停用标识符。区块链可以用于公开且防篡改的操作注册表、签发者信任元数据、密钥轮换事件或简短状态信息，也可以在多方不想由单一运营者控制注册表时帮助共同发现。

区块链同样带来成本和风险。公开记录可以被复制、被关联，而且很难删除；交易的可用性和治理规则会发生变化；哈希并不能证明原始数据本身是准确的；不可变的锚点也修不好一把已经被攻破的签发者密钥。稳健的设计会把个人声明和大型文档放在合适的受保护存储中，只发布注册表真正需要的最少数据，并写清楚更新、恢复、迁移和法律请求分别如何处理。自主主权式的控制，更适合被理解为一组用户与组织的能力，而不是链作出的某种承诺，让人从此独立于签发者、验证者或法律之外。

合规与实际核验清单

身份系统仍然有法律和运营上的义务。根据辖区和用例的不同，运营者可能需要合法依据、目的限定、数据最小化、留存控制、访问与更正流程、安全保障措施、事件响应、跨境传输控制，以及一个可审计的信任框架。欧洲数字身份钱包的材料强调只分享已经约定的信息，而 NIST 的身份核验指南则表明，确认、在可获得时进行的撤销检查，以及认证保证，是彼此分开的步骤。这些都是围绕一份技术凭证的治理要求，而不是 DID 或区块链可以豁免的功能。

真正做一次集成时，请问七个问题。用的是哪种 DID 方法和注册表，解析失败时怎么处理？哪个签发者在这条声明上受信任，主体是怎样完成核验的？需要哪种保护机制、密码套件、密钥关系和展示绑定？有效期、状态、轮换、密钥被攻破和恢复分别怎么检查？请求索取的数据是否超过决定所需，展示能否抵抗重放与关联？凭证、日志和状态记录存在哪里，保留多久？最后，是哪个监管机构、合同、信任列表或内部政策决定验证者能否依赖这条声明？verifiable credentials blockchain 这个说法描述的是基础设施上的可能性，而不是对真实性、隐私或合规的保证。