可验证凭证伪造防御 v1.0

见证列表凭证是一个 可验证 凭证，其 credentialSubject 的类型为 WitnessList，并直接携带见证列表属性 （witnessSeed、witnessLength、 witnessCount 和 encodedWitnesses）。签发者 SHOULD 使用 单独的密钥对——并且 MAY 使用后量子签名方案——来 签署见证列表凭证，因为只有在普通签名密钥 遭到攻破后仍可验证时，其提供的保护 才有意义。

该凭证的 type 数组 MUST 包含 WitnessListCredential。

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/vc-forgery-defense/v1rc1"
  ],
  "id": "https://issuer.example/witnesses/1",
  "type": ["VerifiableCredential", "WitnessListCredential"],
  "issuer": "did:example:issuer",
  "validFrom": "2024-01-15T00:00:00Z",
  "credentialSubject": {
    "type": "WitnessList",
    "witnessSeed": "26ea4078-968d-4d98-aba7-695610c0dfb6",
    "witnessLength": 128,
    "witnessCount": 131072,
    "encodedWitnesses": "uQYF16SSSbR_LrMZFbFvbGkn8B7ggEZtov3KVL..."
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "comment": "MAY use a post-quantum cryptosuite here",
    "verificationMethod": "did:example:issuer#pq-key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z..."
  }
}

当签发者通过空间受限的媒介（例如在 Web 上分发大型凭证） 分发 WitnessListCredentials 时， RECOMMENDED 将其进行 CBOR-LD 编码并作为字节传输。

在显式模式下使用时，受保护的可验证 凭证 MAY 在其 credentialStatus 数组中包含一个见证列表 条目（或将其作为唯一的 credentialStatus 值）。

该条目的 type MUST 为 WitnessListEntry。 按照 可验证凭证位串状态 列表的 statusListCredential 属性模式，该条目通过显式的 witnessListCredential 属性引用其 见证列表凭证，该属性的值是 该凭证的 URL。条目的 id（如果存在）是该条目的 OPTIONAL 唯一标识符，不用于定位列表。

witnessListCredential

REQUIRED。一个 URL，解引用后得到此凭证的见证列表 凭证。该属性类似于 可验证凭证位串 状态列表中的 statusListCredential。

witnessIndex

REQUIRED。一个正整数（从 1 开始），指定此 凭证的见证在被引用列表中的位置。MUST 大于 0，且 MUST NOT 超过 witnessCount。

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/vc-forgery-defense/v1rc1"
  ],
  "id": "https://issuer.example/credentials/1234",
  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
  "issuer": "did:example:issuer",
  "validFrom": "2024-01-15T00:00:00Z",
  "credentialStatus": [
    {
      "id": "https://issuer.example/status/1#94567",
      "type": "BitstringStatusListEntry",
      "statusPurpose": "revocation",
      "statusListIndex": "94567",
      "statusListCredential": "https://issuer.example/status/1"
    },
    {
      "type": "WitnessListEntry",
      "witnessListCredential": "https://issuer.example/witnesses/1",
      "witnessIndex": 94567
    }
  ],
  "credentialSubject": {
    "id": "did:example:holder",
    "degree": {"type": "BachelorDegree", "name": "Computer Science"}
  },
  "proof": { ... }
}

以下算法为一组 N 个凭证哈希生成见证列表。输入：一个包含 N 个哈希的数组， 按照所需的 witnessIndex 值的顺序排列， 以及见证长度 b（默认 128）。输出： 见证种子和编码见证。

1. 使用密码学安全的随机数生成器生成 UUID v4 值 seed [RFC4122]。
2. 令 seedBytes 为 seed 的 16 字节表示， 通过将其十六进制数字（去除连字符）按大端 字节序列解码得到。
3. 令 data 为一个长度为 N × b 位的全零位数组。
4. 对从 0 到 N-1（含）的每个整数 i：
   1. 令 msg 为输入 数组中的第 i 个凭证哈希。
   2. 令 hash 为 SHA-256 [FIPS-180-4] 应用于 串联值 seedBytes || msg 的输出。
   3. 令 w 为 hash 中最高有效的 b 位。
   4. 将 w 按最高有效位优先写入 data， 位偏移为 (i − 1) × b。
5. 令 encodedWitnesses 为 data 的 multibase-base64url 编码， 并在前面加上前缀字符 u [MULTIBASE]。
6. 返回 seed 和 encodedWitnesses。

以下算法将 生成见证列表的输出包装到 一个已签名的可验证凭证中。

1. 使用输入 N 和 b 运行生成见证列表， 生成 seed 和 encodedWitnesses。
2. 构造一个未签名凭证，其中：
   • type 包含 WitnessListCredential
   • credentialSubject.type 设置为 WitnessList
   • credentialSubject.witnessSeed 设置为 seed
   • credentialSubject.witnessLength 设置为 b
   • credentialSubject.witnessCount 设置为 N
   • credentialSubject.encodedWitnesses 设置为 encodedWitnesses
3. 对该凭证进行签名。如果需要防范密钥攻破——包括 量子密钥攻破——签发者 SHOULD 使用 后量子签名方案，并使用不同于签署受保护凭证 所用密钥对的密钥对。
4. 返回已签名凭证。

以下算法验证给定凭证的见证 是否有效。输入：已解析的见证列表凭证、一个 凭证 哈希，以及见证索引 i。

1. 验证见证列表凭证上的所有证明。如果 任一 证明失败，则返回错误。
2. 令 subject 为见证列表凭证的 credentialSubject。
3. 令 seed 为 subject.witnessSeed。
4. 令 b 为 subject.witnessLength。
5. 令 N 为 subject.witnessCount。
6. 如果 i < 1 或 i > N，则返回一个错误， 表示索引超出范围。
7. 令 encodedWitnesses 为 subject.encodedWitnesses。
8. 验证 encodedWitnesses 是否以字符 u 开头。如果不是，则返回错误。
9. 令 data 为对 encodedWitnesses 第一个字符之后的子字符串进行 base64url 解码的结果。
10. 从 data 中提取偏移 (i − 1) × b 到 i × b − 1 的位，按最高有效位优先。 令其为 storedW。
11. 令 seedBytes 为 seed 的 16 字节表示， 通过将其十六进制数字（去除连字符）按大端 字节序列解码得到。
12. 令 msg 为输入凭证哈希。
13. 令 hash 为 seedBytes || msg 的 SHA-256 [FIPS-180-4] 值。
14. 令 computedW 为 hash 中最高有效的 b 位。
15. 如果 storedW 等于 computedW，则返回 valid。否则返回 invalid。

在隐式模式下，受保护凭证不作修改。 凭证本身不出现对见证列表的引用。 验证者使用带外信息定位见证列表—— 通常从凭证现有的 credentialStatus 条目派生——并复用状态列表索引 作为见证索引。

此模式要求：

• 受保护凭证具有一个 BitstringStatusListEntry （或等效项），其索引与 见证列表中的位置一一对应。
• 签发者发布一种发现机制——例如 well-known 端点或其 DID 文档中的条目——用于将给定状态 列表 URL 映射到相应的见证列表凭证 URL。

// Protected credential has:
//   credentialStatus.statusListCredential = "https://issuer.example/status/1"
//   credentialStatus.statusListIndex      = "94567"

// Verifier discovers witness list URL from issuer metadata:
// GET https://issuer.example/.well-known/witness-lists
// -> { "https://issuer.example/status/1":
//      "https://issuer.example/witnesses/1" }

// Witness index = 94567 (same as status list index)
// Run: Verify a Credential Witness with i = 94567

在显式模式下，受保护凭证在其 credentialStatus 中包含一个 见证列表条目。 该 条目的 witnessListCredential 属性给出 见证列表凭证 URL，并且 witnessIndex 指定列表中从 1 开始的位置。不需要发现机制。

显式模式 MAY 与其他 credentialStatus 条目共存（例如用于撤销的 BitstringStatusListEntry）。 如果二者同时存在，witnessIndex 不必等于 状态列表索引。

在独立模式下，见证列表 独立于任何状态列表基础设施使用。将 见证索引分配给凭证的方式由具体 应用或用例定义。见证列表凭证 MAY 从凭证、应用层记录或外部 注册表中引用——引用机制不在本 规范范围内。

具备量子能力的对手可以恢复与 传统（例如 ECDSA）公钥对应的私钥。如果签发者已经 使用后量子签名方案签署了见证列表凭证， 那么只要后量子密钥保持安全，验证者即使在 该列表中凭证的签名密钥被破解之后，仍然可以信任该见证列表。

当见证列表凭证所涵盖的凭证具有重要 价值或长期有效性时，签发者 SHOULD 使用后量子 签名方案对见证列表凭证进行签名。

见证种子出现在见证列表凭证的 credentialSubject 中，并且 对任何获得该见证列表凭证的一方可见。 这是有意设计的——验证者需要该种子来重新计算见证。 希望将验证限制在特定验证者集合内的签发者 SHOULD 相应地限制见证列表凭证的分发。

索引 i 处的伪造凭证通过见证验证的概率为 2^−b，其中 b 是 见证长度。在默认值 b = 128 时， 该概率约为 2.9 × 10⁻³⁹。

实现 MUST NOT 接受小于 32 的 b 值。对于具有重要价值的凭证， RECOMMENDED 的最小值为 64。

见证 SHOULD 以通常抗碰撞的方式计算， 但它们 MUST 以抗第二原像的方式计算。

验证者 MUST 在信任见证列表 凭证 的内容之前，验证其证明。验证者 SHOULD 在其有效期内缓存已解析的见证 列表凭证，以减少网络暴露和 拒绝服务风险。

将 witnessCount 精确设置为列表所涵盖的已签发 可验证凭证 数量，会以两种方式泄露有关签发者 流程的信息：

• 某一时刻的见证总数会告诉攻击者 该时刻存在多少已签发的 VC。
• 随时间跟踪见证总数会告诉攻击者 每单位时间签发了多少 VC。

为缓解第一种泄露，签发者 SHOULD 使用固定的 witnessCount 值，使得所有见证列表中的见证总数 不发生变化，并随着时间推移，将任意数据见证占位符 替换为对应于 VC 的见证。

这足以缓解第一种泄露——然而，攻击者仍可能通过跟踪 哪些见证值随时间发生变化，来追踪有多少见证是“真实”的，以及签发了多少 VC。 为解决此问题，签发者 MUST 在每次更新 WitnessListCredential 时重新生成随机见证种子。

能够用修改版本替换已发布见证列表凭证的攻击者 可以绕过防伪机制。签发者 MUST 通过受完整性保护的 通道发布见证列表凭证，并且 SHOULD 使用较短有效期并结合频繁 重新签发。

签发者是见证列表凭证的唯一作者， 并且 REQUIRED 在每次 列表更新时重新生成见证种子 （参见7.5 签发者信息泄露）。因此，签发者 可以通过发布新的见证列表凭证来否认其先前签发的凭证，在该凭证中， 那个凭证的见证缺失或被改变：对最新列表重新计算 见证的验证者会得到 不匹配结果，并拒绝一个原本真实的凭证。与伪造不同， 这种行为可由合法签发者执行，且不能仅凭该机制 防止，因为每个发布的列表都是一个 有效签名的凭证。

要求签发证据能够经受后续 否认的依赖方 SHOULD 保留（缓存或归档） 其所依赖的见证列表凭证，连同其 证明和有效期。由于每个 见证列表凭证本身都是一个带有 validFrom 值的已签名 可验证凭证， 因此，针对在 否认之前发布的列表完成验证的凭证，仍可证明其在该较早 列表时是真实的——缓存的已签名列表是持久证据，表明签发者 在当时对该凭证进行了证明。对已发布列表进行独立归档、 公证或透明日志见证， 通过使签发者的发布历史 不可否认来加强这一保证。

witnessCount 值会泄露批次中 凭证的最大数量。签发者 MUST 使用较大的集合大小（至少 131072 个条目），以确保个别持有者无法通过其在 列表中的位置被识别。此类集合中的所有槽位都必须填充，无论 用于创建见证的哈希是否对应于 可验证凭证。

获取见证列表凭证会产生一个网络请求， 可能向主机暴露正在进行验证这一事实。验证者 SHOULD 缓存见证列表凭证，并且 MAY 在获取列表时使用 保护隐私的 网络传输。签发者 SHOULD 通过 CDN 或内容寻址系统提供见证 列表，以降低关联 能力。