先明确DID与区块链的关系
DID通常用于表达一种可解析、可验证的去中心化标识，其背后可能关联控制者、验证材料或服务端点。区块链可以作为分布式登记设施，帮助参与者获取标识相关的公开信息，但它不是DID的唯一实现方式。把DID简单理解为“把身份写入区块链”，容易忽略身份控制、凭证签发和实际业务验证等环节。
NIST对区块链的概括强调了分布式账本、密码学和共识机制等基础特征；W3C可验证凭证模型则将签发者、持有者、验证者和数据登记设施区分开来。由此可见，链通常承担公开状态或验证材料的支撑角色，不能替代完整的身份业务和信任治理。
一、不要把上链等同于身份真实
区块链记录具有防篡改和可追溯特征，但它主要保障记录在网络规则下的一致性，并不能自动证明写入内容本身正确。例如，某个地址、声明或凭证状态被登记，并不代表现实中的姓名、学历、资质或组织关系已经得到充分核验。
在DID应用中，应分别确认几个问题：谁创建了标识，谁控制相关密钥，谁签发了凭证，凭证对应的主体是谁，以及验证者依据什么业务规则接受该声明。可验证凭证能够帮助验证签名、来源和状态，但“可验证”不等于其中所有事实天然真实，验证者仍需评估签发者、主体、凭证内容和自身政策。
二、密钥管理是最直接的安全风险
DID的控制能力通常依赖密钥。密钥丢失可能导致用户无法证明对标识的控制，密钥泄露则可能使攻击者冒充控制者签名或更新相关信息。因此，系统需要设计密钥生成、保存、备份、轮换、恢复和吊销流程，而不能只关注链上合约或数据格式。
还应明确不同密钥的用途，例如身份认证、凭证签发、状态更新和日常操作是否分离。高风险操作可采用多方授权、硬件保护或恢复机制；恢复流程也要防止因客服、管理员或单一设备被攻破而接管身份。具体方案应结合使用场景、监管要求和用户的技术能力确定。
三、隐私保护不能依赖“链上不可篡改”
区块链的持久性会放大隐私风险。公开写入的标识、关联地址、时间信息或业务状态，可能被长期保存，并被不同观察者关联分析。即使记录本身不包含姓名，稳定标识、交易轨迹和多次验证行为也可能逐步暴露主体关系。
原则上应避免把身份证件、联系方式、健康信息等个人数据直接写入公开链。链上可考虑只保存必要的公开验证材料、摘要或状态引用，敏感内容放在受控系统中，并评估删除、更正、访问控制和跨境传输要求。对验证者而言，还应尽量只索取完成业务所需的属性，必要时采用选择性披露或零知识证明等隐私增强方法。
四、链上链下边界与凭证状态要设计清楚
可验证凭证通常包含签发者对主体某些属性的声明。区块链可以作为验证材料、凭证模式、撤销登记或其他状态信息的登记设施，但凭证内容、个人数据和业务档案未必适合放在链上。设计时要明确哪些数据必须公开、哪些数据仅由持有者保存、哪些信息由验证者在业务系统中进一步核验。
撤销、过期和密钥变更尤其需要明确状态来源。验证者不能只检查签名，还应确认凭证是否仍在有效期内、是否被撤销、签发者的验证材料是否有效，以及相关格式和业务规则是否匹配。若链上状态更新依赖单一管理员或缺乏恢复路径，系统仍可能形成集中式故障点。
五、共识、性能与可用性要符合场景
不同区块链在参与者准入、共识方式、确认时间、费用、吞吐能力和故障处理上存在差异。DID系统若用于高频验证、公共服务或弱网络环境，不能只依据“去中心化”标签选型，而应评估注册、解析、状态查询和密钥恢复在实际条件下是否可用。
还应考虑网络中断、节点不可用、分叉、协议升级和数据迁移。系统需要规定在无法访问链时能否离线展示凭证、如何缓存公开验证材料、何时重新同步，以及升级后旧凭证和旧标识如何处理。技术性能不足可能直接转化为业务中断，但提高链上容量也不能替代合理的数据分层。
六、兼容性、治理和责任边界不可缺少
DID生态往往涉及多个钱包、签发机构、验证机构和登记设施。若各方对标识方法、凭证格式、签名算法、解析方式或撤销机制的理解不同，即使单个系统运行正常，也可能无法互操作。因此，项目应在早期确定数据模型、接口、算法生命周期和兼容性测试要求，并保留迁移方案。
治理方面要明确谁有权登记或更新验证材料，谁负责处理错误声明、密钥泄露和争议，谁维护解析服务，谁承担停运或协议升级后的责任。技术上的分布式不等于责任分散到无人负责；面向用户的产品仍需要清晰的支持、申诉和恢复机制。
适用条件与常见问题
区块链适合用于多个相互缺乏完全信任、又需要共享验证状态的参与方之间，且这些参与方能够接受共同的数据规则和治理安排。如果场景只有一个可信机构、数据高度敏感或必须支持严格删除，传统数据库、签名文件或受控目录可能更合适。DID方案应通过实际需求论证，而不是为了使用区块链而使用区块链。
常见问题一：DID能否保证身份不被冒用？不能。它可以提供标识控制和密码学验证机制，但仍需保护密钥，并由可信签发者和验证者执行业务核验。问题二：凭证上链后是否不可伪造？签名和状态机制可以提高篡改可检测性，但无法保证签发者声明一定真实，也不能消除密钥泄露风险。问题三：是否必须公开个人身份信息？通常不应如此，应依据最小必要原则设计链上内容和验证流程。