可验证凭证置信方法 v1.0

在出示可验证凭证期间提高置信度

W3C 工作草案

关于本文档的更多详细信息
此版本:
https://www.w3.org/TR/2026/WD-vc-confidence-method-20260910/
最新发布版本:
https://www.w3.org/TR/vc-confidence-method/
最新编辑草案:
https://w3c.github.io/vc-confidence-method/
历史:
https://www.w3.org/standards/history/vc-confidence-method/
提交历史
编辑:
Joe Andrieu (Legendary Requirements)
Denken Chen (台湾数位发展部)
反馈:
GitHub w3c/vc-confidence-method (拉取请求, 新建议题, 开放议题)
相关文档
可验证凭证数据模型 v2.0

摘要

本规范定义了可与 可验证凭证数据模型 v2.0 一起使用的机制,以 提高验证者对于 可验证凭证的出示者实际上 与其使用具有适当关系的置信度。在最简单的 情况下,这意味着出示者是该凭证最初的合法 接收者。本规范定义了用于在 可验证 凭证中表达置信方法和证据的数据 模型,并提供了如何使用 它的示例。

本文档的状态

本节描述本文档 发布时的状态。当前 W3C 出版物的列表以及本技术报告的最新修订版可以在 W3C 标准与草案 索引中找到。

这是一份实验性规范,正在进行定期 修订。它 不适合部署到生产环境中。

本文档由可验证凭证工作 组使用 推荐标准 轨道作为 工作草案发布。

作为 工作草案发布并不意味着 W3C 及其成员认可本文档。

这是一份草案文档,可能随时由其他 文档更新、替换或废止。除作为正在进行的工作外, 不宜引用本文档。

本文档由一个依据 W3C 专利 政策运作的工作组编制。 W3C 维护了一份 所有公开的专利披露列表, 这些披露与该工作组的交付成果 有关;该页面还包含 披露专利的说明。任何实际 知晓某项专利并认为该专利包含 必要权利要求 的个人,都必须按照 W3C 专利政策第 6 节披露相关信息。

本文档受 2025年8月18日 W3C 流程文档约束。

1. 简介

本节为非规范性内容。

本规范定义了验证者可用于 提高其对于可验证凭证或可验证出示中或其自身的某个 属性值准确性的置信度的机制。

特别是,确定当前出示者是某个 主体 (该主体属于某个可验证凭证)是 验证者关注的一个关键 问题。

为此,本规范定义了两种可扩展机制, 发行者 可以使用这些机制来帮助验证者提高其对于 给定可验证凭证的出示是合法的置信度。

confidenceMethod 属性使发行者能够提供 特定的 技术,以提高对于候选方 是 VC 中某个主体的置信度。例如,提高 对于结婚证的出示者是其中某一方的 置信度:主婚人、配偶之一或 证人之一。

confidenceMethod 属性可用于指定一种 特定的生物特征、密码学密钥或其他机制, 出示者可以使用它来证明自己就是 VC 中的该主体。 是否要求 出示者使用该置信方法,或使用 其他机制来提高其对于以下情况的置信度, 由验证者自行决定,例如,出示者是否与发行者 在 VC 中作出声明所涉及的实体相同。此类决定可能会影响 验证者在某些用例中接受 VC 时所承担的 责任。

assuranceLevel 属性使发行者能够声明 发行者在向其初始接收者发行 凭证之前所确立的 保证级别。例如, 发行者可以声明其采用了某种特定的身份 核验流程,以表示标准保证级别,例如 [NIST-SP-800-63-4] 中定义的 IAL 3。这可以 帮助验证者了解 发行者在发行时具有的保证级别,并将其作为自身 就是否接受这些凭证作出知情决定时的输入。

这两种机制都可以使用 JSON-LD 进行扩展,以 定义新的置信方法类型或保证级别。

例如,当雇主( 发行者)向 员工( 主体)发行企业身份证时,它可能 要求员工将某个 特定的密码学 密钥(验证 方法)绑定到可验证凭证 上,这一操作发生在 发行过程中。在这种 情况下,发行者可以 使用本规范向 验证者 传达在最初的身份 保证流程中绑定的是哪个密码学密钥。

换言之,发行者可以使用本规范 传达其使用了哪些 可证明机制来绑定声明(这些声明位于可验证凭证中),从而 使验证者能够 提高其对于多种事项真实性的 置信度,包括以下内容:

1.1 术语

本文档通篇使用的一些术语定义于 可验证凭证数据模型 v2.0规范的 术语 一节以及 受控标识符 v1.0规范的 术语一节。本节定义 本规范通篇 使用的其他术语。

保证级别
一种用于确定个人身份的技术, 它根据特定流程,依据现实世界中的证据和观察 来确定个人身份,该流程通常由美国的 NIST 和 欧盟的 eIDAS 等国家及 国际标准组织定义。

2. 一致性

除标记为非规范性的章节外,本规范中的所有编写指南、图示、示例和注释均为非规范性内容。本规范中的其他所有内容均为规范性内容。

本文档中的关键词 可以必须要求应该 应按照 BCP 14 [RFC2119] [RFC8174] 中所述的方式解释,但当且仅当它们像此处所示以全 大写形式出现时才如此。

一致性 文档是数据模型的任何具体表达形式, 且遵循第 4. 数据模型 节中的相关规范性要求。

一致性 处理器是任何以 软件和/或 硬件实现的算法,它生成和/或使用一致性 文档。一致性 处理器在使用不一致文档时必须产生错误。

3. 证据 属性的关系

本节为非规范性内容。

可验证凭证规范定义了 证据属性:

发行者可以包含证据,以向验证者 提供 可验证凭证中的额外支持信息。 验证者 可以使用这些信息来确定其 依赖可验证凭证中声明时的置信度。例如, 发行者 可以在发行凭证之前检查主体提供的 实体文档,或者 执行一系列背景调查。 在 某些场景中,当 验证者确定依赖给定 凭证所涉及的风险时,这些信息十分有用。

该属性预期在 凭证的顶层使用,实际上是为 整个凭证提供“支持信息”。

规范中提供的示例说明了可以如何 使用该属性:

示例 1:支持技能成就 凭证的证据示例
{
  ...
  "evidence": [{
      // 指向外部托管的证据文件/制品的 URL
      "id": "https://videos.example/training/alice-espresso.mp4",
      "type": ["Evidence"],
      "name": "制作双份浓缩咖啡的边做边讲视频",
      "description": "这是 Alice 演示如何制作双份浓缩咖啡饮品的边做边讲视频。",
      // mp4 视频文件的摘要哈希
      "digestMultibase": "uELq9FnJ5YLa5iAszyJ518bXcnlc5P7xp1u-5uJRDYKvc"
    }
  ]
}

该示例附有以下注释:

:证据与 安全机制的用途不同

evidence 属性所提供的信息 不同于 安全机制所使用的 信息。evidence 属性用于 表达与 可验证凭证相关的支持信息,例如文档 证据。 相比之下,安全 机制 用于 表达与 发行者真实性以及 可验证凭证完整性相关的机器可验证数学证明。 有关 安全机制的更多 信息,请参阅 #安全机制一节。

如上所示,evidence 属性预期用于提供 证据,例如示例中的 mp4 视频文件。

本规范提出了另外两种措施, 它们提供了在不披露不必要个人 信息的情况下提高验证者对 特定主体置信度的机制。与提供额外“证据”不同, confidenceMethodassuranceLevel 这两个附加属性提供 来自发行者的不同证明:

evidence 作为顶层属性,它提供 验证者无需与发行者或持有者进一步 交互即可独立评估的证据。例如, 发行者可能会提供主体 执行某个特定动作(例如完成某项任务)的视频。
confidenceMethod 作为主体级属性,它定义了 验证者可以使用的机制,以 提高对于 VC 的某个 主体 也是另一项交互主体的置信度。例如,发行者可能提供 一个验证 方法,例如公钥, 验证者可据此应用使用证明协议, 从而确定当前用户具备使用 发行者认为由主体控制的同一密码学 秘密来签署密码学质询的能力。 这有时被称为“控制权证明”。
assuranceLevel 作为主体级属性, 它允许发行者证明 已按照 NIST-SP-800-63-4 和 EIDAS2 等公共标准确立了已知保证级别。 与提供待评估的证据或待应用的机制不同, 该属性只是描述发行者自身在发行凭证之前识别 主体所采用的流程。

4. 数据模型

本规范定义了 confidenceMethod 属性,用于 在 可验证 凭证中的 credentialSubject 中表达 置信方法信息。

confidenceMethod

如果存在,confidenceMethod 属性的值为 一个或多个 如下定义的置信方法。每个置信方法 指定具体的 置信方法类型,以及评估该方法时 可能需要的任何参考数据。该方法与 可验证 凭证中的 主体 绑定,并提供足够的 信息,使 验证者能够 评估某个特定候选方就其用途而言 是否与凭证中引用的实体相同。验证者会评估置信 方法,并执行该方法的流程。评估 成功表示凭证已满足 置信方法,而验证者可以安全地依赖这一 判断来提供服务。

每个置信方法必须指定其 type,并且可以 指定 id。每个置信方法的确切属性和语义 由具体的 confidenceMethod 类型定义确定。

assuranceLevel
(存在风险的特性)议题 1

如果存在,assuranceLevel 属性的值为 一个或多个如下定义的保证级别。每种保证 方法指定具体的保证级别类型以及 评估该方法时可能需要的 任何参考数据。该方法与 可验证 凭证中的 主体绑定,并提供有关 发行者在发行时对于该主体所具有的 保证级别的信息。这可以帮助验证者 了解验证者通过何种手段为该主体 建立了自身的保证级别。不同 主体可能具有不同的保证级别,从而允许 发行者对同一凭证中的不同 主体使用不同的保证级别。例如,发行者可以 对结婚证中作为 主婚人或配偶的主体使用较高保证级别,而对 该仪式的证人使用较低保证级别。

每个保证级别必须指定其 type,并且可以 指定 id。每个保证级别的确切属性和语义 由具体的 assuranceLevel 类型定义确定。

验证者可以 决定接受可验证凭证中的声明 而不要求使用置信方法,或者使用 其他机制来 提高其对于以下情况的置信度,例如, 持有者是否与 发行者在可验证凭证中作出声明所涉及的实体相同。 此类 决定可能会影响验证者在某些用例中接受 可验证 凭证时所承担的责任。

验证者可以 通过使用 置信方法中的 信息验证可验证出示证明,来验证持有者控制某个置信方法,或已被 指定具有使用该置信方法的 能力。置信方法可以包含 验证密钥,或者 置信方法的类型可以定义应从 可验证凭证中的其他属性 推断验证密钥,例如 credentialSubject.id

以下示例演示了可以使用的各种 置信方法 类型,包括公钥密码学密钥、 验证方法 和去中心化标识符文档。

示例 2:VerificationKeyConfirmation 类型的 confirmationMethod 属性的用法
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "confidenceMethod": [{
      "type": "BiometricImage",
      "biometricModality": "face",
      "image": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAgAAZABkAAD"
    }, {
      "id": "urn:uuid:818d5ca0-3978-11f0-8658-4f17a1afd652#key-abc",
      "type": "JsonWebKey",
      "controller": "urn:uuid:818d5ca0-3978-11f0-8658-4f17a1afd652",
      "publicKeyJwk": {
        "crv": "Ed25519",
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ",
        "kty": "OKP",
        "kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A"
      }
    }, {
      "id": "did:example:123#key-567",
      "type": "Multikey",
      "controller": "did:example:123",
      "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }, {
      "id": "did:example:1234",
      "type": "DecentralizedIdentifierDocument"
    }],
    "degree": {
      "type": "BachelorDegree",
      "name": "理学与文学学士"
    }
  },
  "proof": { ... }
}

置信方法可以表达各种元数据,例如 发行者对于 持有者可验证凭证主体的置信 级别、 认证器的特定形态或机制,和/或 对其他可验证凭证 或版本化 信任框架的引用。 例如,发行者可以就 基于密码学密钥对的置信方法作出声明,但要使用该密钥 生成签名, 持有者必须 使用多因素 认证解锁设备。

5. 置信方法

VerificationConfidence

VerificationConfidence 指定如何在 DID 文档等受控标识符文档中使用验证 方法。

BiometricImage

BiometricImage 指定如何使用可验证凭证中的 图像来识别 该凭证的主体。

5.1 验证置信度

待定

5.2 生物特征图像

BiometricImage 使颁发者能够将主体的图像嵌入 可验证凭证中, 以便 验证者可以 将该图像与出示 凭证的人进行比较,并提高对 出示者就是主体,即颁发者对其作出声明的主体的置信度。

生物特征图像置信度方法由以下属性定义:

type
要求。该值必须BiometricImage
biometricModality
要求。图像所捕获的模态。本规范 为此字段定义了一个值,即 face。也可以使用其他值,但如果没有 进一步的标准化,则不能保证互操作性。
image
要求。使用 base64 编码的 data: URL [RFC2397],其 媒体类型为图像媒体类型,例如 image/jpegimage/png。该图像必须嵌入可验证 凭证中,而不是由可解引用的 URL 引用。

验证者 通过验证 BiometricImage 所在的 可验证凭证、 解码 image 的值,并将解码后的图像与 出示凭证的人进行比较来评估该对象。

示例 3:生物特征图像置信度方法的用法
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "confidenceMethod": {
      "type": "BiometricImage",
      "biometricModality": "face",
      "image": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAgAAZABkAAD"
    },
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": { ... }
}

5.3 密码学密钥

密码学密钥置信度方法使颁发者能够将在诸如 MultikeyJsonWebKey 等格式中表示的特定 密码学公钥绑定到主体,并包含在 可验证凭证中。 颁发者 记录一个被认为在颁发和出示时可由主体使用或代表其使用的公钥 (使用证明)。颁发者在颁发前应该验证与该公钥 关联的私钥的使用。这为验证者 提供了一个密码学锚点,可用于确认出示者控制 相应的私钥。由于此绑定由颁发者声明, 并受到凭证保护机制的保护,因此验证者可以相信 该密码学密钥材料反映了颁发者在 颁发时验证的内容。

示例 4:在可验证凭证中表示的密码学密钥置信度方法
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiableCredential", "EmployeeCredential"],
  "issuer": "https://example.com/issuers/42",
  "validFrom": "2026-07-15T00:00:00Z",
  "credentialSubject": {
    "name": "Alice Doe",
    "confidenceMethod": [{
      // 内联表示公钥
      "type": "Multikey",
      "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }, {
      // 通过引用表示公钥
      "id": "did:example:123456789#key-1",
      "type": "Multikey"
    }, {
      // 支持多种公钥格式
      "type": "JsonWebKey",
      "publicKeyJwk": {
        "crv": "Ed25519",
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ",
        "kty": "OKP",
        "kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A"
      }
    }]
  },
  "proof": { ... }
}

可验证 呈现期间,验证者使用置信度方法中的公钥 执行使用证明协议。验证者 发出一个密码学质询,通常是绑定到会话的 nonce,然后 持有者使用与 置信度方法中记录的公钥相对应的私钥对 质询进行签名。随后验证者 根据所声明的公钥验证该签名。验证成功 即表明出示者控制着颁发者在颁发时绑定到 主体的私钥, 从而提高对出示者就是该 可验证凭证预期主体的置信度。

5.4 受控标识符

受控标识符置信度方法使颁发者能够将 主体绑定到其 控制的受控标识符 文档,而不是直接在 可验证凭证中嵌入特定密钥。 去中心化标识符(DID)是一种 广为人知的受控标识符类型。颁发者记录在颁发时经验证的主体的受控 标识符,使 验证者能够 在出示时检索当前受控标识符文档,并发现 主体的authentication 验证 关系中列出的验证方法。此方法可适应密钥轮换以及 主体密码学材料的其他生命周期变化,而 无需 颁发者重新颁发可验证凭证, 只要 主体 本身仍保持对标识符的控制即可。

示例 5:在可验证凭证中表示的受控标识符置信度方法
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiableCredential", "MembershipCredential"],
  "issuer": "https://example.org/issuers/7",
  "validFrom": "2026-07-01T00:00:00Z",
  "credentialSubject": {
    "name": "Alex Utopian"
    "memberOf": {
      "name": "Utopia Libraries"
    },
    "confidenceMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  },
  "proof": { ... }
}

可验证 呈现期间,验证者解析置信度方法中的受控 标识符,以获取当前受控标识符 文档。验证者提取该文档的 验证 方法,这些方法列在其 authentication 验证 关系中,然后发出密码学质询并 请求持有者使用其中一种 authentication 验证方法生成证明。如果持有者成功使用 已授权密钥对质询进行签名,则验证者会提高对 出示者控制着颁发者在颁发时与主体关联的 标识符的置信度。 由于受控标识符文档由主体维护,因此此 协议可以透明地适应密钥轮换:持有者可以使用 当前任何已授权的 authentication 密钥进行出示,而无需从颁发者处获取新 凭证。

5.5 生物特征图像置信度

待定

5.6 生物特征向量 置信度方法

(风险特性)问题 2:生物特征向量置信度方法尚不稳定
生物特征向量置信度方法尚不稳定,任务组仍在继续 对其进行完善。目前正在积极处理以下 问题:
  1. 本规范需要对生物特征匹配 提供商保持中立,不偏向任何特定的专有或开放 方法或类型。
  2. 模型和向量数据可能会被合并,因为它们彼此 相关。将模型 与向量信息解耦实际上没有太大意义。使用 base64url 编码的 CBOR 可能 是保存这些信息的更好方法。
  3. 我们如何使用开放匹配模型指定示例,而这些 示例需要存在于规范中?
  4. 明确说明颁发者可以在凭证颁发时提供来自 不同提供商的多个向量。
  5. 目前还没有用于生物特征匹配的标准化 ZKP, 但本组认为这是理想的最终状态。
  6. 颁发者将服务 URL 放入生物特征匹配模型 可能不是最佳设计,需要进一步完善。还需要进行更多 工作,以确定应如何在持有者与验证者之间以及 持有者与颁发者之间执行协商。
  7. 这些信息应该发布在哪里?将 这些信息放在 DID 文档中安全吗?
  8. 在规范中描述“理想状态”用例。
  9. 持有者如何找到“正确的”生物特征提供商?这是否 对持有者要求过高?这是否会带来安全/隐私风险? 我们到底要求持有者做多少事情?
  10. 对于本地 设备检查,是否需要执行应用完整性检查?
  11. 需要向模型添加 nonce。

BiometricVectorConfidenceMethod 使颁发者能够在可验证凭证中嵌入 生物特征向量, 以便 验证者可以 提高对 出示者就是颁发者对其作出 声明的同一个人的置信度。 与原始生物特征数据(例如照片、音频 录音)不同,生物特征向量是由匹配模型 生成的紧凑数学表示。来自不同 模型的向量不能互换。

5.6.1 用例

销售点年龄验证。当消费者 购买有年龄限制的商品时,目前店员会接触 消费者的实体身份证件,从而暴露其全名、地址和出生 日期——这会带来身份盗窃和人身安全风险。使用 生物特征向量置信度方法时,消费者的设备执行 生物特征匹配,并且只向 销售点系统发送签名后的验证结果。店员永远不会看到消费者的个人 信息,也无需判断文档是否真实。

账户恢复。当用户由于 忘记密码或设备丢失而无法访问 账户时,服务提供商通常依赖不安全的基于知识的身份验证 或人工支持流程。生物特征向量置信度方法 可通过将新采集的生物特征 与注册时登记的向量进行比较来实现自动恢复——比安全 问题更可靠,比客户支持更快速,而且无需存储照片。

移动凭证出示者限制。诸如移动 驾驶证之类的数字凭证可以被转移给 未经授权的人员,而没有一种机制来验证出示者 是否为合法且预期的出示者。生物特征向量置信度 方法为出示者提供密码学验证——凭证 包含已登记的向量,并且出示者通过 在出示时进行新的生物特征匹配证明其已授权持有。

远程入驻和身份核验。当 组织需要远程验证某人的身份时——例如用于 就业、金融服务或政府福利——生物特征 向量置信度方法可以将已验证身份绑定到 凭证,而无需本人亲自到场。生物特征 匹配可确认远程出示身份的人与 颁发期间已完成身份核验的人是同一个人,从而减少欺诈,同时 保护隐私。

生物特征向量置信度方法必须指定以下属性:

id
此置信度方法实例的唯一标识符。使一个 人能够针对不同上下文维护多个生物特征登记。
type
该值必须BiometricVectorConfidenceMethod
biometricModality
生物特征模态。预期值包括 facevoicefingerprintpalmprintirisretina
captureFormat
捕获格式。预期值包括 videostatic-imageimage-sequenceaudio
biometricModel
标识匹配模型的对象,包含一个 type 属性 (必须BiometricMatchingModel)以及一个 matchingModel 属性 (供应商和模型标识符,例如 example-biometric-2026-v3.2)。
biometricVectors
使用 Multibase 编码(base64url-nopad)的生物特征向量。其格式 取决于生成它的匹配模型。颁发者可以 包含来自不同提供商的多个向量,从而使 持有者 能够灵活选择验证服务。

生物特征向量置信度方法可以另外指定:

service
用于服务器辅助验证的服务端点,遵循 [[DID-CORE] ][DID-CORE] 中的服务定义结构,包含 idtypeBiometricVerificationService)和 serviceEndpoint 属性。

支持两种实现情景:客户端本地处理 和用户选择的提供商。在这两种情况下,都会捕获新的生物特征样本 并将其与已登记的向量进行比较。结果以 BiometricVerificationCredential 表示。

5.6.2 客户端验证

在此情景中,生物特征验证完全在 持有者的 设备上进行。任何生物特征数据都不会离开设备; 零知识证明用于证明匹配结果。

以下示例展示了一个包含用于客户端验证的生物特征向量 置信度方法的凭证:

示例 6:客户端生物特征向量置信度 方法
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "validFrom": "2026-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "confidenceMethod": {
      "id": "urn:uuid:a7f8c3d1-4b2e-4f9a-8c6d-1e3b5a7f9c2d",
      "type": "BiometricVectorConfidenceMethod",
      "biometricModality": "face",
      "captureFormat": "video",
      "biometricModel": {
        "type": "BiometricMatchingModel",
        "matchingModel": "example-biometric-2026-v3.2"
      },
      "biometricVectors": "uAVvLMv6gm...MNam"
    },
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science"
    }
  }
}

持有者的 设备捕获一个新的生物特征样本,并在本地 将其与已登记的 biometricVectors 进行比较,然后生成一个 BiometricVerificationCredential 来声明匹配。请注意, 验证输出中的 credentialSubject.id 引用了 上述凭证中的置信度方法 id,从而将 验证结果与特定的生物特征登记关联起来:

示例 7:客户端生物特征 匹配的验证输出
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiableCredential", "BiometricVerificationCredential"],
  "issuer": "did:example:holder-device",
  "validFrom": "2026-05-15T14:30:00Z",
  "validUntil": "2026-05-15T14:45:00Z",
  "credentialSubject": {
    "id": "urn:uuid:a7f8c3d1-4b2e-4f9a-8c6d-1e3b5a7f9c2d",
    "biometricMatch": {
      "type": "BiometricMatch",
      "matchingMethod": "client-side-zkp",
      "matchDate": "2026-05-15T14:30:00Z",
      "matchResult": "verified",
      "confidence": "0.96"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "example-biometric-zkp-2028",
    "created": "2026-05-15T14:30:05Z",
    "challenge": "9a4f2c8b-3e7d-4f1a-b5c9-2d8e6f0a1b3c",
    "verificationMethod": "did:example:holder-device#key-1",
    "proofPurpose": "authentication",
    "proofValue": "z58DAdFfa9SkqZMVPxAQpic7ndTeel..."
  }
}
(风险特性)问题 3

在本文撰写时,example-biometric-zkp-2028 密码套件尚不存在。 此处包含它是为了说明未来的 零知识证明密码套件可如何用于客户端 生物特征验证。该领域目前仍处于积极研究之中。

5.6.3 用户选择的提供商

在此情景中,持有者选择一个受信任的 生物特征 验证服务。钱包会显示可用选项,并且 持有者 会在传输任何生物特征数据之前给予同意。 持有者的 生物特征数据只发送给其选择的提供商,而不会 发送给验证者

以下示例展示了一个包含服务端点的生物特征向量 置信度方法的凭证:

示例 8:用户选择的提供商生物特征向量 置信度方法
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "validFrom": "2026-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "confidenceMethod": {
      "id": "urn:uuid:a7f8c3d1-4b2e-4f9a-8c6d-1e3b5a7f9c2d",
      "type": "BiometricVectorConfidenceMethod",
      "biometricModality": "face",
      "captureFormat": "video",
      "biometricModel": {
        "type": "BiometricMatchingModel",
        "matchingModel": "example-biometric-2026-v3.2"
      },
      "service": {
        "id": "urn:uuid:service-1",
        "type": "BiometricVerificationService",
        "serviceEndpoint": "https://biometric-provider.example/verify/v3"
      },
      "biometricVectors": "uAVvLMv6gm...MNam"
    },
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science"
    }
  }
}

验证流程确保生物特征提供商与 验证者不 需要了解彼此:

  1. 验证者持有者 请求生物特征验证, 指定可接受的生物特征提供商以及一个质询 nonce。
  2. 钱包向持有者显示可接受的提供商,由其 选择偏好的提供商并同意进行 验证。
  3. 钱包将 biometricVectors、新捕获的生物特征 以及质询 nonce 传输到所选提供商的 serviceEndpoint
  4. 提供商将新捕获的数据与已登记的 向量进行比较,并颁发一个签名的 BiometricVerificationCredential,其中 嵌入质询 nonce。
  5. 钱包将 BiometricVerificationCredential 出示给 验证者,验证者验证 证明,并检查其中嵌入的 质询是否与其原始请求匹配。

质询 nonce 可防止重放攻击,并证明此次验证 是为响应验证者的特定请求而执行的。 与客户端情景一样,验证 输出中的 credentialSubject.id 引用了 上述凭证中的置信度方法 id

示例 9:用户选择的提供商 生物特征匹配的验证输出
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiableCredential", "BiometricVerificationCredential"],
  "issuer": "did:web:biometric-provider.example",
  "validFrom": "2026-05-15T14:30:00Z",
  "validUntil": "2026-05-15T14:45:00Z",
  "credentialSubject": {
    "id": "urn:uuid:a7f8c3d1-4b2e-4f9a-8c6d-1e3b5a7f9c2d",
    "biometricMatch": {
      "type": "BiometricMatch",
      "matchingMethod": "server-assisted-video-stream",
      "matchDate": "2026-05-15T14:30:00Z",
      "domain": "https://verifier.example/",
      "matchResult": "verified",
      "confidence": "0.94"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-rdfc-2019",
    "created": "2026-05-15T14:30:05Z",
    "challenge": "9a4f2c8b-3e7d-4f1a-b5c9-2d8e6f0a1b3c",
    "verificationMethod": "did:web:biometric-provider.example#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z58DAdFfa9SkqZMVPxAQpic7ndTeel..."
  }
}

6. 保证级别

NIST_800-63-4_LOA

NIST_800-63-4 定义了一个基于 [NIST-SP-800-63-4] 规范的保证级别。

EIDAS_LOA

EIDAS_LOA 定义了一个基于 [EIDAS2] 的保证级别。

6.1 NIST_800-63-4_LOA

待定

6.2 EIDAS_LOA

待定

7. 安全考量

议题 4:添加安全 考量一节
添加安全考量一节,其中至少包括 以下主题:
  • 由于置信方法可以选择性披露, 在处理允许选择性披露或 不可关联披露的证明机制时,验证者需要在高保证 用例中 明确请求置信方法。

8. 隐私考量

议题 5:添加隐私 考量一节
添加隐私考量一节,其中至少包括 以下主题:
  • 置信方法预期应选择性披露, 因为在许多低保证用例中可能 并不需要它们,或者可以通过其他 方式实现高保证,例如面对面 对照照片进行验证。
  • 如果置信方法以不可关联方式披露,它可能 泄露 可关联的标识符,例如公共密码学密钥 标识符。
  • 强烈建议不要将生物特征用于置信 方法,除非 绝对必要。应警告验证者仅在 万不得已时才要求 生物特征照片,并应在交易 完成后销毁这些信息。

A. 参考文献

A.1 规范性参考文献

[CID]
受控标识符 v1.0。Michael Jones;Manu Sporny。W3C。2025 年 5 月 15 日。W3C 推荐标准。URL:https://www.w3.org/TR/cid-1.0/
[DID-CORE]
去中心化标识符(DID)v1.0。 Manu Sporny;Amy Guy;Markus Sabadello;Drummond Reed。W3C。2022 年 7 月 19 日。W3C 推荐标准。URL: https://www.w3.org/TR/did-core/
[EIDAS2]
欧洲议会和欧盟 理事会 2024 年 4 月 11 日第 (EU) 2024/1183 号条例,修订第 (EU) 910/2014 号条例, 以建立欧洲数字身份框架。欧洲 议会;欧盟理事会。《欧盟官方公报》。2024 年 4 月 30 日。 URL:http://data.europa.eu/eli/reg/2024/1183/oj
[NIST-SP-800-63-4]
数字身份 指南。David Temoshok;Yee-Yin Choong;Ryan Galluzzo;Connie LaSalle;Andrew Regenscheid;Diana Proud-Madruga;Sarbari Gupta;Naomi Lefkovitz。美国国家标准与 技术研究院。2025 年 8 月。URL:https://pages.nist.gov/800-63-4/sp800-63.html
[RFC2119]
RFC 中用于指示 要求级别的关键词。S. Bradner。IETF。1997 年 3 月。最佳当前实践。URL:https://www.rfc-editor.org/info/rfc2119/
[RFC2397]
“data”URL 方案。L. Masinter。IETF。1998 年 8 月。提议标准。URL:https://www.rfc-editor.org/info/rfc2397/
[RFC8174]
RFC 2119 关键词中大写与小写的歧义。B. Leiba。IETF。2017 年 5 月。最佳当前实践。URL:https://www.rfc-editor.org/info/rfc8174/
[VC-DATA-INTEGRITY]
可验证凭证数据完整性 1.0. Ivan Herman; Manu Sporny; Ted Thibodeau Jr; Dave Longley; Greg Bernstein. W3C. 2025 年 5 月 15 日。W3C 推荐标准。URL:https://www.w3.org/TR/vc-data-integrity/
[VC-DATA-MODEL-2.0]
可验证凭证数据模型 v2.0。Ivan Herman;Michael Jones;Manu Sporny;Ted Thibodeau Jr;Gabe Cohen。W3C。 2025 年 5 月 15 日。W3C 推荐标准。URL:https://www.w3.org/TR/vc-data-model-2.0/