可验证凭证数据完整性 1.1

数据完整性证明提供关于证明机制、 验证该证明所需参数以及证明值本身的信息。所有 这些信息都使用关联数据词汇表提供，例如 安全 词汇表。

在对象上表达数据完整性证明时， MUST 使用 proof 属性。 可验证凭证 中的 proof 属性是一个命名图。如果存在， 其值 MUST 是单个对象，或一个无序对象集， 使用以下属性表达：

id

证明的可选标识符，它 MUST 是一个 URL [URL]， 例如作为 URN 的 UUID（urn:uuid:6a1676b8-b51f-11ed-937b-d76685a20ff5）。 此属性的用法在第 2.1.2 证明 链中进一步说明。

type

证明的具体类型 MUST 指定为一个映射到 URL [URL] 的字符串。 证明类型示例包括 DataIntegrityProof 和 Ed25519Signature2020。证明类型决定需要哪些其他字段来 保护和验证该证明。

proofPurpose

证明被创建的原因 MUST 指定为一个映射到 URL [URL] 的字符串。 证明目的充当保障措施，以防止 证明被误用于不同于其预期目的的用途。例如，如果没有此值， 证明创建者可能会被诱导在登录过程中使用通常用于创建可验证 凭证（assertionMethod）的密码学材料（authentication）， 这将导致创建一个他们从未打算创建的可验证 凭证，而不是预期的仅登录网站这一动作。

verificationMethod

验证方法是验证证明所需的手段和信息。 如果包含该值，则其值 MUST 是一个映射到 [URL] 的 字符串。包含 verificationMethod 是 OPTIONAL 的，但如果不包含， 其他属性（如 cryptosuite）可能提供一种机制，用于获取 验证证明所需的信息。注意，当 verificationMethod 在 数据完整性证明中 表达时，该值指向数据的实际位置；也就是说，verificationMethod 通过 URL 引用 可用于验证该证明的公钥的位置。该 公钥数据存储在受控标识符 文档中，该文档包含对验证方法的 完整描述。

cryptosuite

用于标识可验证证明的加密套件的标识符。更多信息见 3. 加密套件。如果证明 type 是 DataIntegrityProof，则 cryptosuite MUST 被指定；否则，cryptosuite MAY 被指定。如果被指定，其值 MUST 是 一个字符串。

created

证明创建的日期和时间是 OPTIONAL 的；如果包含，则 MUST 指定为 [XMLSCHEMA11-2] dateTimeStamp 字符串，使用协调世界时（UTC）（值末尾以 Z 表示）， 或使用相对于 UTC 的时区偏移。一致的处理器 MAY 选择消费 未带偏移量而错误序列化的时间值。未带偏移量的错误 序列化时间值应解释为 UTC。

expires

expires 属性是 OPTIONAL 的；如果存在，它指定 证明何时过期。如果存在，它 MUST 是一个 [XMLSCHEMA11-2] dateTimeStamp 字符串， 使用协调世界时（UTC）（值末尾以 Z 表示），或使用相对于 UTC 的时区偏移。 一致的处理器 MAY 选择消费未带偏移量而错误序列化的时间值。 未带偏移量的错误序列化时间值应解释为 UTC。

domain

domain 属性是 OPTIONAL 的。它传达证明 预期被使用的一个或多个安全域。如果被指定，关联值 MUST 是一个字符串，或一个无序字符串集。验证者 SHOULD 使用该值 来确保该证明预期用于验证者正在操作的安全域。 domain 参数的指定在挑战-响应协议中很有用， 其中验证者在证明创建者已知的安全域内操作。示例 domain 值包括： domain.example（DNS 域）、https://domain.example:8443 （Web 源）、mycorp-intranet（自定义文本字符串）以及 b31d37d4-dd59-47d3-9dd8-c973da43b63a（UUID）。

challenge

一个字符串值， 如果指定了 domain，则 SHOULD 在证明中包含它。 该值在特定域和时间窗口中使用一次。 该值用于缓解重放攻击。challenge 值示例包括： 1235abcd6789、79d34551-ae81-44ae-823b-6dadbab9ebd4 和 ruby。

proofValue

一个字符串值， 它表达验证使用指定 verificationMethod 的 数字证明所需的 base 编码二进制数据。该值 MUST 使用 受控标识符 v1.0 规范第 2.4 Multibase 节所述的 头部和编码来表达二进制数据。 该值的内容由具体 cryptosuite 决定，并设置为该 cryptosuite 的 添加证明算法生成的证明值。 可使用由 cryptosuite 指定且具有不同编码的替代属性， 代替此属性，以编码验证数字证明所需的数据。

previousProof

previousProof 属性是 OPTIONAL 的。如果存在，它 MUST 是字符串 值或无序字符串值列表。每个值标识另一个 数据完整性证明，所有这些证明 MUST 也通过验证，当前证明才被视为已验证。此属性用于第 2.1.2 证明链。

nonce

由证明创建者提供的 OPTIONAL 的字符串值。 此字段的一个用途是通过降低确定性生成签名所导致的可关联性来 增强隐私。

可以像下面这样向 JSON 文档添加证明：

{
  "myWebsite": "https://hello.world.example/"
};

以下证明使用 eddsa-jcs-2022 加密套件 [DI-EDDSA] 保护上述文档， 该套件通过使用 JSON 规范化方案（JCS） [RFC8785] 转换输入数据，然后使用 Edwards 数字签名 算法（EdDSA）对其进行数字签名，从而生成可验证的数字证明。

{
  "myWebsite": "https://hello.world.example/",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "created": "2023-03-05T19:23:24Z",
    "verificationMethod": "https://di.example/issuer#z6MkjLrk3gKS2nnkeWcmcxiZPGskmesDpuwRBorgHxUXfxnG",
    "proofPurpose": "assertionMethod",
    "proofValue": "zQeVbY4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYV8nQApmEcqaqA3Q1gVHMrXFkXJeV6doDwLWx"
  }
}

类似地，可以像下面这样向 JSON-LD 数据文档添加证明：

{
  "@context": {"myWebsite": "https://vocabulary.example/myWebsite"},
  "myWebsite": "https://hello.world.example/"
};

以下证明通过使用 ecdsa-rdfc-2019 加密套件 [DI-ECDSA] 来保护上述文档， 该套件通过使用 RDF 数据集规范化方案 [RDF-CANON] 转换输入数据，然后使用 椭圆曲线数字 签名算法（ECDSA）对其进行数字签名，从而生成可验证的数字证明。

{
  "@context": [
    {"myWebsite": "https://vocabulary.example/myWebsite"},
    "https://w3id.org/security/data-integrity/v2"
  ],
  "myWebsite": "https://hello.world.example/",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-rdfc-2019",
    "created": "2020-06-11T19:14:04Z",
    "verificationMethod": "https://ldi.example/issuer#zDnaepBuvsQ8cpsWrVKw8fbpGpvPeNSjVPTWoq6cRqaYzBKVP",
    "proofPurpose": "assertionMethod",
    "proofValue": "zXb23ZkdakfJNUhiTEdwyE598X7RLrkjnXEADLQZ7vZyUGXX8cyJZRBkNw813SGsJHWrcpo4Y8hRJ7adYn35Eetq"
  }
}

{
  "@context": [
    {"myWebsite": "https://vocabulary.example/myWebsite"},
    "https://w3id.org/security/data-integrity/v2"
  ],
  "myWebsite": "https://hello.world.example/",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-rdfc-2019",
    "created": "2020-06-11T19:14:04Z",
    // 该证明在创建一个月后过期
    "expires": "2020-07-11T19:14:04Z",
    "verificationMethod": "https://ldi.example/issuer#zDnaepBuvsQ8cpsWrVKw8fbpGpvPeNSjVPTWoq6cRqaYzBKVP",
    "proofPurpose": "assertionMethod",
    "proofValue": "z98X7RLrkjnXEADJNUhiTEdwyE5GXX8cyJZRLQZ7vZyUXb23ZkdakfRJ7adYY8hn35EetqBkNw813SGsJHWrcpo4"
  }
}

数据完整性规范支持在单个文档中包含多个 证明的概念。它识别了两种多证明 方法：证明集（无序）和证明链 （有序）。

{
  "@context": [
    {"myWebsite": "https://vocabulary.example/myWebsite"},
    "https://w3id.org/security/data-integrity/v2"
  ],
  "myWebsite": "https://hello.world.example/",
  "proof": [{
    // 这是该集合中的一个证明
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2020-11-05T19:23:24Z",
    "verificationMethod": "https://ldi.example/issuer/1#z6MkjLrk3gKS2nnkeWcmcxiZPGskmesDpuwRBorgHxUXfxnG",
    "proofPurpose": "assertionMethod",
    "proofValue": "z4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYVQeVbY8nQAVHMrXFkXJpmEcqdoDwLWxaqA3Q1geV6"
  }, {
    // 这是该集合中的另一个证明
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2020-11-05T13:08:49Z",
    "verificationMethod": "https://pfps.example/issuer/2#z6MkGskxnGjLrk3gKS2mesDpuwRBokeWcmrgHxUXfnncxiZP",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5QLBrp19KiWXerb8ByPnAZ9wujVFN8PDsxxXeMoyvDqhZ6Qnzr5CG9876zNht8BpStWi8H2Mi7XCY3inbLrZrm95"
  }]
}

{
  "@context": [
    {"myWebsite": "https://vocabulary.example/myWebsite"},
    "https://w3id.org/security/data-integrity/v2"
],
  "myWebsite": "https://hello.world.example/",
  "proof": [{
    // 'id' 值标识此特定证明
    "id": "urn:uuid:60102d04-b51e-11ed-acfe-2fcd717666a7",
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2020-11-05T19:23:42Z",
    "verificationMethod": "https://ldi.example/issuer/1#z6MkjLrk3gKS2nnkeWcmcxiZPGskmesDpuwRBorgHxUXfxnG",
    "proofPurpose": "assertionMethod",
    "proofValue": "zVbY8nQAVHMrXFkXJpmEcqdoDwLWxaqA3Q1geV64oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYVQe"
  }, {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2020-11-05T21:28:14Z",
    "verificationMethod": "https://pfps.example/issuer/2#z6MkGskxnGjLrk3gKS2mesDpuwRBokeWcmrgHxUXfnncxiZP",
    "proofPurpose": "assertionMethod",
    "proofValue": "z6Qnzr5CG9876zNht8BpStWi8H2Mi7XCY3inbLrZrm955QLBrp19KiWXerb8ByPnAZ9wujVFN8PDsxxXeMoyvDqhZ",
    // 'previousProof' 值标识在此证明之前验证的证明
    "previousProof": "urn:uuid:60102d04-b51e-11ed-acfe-2fcd717666a7"
  }]
}

描述其目的的证明有助于防止它被误用于某些 其他目的。证明目的使验证者能够了解 证明创建者的意图，因此消息不会被意外滥用于 另一种目的。例如，一条仅为作出断言（或许预期广泛共享） 而签名的消息，被滥用为 用于向服务认证或执行某些操作（如调用某项能力）的消息。

需要注意，证明目的不同于 JSON Web Key (JWK) 中的 key_ops 限制、 Web Cryptography API 中的 KeyUsage 限制，以及 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile。 证明目的表达的是 证明为何被创建以及其预期使用域，而 前述其他机制旨在限制私钥可以用来 做什么。证明目的会随证明“一起传递”，而密钥限制 不会。

以下是常用证明目的值的列表。

authentication

表示给定证明仅用于认证协议的目的。

assertionMethod

表示证明只能用于作出断言，例如 签署可验证 凭证。

keyAgreement

表示证明用于密钥协商协议，例如流行加密 库使用的椭圆曲线 Diffie Hellman 密钥协商。

capabilityDelegation

表示证明只能用于委托能力。更多详细信息见 授权能力 [ZCAP] 规范。

capabilityInvocation

表示证明只能用于调用能力。更多详细信息见 授权能力 [ZCAP] 规范。

当一致的受保护文档中包含指向外部资源的链接时， 希望能够知道所标识的资源自证明创建以来是否已经改变。 这既适用于存在远程获取的外部资源的情况，也适用于 验证者可能拥有 该资源的本地缓存副本的情况。

为了确认一致的受保护文档所引用的资源 自文档被保护以来没有发生变化，实现者 MAY 在任何包含 id 属性的对象中包含一个名为 digestMultibase 的属性。 如果存在，digestMultibase 值 MUST 是单个 字符串值，或一个列表，其中包含多个 字符串值，每个值都是 Multibase 编码的 Multihash 值。

JSON-LD 上下文作者应将 digestMultibase 添加到 用于引用其他资源的文档的上下文中，并包含 关联的密码学摘要。例如，可验证凭证数据模型 v2.0 基础 上下文（https://www.w3.org/ns/credentials/v2）包含 digestMultibase 属性。

下面显示了一个受资源完整性保护对象的示例：

{
  ...
  "image": {
    "id": "https://university.example.org/images/58473",
    "digestMultibase": "zQmdfTbBqBPQ7VNxZEYEj14VmRuZBkqFbiwReogJgS1zR1n"
  },
  ...
}

敦促实现者咨询适当来源，例如 FIPS 180-4 安全哈希标准和 商用国家安全算法套件 2.0，以确保他们 选择适合其用例的哈希算法。

执行 JSON-LD 处理的实现 MUST 将以下 JSON-LD 上下文 URL 视为已解析，其中已解析文档与下面的 相应哈希值匹配：

可以通过在现代类 UNIX 操作系统命令行界面中运行如下 命令来确认上面列出的密码学摘要（将 <DOCUMENT_URL> 替换为适当的 值）：curl -sL -H "Accept: application/ld+json" <DOCUMENT_URL> | openssl dgst -sha256

上面列出的 JSON-LD 上下文解析到的安全词汇表术语 位于 https://w3id.org/security# 命名空间中。也就是说，该词汇表中的所有安全术语都采用 https://w3id.org/security#TERM 的形式，其中 TERM 是术语名称。

执行 RDF 处理的实现 MUST 将 词汇表 URL 的 JSON-LD 序列化视为已经解除引用，其中解除引用的文档 与下面的相应哈希值匹配。

当解除引用 https://w3id.org/security# URL 时， 返回数据的媒体类型取决于 HTTP 内容协商。如下所示：

可以通过在现代类 UNIX 操作系统命令行界面中运行 如下命令来确认上面列出的密码学摘要（将 <MEDIA_TYPE> 和 <DOCUMENT_URL> 替换为适当的值）： curl -sL -H "Accept: <MEDIA_TYPE>" <DOCUMENT_URL> | openssl dgst -sha256

应用程序特定词汇表和规范的作者 SHOULD 确保 其 JSON-LD 上下文和词汇表文件使用上述缓存方法或功能等价机制 可永久缓存。

实现 MAY 在开发期间从网络加载应用程序特定的 JSON-LD 上下文文件， 但在生产环境中，SHOULD 永久缓存 一致的受保护文档所使用的 JSON-LD 上下文文件， 以增强其安全性和隐私特性。处理速度目标 MAY 通过 上述缓存方法或功能等价机制实现。

某些应用程序，例如能够持有任意 可验证凭证 或其他受数据完整性保护文档的数字钱包，来自 任意发行者并使用任意上下文，可能需要能够在生产环境中加载外部 链接资源，例如 JSON-LD 上下文文件。预计这会随着时间推移提高 生态系统中的用户选择、可扩展性和去中心化升级能力。建议此类应用程序的作者 阅读本文档的安全和隐私章节以获取进一步考量。

有关 JSON-LD 上下文和 词汇表处理的更多信息，见 可验证 凭证 v2.0：基础上下文 和 可验证凭证 v2.0：词汇表。

“关联数据”一词用于描述一种推荐的最佳实践， 即使用标准（如 URL）在 Web 上公开、共享和连接信息， 以标识事物及其属性。当信息以关联数据形式呈现时， 可以轻松发现其他相关信息，也可以轻松将新 信息链接到它。关联数据以去中心化方式可扩展， 大大降低了大规模集成的障碍。

随着关联数据在各种应用中的使用增加， 需要能够验证关联数据文档的真实性和完整性。 本规范通过使用数学证明为数据文档添加认证和完整性保护， 同时不牺牲关联数据的可扩展性和可组合性等特性。

实现本规范的加密套件可用于保护 可验证凭证 和可验证 表示。处理 这些用例的实现者应注意，在处理这些类型的文档时， 可能需要进行额外检查。

在某些用例中，重要的是确保证明中使用的 验证 方法与 issuer（在 可验证凭证中）或 holder（在 可验证表示中）相关联，在 验证过程中尤其如此。检查这种关联的一种 方法是确保证明的验证方法的 controller 属性值 与用于标识 issuer 或 holder 的 URL 值分别匹配， 并且 验证方法表达在一个给定证明目的可接受的验证关系下。 这种特定关联表示 issuer 或 holder 分别 是用于验证该证明的验证方法的控制者。

建议文档作者和实现者理解 证明的有效期（使用 created 和 expires 属性表达）与 凭证的有效期之间的区别， 后者使用 validFrom 和 validUntil 属性表达。 虽然这些属性有时可能表达相同的有效期， 但在其他时候它们可能并不一致。在验证 证明时，重要的是确保关注的时间 （可能是当前时间或任何其他时间）处于 证明的有效期内（即位于 created 和 expires 之间）。 在验证 可验证凭证时， 重要的是确保关注的时间处于 凭证的有效期内（即 位于 validFrom 和 validUntil 之间）。注意 未能验证证明的有效期，或 凭证的有效期， 可能导致接受本应被拒绝的数据。

最后，还敦促实现者理解，与可验证凭证相关的 撤销信息，与撤销 以及过期时间 （针对验证 方法）之间存在区别。 撤销和 过期时间对于 验证 方法而言，分别使用 revocation 和 expires 属性表达；它们与秘密密钥被 泄露或过期等事件相关；并且可能提供可能揭示 控制者详情的时间信息，例如其安全实践或何时可能 已被攻破。可验证凭证 的撤销信息使用 credentialStatus 属性表达；它与 个人失去由 可验证凭证 授予的权限等事件相关； 并且不提供时间信息，从而增强隐私。

当表达数据完整性证明时， 许多加密套件遵循相同的基本模式。本节规定这种通用 设计模式，即一种称为 DataIntegrityProof 的加密套件类型， 它通过复用设计基元和源代码，降低编写和实现加密套件 的负担。

在指定使用此设计模式的加密套件时， proof 值采用以下形式：

type

type 属性 MUST 包含字符串 DataIntegrityProof。

cryptosuite

cryptosuite 属性的值 MUST 是一个字符串，用于标识 加密套件。如果处理环境支持 字符串 子类型，则 cryptosuite 值的子类型 MUST 是 https://w3id.org/security#cryptosuiteString 子类型。

proofValue

proofValue 属性 MUST 按第 2.1 证明中的规定使用。

加密套件设计者 MUST 使用 第 2.1 证明中定义的强制 proof 值属性， 并且 MAY 定义其加密套件特有的其他属性。

以下算法规定如何从包含证明或 证明集/链的受保护文档开始，向证明 集或证明链增量添加证明。必需输入是受保护数据文档（映射 securedDocument）、加密套件（cryptosuite 实例 suite）以及一组选项（映射 options）。输出是新的 受保护数据文档（映射）。每当此算法对字符串进行编码时， 它 MUST 使用 UTF-8 编码。

1. 令 proof 设置为 securedDocument.proof。令 allProofs 为空列表。如果 proof 是列表，则将 proof 的所有元素复制到 allProofs。如果 proof 是对象，则将该对象的副本添加到 allProofs。
2. 令 inputDocument 为移除 proof 属性后的 securedDocument 副本。令 output 为 inputDocument 的副本。
3. 令 matchingProofs 为空列表。
4. 如果 options 具有一个为字符串的 previousProof 项，则将 allProofs 中 id 属性与 previousProof 匹配的元素添加到 matchingProofs。如果 allProofs 中不存在 id 等于 previousProof 的证明， 则 MUST 引发错误，并且 SHOULD 传达错误类型 PROOF_GENERATION_ERROR。
5. 如果 options 具有一个为数组的 previousProof 项，则添加 allProofs 中 id 属性与该数组中某个元素匹配的每个 元素。如果 previousProof 列表中的任何元素具有一个 与 allProofs 中任何元素的 id 属性都不匹配的 id 属性，则 MUST 引发错误，并且 SHOULD 传达错误类型 PROOF_GENERATION_ERROR。
6. 将 inputDocument.proof 设置为 matchingProofs。
   注：此步骤保护文档和现有 证明

   此步骤添加对命名 图的引用，并添加 证明 图中包含的所有声明的副本。此步骤至关重要， 因为它会在应用当前证明之前，将任何匹配的证明绑定到文档。 本算法后续步骤将更新文档的 proof 值。

7. 运行第 4.2 添加证明 中算法的第 1 到第 6 步，并传入 inputDocument、suite 和 options。如果未引发异常， 则将 生成的 proof 值追加到 allProofs；否则，引发该异常。
8. 将 output.proof 设置为 allProofs 的值。
9. 将 output 作为新的受保护数据文档返回。

以下算法规定如何通过验证数字证明，检查 受保护数据文档的真实性和完整性。 该算法 接受以下输入：

mediaType

[MIMESNIFF] 中定义的媒体类型

documentBytes

一个字节序列， 其媒体类型为 mediaType

cryptosuite

一个cryptosuite 实例

expectedProofPurpose

一个可选字符串，由验证者用于 确保 proof 是由 证明创建者出于预期原因生成的。常用值见 2.2 证明 目的

domain

一个可选的集合，其中包含字符串，由证明 创建者用于将证明锁定到 特定安全域，并由验证者用于确保该证明 不会跨不同安全域使用

challenge

一个可选的字符串challenge，由验证者用于确保 攻击者没有重放先前创建的证明

此算法返回一个验证结果，它是一个结构，其 项为：

verified

true 或 false

verifiedDocument

如果 verified 为 false，则为 Null；否则，为一个输入文档

mediaType

如果 verified 为 false，则为 Null；否则，为一个媒体类型，它 MAY 包含参数

warnings

一个列表，其中包含ProblemDetails，默认为空列表

errors

一个列表，其中包含ProblemDetails，默认为空列表

当某个步骤说“MUST 引发错误”时，意味着 MUST 返回一个验证结果，其中 verified 值为 false，且 errors 列表非空。

1. 令 securedDocument 为对 documentBytes 运行将 JSON 字节解析为 Infra 值的结果。
2. 如果 securedDocument 不是一个映射，或 securedDocument.proof 不是一个映射， 则 MUST 引发错误，并且 SHOULD 传达错误类型 PARSING_ERROR。
3. 令 proof 为 securedDocument.proof。
4. 如果 proof.type、 proof.verificationMethod 和 proof.proofPurpose 中的一个或多个不存在 exist， 则 MUST 引发错误，并且 SHOULD 传达错误 类型 PROOF_VERIFICATION_ERROR。
5. 如果给出了 expectedProofPurpose，且它不匹配 proof.proofPurpose， 则 MUST 引发错误，并且 SHOULD 传达错误 类型 PROOF_VERIFICATION_ERROR。
6. 如果给出了 domain，且它不包含与 proof.domain 相同的字符串（将单个字符串视为只包含 该字符串的集合），则 MUST 引发错误，并且 SHOULD 传达错误类型 INVALID_DOMAIN_ERROR。
7. 如果给出了 challenge，且它不匹配 proof.challenge，则 MUST 引发错误，并且 SHOULD 传达错误类型 INVALID_CHALLENGE_ERROR。
8. 令 cryptosuiteVerificationResult 为使用 securedDocument 作为输入运行 cryptosuite.verifyProof 算法的结果。
9. 返回一个验证结果，其中包含项：

   verified

   cryptosuiteVerificationResult.verified

   verifiedDocument

   cryptosuiteVerificationResult.verifiedDocument

   mediaType

   mediaType

在证明集或证明链中， 受保护数据文档具有一个 proof 属性，其中包含证明列表（allProofs）。以下 算法提供了一种检查 受保护数据文档真实性和完整性的方法， 通过验证 allProofs 中的每个 证明来实现。 也可以采用其他方法，尤其是在只希望验证 allProofs 中所含证明的一个子集时。如果采用另一种方法 只验证证明子集，则需要注意，该子集中任何带有 previousProof 的证明，只有在它引用的证明也被视为已验证时， 才能被视为已验证。

必需输入是受保护数据文档 （securedDocument）。将生成一个 与 allProofs 中每个证明对应的验证结果列表， 并返回一个组合后的单一验证结果作为 输出。 实现 MAY 在组合后的验证结果旁一并返回任何其他验证结果和/或任何 其他元数据。

1. 将 allProofs 设置为 securedDocument.proof。
2. 将 verificationResults 设置为空列表。
3. 对 allProofs 中的每个 proof，执行以下步骤：
   1. 令 matchingProofs 为空列表。
   2. 如果 proof 包含 previousProof 属性，且该 属性的值是一个字符串，则将 allProofs 中 id 属性值与 previousProof 的值匹配的元素添加到 matchingProofs。 如果 allProofs 中不存在 id 值等于 previousProof 值的证明，则 MUST 引发错误，并且 SHOULD 传达错误 类型 PROOF_VERIFICATION_ERROR。如果 previousProof 属性是一个列表，则添加 allProofs 中 id 属性值与该 列表中某个元素的值匹配的每个元素。 如果 previousProof 列表中的任何元素具有的 id 属性 值与 allProofs 中任何元素的 id 属性值都不匹配， 则 MUST 引发错误，并且 SHOULD 传达错误类型 PROOF_VERIFICATION_ERROR。
   3. 令 inputDocument 为移除 proof 值后的 securedDocument 副本， 然后将 inputDocument.proof 设置为 matchingProofs。
      注：保护文档和先前 证明

      请参阅第 4.3 添加证明集/链第 6 步中的注释，以了解 此步骤保护哪些文档属性和先前证明。

   4. 在 inputDocument 上运行第 4.4 验证证明中算法的第 4 到第 8 步；如果未引发异常，则将 cryptosuiteVerificationResult 追加到 verificationResults。
4. 将 successfulVerificationResults 设置为空列表。
5. 令 combinedVerificationResult 为空结构。将 combinedVerificationResult.status 设置为 true，将 combinedVerificationResult.document 设置为 null，并将 combinedVerificationResult.mediaType 设置为 null。
6. 对 verificationResults 中的每个 cryptosuiteVerificationResult：
   1. 如果 cryptosuiteVerificationResult.verified 为 false，则将 combinedVerificationResult.verified 设置为 false。
   2. 否则，将 combinedVerificationResult.document 设置为 cryptosuiteVerificationResult.verifiedDocument，将 combinedVerificationResult.mediaType 设置为 cryptosuiteVerificationResult.mediaType，并将 cryptosuiteVerificationResult 追加到 successfulVerificationResults。
7. 如果 combinedVerificationResult.status 为 false，则将 combinedVerificationResult.document 设置为 null，并将 combinedVerificationResult.mediaType 设置为 null。
8. 返回 combinedVerificationResult、successfulVerificationResults。

密码学通过使用秘密来保护信息。知道必要的秘密会使访问某些信息 在计算上变得容易。如果通过计算上困难的暴力尝试成功猜中该秘密， 也可以访问同一信息。所有现代密码学都要求这种 计算上困难的方法随着时间推移始终保持困难，但由于科学和数学上的 突破，这并不总是成立。也就是说， 密码学有保质期。

本规范通过断言今天使用的任何密码学都很可能会随着时间推移被攻破， 来为所有密码学方法的过时做好准备。软件系统必须能够随着时间推移 改变所使用的密码学，以继续保护信息。此类改变可能 涉及增加所需秘密的大小，或修改所使用的密码学 基元。然而，某些密码学参数的组合 实际上可能降低安全性。基于这些假设，系统需要能够 区分不同的安全密码学参数组合，也称为 加密套件。在标识或版本化 加密套件时，可以采用多种方法， 包括：参数、编号和日期。

参数化版本控制指定加密套件中使用的特定密码学参数。 例如，可以使用诸如 RSASSA-PKCS1-v1_5-SHA1 的标识符。 此方案的好处是，训练有素的密码学家能够通过该 标识符确定所有正在使用的参数。此方案的缺点是，大多数 使用这类标识符的人并未受过良好训练，因此不会理解 前面提到的标识符是一个已不再安全可用的加密套件。 此外，这种知识缺乏可能导致软件 开发者泛化加密套件标识符的解析， 使任何密码学基元组合都变得可接受， 从而降低安全性。理想情况下，加密套件应在软件中 作为特定、可接受的密码学参数配置文件来实现。

编号版本控制可以指定主版本号和次版本号，例如 1.0 或 2.1。编号版本控制传达特定顺序，并暗示 较高版本号比较低版本号更有能力。这种方法的好处 是它移除了经验较少的开发者可能不理解的复杂参数， 并用一个更简单的模型传达可能适合升级的信息。 这种方法的缺点是并不清楚是否有必要升级，因为软件版本号的增加 通常并不要求升级软件才能继续运行。这可能 导致开发者认为他们使用某个特定版本是安全的， 但事实并非如此。理想情况下，应向在软件中使用 加密套件的开发者提供额外信号，说明需要 定期审查这些套件以确认其持续安全性。

基于日期的版本控制为特定加密套件指定一个具体 发布日期。日期（例如年份）的好处在于， 开发者可以立即看出该日期相对较旧还是较新。看到 较旧日期可能促使开发者去寻找更新的 加密套件，而参数化或基于编号的版本控制方案 可能不会。基于日期的版本的缺点是，一些加密 套件可能 5-10 年都不会过期，这会促使开发者去 寻找更新的加密套件，却发现没有更新的可用。 虽然这可能带来不便，但这种不便会带来更安全的 生态系统行为。

现代密码学算法提供许多可调参数和 选项，以确保算法能够满足不同用例的各种需求。 例如，嵌入式系统的处理和内存环境有限， 可能没有资源为给定算法生成最强的数字签名。 其他环境，例如金融交易系统， 可能只需要在交易发生期间保护数据一天，而 其他环境可能需要保护数据数十年。为满足 这些需求，密码学算法设计者通常会提供多种方式来 配置密码学算法。

密码学库实现者通常会采用密码学算法设计者和规范作者创建的 规范，并将其实现为所有选项都可供使用这些 库的应用程序开发者使用。这可能是因为不知道某个 特定应用程序开发者在给定密码学部署中可能需要哪种功能组合。 所有选项通常都会暴露给应用程序开发者。

使用密码学库的应用程序开发者通常不具备 为给定应用程序适当选择密码学参数和选项所需的 必要密码学专业知识和知识。这种专业知识缺乏 可能导致为特定应用程序不当选择密码学参数 和选项。

本规范设定的利益方优先级为：保护应用程序 开发者优先于密码学库实现者，密码学库实现者优先于密码学 规范作者，密码学规范作者优先于密码学算法设计者。基于这些 优先级，提出以下建议：

• 建议密码学算法设计者 [RFC7696] 将选项和参数的 数量尽可能减少到最少，以确保 密码学库实现者的软件库具有更容易审计的安全攻击 面。
• 建议密码学规范作者在可能的情况下，进一步 将选项和参数的数量尽可能减少到最少，以确保 密码学敏捷性，同时也将下游软件库可审计的安全 攻击面保持在最低限度。
• 建议密码学库实现者在可能的情况下，向应用程序开发者提供 已知良好的选项和参数组合。理想情况下，对于任何算法 类别，例如椭圆曲线数字签名，应有两个预设默认配置， 在使用这些预设时不能微调参数和选项。可以向 专家提供库选项，以微调其对库的使用，但应不鼓励一般 应用程序开发者群体使用这些选项。
• 密码学库实现者可以提供已弃用和实验性 密码学功能，但建议仅在开发者明确请求时才这样做， 例如通过库选项，并使该库产生警告，说明已为应用程序 启用已弃用或实验性密码学。
• 建议应用程序开发者从若干预设的 密码学库配置中选择，并避免修改密码学 选项和参数，或使用实验性或已弃用的密码学。

上述指导旨在确保有用的密码学选项和 参数在架构的较低层提供，同时不将这些选项和参数 暴露给可能并不完全理解每个选项的利益与缺点权衡的 应用程序开发者。

第 5.1 加密套件的版本控制强调了 提供相对容易理解的信息来说明特定加密套件时效性的 重要性，而第 5.2 保护应用程序开发者进一步强调了尽量减少 需要指定的选项数量。实际上，第 3. 加密套件 列出了加密套件的要求，其中包括对算法、转换、哈希和序列化的 详细规定。因此，加密套件的名称不需要包含所有这些细节， 这意味着第 5.1 加密套件的版本控制中提到的 参数化版本控制既没有必要 也不可取。

推荐的加密套件命名约定是一个 字符串，它由签名算法标识符组成，如果 cryptosuite 支持不兼容的 实现选项，则再用连字符分隔一个选项标识符， 后面再跟一个连字符和该套件被提出的大致年份标识。

例如，[DI-EDDSA] 基于 EdDSA 数字签名，支持 两个基于规范化方法的不兼容选项，并大约在 2022 年提出， 因此它会有两个不同的 cryptosuite 名称： eddsa-rdfc-2022 和 eddsa-jcs-2022。

尽管 [DI-ECDSA] 基于 ECDSA 数字签名，支持与 [DI-EDDSA] 相同的 两种不兼容规范化方法，并通过两组替代的 椭圆曲线和哈希支持两个不同的安全级别（128 位和 192 位）， 但它只有两个 cryptosuite 名称： ecdsa-rdfc-2019 和 ecdsa-jcs-2019。安全级别以及相应的 曲线和哈希由验证中使用的公钥的 multi-key 格式确定。

密码学敏捷性是一种实践，即设计 经常连接的信息安全系统，使其支持 在多个密码学基元和/或算法之间切换。密码学敏捷性的主要 目标是让系统能够快速适应新的 密码学基元和算法，而无需对 系统基础设施进行破坏性改变。因此，当某个特定密码学基元， 例如 SHA-1 算法，被确定为不再安全可用时，系统可以 通过简单的配置文件更改重新配置为使用更新的基元。

当信息安全系统中的客户端和服务器 定期接触时，密码学敏捷性最有效。然而，当受特定密码学算法 保护的消息具有长期寿命时，例如 可验证 凭证，和/或当客户端（持有者）可能无法轻松 重新联系服务器（发行者）时，密码学敏捷性就无法提供 所需保护。

密码学分层是一种实践，即设计 很少连接的信息安全系统，使其 同时采用多个基元和/或算法。密码学分层的 主要目标是使系统在一个或多个密码学算法或基元失效时仍能 保持有效，而不会失去对载荷的密码学保护。例如，并行使用 RSA、ECDSA 和 Falcon 算法对单个 信息片段进行数字签名，将提供一种机制，使其能够在这三个数字 签名算法中的两个失效时仍能存活。当某个特定的密码学保护被攻破时， 例如使用 768 位密钥的 RSA 数字签名，系统仍然可以利用 未被攻破的密码学保护来继续保护 信息。敦促开发者对所有可能需要保护一年或更长时间的 已签名内容利用此功能。

本规范提供了这两种形式的敏捷性。它提供 密码学敏捷性，使人们能够轻松地从一种算法切换到 另一种算法。它还提供密码学分层，使人们能够 同时使用多个密码学算法，通常是并行使用， 从而任何用于保护信息的算法都可以被使用，而不依赖于 或要求其他算法，同时仍保持数字证明格式 便于开发者使用。

证明包含一个 proofValue，其中可以嵌入若干 与密码学证明相关的参数。例如， 数据完整性 ECDSA 加密套件 v1.0 规范中的选择性披露算法 在 proofValue 中包含多个密码学签名，每个可选择性披露的 项对应一个签名。这样做是为了使 应用程序开发者更容易、更安全地使用该技术。

本规范敦促规范作者使用单个值来抽象 应用层很少需要的信息。就像表达图像的 data: URL 会将许多图像渲染参数封装到 单个值中一样，proofValue 属性（以及其他类似属性） 会抽象那些对应用程序开发者没有用的信息，以便 简化对应用程序重要字段的识别。 以这种方式抽象信息会形成更易于 开发者处理的数据结构，同时也更不容易受到诸如编程错误导致 添加或删除关键属性而造成的意外 损坏，从而负面影响密码学层。

本规范中的数据完整性设计将通常只对 密码学层有用的信息抽象到单个属性中，以减轻 应用程序开发者的负担并增强系统安全性。

有时，在密码学保护过程中转换被保护的数据是有益的。 这种“内联”转换可以使某种特定类型的密码学保护 与其承载的数据格式无关。例如，一些数据完整性加密套件使用 RDF Dataset Canonicalization [RDF-CANON]，它会将初始 表示转换为规范形式 [N-QUADS]，然后对其进行序列化、 哈希和数字签名。只要表达受保护 数据的任何语法都能转换为这种规范形式，数字签名就可以被 验证。这使得同一信息上的同一数字签名能够以 JSON、CBOR、YAML 和其他兼容语法表达，而无需 为每种语法创建一个密码学证明。

能够在多种语法之间表达同一数字签名是有益的， 因为系统通常具有其运行所使用的原生数据格式。 例如，一些系统面向 JSON 数据编写，而另一些 系统面向 CBOR 数据编写。没有转换时，内部以 CBOR 处理 数据的系统必须将数字签名的数据 结构存储为 JSON（反之亦然）。这会导致重复存储数据，并且如果 数据库中存储的未签名表示意外偏离已签名表示， 可能导致安全攻击面增大。通过使用 转换，数字证明可以存在于原生数据格式中，以 帮助防止随着时间推移出现本来无法检测的数据库漂移。

本规范被设计为通过利用“内联”数据转换，避免要求重复 已签名信息。敦促应用程序开发者 在其应用程序的原生数据格式中处理受密码学保护的数据，并且不要 将密码学证明与被保护数据分开存储。还敦促开发者 定期确认受密码学保护的数据在写入和 从应用程序存储读取时未被篡改。

一些转换，例如 RDF Dataset Canonicalization [RDF-CANON]，具有 缓解措施，用于处理攻击者可用来消耗 过多处理周期的输入数据集。这类攻击称为 数据集投毒，并且所有 现代 RDF Dataset 规范化器都要求检测这些类型的恶意 输入并停止处理。RDF Dataset Canonicalization 的测试套件 包含此类投毒数据集，以确保所有 一致实现中都存在此类缓解措施。一般来说，使用转换的 加密套件规范需要缓解这些类型的 攻击，并敦促实现者确保他们使用的软件库 强制执行这些缓解措施。这些攻击与任何资源耗尽攻击属于同一大类， 例如故意放慢连接速度的 HTTP 客户端，从而使服务器上的连接资源 枯竭。建议实现者在实施 防御性安全策略时考虑这些类型的攻击。

由任何数据完整性证明保护的数据是 已转换数据。已转换数据 由特定cryptosuite指定的转换算法 生成。该保护机制不同于一些 更传统的数字签名机制，后者不会对输入数据执行任何形式的 转换。转换的好处 详见第 5.6 转换。

例如，cryptosuites，如 ecdsa-jcs-2019 和 eddsa-jcs-2022，使用 JSON 规范化方案（JCS）将数据转换为规范化 JSON， 然后对其进行密码学哈希和数字签名。此 方法的一个好处是，添加或删除不会影响被签名信息 含义的格式字符，例如空格、制表符和换行符， 不会使数字签名失效。更传统的数字签名 机制不具备这种能力。

其他cryptosuites，如 ecdsa-rdfc-2019 和 eddsa-rdfc-2022，使用 RDF Dataset Canonicalization 将 数据转换为规范化的 N-Quads [N-QUADS]，然后对其进行密码学哈希和 数字签名。此方法的一个好处是，密码学签名 可移植到多种不同语法中，例如 JSON、YAML 和 CBOR， 而不会使签名失效。更传统的密码学签名 机制不具备这种能力。

敦促实现者和开发者不要信任 包含数据完整性证明的信息，除非该证明已被验证 并且已验证数据由软件库的返回值提供， 该软件库已确认返回的所有数据均已成功受到保护。

应用程序数据的可检查性会影响系统效率和 开发者生产力。当受密码学保护的应用程序数据，例如 base 编码二进制数据，无法被应用程序子系统 （例如数据库）轻松处理时，会增加处理受密码学 保护信息的工作量。例如，可以由数据库原生存储和索引的 受密码学保护载荷会产生一个更简单的系统，该系统：

• 受益于利用现有行业标准数据库功能，且无需 更改受保护信息，
• 避免重复数据的复杂性，其中一份数据副本保留 消息和数字签名，而另一份副本仅存储和索引 消息，并且是驱动系统行为的内容，
• 避免定制解决方案的复杂性，这些方案必须结构性地修改 受保护信息，例如序列化和反序列化嵌套的 数字签名数据，该数据具有多个嵌套的 base 编码载荷。

类似地，可以由多个上游联网系统处理的受密码学保护载荷 会增强适当分层安全架构的能力。例如，如果上游系统无需 反复解码传入载荷，则会增强系统通过专门化上游子系统来分发 处理负载并主动对抗攻击的能力。虽然数字签名 始终需要在采取实质性行动之前检查，但可以对透明 载荷执行其他上游检查——例如基于标识符的速率限制、 签名过期检查，或 nonce/challenge 检查——以拒绝明显恶意的请求。

此外，如果开发者无法轻松查看系统中的数据， 轻松审计或调试系统正确性的能力就会受到阻碍。例如， 要求应用程序开发者剪切并粘贴 base 编码的应用程序数据 会使开发更加困难，并增加明显 bug 被遗漏的可能性， 因为每条消息都需要通过手动操作的 base 解码工具。

然而，有时正确的设计决策是使数据 不透明。不需要由其他应用程序子系统处理的数据， 以及不需要由应用程序开发者修改或访问的数据， 可以序列化为不透明格式。示例包括数字 签名值、密码学密钥参数，以及其他只 需要由密码学库访问而不需要由 应用程序开发者修改的数据字段。还有一些示例中，数据不透明性是合适的， 例如底层子系统不会将应用程序开发者暴露给 不透明数据的底层复杂性，如执行 静态加密的数据库。在这些情况下，应用程序开发者继续 面向透明应用程序数据格式开发，而数据库则管理 将应用程序数据加密和解密到长期存储及从长期存储中取回的复杂性。

本规范力求提供一种架构，其中应用程序数据 保持其原生格式且不会变为不透明，而其他密码学 数据（例如数字签名）则保持其不透明的二进制编码形式。 敦促加密套件实现者在设计其套件时考虑适当使用数据 不透明性，并在使应用程序数据不透明与在 应用层提供对密码学数据的访问之间权衡设计取舍。

实现者通过从验证方法的定义转到 受控标识符 文档，然后确保该受控标识符 文档也 包含对验证方法的引用，来确保 验证方法绑定到特定 控制者。此过程 在用于 检索验证方法的算法中描述。

当实现正在验证证明时，它必须 验证的不仅是用于生成证明的验证方法是否列在 受控标识符 文档中，还必须验证它 预期用于生成正在验证的证明。此过程 称为“验证关系验证”。

验证关系的验证过程概述于 受控标识符 v1.0 规范的第 3.3 检索验证方法。

此过程用于确保密码学材料，例如私有 密码学密钥，不会被应用程序误用于非预期目的。 密码学材料误用的示例是，本应被用于签发 可验证凭证的私有密码学 密钥，反而被用于 登录网站（即用于认证）。不检查验证关系是危险的， 因为某些密码学材料的限制和保护配置文件可能由其预期用途确定。 例如，一些应用程序可能被信任为仅将密码学材料用于 一个目的，或者某些密码学材料可能受到更强保护， 例如存储在数据中心的硬件安全模块中， 而不是作为笔记本电脑上的未加密文件。

当实现正在验证证明时，它必须 验证证明目的是否匹配预期用途。

此过程用于确保证明不会被应用程序误用于 非预期目的，因为这对证明创建者是危险的。 误用的示例是，如果某个证明声明其目的是保护 可验证凭证 中的断言，却反而被用于认证以 登录网站。在这种情况下，证明创建者将证明附加到任意数量的 可验证凭证上， 并期望它们分发给 不受限制数量的其他方。如果网站错误地将此类证明接受为 认证而非其预期目的， 这些任一方都可能以证明创建者的身份登录网站。

转换（例如规范化）的执行方式可能会 影响系统的安全特性。选择最佳 规范化机制取决于用例。通常， 满足所需安全要求的最简单机制 是最佳选择。本节试图提供简单指导，以帮助 实现者在本规范提到的两个主要规范化机制之间进行选择， 即 JSON Canonicalization Scheme [RFC8785] 和 RDF Dataset Canonicalization [RDF-CANON]。

如果应用程序只使用 JSON，且不依赖任何形式的 RDF 语义，那么使用采用 JSON Canonicalization Scheme [RFC8785] 的加密套件是一种有吸引力的方法。

如果应用程序使用 JSON-LD，并需要保护 文档的语义，那么使用采用 RDF Dataset Canonicalization [RDF-CANON] 的加密套件是一种有吸引力的 方法。

还建议实现者注意，还有其他不执行 转换的机制可用，它们通过将数据包装在 密码学信封中而不是将证明嵌入数据来保护数据，例如 JWT [RFC7519] 和 CWT [RFC8392]。 这些方法在某些用例中具有简单性 优势，但会牺牲本规范详述方法所提供的一些好处。

本规范使用的算法过程之一是规范化， 它是一种转换。规范化是指 以可能用多种语义上等价方式表达的信息作为输入， 并将所有输出表达为单一方式，即 “规范形式”的过程。

利用规范化的最终数据完整性证明的安全性 高度依赖于算法的正确性。例如， 如果规范化算法将具有不同含义的两个输入 转换为相同输出，那么作者的意图可能会被 错误地表示给验证者。这可以被 对手用作攻击向量。

此外，如果输入中语义相关的信息没有出现在 输出中，那么攻击者可以在消息中插入此类信息 而不会导致证明验证失败。这类似于另一种 在对消息进行密码学签名时常用的转换： 密码学哈希。如果攻击者能够从不同输入生成相同的 密码学哈希，则该密码学哈希算法不被 认为是安全的。

强烈敦促实现者确保对任何将用于将输入转换到 哈希 过程的规范化算法进行适当审查。适当审查至少包括 与经过同行评审的算法正确性数学证明相关联；最好有多个实现， 并由标准制定组织中的专家进行审查。强烈敦促实现者 不要发明或使用新机制，除非他们接受过信息规范化方面的正式 培训，和/或可以接触到该领域中能够产生经过同行评审的 算法正确性数学证明的专家。

本规范的设计方式是，在一致的受保护文档上验证证明时， 不需要任何网络请求。 然而，读者可能会注意到，JSON-LD 上下文 和验证 方法可能包含可通过网络连接 检索的 URL。对于验证期间或验证之后可能 从网络加载的任何 URL，都存在这种担忧。

在尽可能的范围内，敦促实现者永久或积极地 缓存此类信息，以减少可能需要通过网络获取此类 URL 的实现的 攻击面。例如， JSON-LD 上下文的缓存技术在第 2.4 上下文和词汇表中描述，而某些验证 方法，例如 did:key [DID-KEY]，完全不需要从网络获取。

当无法使用缓存信息时，例如第一次遇到基于特定 HTTP URL 的验证方法实例时， 告诫实现者在任何可能从网络获取资源的过程中使用防御性措施， 以缓解 拒绝服务攻击。

由于本规范描述的用于保护文档的技术 本质上是通用的，其使用所带来的安全影响可能并不会 立即被读者察觉。为了理解在完整软件系统中可能需要考虑的 安全问题类型，敦促实现者阅读该技术在 可验证凭证 生态系统中的使用方式 [VC-DATA-MODEL-2.0]；更多信息见 可验证凭证安全考量章节。

当数字签名载荷包含会被多个 验证者看到的数据时，它会成为一个关联点。此类数据的示例是 购物会员卡号。可关联数据可被验证者用于跟踪 目的，有时可能违反隐私期望。某些数据可用于跟踪这一事实 可能并不立即显而易见。此类可关联数据的示例包括但不限于 静态数字签名或图像的密码学哈希。

可以创建一种数字签名载荷，它不包含任何 可关联的跟踪数据，同时仍提供某种程度的保证，使得该 载荷在给定交互中可信。此特性称为 不可关联性，它确保数字签名载荷中不使用任何可关联 数据，同时仍提供某种程度的 信任，其充分性必须由每个验证者来确定。

重要的是要理解，并非所有用例都需要甚至允许 不可关联性。有些用例因监管或安全原因而 需要可关联性和关联，例如关联运输和储存危险材料的 组织和个人。当某次特定交互存在隐私期望时，不可关联性 是有用的。

至少有两种机制可以提供某种程度的不可关联性。 第一种方法是确保消息中使用的任何数据值都不会 在未来消息中重复。第二种方法是确保任何重复数据 值都能提供足够的群体隐私，从而使关联在该交互中期望某种隐私水平的实体 在实践上变得不可能。

可以使用多种方法来实现不可关联性。这些方法包括 确保消息是一次性 bearer token，且不包含任何 可用于关联目的的信息；使用能够确保 足够群体隐私水平的属性；以及使用使 展示消息的实体能够重新生成新签名而不损害 所展示消息可信性的 cryptosuites。

选择性披露是一种技术，它使先前已签名消息 （即由其创建者签名的消息）的接收者能够只揭示 该消息的部分内容，而不破坏这些 部分的可验证性。例如，人们可能会为了租车而选择性披露数字驾驶证。 这可能涉及只揭示签发 机构、驾驶证号码、生日和授权机动车类别。 注意，在这种情况下，驾驶证号码是可关联 信息，但由于驾驶员的全名和地址没有共享， 仍保留了一定程度的隐私。

并非所有软件或 cryptosuites 都能够提供选择性披露。 如果消息作者希望其消息可由接收者进行选择性披露， 那么他们需要在该特定消息上启用选择性披露， 并且双方都需要使用具备该能力的 cryptosuite。作者也可以 强制要求披露消息的某些部分。想要 选择性披露消息部分内容的接收者需要使用 能够执行该技术的软件。支持选择性披露的 cryptosuite 示例是 bbs-2023。

可以以不保留不可关联性的方式选择性披露信息。 例如，人们可能希望披露与某批货物相关的检查 结果，其中包括货物标识符或批号， 由于监管要求，这些信息可能必须是可关联的。 然而，披露完整检查结果可能并非必要，因为 只选择性披露通过/未通过状态可能被认为已经足够。 有关在保护隐私的同时披露信息的更多信息，见第 6.1 不可关联性。

当使用第 2.1.2 证明 链中定义的 previousProof 功能时， 实现需要对一个或多个先前证明进行数字签名， 以便将它们包含在受保护载荷中。这不可避免地暴露 与添加先前证明的每个实体相关的信息。

至少，先前证明的验证方法， 例如公钥，会被证明链中下一个证明的创建者看到。 如果先前证明的创建者并不打算被包含在证明链中， 这可能成为隐私问题，但当 向任何类型的文档添加不可否认的数字签名时，这是一种不可避免的结果。

可以使用更高级的密码学机制，例如 群签名， 来隐藏消息签名者的身份， 数据完整性加密套件也可以 缓解这一隐私问题。

对于在证明验证期间或之后可能从网络加载的任何 URL， 都存在指纹识别方面的担忧。本 规范的设计方式是，在一致的受保护文档上验证证明时 不需要网络请求。 然而，读者可能会注意到，JSON-LD 上下文和 验证 方法可能包含可通过网络连接检索的资源 URL， 从而导致指纹识别方面的担忧。

例如，一致的受保护文档的创建者 可能会为JSON-LD 上下文和 验证 方法制作每个文档唯一的 URL。在验证此类文档时，从网络获取 该信息的验证者会向文档创建者暴露其对 一致的受保护文档的兴趣，这可能导致 任何非文档创建者的实体产生隐私期望不匹配。

敦促实现者遵循第 5.14 网络 请求 中关于 URL 缓存和在从网络获取 URL 时进行防御性实现的指导。 鼓励使用诸如 Oblivious HTTP 之类的技术从网络检索资源，而不暴露 发出请求的客户端。此外， 可以使用启发式方法来确定一致的受保护文档的创建者 是否以可能违反隐私期望的方式使用指纹识别 URL。 这些启发式方法可用于向可能 处理包含疑似指纹识别 URL 的文档的实体显示警告。

转换（即规范化）的执行方式可能 影响系统的隐私特性。选择最佳 规范化机制取决于用例。 本节试图从隐私角度提供简单指导， 帮助实现者在本规范提到的两个主要规范化机制之间作出选择， 即 JSON Canonicalization Scheme [RFC8785] 和 RDF Dataset Canonicalization [RDF-CANON]。

如果应用程序不需要对受保护文档中的 信息执行选择性披露，也不使用 JSON-LD，那么 JSON Canonicalization Scheme [RFC8785] 是一种有吸引力的方法。

如果应用程序使用 JSON-LD，并且可能需要对受保护文档中的 信息进行选择性披露，那么使用采用 RDF Dataset Canonicalization [RDF-CANON] 的加密套件是一种有吸引力的 方法。

还建议实现者注意，其他不执行转换的选择性披露机制 也是可用的，它们通过将数据包装在 密码学信封中而不是将证明嵌入数据来保护数据，例如 SD-JWT [SD-JWT]。这种方法在某些用例中具有简单性 优势， 但会牺牲本规范详述方法所提供的一些好处。

由于本规范描述的用于保护文档的技术 本质上是通用的，其使用所带来的隐私影响可能并不会 立即被读者察觉。为了理解在完整软件系统中可能需要考虑的 隐私问题类型，敦促实现者阅读该技术在 可验证凭证 生态系统中的使用方式 [VC-DATA-MODEL-2.0]；更多信息见 可验证凭证隐私考量章节。

本规范支持表达与密码学证明有效期相关的 日期和时间。如果证明被处理并被检测到超出 允许的时间范围，此信息可能会间接 暴露给个人。在向个人暴露这些日期和时间时， 敦促实现者在显示软件中考虑 表示日期和时间时的文化规范和语言环境。 除这些考量外，以减轻接收信息个人的认知负担的方式 呈现时间值是一项建议的最佳实践。

例如，在传达某组 数字签名信息的过期日期时，敦促实现者使用 更容易理解的语言来呈现过期 时间，而不是使用为准确性优化的语言。将过期时间呈现为 “这张票已在三天前过期。”优于诸如“这张票已于 2023 年 7 月 25 日下午 3:43 过期。”这样的表述。前者提供了更容易 理解的相对时间，而后者要求个人在脑中进行 计算，并假定他们有能力进行这种 计算。