跳到主要内容

从密码到可携带的证明：2025 年构建者的 Web3 身份指南

· 阅读需 10 分钟
Dora Noda
Dora Noda
Software Engineer

大多数应用仍然将身份绑定到用户名、密码和中心化数据库。这种模型脆弱（泄露）、易泄漏（数据转售）且笨拙（无尽的 KYC 重复）。围绕去中心化标识符（DID）、可验证凭证（VC）和声明的新技术栈指向了不同的未来：用户携带关于自己的加密证明，只披露必要的信息——不多也不少。

本文提炼了全景，并提供了一个可以今天就交付的实用蓝图。

转变：从账户到凭证​

这套新身份栈的核心建立在两个基础性的 W3C 标准之上，彻底改变了我们处理用户数据的方式。

  • 去中心化标识符（DIDs）： 由用户自行控制的标识符，无需像域名系统那样的中心化注册表。可以把 DID 看作是永久的、自己拥有的身份地址。DID 解析为签名的 “DID 文档”，其中包含公钥和服务端点，实现安全的去中心化认证。v1.0 标准于 2022 年 7 月 19 日 成为正式的 W3C 推荐稿，标志着生态系统的重要里程碑。
  • 可验证凭证（VCs）： 一种防篡改的数字格式，用于表达诸如 “年龄超过 18 岁”、 “拥有 X 大学的文凭” 或 “已通过 KYC 检查” 等声明。VC 数据模型 2.0 于 2025 年 5 月 15 日 成为 W3C 推荐稿，为凭证的发行与验证奠定了现代化基础。

对开发者有什么变化？ 影响深远。你不再把敏感的个人可识别信息（PII）存入数据库，而是验证用户钱包提供的加密证明。得益于 选择性披露 等强大原语，你可以仅请求所需的特定信息（例如特定国家的居住权），而无需看到完整文档。

与现有登录方式的结合​

这新世界并不要求抛弃熟悉的登录体验，而是对其进行补充。

  • Passkeys / WebAuthn： 防钓鱼的首选认证方式。Passkey 是绑定到设备或生物特征（如 Face ID、指纹）的 FIDO 凭证，已在所有主流浏览器和操作系统上得到广泛支持，为你的应用或钱包提供无缝的无密码登录体验。
  • Sign‑In with Ethereum（SIWE / EIP‑4361）： 该标准让用户证明对区块链地址的控制权，并将其关联到应用会话。通过签名的一次性 nonce 消息，实现 Web2 会话与 Web3 控制的清晰桥接。

最佳实践是将两者结合使用：对主流、日常登录实现 Passkeys，在需要钱包关联的场景提供 SIWE，以完成加密原生操作的授权。

发放与校验凭证的基础设施​

要让凭证发挥作用，需要标准化的发放和呈现方式。OpenID 基金会提供了两大关键协议。

  • 发放：OpenID for Verifiable Credential Issuance（OID4VCI） 定义了受 OAuth 保护的 API，帮助将凭证从发行方（如政府机构或 KYC 提供商）导入用户的数字钱包，兼容多种凭证格式。
  • 呈现：OpenID for Verifiable Presentations（OID4VP） 标准化了应用发起 “证明请求” 与用户钱包响应的交互，可通过传统的 OAuth 重定向或现代浏览器 API 完成。

在实现时，你会遇到几种针对不同生态和使用场景设计的凭证格式：

  • W3C VC + Data Integrity Suites（JSON‑LD）： 常配合 BBS+ 加密，实现强大的选择性披露。
  • VC‑JOSE‑COSE 与 SD‑JWT VC（IETF）： 基于 JWT 与 CBOR 的生态，同样具备选择性披露能力。

幸运的是，互操作性正在快速提升。OpenID4VC High Assurance 等配置文件正帮助缩减技术选项，使跨供应商集成对开发者更友好。

DID 方法：选择合适的地址方案​

DID 本身只是标识符；“DID 方法”决定了它如何锚定到信任根。建议支持以下常见方法：

  • did:web： 通过你控制的域名实现 DID，部署极其简便，是企业、发行方以及希望利用现有 Web 基础设施作为信任锚的组织的理想选择。
  • did:pkh： 直接从区块链地址（例如以太坊地址）派生 DID，适用于已有加密钱包的用户，可将身份与链上资产关联。

经验法则： 至少支持两种方法——did:web 用于组织，did:pkh 用于个人。使用标准的 DID 解析库处理查询，并参考官方注册表评估任何新方法的安全性、持久性和治理模型。

可直接使用的构建块​

核心标准之外，还有若干工具可以增强你的身份栈。

  • ENS（以太坊名称服务）： 提供可读的名称（如 yourname.eth），可映射到区块链地址和 DID，极大提升用户体验，降低错误率，并提供简易的个人资料层。
  • 声明（Attestations）： 灵活的、可验证的 “关于任何事物的事实”，可记录在链上或链下。例如 Ethereum Attestation Service（EAS） 为构建声誉与信任图提供了坚实底座，且无需在公共账本上存储 PII。

合规风向标​

监管常被视为障碍，但在本领域却是强大的加速器。欧盟数字身份框架（eIDAS 2.0） 已于 2024 年 5 月 20 日 正式通过，作为 EU 2024/1183 法规生效，要求所有欧盟成员国为公民提供免费 EU Digital Identity Wallet（EUDI）。实施细则于 2025 年 5 月 7 日 发布，这对公共和私营部门在欧洲采用基于钱包的凭证形成了强有力的信号。

即便你不在欧盟运营，也应预期 EUDI 钱包及其底层协议将塑造全球用户期待，推动钱包普及。

2025 年可落地的设计模式​

  • 无密码优先，钱包可选： 默认使用 Passkeys 登录，安全、简洁且用户熟悉。仅在用户需要执行加密关联操作（如铸造 NFT、收款）时引入 SIWE。
  • 请求证明而非文档： 用 OID4VP 发起简洁的 VC 证明请求，替代繁琐的文件上传。例如不要求驾驶证原件，而是请求 “年龄超过 18 岁” 或 “居住国为 X”。接受支持选择性披露的凭证，如 BBS+ 或 SD‑JWT。
  • 服务器不存 PII： 当用户完成验证后，仅记录 声明 或短期验证结果，而非原始凭证本身。链上声明可提供可审计的记录——“用户 Y 于日期 D 通过发行方 Z 的 KYC”，而无需保存任何个人数据。
  • 组织使用 did:web 成为发行方： 企业、大学等已有域名的组织可使用 did:web 作为发行方标识，凭借现有的 Web 治理模型管理密钥。
  • ENS 用作昵称而非身份根基： 将 ENS 视为友好的句柄与个人资料指针，提升 UX，但真正的身份声明仍保存在凭证与声明中。

入门架构示例​

下面是一套现代化、基于凭证的身份系统蓝图：

  • 认证层
    • 默认登录： Passkeys（FIDO/WebAuthn）。
    • 加密关联会话： Sign‑In with Ethereum（SIWE）用于钱包操作。
  • 凭证层
    • 发放： 集成选定发行方的 OID4VCI 接口（如 KYC 提供商、大学）。
    • 呈现： 在 Web 或原生 App 中触发 OID4VP 证明请求，兼容 W3C VC（BBS+）和 SD‑JWT VC。
  • 解析与信任层
    • DID 解析器： 使用支持 did:web 与 did:pkh 的库，并维护可信发行方 DID 白名单，防止伪造。
  • 声明与声誉层
    • 持久记录： 需要审计的验证信号时，铸造包含哈希、发行方 DID 与时间戳的 声明，而非存储完整凭证。
  • 存储与隐私层
    • 最小化原则： 服务器端仅存储必要的元数据，全部加密并设定严格的 TTL。优先使用瞬时证明，借助零知识或选择性披露降低数据泄露风险。

UX 经验教训​

  • 先让钱包“隐形”： 对大多数用户而言，最佳钱包是他们根本不需要感知的。使用 Passkeys 完成登录，只有在业务必需时才弹出钱包交互。
  • 渐进式披露： 不要一次性请求全部信息。仅请求能解锁当前目标的最小证明。选择性披露让你无需完整文档即可验证单一事实。
  • 密钥恢复至关重要： 单设备绑定的凭证风险极大。务必从第一天就规划重新发行与跨设备迁移，这也是现代配置文件倾向采用 SD‑JWT VC 与基于声明的持有者绑定的原因。
  • 可读句柄提升体验： ENS 名称远比长串十六进制地址友好，能显著降低用户错误，即使真正的权威仍在凭证与声明中。

下季度交付路线图（务实版）​

  • 第 1‑2 周：
    • 为主登录流程加入 Passkeys。
    • 将所有加密原生操作置于 SIWE 检查之后。
  • 第 3‑6 周：
    • 试点一个简单的 “年龄或地区门禁”，使用 OID4VP 请求。
    • 接收 VC 2.0 并支持选择性披露（BBS+ 或 SD‑JWT VC）。
    • 开始为 “验证通过” 事件生成 声明，而非记录 PII。
  • 第 7‑10 周：
    • 引入合作发行方（如你的 KYC 提供商），使用 did:web 并实现 DID 白名单。
    • 在用户资料中加入 ENS 名称绑定，提升地址可读性。
  • 第 11‑12 周：
    • 对呈现与撤销流程进行威胁模型分析。加入常见失败（凭证过期、发行方不可信）监控。
    • 发布明确的 隐私声明，说明收集内容、保留时长以及用户审计方式。

快速变化的关注点​

  • 欧盟 EUDI 钱包 rollout： 实施与合规测试将极大影响全球的验证体验与能力。
  • OpenID4VC 配置文件： 发行方、钱包与验证方之间的互操作性正因新配置文件与测试套件而持续提升。
  • 选择性披露密码套件： BBS+ 与 SD‑JWT VC 的库与开发者指南正快速成熟，落地实现难度大幅下降。

构建原则​

  • 证明优先，数据后置： 先验证加密证明，再决定是否需要持久化任何信息。
  • 最小化收集： 只收集业务绝对必需的数据。
  • 去中心化信任： 通过 DID 方法与声明构建可审计的信任链。
  • 互操作优先： 采用已被广泛支持的标准与配置文件，降低供应商锁定风险。

坚持这些原则，你将在安全、合规且用户友好的数字身份领域保持竞争优势。

Share on Twitter