DID、凭证与授权怎样组成身份信任链？

Table of Contents

身份系统要依次回答：谁在控制某个标识符、谁声称此人具有什么属性、验证者为何接受该声明，以及当前操作是否被允许。这些问题相连，但不能用一张有效签名全部代替。

判断归属：AI 候选整合。 DID 和 VC 机制依据W3C 标准，资源访问原则依据NIST 摘要。

标识符控制与属性声明
#

DID 给出标识符及解析关联信息的办法；DID document 可以提供验证方法与验证关系。能完成一个认证挑战，通常证明调用者控制相应认证材料，不自动证明其现实姓名、学历或职业。DID Core 不预设必须使用区块链；具体 method 的运行和治理条件需要另查。

VC 则表达发行者对主体的声明。发行者签发，持有者保存或展示，验证者检查；持有者不总等于声明主体。验证者既要核对密码学真实性、有效期和适用状态，也要按自己的规则判断该发行者是否有资格作出此类声明。W3C 明确提醒：可验证不代表声明必然真实。

例如，能验证某组织签发的“具有资质”凭证，并不说明该组织有权认证这一资质。错误发行者产生的有效签名仍不能成为可靠业务依据。

公开综述用 Account、Authentication、Authorization、Audit 四类职责组织身份流程：建立和管理标识、证明控制、判断权限、保留必要证据。这是分析框架，不意味着所有 Web3 服务采用同一实现。

认证成功之后，资源方仍需决定允许执行何种操作、针对什么资源、持续多久。零信任原则不因请求来自内网或自有设备就自动信任；认证与授权应分开。审计记录也需受访问、保留和隐私约束，不能把“全量永久公开”当成默认正确方案。

SSI 强调持有者对标识与凭证的控制，但不取消发行者、验证者和恢复服务的角色。密钥丢失后的恢复、撤销信息怎样更新、跨应用怎样减少关联，仍是系统问题。选择性披露、不可关联展示与普通签名凭证是不同能力，必须检查采用的具体机制；DID 或 VC 的名称本身不是匿名保证。