什么是Verifiable Credentials？它和DNS验证有什么关系？

在互联网上证明一件事是真的，从来都不是一个简单的问题。你说自己是某个大学的毕业生，对方怎么相信？你说这封邮件确实发自某个域名，接收方如何核实？为了解决这类问题，W3C推出了Verifiable Credentials（可验证凭证，简称VC）标准，而DNS验证则是在域名层面建立信任的传统方案。这两者看似属于不同领域，实际上正在越来越多地被结合起来使用，构建更完整的信任链路。本文将从概念、数据模型、验证流程和结合方式几个角度展开分析。

一、Verifiable Credentials的核心概念与数据模型

Verifiable Credentials是W3C在2022年正式发布推荐标准的一套规范，它描述的是一种防篡改的数字凭证。传统意义上的数字证书、学历证明、会员卡，都可以用VC的形式来表达。一个VC通常涉及三个角色：签发者（Issuer）、持有者（Holder）和验证者（Verifier）。签发者创建并签署凭证，持有者保存凭证并决定何时出示，验证者检查凭证的真实性和有效性。

从数据结构上看，一个VC包含几个关键部分。第一部分是凭证元数据，比如凭证类型、签发日期、过期日期和唯一标识符。第二部分是声明（Claims），也就是凭证要表达的具体内容，比如姓名、学位、成绩。第三部分是证明（proof），通常是一个数字签名，由签发者使用私钥生成。验证者拿到凭证后，用签发者的公钥验证签名，就能确认凭证没有被篡改，且确实出自该签发者。

下面是一个简化的VC JSON结构示例：

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "https://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "AlumniCredential"],
  "issuer": "https://example.edu/issuers/565049",
  "validFrom": "2020-01-01T00:00:00Z",
  "validUntil": "2027-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": "Example University"
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2023-06-01T12:00:00Z",
    "verificationMethod": "https://example.edu/issuers/565049#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3vX9...签名内容"
  }
}

这个结构里有几个值得注意的点。@context字段借鉴了JSON-LD的设计，用来明确各字段的语义，保证不同系统对同一份凭证的理解一致。credentialSubject里的id通常是一个去中心化标识符（DID），它指向凭证的主体。proof部分则是整个凭证可信的根基，任何对凭证内容的修改都会导致签名校验失败。

二、DNS验证的常见机制及其信任基础

DNS验证在互联网中已经存在了二十多年，最典型的场景是邮件验证。DKIM（DomainKeys Identified Mail）通过在邮件头中附加数字签名，并把公钥发布在域名的TXT记录中，让接收方确认邮件确实来自该域名且内容未被篡改。SPF记录则声明哪些IP地址有权以该域名发送邮件，DMARC在此基础上定义了验证失败后的处理策略。可以看到，DKIM的思路和VC非常相似：都是私钥签名加公开可查询的公钥。

DNS本身是一个分层的、可缓存的分布式系统，它的信任来自根服务器到各级权威服务器的委派链。但传统的DNS查询是明文且未签名的，容易被中间人篡改。为了解决这个问题，DNSSEC应运而生。DNSSEC使用非对称密码学对DNS记录进行签名，通过一条从根区开始的信任链，逐级验证每个区域的签名，从而保证查询结果的完整性和来源真实性。打个比方，DNSSEC相当于给整个DNS系统装上了防伪标签，任何一条记录都能追溯到根区的信任锚。

查询一个域名的TXT记录，用命令行工具就能完成，比如：

# 查询域名用于DKIM验证的公钥记录
dig TXT selector1._domainkey.ippipp.com +short

# 查询DNSSEC相关的DS记录
dig DS ippipp.com +short

这些机制的存在说明了一件事：DNS天然是一个分布式的、全球可达的公钥发布渠道。这个特性正是它能与Verifiable Credentials产生交集的关键。

三、两者如何结合：did:web与DNS锚定信任

VC的验证依赖于获取签发者的公钥，而这个公钥放在哪里，是一个架构决策。如果放在中心化的数据库里，系统就回到了传统的信任模型。DID规范定义了多种方法来发布公钥，其中did:web方法直接复用了HTTPS加域名的组合：把DID文档以JSON文件的形式托管在网站的固定路径下，例如域名ippipp.com对应的DID文档就放在https://ippipp.com/.well-known/did.json。

这种方式的好处是实现门槛极低，任何拥有域名和HTTPS证书的主体都可以立刻成为一个VC签发者，不需要部署区块链节点或专门的分布式网络。坏处则是信任根变成了域名加证书颁发机构，与传统PKI的信任模型差别不大。一些增强方案会进一步要求启用DNSSEC，并通过DANE协议把证书信息写入DNS记录，这样验证者不仅要检查HTTPS证书，还要确认证书的指纹与DNSSEC签名的记录一致，等于在PKI之外又叠加了一层DNS侧的验证。

一个简单的did:web DID文档示例如下：

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:web:ippipp.com",
  "verificationMethod": [{
    "id": "did:web:ippipp.com#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:web:ippipp.com",
    "publicKeyMultibase": "z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
  }],
  "authentication": ["did:web:ippipp.com#key-1"],
  "assertionMethod": ["did:web:ippipp.com#key-1"]
}

验证者拿到VC后，从issuer字段推导出DID，解析出对应的域名，拉取DID文档，取出assertionMethod中声明的公钥，最后校验凭证签名。整个链路的信任最终落在域名所有权上，而域名所有权又可以通过DNSSEC和域名注册商的记录来追溯。一些研究项目还在探索did:dns这类直接把DID文档存储在DNS TXT记录中的方案，进一步缩短信任链。

四、实践中的权衡与选型建议

把VC和DNS结合并不是唯一选择，实际项目中需要在几种方案之间做取舍。第一种是纯did:web路线，优点是部署快、运维简单，适合企业对内签发员工凭证、学校给毕业生发数字学历这类场景。第二种是基于DNSSEC的增强路线，适合对信任根要求较高的场景，比如政府机构或金融机构，但要求验证端具备DNSSEC校验能力，这在很多内网环境中并不总是具备。第三种是使用did:key或did:ion等方法，把公钥直接编码进DID本身或写入分布式账本，完全绕开DNS，代价是撤销机制和密钥轮换相对复杂。

从工程角度看，还有几个容易踩坑的地方需要注意。首先是缓存问题，DNS记录的TTL和DID文档的HTTP缓存会影响密钥轮换的生效时间，签发凭证时要避免在轮换窗口内使用即将废弃的密钥。其次是凭证撤销，VC规范推荐使用状态列表（Status List）机制，签发者定期发布一份位图式的撤销状态文件并签名，验证者按位查询即可，这个文件本身也可以托管在与域名绑定的固定地址上。最后是兼容性，DNS TXT记录对长度有限制，超长内容需要拆分多条记录，如果选择把DID文档放进DNS，必须处理好记录拼接和编码问题。

总体而言，Verifiable Credentials解决了凭证本身的防伪问题，DNS验证解决了公钥分发和域名归属的信任问题，两者结合可以用较低的成本搭建出一条从域名到凭证的完整信任链。对于大多数业务系统来说，从did:web起步，逐步叠加DNSSEC校验，是一条稳妥且可演进的技术路径。

Verifiable CredentialsDNS验证去中心化身份修改时间：2026-09-13 00:12:40