先理解“区块链思想”在身份认证中的位置
区块链思想用于身份认证时，核心通常是把信任关系、凭证流转和验证状态设计得更清楚，而不是简单地把个人信息写入链上。一个身份认证系统需要回答几个基本问题：谁负责声明身份，谁持有凭证，谁在验证身份，验证依据存放在哪里，以及凭证失效后如何处理。区块链或分布式账本可以作为验证材料、标识符、凭证模式或撤销状态的登记机制，但认证结果仍然取决于发行者、凭证内容、证明方式和验证者自身的业务规则。
第一步：先查可验证凭证数据模型
设计文档检索可以从“Verifiable Credentials Data Model”或“可验证凭证数据模型”开始。相关模型把系统角色拆分为发行者、持有者、主体和验证者，并描述凭证与可验证展示的基本关系。发行者对主体作出声明并生成凭证，持有者保存凭证、按需要生成展示，验证者接收并检查凭证或展示。主体可以是人，也可以是其他对象；持有者也不一定总是凭证所描述的主体。
阅读这类文档时，重点查看数据结构、证明机制、凭证有效期、验证材料、隐私要求和扩展方式。可验证意味着凭证或展示可以被验证，并不自动代表其中所有声明都是真实或符合业务要求。验证者仍需检查发行者是否可信、证明是否有效、凭证是否仍在有效期内，以及声明是否满足具体场景的政策。这个区分对设计文档很重要，能够避免把“签名有效”误写成“身份事实已经完全确认”。
第二步：用数字身份指南补齐认证环节
可验证凭证模型主要帮助理解凭证如何表达和交换，身份认证设计还需要查阅数字身份指南。NIST SP 800-63 系列资料覆盖身份核验、注册、认证器、认证器管理、认证协议、联邦认证以及相关声明等主题。检索时，可以根据问题继续查看 identity proofing、authenticator、authentication protocol、federation 和 assurance 等关键词。
这类指南适合用来检查设计文档是否写清楚了用户如何完成初次身份核验、如何绑定认证器、认证器丢失后如何恢复、认证请求如何抵抗重放，以及不同认证强度对应什么业务风险。它面向数字身份服务的技术要求，使用时应结合目标组织、监管环境和具体系统范围，不能直接当作所有场景的唯一实现方案。
第三步：按设计文档的章节反向检索
如果搜索“身份认证设计文档”得到的结果过于宽泛，可以把问题拆成几个文档主题。数据模型部分检索 credential schema、claims、verifiable presentation；密码与证明部分检索 digital signature、verification method、key management；生命周期部分检索 expiration、status、revocation；认证流程部分检索 identity proofing、authenticator enrollment、authentication protocol；隐私部分检索 selective disclosure、data minimization 和 correlation。
查到文档后，先确认其发布机构、文档类型、适用范围和版本状态，再阅读目录、术语、概念模型、要求章节和安全隐私章节。标准、建议、草案、实现指南和项目说明承担的作用不同。设计文档应记录采用某项规范的具体章节、适用条件和未覆盖内容，避免只列出链接而没有说明实际采用了哪些要求。
区块链系统需要特别核对的设计问题
身份认证系统采用区块链或分布式账本时，应重点检查上链数据是否必要。个人姓名、证件号码、生物特征和详细属性通常涉及隐私，设计时应优先考虑链下保存、链上登记证明材料或状态信息的方式。还要明确链上标识符与现实身份之间由谁建立关联，以及这种关联是否会造成跨场景追踪。
文档还应说明密钥轮换、密钥泄露、凭证撤销、状态更新和离线验证等情况。若验证依赖某个登记系统，必须写清楚验证者在无法访问登记系统时能确认什么、不能确认什么。区块链的不可篡改特性只能帮助保存某些记录的完整性，不能自动解决错误发行、身份冒用、密钥丢失或发行者失信等问题。
常见问题
问：应该先看区块链白皮书，还是先看身份认证标准？答：如果目标是写身份认证设计文档，建议先明确角色、凭证和认证流程，再用区块链资料补充共识、登记和状态管理部分。这样可以避免把账本机制误当成认证协议。
问：有数字签名就能证明一个人是真实身份吗？答：数字签名可以帮助验证某份数据是否由相应密钥签署、内容是否被篡改，但还需要确认签发者身份、密钥绑定关系、凭证状态和业务规则。
问：怎样判断一份设计文档是否完整？答：至少检查角色定义、信任边界、身份核验、认证器生命周期、凭证格式、验证流程、密钥管理、撤销或状态处理、隐私保护、错误恢复和审计要求是否相互一致。