什么是可验证凭证？

在现实世界中，凭证可能包括：

• 与凭证主体相关的身份信息（例如，照片、姓名或身份证号）
• 与颁发机构相关的信息（例如，市政府、国家机构或认证机构）
• 与此凭证类型相关的信息（例如，荷兰护照、美国驾驶执照或健康保险卡）
• 由颁发机构关于主体的特定属性或属性的相关信息（例如，国籍、有资格驾驶的车辆类别或出生日期）
• 与凭证衍生的证据相关的信息
• 与凭证约束相关的信息（例如，有效期或使用条款）。

可验证凭证可以表示与实体凭证相同的所有信息。数字签名等技术的添加使可验证凭证比实体凭证更具篡改证据和更值得信赖。

可验证凭证的持有者可以生成可验证展示，然后与验证者共享这些可验证展示，以证明他们具有某些特征的可验证凭证。

可验证凭证和可验证展示可以快速传输，使它们在远程建立信任时比实体凭证更方便。

虽然本规范试图改进表达数字凭证的便利性，但它还试图平衡这一目标与一系列保护隐私的目标。数字信息的持久性以及不同数字数据来源的收集和关联的便利性，构成了使用可验证且易于机器阅读的凭证可能加剧的隐私问题。本文档在部分概述并试图解决这些问题。本文档还提供了如何使用保护隐私的技术（例如零知识证明）使用此数据模型的示例。

术语可验证凭证和可验证展示中的“可验证”是指凭证或展示具有可由验证者验证的特性，如本文档所定义。凭证的可验证性并不意味着其中编码的声明是真实的。相反，在建立可验证凭证或可验证展示的真实性和时效性后，验证者使用自己的业务规则验证包含的声明，然后才依赖它们。这种依赖仅在评估发行者、证明、主题和声明之后，根据一个或多个验证者策略进行。

生态系统概述

本节描述了核心参与者的角色以及在可验证凭证预期有用的生态系统中它们之间的关系。角色是一个抽象，可以用许多不同的方式实现。角色的分离表明了可能的接口和协议标准化。本规范引入了以下角色：

[=持有者=]（持有者）

通过拥有一个或多个可验证凭证并从中生成可验证展示来执行的实体角色。示例持有者包括学生、员工和客户。

[=发行者=]（发行者）

实体执行的角色，通过对一个或多个主体进行声明，从这些声明中创建可验证凭证，并将可验证凭证传输给持有者。示例发行者包括公司、非营利组织、行业协会、政府和个人。

[=主体=]（主体）

进行声明的实体。示例主体包括人类、动物和事物。在许多情况下，可验证凭证的持有者是主体，但在某些情况下不是。例如，父母（持有者）可能持有孩子（主体）的可验证凭证，或者宠物主人（持有者）可能持有他们宠物（主体）的可验证凭证。有关这些特殊情况的更多信息，请参阅可验证凭证实施指南[[VC-IMP-GUIDE]]中的 主体-持有者关系部分。

[=验证者=]（验证者）

通过接收一个或多个可验证凭证（可选地在可验证展示中）进行处理的实体角色。示例验证者包括雇主、安全人员和网站。

[=可验证数据注册表=]（可验证数据注册表）

系统可能通过调解创建和验证标识符、密钥和其他相关数据（如可验证凭证模式、撤销注册表、发行者公钥等）来执行的角色，这些数据可能需要使用可验证凭证。某些配置可能需要可关联的主体标识符。示例可验证数据注册表包括可信数据库、分布式数据库、政府ID数据库和分布式分类帐。通常，在生态系统中会使用多种类型的可验证数据注册表。

上面的提供了一个示例生态系统，以便将本规范的其他概念固定下来。其他生态系统（如受保护的环境或专有系统）也存在，其中可验证凭证也具有优势。

声明

一个[=声明=]是关于一个[=主体=]的陈述。一个[=主体=]是可以对其进行[=声明=]的事物。[=声明=]使用主体- 属性-值关系来表示。

如上图所示，[=声明=]的数据模型非常强大，可以用来表示各种各样的陈述。例如，某人是否从某个特定大学毕业，可以如下图所示表示。

单个[=声明=]可以合并在一起，以表达关于[=主体=]的信息[=图=]。下图中的示例通过添加Pat认识Sam的[=声明=]以及Sam被雇佣为教授的[=声明=]来扩展之前的[=声明=]。

到目前为止，已经介绍了[=声明=]和信息[=图=]的概念。为了能够信任[=声明=]，预计将向图中添加更多信息。

凭证

一个[=凭证=]是由相同的[=实体=]做出的一个或多个[=声明=]的集合。[=凭证=]还可能包括一个标识符和元数据，用于描述[=凭证=]的属性，如[=发行者=]、有效日期和时间段、代表性图像、[=验证材料=]、吊销机制等。元数据可能由[=发行者=]签名。一个[=可验证凭证=]是一个防篡改的[=声明=]和元数据的集合，可以加密地证明谁发行了它。

[=可验证凭证=]的示例包括数字员工身份证、数字出生证明和数字教育凭证。

[=凭证=]标识符通常用于识别特定实例的[=凭证=]。这些标识符也可以用于关联。希望最小化关联的[=持有者=]建议使用一种选择性披露方案，该方案不会泄露[=凭证=]标识符。

上面显示了一个[=可验证凭证=]的基本组件，但抽象了关于如何将[=声明=]组织成信息[=图=]的细节，然后将其组织成[=可验证凭证=]。

下面显示了一个使用基于[[?VC-DATA-INTEGRITY]]的[=嵌入式证明=]的更完整的[=可验证凭证=]描述。它由至少两个信息[=图=]组成。 这些信息[=图=]中的第一个，即[=可验证凭证图=]（它是[=默认图=]），通过[=凭证=]元数据和其他[=声明=]来表达[=可验证凭证=]本身。 第二个信息[=图=]，由`proof`属性引用，是[=可验证凭证=]的证明图，是一个单独的[=命名图=]。 [=证明图=]表达了数字证明，这种情况下是数字签名。

下面显示了与相同的可验证凭证， 但使用基于[[?VC-JOSE-COSE]]的JOSE。负载包含一个信息图，即可验证凭证图，其中包含凭证元数据和其他声明。

可以有一个[=凭证=]，例如结婚证凭证，其中包含关于不同[=主体=]的多个[=声明=]，这些主题不需要相关。

可以有一个[=凭证=]，其中不包含关于发行[=凭证=]的[=实体=]的任何[=声明=]。例如，一个只包含关于特定的某只狗的[=声明=]，但发给其主人的[=凭证=]。

展示

增强隐私是本规范的一个关键设计特性。因此，对于使用这项技术的[=实体=]来说，能够仅表达适用于特定情境的个人形象的部分非常重要。一个人形象的子集被称为[=可验证展示=]。不同形象的例子包括一个人的专业形象、他们的在线游戏形象、他们的家庭形象或匿名形象。

一个[=可验证展示=]是由[=持有者=]创建的，可以表达来自多个[=可验证凭证=]的数据，并且可以包含编码为JSON-LD的任意额外数据。它们被用于向[=验证者=]展示[=声明=]。也可以直接展示[=可验证凭证=]。

[=展示=]中的数据通常与同一个[=主体=]有关，但可能是由多个[=发行者=]发布的。这些信息的汇总通常表达了一个人、组织或[=实体=]的某个方面。

上面显示了[=可验证展示=]的组件，但抽象了关于如何将[=可验证凭证=]组织成信息[=图=]的细节，然后将这些信息[=图=]组织成[=可验证展示=]。

下面显示了一个使用基于[[?VC-DATA-INTEGRITY]]的[=嵌入式证明=]的[=可验证展示=]的更完整描述。它由至少四个信息[=图=]组成。其中第一个信息[=图=]，即[=可验证展示图=]（它是[=默认图=]），通过[=展示=]元数据表达[=可验证展示=]本身。[=可验证展示=]通过`verifiableCredential`属性引用一个[=可验证凭证=]。这个[=凭证=]是一个包含[=凭证=]元数据和其他[=声明=]的独立[=可验证凭证图=]。这个[=凭证=]通过`proof`属性引用一个[=可验证凭证=]的[=证明图=]，表达了[=凭证=]的证明（通常是数字签名）。这个[=可验证凭证图=]及其链接的[=证明图=]分别构成第二和第三个信息[=图=]，每个都是一个单独的[=命名图=]。[=展示=]还通过`proof`属性引用[=展示=]的[=证明图=]，这是第四个信息[=图=]（另一个[=命名图=]）。这个[=展示=]的[=证明图=]表示[=可验证展示图=]、[=可验证凭证图=]以及从[=可验证凭证图=]链接的[=证明图=]的数字签名。

为了创建一个[=可验证展示=]，[=持有者=]需要将一个或多个[=可验证凭证=]组合在一起，并在需要时添加其他相关信息。然后，[=持有者=]需要对整个[=可验证展示=]进行签名，以确保接收方可以验证其来源和完整性。这样，[=验证者=]就可以确信这些[=声明=]是真实的，并且是由相应的[=发行者=]颁发的。

为了验证一个[=可验证展示=]，[=验证者=]需要执行以下步骤：

1. 检查[=可验证展示=]的数字签名以确保其来源和完整性。
2. 检查每个包含在[=可验证展示=]中的[=可验证凭证=]的数字签名。
3. 确保每个[=可验证凭证=]都是由可信的[=发行者=]颁发的。
4. 确保每个[=可验证凭证=]都没有过期或被撤销。
5. 根据需要，确保[=可验证展示=]和[=可验证凭证=]满足特定的业务规则和策略。

一旦[=验证者=]完成了这些步骤，他们就可以信任[=可验证展示=]中的[=声明=]，并据此做出决策。例如，根据所提供的年龄证明，他们可以决定是否允许用户访问年龄受限的内容。

请注意，[=可验证展示=]和[=可验证凭证=]的验证过程可能会涉及与多个[=发行者=]和其他参与者的交互，以检查凭证状态、获取公钥等。为了保护用户隐私，这些交互应尽可能地减少，并遵循最小披露原则，即仅披露验证所需的最少信息。

本规范描述了创建和验证[=可验证展示=]和[=可验证凭证=]的通用方法和原则。实际应用中可能会有多种实现方式和技术，以满足不同场景和需求。这些实现应遵循本规范的核心原则，以确保互操作性和安全性。

下面显示的是与 相同的 [=可验证展示=]，但使用基于 [[?VC-JOSE-COSE]] 的 [=封装式证明=]。有效负载仅包含两个信息图：通过展示元数据表达 [=可验证展示=] 本身的 [=可验证展示图=]；以及相应的 [=可验证凭证图=]，由 `verifiableCredential` 属性引用。[=可验证凭证图=] 包含单个 `EnvelopedVerifiableCredential` 实例，通过 `data:` URL [[RFC2397]] 引用，指向通过 上显示的 [=封装式证明=] 保护的可验证凭证。

可以有一个[=展示=]，例如一组大学凭证，它们依赖于关于不同[=主体=]的多个[=凭证=]，这些主题通常是相关的，但不是必须的。 这是通过使用`verifiableCredential`属性来引用多个[=可验证凭证=]来实现的。 有关更多详细信息，请参见附录。

具体生命周期示例

前面的章节使用图形描述介绍了[=声明=]、[=可验证凭证=]和[=可验证展示=]的概念。本节提供了一个具体的简单但完整的生命周期示例，用本规范支持的一种具体语法表示数据模型。在 可验证凭证生态系统中，[=凭证=]和[=展示=]的生命周期通常遵循以下路径：

1. 发行一个或多个[=可验证凭证=]。
2. 将[=可验证凭证=]存储在[=仓库=]（如数字钱包）中。
3. 将[=可验证凭证=]组合成一个[=可验证展示=]，供[=验证者=]使用。
4. [=验证者=]对[=可验证展示=]进行[=验证=]。
5. [=验证者=]对包含在[=可验证展示=]中的相关[=声明=]进行[=校验=]。

为了说明这个生命周期，我们将使用从大学兑换校友折扣的例子。在下面的例子中，Pat从一所大学获得了一份校友[=可验证凭证=]，并将这个[=可验证凭证=]存储在一个数字钱包中。

{
  // 设置上下文，建立我们将使用的特殊术语
  // 如'issuer'和'alumniOf'。
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  // 指定凭证的标识符
  "id": "http://university.example/credentials/1872",
  // 凭证类型，声明凭证中期望的数据
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  // 发行凭证的实体
  "issuer": "https://university.example/issuers/565049",
  // 凭证发行的时间
  "validFrom": "2010-01-01T19:23:24Z",
  // 关于凭证主体的声明
  "credentialSubject": {
    // 凭证唯一主体的标识符
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    // 关于凭证唯一主体的断言
    "alumniOf": {
      // 大学的标识符
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      // 大学的名称
      "name": "Example University"
    }
  }
}
        

然后，Pat尝试兑换校友折扣。[=验证者=]，一个票务销售系统，声明“Example University”的校友可以获得体育赛事季票的折扣。使用移动设备，Pat开始购买季票的过程。在这个过程中的一个步骤请求一个校友[=可验证凭证=]，这个请求被路由到Pat的数字钱包。数字钱包询问Pat是否愿意提供以前发行的[=可验证凭证=]。Pat选择了校友[=可验证凭证=]，然后将其组合成一个[=可验证展示=]。[=可验证展示=]被发送到[=验证者=]并进行[=验证=]。

一旦被[=验证=]为真实和当前有效的，季票的卖家然后验证[=可验证凭证=]的[=发行者=]是否被认可为校友状态的声明——它是，因为它是由Example University发行的——并且今天的日期在由`validFrom`和`validUntil`属性定义的有效期内。由于期望[=持有者=]是[=可验证凭证=]的[=主体=]，[=验证者=]也确认校友声明的`id`与[=可验证展示=]的创建者的`id`匹配。

在[=验证=]了凭证和展示，并验证了相关的声明后，票务销售商安全地为Pat启用了校友折扣，确信Pat有合法的权利享受这个折扣。

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": "VerifiablePresentation",
  // 在上一个示例中发行的可验证凭证
  "verifiableCredential": [{
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "id": "http://university.example/credentials/1872",
    "type": ["VerifiableCredential", "ExampleAlumniCredential"],
    "issuer": "https://university.example/issuers/565049",
    "validFrom": "2010-01-01T19:23:24Z",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "alumniOf": {
        "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
        "name": "Example University"
      }
    }
  }]
}
        

上面的例子是未加密的。对于有兴趣了解更多关于保护[=可验证凭证=]的实现者，可以参见规范[[[VC-JOSE-COSE]]] [[VC-JOSE-COSE]]和[[[VC-DATA-INTEGRITY]]] [[VC-DATA-INTEGRITY]] 以及[[[VC-SPECS]]] [[VC-SPECS]]的"Proofs"部分。

隐私范围

重要的是要认识到，隐私有一个范围，从伪名到强烈识别。根据用例，人们对于他们愿意提供的信息以及从所提供的信息中可以得出的信息有不同的舒适度。

例如，大多数人在购买酒精时可能希望保持匿名，因为所需的监管检查仅基于一个人是否超过特定年龄。另一方面，对于医生为患者开具的医疗处方，配药的药房需要更强烈地识别医疗专业人员和患者。因此，并没有一种适用于所有用例的隐私方法。隐私解决方案是针对特定用例的。

即使对于那些在购买酒精时希望保持匿名的人，也可能仍需要提供照片身份证明以向商家提供适当的保证。商家可能不需要知道您的姓名或其他详细信息（除了您是否超过特定年龄），但在许多情况下，仅提供年龄证明可能仍然不足以满足法规要求。

可验证凭证数据模型力求支持完整的隐私范围，并且在任何特定交易的正确匿名程度上不持哲学立场。以下各节为希望避免特定对隐私不友好的场景的实施者提供指导。

软件信任边界

在本规范所描述的生态系统中存在各种信任关系。个人使用Web浏览器时，信任Web浏览器（也称为用户代理）不会将他们的个人信息上传到数据代理；同样，填充本规范所描述的生态系统中的角色的实体信任代表这些角色的软件。示例包括以下内容：

• [=发行者=]的用户代理（发行者软件），例如在线教育平台，预期只向发行者确认已完成其教育计划的个人发行[=可验证凭证=]。
• [=验证者=]的用户代理（验证软件），例如招聘网站，预期只允许具有有效验证状态的个人访问，这些个人向平台提供[=可验证凭证=]和[=可验证展示=]。
• [=持有者=]的用户代理（持有者软件），例如数字钱包，预期只有在[=持有者=]同意释放该信息时才会向[=验证者=]泄露信息。

上述示例并非详尽无遗，这些角色中的用户还可以期望从他们用来实现目标的软件中获得各种其他功能。简而言之，预计软件将为用户的最佳利益服务，违反该期望将导致信任的破裂，软件将被不违反信任的其他软件替代。强烈建议实施者编写不违反其服务用户信任的软件。实施者还建议在他们创建的软件中提供审计功能，以便用户或受信任的第三方可以检查软件是否确实在为他们的最佳利益服务。

建议读者注意，某些软件（例如为单个[=验证者=]和多个[=持有者=]提供服务的网站）可能作为用户代理同时为这两个角色提供服务，但可能无法始终同时为所有各方的最佳利益服务。例如，如果该网站检测到多个[=持有者=]之间存在欺诈性[=可验证凭证=]的使用尝试，它可能会向[=验证者=]报告此类异常，这可能被认为不符合犯规的[=持有者=]的最佳利益，但符合[=验证者=]以及任何不犯此类违规行为的[=持有者=]的最佳利益。强烈建议在软件以这种方式运行时，通过诸如网站使用政策之类的机制明确软件是在谁的最佳利益下运行。

个人身份信息

存储在`credential.credentialSubject`字段中与[=可验证凭证=]相关的数据在与[=验证者=]共享时容易受到隐私侵犯。例如政府发行的标识符、邮寄地址和全名等个人身份信息，可以很容易地用来确定、追踪和关联一个[=实体=]。即使是看似不具有个人身份特征的信息，如出生日期和邮政编码的组合，也具有非常强大的关联和去匿名化能力。

强烈建议实施者在[=持有者=]分享这类特征的数据时进行警告。强烈建议[=发行者=]在可能的情况下提供保护隐私的[=可验证凭证=]。例如，当一个[=验证者=]想要确定一个[=实体=]是否已满18岁时，发行`ageOver` [=可验证凭证=]而不是出生日期[=可验证凭证=]。

由于[=可验证凭证=]通常包含个人身份信息(PII)，因此强烈建议实施者在存储和传输[=可验证凭证=]时使用保护数据免受非法访问的机制。可以考虑的机制包括传输层安全性(TLS)或其他在传输过程中加密数据的方式，以及加密或数据访问控制机制来保护存储在[=可验证凭证=]中的数据。

基于标识符的关联

[=可验证凭证=]的[=主体=]使用`credential.credentialSubject.id`字段进行识别。用于识别[=主体=]的标识符在跨多个网络域或长时间使用时，关联风险更大。

同样地，披露[=凭证=]标识符（`credential.id`）会导致多个[=验证者=]或[=发行者=]与[=验证者=]串通关联[=持有者=]的情况。如果[=持有者=]希望减少关联，他们应使用允许在[=可验证展示=]过程中隐藏标识符的[=可验证凭证=]方案。这类方案要求[=持有者=]生成标识符，甚至允许在保持标识符嵌入并签署在[=可验证凭证=]中的同时，将标识符对[=发行者=]进行隐藏。

如果在[=可验证凭证=]系统中需要强大的反关联特性，强烈建议标识符采用以下方式之一：

• 绑定到单一来源
• 一次性使用
• 根本不使用，而是用短时、一次性的持有者令牌替代。

基于签名的关联

使用安全机制保护[=凭证=]的内容。当在多个会话或域中使用相同的值且值不变时，用于表示安全机制的值会增加关联风险。

如果需要强大的反关联特性，建议使用第三方成对签名、零知识证明或群签名等技术，每次重新生成签名值和元数据。

即使在使用反关联签名时，[=可验证凭证=]中可能仍然包含信息，从而使所使用的密码学的反关联特性失效。

基于长期标识符的关联

[=可验证凭证=]可能包含可用于关联个人的长期标识符。这些类型的标识符包括 [=主体=]标识符、电子邮件地址、政府颁发的标识符、 机构颁发的标识符、地址、医疗保健生命体征、 [=可验证凭证=]特定的JSON-LD上下文，以及许多其他类型的 长期标识符。

向[=持有者=]提供软件的组织应努力识别 [=可验证凭证=]中包含可用于关联个人的信息的字段，并在此类信息被 共享时警告[=持有者=]。

基于元数据的关联

在第节和第节中描述的不同扩展点的使用 如果使用特定扩展类型或类型组合的[=发行者=]数量相对较少， 可能会成为一种无意识或不希望的关联机制。 例如，仅由特定国家使用的某些类型的加密技术，或特定司法管辖区使用的吊销格式， 或特定地区使用的凭证类型，都可以作为一种机制 降低[=持有者=]在向[=验证者=]选择性披露信息时期望的匿名性。

建议[=发行者=]在颁发预期以匿名方式使用的[=可验证凭证=]时减少基于元数据的关联可能性， 通过减少可用于缩小[=持有者=]匿名性的扩展类型。使用具有全球应用的凭证类型、 扩展和技术概况优于具有国家应用的凭证类型，而具有国家应用的凭证类型优于仅具有地方应用的凭证类型。

设备追踪和指纹识别

存在一些外部机制，用于在互联网和Web上追踪和关联个体，这些机制不包括[=可验证凭证=]。这些机制包括互联网协议（IP）地址追踪、网络浏览器指纹识别、永久cookies、广告网络追踪器、移动网络位置信息以及应用内全球定位系统（GPS）API。使用[=可验证凭证=]无法阻止这些其他追踪技术的使用。此外，当这些技术与[=可验证凭证=]一起使用时，可能会发现新的可关联信息。例如，生日与GPS位置的组合可以被用来在多个网站上强烈关联一个个体。

建议尊重隐私的系统在使用[=可验证凭证=]时阻止这些其他追踪技术的使用。在某些情况下，可能需要在代表[=持有者=]传输[=可验证凭证=]的设备上禁用追踪技术。

Oblivious HTTP协议[[?OHTTP]]是实施者在获取与[=可验证凭证=]或[=可验证展示=]相关的外部资源时可能会考虑使用的一种机制。Oblivious HTTP允许客户端向源服务器发送多个请求，而该服务器无法将这些请求链接到该客户端，甚至无法识别这些请求来自同一个客户端，同时只对用于转发消息的节点有限的信任。因此，Oblivious HTTP是一种可以用来减少设备追踪和指纹识别可能性的保护隐私的机制。以下包含了Oblivious HTTP如何使生态系统参与者受益的具体示例。

• 使用数字钱包的[=持有者=]可以减少他们在访问存储在其数字钱包中的[=可验证凭证=]内的外部链接时被第三方追踪的可能性。例如，数字钱包可能会获取并展示链接的图像，或者通过获取外部链接的撤销列表来检查[=可验证凭证=]的有效性。
• [=验证者=]可以减少向[=发行者=]发出已收到特定[=可验证凭证=]的信号。例如，[=验证者=]在对[=可验证凭证=]进行状态检查时，可能会获取外部链接的撤销列表。

偏爱抽象声明

为了让[=可验证凭证=]的接收者在各种情况下使用它们，而无需透露比交易所需更多的个人身份信息（PII），[=发行者=]应考虑将发布在[=凭证=]中的信息限制为预期目的所需的最小集合。避免在[=凭证=]中放置个人身份信息的一种方法是使用一种抽象的[=属性=]，该属性满足[=验证者=]的需求，而无需提供关于[=主体=]的具体信息。

例如，本文档使用了`ageOver` [=属性=]，而不是具体的出生日期，后者构成了更强的个人身份信息。如果某个特定市场的零售商通常要求购买者年龄大于某个年龄，那么在该市场受信任的[=发行者=]可能会选择提供一种[=可验证凭证=]，声称[=主体=]已经满足了该要求，而不是提供包含关于具体出生日期的[=声明=]的[=可验证凭证=]。这使得个人顾客可以在不透露具体个人身份信息的情况下进行购买。

数据最小化原则

当在一个上下文中泄露的信息泄露到另一个上下文时，就会发生隐私侵犯。防止此类侵犯的公认最佳做法是将请求和接收的信息限制到绝对最小必要。这种数据最小化方法在多个司法管辖区中都被法规要求，包括美国的健康保险可携带性和责任法案（HIPAA）和欧盟的一般数据保护条例（GDPR）。

对于[=可验证凭证=]，对[=发行者=]来说，数据最小化意味着将[=可验证凭证=]的内容限制到潜在的[=验证者=]预期使用所需的最小限度。对于[=验证者=]，数据最小化意味着限制请求或获取服务所需的信息范围。

例如，一个包含驾驶员ID号码、身高、体重、生日和家庭地址的驾驶执照是一个[=凭证=]，它包含的信息比确认一个人是否超过某个年龄所需的信息更多。

一般认为，[=发行者=]最好将信息原子化或使用允许[=选择性披露=]的签名方案。例如，驾驶执照的[=发行者=]可以发行一个包含驾驶执照上出现的每个属性的[=可验证凭证=]，以及一组每个[=可验证凭证=]只包含一个属性（如一个人的生日）的[=可验证凭证=]。它还可以发行更抽象的[=可验证凭证=]（例如，只包含`ageOver`属性的[=可验证凭证=]）。一种可能的适应方式是[=发行者=]提供安全的HTTP端点，用于检索单次使用的[=持有者凭证=]，以促进[=可验证凭证=]的匿名使用。认为这种做法不切实际或不安全的实施者，应考虑使用[=选择性披露=]方案，以消除在证明时间和减少来自[=发行者=]的时间关联风险的依赖。

强烈建议[=验证者=]只请求进行特定交易绝对必要的信息。这至少有两个原因。它：

• 减少了[=验证者=]处理其不需要的高度敏感信息的责任。
• 通过只询问特定交易所需的信息，增强了个人的隐私。

虽然可以实践最小披露原则，但在一个会话或多个会话中，对于特定用例，可能无法避免强烈识别个人。本文档的作者无法强调在现实世界场景中满足这一原则有多困难。

持有者凭证

一个持有者凭证是一种 增强隐私的信息，例如音乐会门票，它使得持有者凭证的[=持有者=]有权获得特定资源，而无需 泄露关于[=持有者=]的敏感信息。持有者凭证通常用于低风险的使用场景，其中分享持有者凭证不是 一个问题，或者不会导致巨大的经济或声誉损失。

[=可验证凭证=]中的[=持有者凭证=]是通过不指定[=主体=]标识符实现的，该标识符使用 `id` [=属性=]表示，它嵌套在 `credentialSubject` [=属性=]中。例如，以下 [=可验证凭证=]是一个[=持有者凭证=]：

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/temporary/28934792387492384",
  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2017-10-22T12:23:48Z",
  "credentialSubject": {
    // note that the 'id' property is not specified for bearer credentials
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}
        

虽然[=持有者凭证=]可以增强隐私，但必须精心设计，以免意外泄露比[=持有者=] 预期的更多信息。例如，在多个站点上重复使用相同的 [=持有者凭证=]使这些站点可能串通起来不当地跟踪或关联[=持有者=]。同样， 可能看似非识别的信息，如出生日期和邮政编码，在同一[=持有者凭证=]或会话中一起使用时 可以用于统计识别个人。

[=发行者=]应确保[=持有者凭证=]提供增强隐私的好处，包括：

• 尽可能实现一次性使用。
• 不包含个人识别信息。
• 不会过度关联。

如果发行或请求包含敏感信息的[=持有者凭证=]，或者在一个或多个会话中组合两个或多个[=持有者凭证=]时存在关联风险， [=持有者=]应被其软件警告。虽然检测到所有关联风险可能是不可能的，但某些风险肯定是可以检测到的。

[=验证者=]不应请求可用于不当关联[=持有者=]的[=持有者凭证=]。

验证

在处理[=可验证凭证=]时，[=验证者=] 在依赖它们之前会评估任何相关的[=声明=]。只要满足 进行验证的[=验证者=]的要求，这种评估可以以任何期望的方式进行。 许多验证者将执行附录中列出的检查，以及各种 特定的业务流程 检查，例如：

• [=持有者=]的专业许可状态。
• 许可证续期或撤销的日期。
• 个人的子资格。
• [=持有者=]与[=持有者=]试图互动的[=实体=] 之间是否存在关系。
• 与[=持有者=]相关联的地理位置信息。

执行这些检查的过程可能会导致信息泄露，从而侵犯[=持有者=]的隐私。例如，一个简单 的操作，如检查一个配置不当的撤销列表，可以 通知[=发行者=]某个特定的业务可能正在与[=持有者=]互动。这可能 使[=发行者=]在不知情的情况下串谋关联个人。

建议[=发行者=]在 [=验证=]过程中不要使用可能导致隐私侵权的机制，如每个[=凭证=]都有唯一的撤销列表。为[=持有者=]提供软件的组织应当警告，当[=凭证=]包含可能在验证过程中导致隐私侵权的信息时。[=验证者=]应考虑拒绝可能产生隐私侵权或促成不良隐私实践的[=凭证=]。

存储提供商和数据挖掘

当一个[=持有者=]从[=发行者=]那里收到一份[=可验证凭证=]时，这份[=可验证凭证=]需要存储在某个地方（例如，在一个[=凭证=]仓库中）。[=持有者=]需要注意，[=可验证凭证=]中的信息具有敏感性和高度个性化，使其成为数据挖掘的高价值目标。宣传免费存储[=可验证凭证=]的服务实际上可能在挖掘个人数据，并将其出售给希望建立个人和组织个性化档案的组织。

[=持有者=]需要了解他们的[=凭证=]仓库的服务条款，特别是针对那些将其[=可验证凭证=]存储在服务提供商处的用户的关联和数据挖掘保护措施。

针对数据挖掘和分析的一些有效缓解措施包括使用：

• 不将您的信息出售给第三方的服务提供商。
• 对[=可验证凭证=]进行加密的软件，以使服务提供商无法查看[=凭证=]的内容。
• 将[=可验证凭证=]存储在您控制的设备上的软件，该软件不会在超出您的期望范围内上传或分析您的信息。

凭证的聚合

持有关于同一[=主体=]的两份信息几乎总是会揭示出比两份信息之和更多的关于[=主体=]的信息，即使这些信息是通过不同的渠道传递的。[=可验证凭证=]的聚合是一个隐私风险，生态系统中的所有参与者都需要意识到数据聚合的风险。

例如，如果两个[=持有者凭证=]，一个是电子邮件地址，另一个声明[=持有者=]已经超过21岁，都在多个会话中提供，那么信息的[=验证者=]现在就拥有了该个体的唯一标识符以及与年龄相关的信息。现在很容易为[=持有者=]创建和建立一个档案，以便随着时间的推移泄露出越来越多的信息。在彼此串通的多个网站上也可以进行[=凭证=]的聚合，这会导致隐私侵犯。

从技术角度来看，防止信息聚合是一个非常难以解决的隐私问题。虽然新的加密技术，如零知识证明，被提出来解决聚合和关联问题，但是长期存在的标识符和浏览器跟踪技术甚至可以打败最现代的加密技术。

解决关联或聚合的隐私问题的解决方案往往不是技术性的，而是由政策驱动的。因此，如果一个[=持有者=]不希望他们的信息被聚合，他们必须在他们传输的[=可验证展示=]中表达这一点。

使用模式

尽管我们竭尽全力确保隐私，但实际使用[=可验证凭证=]可能会导致去匿名化和隐私丧失。这种关联可能发生在以下情况：

• 相同的[=可验证凭证=]被展示给同一个[=验证者=]多次。[=验证者=]可以推断出[=持有者=]是同一个人。
• 相同的[=可验证凭证=]被展示给不同的[=验证者=]，这些[=验证者=]串通起来或者第三方可以访问来自两个[=验证者=]的交易记录。一个观察者可以推断出展示[=可验证凭证=]的个体在两个服务中是同一个人。也就是说，这些账户由同一个人控制。
• [=凭证=]的[=主体=]标识符在多个[=展示=]或[=验证者=]中都指向同一个[=主体=]。即使展示的[=凭证=]不同，如果[=主体=]标识符相同，[=验证者=]（以及那些可以访问[=验证者=]日志的人）可以推断出[=凭证=]的[=持有者=]是同一个人。
• [=凭证=]中的基本信息可以用于在各种服务中识别个人。在这种情况下，使用来自其他来源的信息（包括由[=持有者=]直接提供的信息），[=验证者=]可以使用[=凭证=]中的信息将个人与现有的个人资料进行关联。例如，如果[=持有者=]展示包含邮政编码、年龄和性别的[=凭证=]，[=验证者=]可以将该[=凭证=]的[=主体=]与已建立的个人资料进行关联。有关更多信息，请参阅[[DEMOGRAPHICS]]。
• 将[=凭证=]的标识符传递给一个集中式撤销服务器。集中式服务器可以在交互过程中关联[=凭证=]的使用。例如，如果以这种方式使用[=凭证=]作为年龄证明，集中式服务可以知道[=凭证=]展示的所有地方（所有的酒类商店、酒吧、成人商店、彩票购买等）。

在某种程度上，可以通过以下方式来减轻这种去匿名化和隐私丧失：

• 使用全球唯一标识符作为任何给定[=凭证=]的[=主体=]，并且永远不要重复使用该[=凭证=]。
• 如果[=凭证=]支持撤销，使用全球分布式服务进行撤销。
• 设计不依赖于提交[=凭证=] ID 的撤销 API。例如，使用撤销列表而不是查询。
• 避免将个人身份信息与任何特定的长期[=主体=]标识符关联起来。

人们理解这些缓解技术并不总是实用，甚至与必要的使用兼容。有时候关联是一种要求。

例如，在某些处方药监测计划中，使用监测是一项要求。执法实体需要确认个人没有欺骗系统以获得多个受控药物的处方。这种法定或监管需求优先于个人隐私关切。

[=可验证凭证=]还将被用于在服务之间有意识地关联个人，例如，在使用通用角色登录多个服务时，以便在这些服务上的所有活动都有意识地与同一个个人关联。只要每个服务都按照预期的方式使用关联，这就不是一个隐私问题。

[=凭证=]使用的隐私风险发生在因展示[=凭证=]而产生意外或意料之外的关联时。

与错误的一方分享信息

当一个[=持有者=]选择与[=验证者=]分享信息时， 可能的情况是[=验证者=]恶意行事并请求 可能用于伤害[=持有者=]的信息。例如， [=验证者=]可能会要求提供银行账号，然后可以使用 其他信息来欺诈[=持有者=]或银行。

[=发行者=]应努力将尽可能多的信息标记化， 这样即使[=持有者=]不小心将[=凭证=]传输给错误的 [=验证者=]，情况也不会太糟。

例如，不是为了检查个人的银行余额而包含银行账号， 而是提供一个令牌，使[=验证者=]能够检查余额是否超过某个金额。 在这种情况下，银行可以向[=持有者=]发出包含余额检查令牌的 [=可验证凭证=]。然后，[=持有者=]将 [=可验证凭证=]包含在[=可验证展示=]中，并使用数字签名将 令牌绑定到信用检查机构。然后，[=验证者=]可以将他们的 数字签名包裹在[=可验证展示=]中，并将其交还给发行者以动态检查 账户余额。

使用这种方法，即使[=持有者=]与错误的一方分享了账户余额令牌， 攻击者也无法发现银行账号，也无法知道账户中的确切金额。并且考虑到 反签名的有效期，攻击者也无法获得令牌的访问权限超过几分钟。

数据盗窃

在[=可验证凭证=]和[=可验证展示=]中表达的数据具有价值，因为它们包含由值得信赖的第三方（如[=发行者=]）或个人（如[=持有者=]和[=主体=]）所作的真实陈述。存储这些数据会产生攻击者有动机突破以获取和交换数据以获得经济利益的敏感数据蜜罐。

建议[=发行者=]保留发行[=可验证凭证=]给[=持有者=]以及管理这些凭证的状态和撤销所需的最少数据量。

建议[=持有者=]使用在传输和休息时适当加密其数据的实现，并以无法轻易从硬件设备中提取的方式保护敏感材料（如加密秘密）。此外，建议[=持有者=]仅在他们控制的设备上存储和操作他们的数据，远离集中式系统，以减少对他们数据的攻击可能性，或者如果攻击成功，减少大规模盗窃的可能性。

建议[=验证者=]仅要求进行特定交易所需的数据，并且不要保留超出任何特定交易需求的任何数据。

建议监管者重新考虑审计要求，以便可以使用更多隐私保护机制来实现类似的执法和审计能力。例如，以收集和长期保留个人身份信息为目的的审计型法规可能会对个人和组织造成伤害，如果这些信息被攻击者窃取并访问。本规范描述的技术使[=持有者=]能够更容易地证明他们自己和他人的属性，从而减少了[=验证者=]对长期数据保留的需求。替代方案包括保留收集和检查信息的日志，以及随机测试以确保合规制度按预期运行。

声明发行频率

如第节详述，使用模式可以与某些类型的行为相关联。当[=持有者=]在不知道[=发行者=]的情况下使用[=可验证凭证=]时，这种关联的一部分就被减轻了。然而，[=发行者=]可以通过使其[=可验证凭证=]的有效期短暂且自动更新来破坏这种保护。

例如，`ageOver` [=可验证凭证=]对于进入酒吧是有用的。如果[=发行者=]发行这样一个具有非常短的有效期和自动更新机制的[=可验证凭证=]，那么[=发行者=]可能会以一种对[=持有者=]产生负面影响的方式关联[=持有者=]的行为。

为[=持有者=]提供软件的组织应该警告他们，如果他们反复使用具有短生命周期的[=凭证=]，可能会导致行为关联。[=发行者=]应避免以一种使他们能够关联使用模式的方式发行[=凭证=]。

优先使用一次性凭证

理想的尊重隐私的系统只需要由[=持有者=]披露与[=验证者=]互动所需的信息。 [=验证者=]随后记录披露要求得到满足，并忘记披露的任何敏感信息。在许多情况下， 诸如监管负担等相互竞争的优先事项，阻止了这一理想系统的实施。在其他情况下，长期存在的标识符阻止了一次性使用。然而， 任何[=可验证凭证=]生态系统的设计都应力求尽可能尊重隐私，尽可能优先使用一次性 [=可验证凭证=]。

使用一次性[=可验证凭证=]带来了几个好处。第一个好处是对[=验证者=]，他们可以确保 [=可验证凭证=]中的数据是最新的。第二个好处是对[=持有者=]，他们知道如果 [=可验证凭证=]中没有长期存在的标识符，那么[=可验证凭证=]本身就不能用于 在线跟踪或关联他们。最后，攻击者没有可窃取的东西，使整个生态系统更安全地运行。

私密浏览

在理想的私密浏览场景中，不会泄露任何个人身份信息（PII）。因为许多 [=凭证=]包含个人身份信息，为[=持有者=]提供软件的组织应该警告他们，如果他们希望在私密浏览模式下使用 [=凭证=]和[=展示=]，可能会泄露这些信息。由于每个浏览器厂商处理私密浏览的方式不同，有些浏览器可能根本没有这个功能，所以 实施者需要了解这些差异并相应地实施解决方案。

发行者合作对隐私的影响

无法过分强调[=可验证凭证=]对[=发行者=]的高度信任的依赖性。[=持有者=]可能利用可能的隐私保护的程度通常强烈依赖于[=发行者=]对这些功能的支持。在许多情况下，利用零知识证明、数据最小化技术、持有者凭证、抽象声明以及防止基于签名的关联的隐私保护，需要[=发行者=]积极支持这些能力并将它们纳入他们发行的[=可验证凭证=]中。

还应注意，除了依赖[=发行者=]参与提供帮助保护[=持有者=]和[=主体=]隐私的[=可验证凭证=]能力外，[=持有者=]还依赖[=发行者=]不故意破坏隐私保护。例如，[=发行者=]可能使用一种保护免受基于签名的关联的签名方案来签署[=可验证凭证=]。这将保护[=持有者=]免受由于签名值在[=验证者=]之间共享而产生的关联。然而，如果[=发行者=]为每个发行的[=凭证=]创建一个唯一的密钥，那么[=发行者=]可能能够跟踪[=凭证=]的[=展示=]，无论[=验证者=]是否有能力这样做。

除了前述的隐私保护，[=发行者=]可能使用，[=发行者=]还需要注意他们在发行[=凭证=]时使用的与标识符和声明类型相关的数据泄漏。这的一个例子可能是[=发行者=]发行驾驶执照，这既揭示了他们有管辖权的地点，也揭示了[=主体=]的居住地。[=验证者=]可能利用这一点，通过请求[=凭证=]来检查[=主体=]是否有驾驶执照，实际上他们对凭证的元数据关于感兴趣，例如哪个[=发行者=]发行了凭证，以及可能被[=发行者=]泄漏的与主题的家庭地址等相关的间接信息。为了减轻这种泄漏，[=发行者=]可能选择使用常见的标识符来掩盖特定的位置信息或其他敏感的元数据；例如，使用一个在州或国家级别共享的发行者标识符，而不是在县、城市、镇或其他较小的市政单位级别。此外，[=验证者=]可以使用[=持有者=]的声明机制来保护隐私，通过提供证明一个[=发行者=]存在于一组受信任的实体中，而无需公开具体的[=发行者=]。

加密套件和库

本规范中描述的数据模型的某些方面可以通过使用加密来保护。实施者需要了解用于创建和处理[=凭证=]和[=展示=]的加密套件和库。实施和审计加密系统通常需要丰富的经验。有效的 红队也可以帮助消除安全审查中的偏见。

加密套件和库有一定的使用寿命，最终会受到新攻击和技术进步的影响。生产质量的系统需要考虑到这一点，并确保存在机制来轻松且主动地升级过期或损坏的加密套件和库，以及使现有[=凭证=]失效和替换。定期监控对于确保处理[=凭证=]的系统的长期可行性非常重要。

密钥管理

大多数数字签名算法的安全性，用于保护[=可验证凭证=]和[=可验证展示=]，取决于其私有签名密钥的质量和保护。关于加密密钥管理的指导是一个很大的主题，建议读者参考[[NIST-SP-800-57-Part-1]]以获得更详细的建议和讨论。正如[[FIPS-186-5]]和[[NIST-SP-800-57-Part-1]]强烈建议的那样，私有签名密钥不应用于多种用途，例如，私有签名密钥不应用于加密以及签名。

[[NIST-SP-800-57-Part-1]]强烈建议私有签名密钥和公共验证密钥具有有限的加密周期，其中加密周期是“合法实体授权使用特定密钥的时间跨度，或者给定系统的密钥将保持有效。”[[NIST-SP-800-57-Part-1]]针对不同情况下不同密钥类型的加密周期提供了广泛的指导，并通常建议私有签名密钥的加密周期为1-3年。

为应对潜在的私钥泄露，[[NIST-SP-800-57-Part-1]]提供了保护措施、减少损害和撤销的建议。尽管本节主要关注私有签名密钥的安全性，但[[NIST-SP-800-57-Part-1]]还强烈建议在使用所有[=验证材料=]之前确认其有效性。

内容完整性保护

[=可验证凭证=]通常包含指向位于 [=可验证凭证=]本身之外的数据的URL。链接到存在于 [=可验证凭证=]之外的内容，如图片、JSON-LD上下文、JSON模式， 以及其他机器可读数据，通常无法防止篡改， 因为数据位于之外的 [=可验证凭证=]。例如，通过解引用以下突出显示的链接可检索的内容没有完整性保护，但 可能应该有：

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/58473",
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "image": "https://university.example/images/58473",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  }
}
        

尽管本规范没有推荐任何特定的内容完整性保护，但建议希望确保链接到内容具有完整性保护的文档作者使用强制内容完整性的URL方案。

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2?hl=z3aq31uzgnZBuWNzUB",
    "https://www.w3.org/ns/credentials/examples/v2?hl=z8guWNzUBnZBu3aq31"
  ],
  "id": "http://university.example/credentials/58473",
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "image": "https://example.com/image",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  }
}
        

上述JSON-LD上下文是否需要保护是有争议的，因为预期生产实现将配备重要的JSON-LD上下文的静态副本。

虽然上述示例是实现内容完整性保护的一种方式，但对于某些应用程序，可能有其他更适合的解决方案。实施者被敦促理解链接到未受内容完整性保护的外部机器可读内容可能如何导致对他们的应用程序的成功攻击。

未签名声明

本规范允许生成没有通过签名或任何形式的证明来保护的[=凭证=]。这类[=凭证=]通常用于中间存储或自我声明信息，类似于在网页上填写表单。实现者应该注意，这类[=凭证=]不是[=verifiable=]的，因为作者身份要么未知，要么不可信。

中间人（MITM）、重放和克隆攻击

数据模型本身并不能防止 中间人（MITM）， 重放和 欺骗攻击。 在线和离线使用场景都可能受到这类攻击的影响，其中对手在传输或存储过程中截取、修改、重用和/或复制 [=可验证凭证=]数据。

中间人（MITM）攻击

[=验证者=]可能需要确保它是[=可验证展示=]的预期接收者，而不是 中间人攻击的目标。一些安全 机制，如[[VC-JOSE-COSE]]或[[VC-DATA-INTEGRITY]]，提供了指定[=展示=]的预期受众或域的选项， 这有助于降低这种风险。

诸如令牌绑定[[RFC8471]]之类的替代方法，将请求 [=可验证展示=]与响应绑定，可以保护协议。 任何未加密的协议都容易受到中间人攻击。

重放攻击

[=验证者=]可能希望确保[=可验证展示=]不会被使用超过一定次数。例如，表示活动门票的[=可验证凭证=]，如果多次展示，可能允许多个人进入，从而破坏了门票在发行方看来的目的。为防止此类攻击， [=持有者=]可以使用诸如在展示过程中包含 随机数或添加过期时间戳以减少攻击窗口的技术。

欺骗攻击

[=验证者=]有充分的利益知道[=持有者=]有权展示[=可验证展示=]内的声明。 虽然数据模型概述了[=可验证凭证=]所需的结构和数据元素，但它没有包含确定展示[=凭证=]的授权的机制。为解决这个问题， 实现者可能需要探索补充方法，如将[=可验证凭证=]绑定到强认证机制或使用 [=可验证展示=]中的附加属性 以实现控制证明。

捆绑相关声明

对于[=发行者=]，将信息原子化到[=凭证=]中，或使用允许选择性披露的签名方案被认为是最佳实践。在原子化的情况下，如果[=发行者=]没有安全地进行操作，[=持有者=]可能会以[=发行者=]未预期的方式将不同的[=凭证=]捆绑在一起。

例如，一所大学可能向一个人发放两个[=可验证凭证=]，每个凭证包含两个[=属性=]，这两个属性必须一起使用，以指定该人在某个“部门”的“角色”，例如“计算机系”的“工作人员”或“经济系”的“研究生”。如果将这些[=可验证凭证=]原子化，将这些[=属性=]中的每一个分别放入每一个[=凭证=]中，那么大学将向这个人发放四个[=凭证=]，每个凭证包含以下一个称号：“工作人员”、“研究生”、“计算机系”和“经济系”。[=持有者=]可能会将“工作人员”和“经济系”的[=可验证凭证=]转移到[=验证者=]，这两个凭证一起构成了一个错误的[=声明=]。

高度动态信息

当为高度动态信息发放[=可验证凭证=]时，实施者应确保有效期设置得当。有效期长于[=可验证凭证=]预期使用时间范围可能会产生可利用的安全漏洞。有效期短于[=可验证凭证=]所表达的信息预期使用时间范围，会给[=持有者=]和[=验证者=]带来负担。因此，为[=可验证凭证=]设置适合用例和所包含信息预期使用寿命的有效期非常重要。

设备盗窃和冒充

当[=可验证凭证=]存储在设备上，且该设备丢失或被盗时，攻击者可能能够利用受害者的[=可验证凭证=]获得对系统的访问权限。缓解这种类型攻击的方法包括：

• 在设备上启用密码、PIN码、图案或生物识别屏幕解锁保护。
• 为[=凭证=] [=仓库=]启用密码、生物识别或多因素认证。
• 在访问加密密钥时启用密码、生物识别或多因素认证。
• 使用单独的基于硬件的签名设备。
• 上述所有或任何组合。

此外，冒充的实例可以以各种形式出现，包括[=实体=]试图否认其行为的情况。提高[=可验证凭证=]领域的信任和安全级别不仅仅是避免冒充；它涉及到非否认机制的实施。这些机制巩固了[=实体=]对其行为或交易的责任，从而加强了问责制并阻止了恶意行为。实现非否认是一项多方面的努力，包括从、持有证明和各种协议中的认证方案等一系列技术。

可接受的使用

确保[=实体=]的行为，如[=展示=]，与这些行为的预期目的保持一致，是非常重要的。这涉及到有权使用[=可验证凭证=]，以及按照其指定的范围和目标使用[=凭证=]。在这个背景下出现的两个关键问题是未经授权的使用和不适当的使用。

未经授权的使用

任何实体试图在未经授权的情况下使用[=可验证凭证=]和[=可验证展示=]，都可以被视为未经授权的使用。未经授权使用的一种类型是保密性违规。考虑一个例子，一个[=持有者=]与[=验证者=]分享一个[=可验证展示=]，以确定他们的年龄和居住状态。如果[=验证者=]然后在未经适当同意的情况下利用[=持有者=]的数据，比如将数据卖给数据经纪人，那么这将构成对数据的未经授权的使用，违反了[=持有者=]在交易中可能对隐私的期望。

同样，[=发行者=]可以使用 termsOfUse属性来规定凭证可能如何和何时被使用。一个[=持有者=]在`termsOfUse`定义的范围之外使用凭证将被视为未经授权的使用。

需要进一步研究如何确定[=持有者=]在[=展示=]后可以如何声明和执行他们的数据的授权使用。

不适当的使用

虽然有效的加密签名和成功的状态检查表明[=凭证=]的可靠性，但它们并不表明所有[=凭证=]在所有情况下都是可互换的。对于[=验证者=]来说，也必须验证任何可能相关的声明，考虑到声明的来源和性质以及凭证所展示的特权或服务。

例如，在需要认证的医疗诊断的情况下，一个自我声明的[=凭证=]携带必要的数据可能不足够，因为它缺乏来自权威医疗来源的有效性。为了确保[=凭证=]的适当使用，各方都被敦促在他们预期的应用的特定上下文中评估凭证的相关性和权威性。

数据优先方法

当今使用的许多实体[=凭证=]，如政府身份证件，具有较差的可访问性特征，包括但不限于小字体、依赖小型和高分辨率图像以及对视力障碍者没有便利设施。

在使用此数据模型创建[=可验证凭证=]时，建议数据模型设计者采用数据优先方法。例如，在使用数据或图形图像来描述[=凭证=]时，设计者应以机器可读的方式表达图像的每个元素，如机构名称或专业[=凭证=]，而不是依赖观众对图像的解释来传达这些信息。采用数据优先方法是首选，因为它为为不同能力的人构建不同界面提供了基本元素。

复杂语言标记

当单个自然语言字符串包含多种语言或注释时，字符串的内容可能需要额外的结构或标记才能正确展示。可以使用标记语言，如HTML，来标记不同语言的文本片段或提供展示[=bidirectional text=]所需的字符串内部标记。还可以使用`rdf:HTML`数据类型在JSON-LD中准确地编码这些值。

尽管可以将信息编码为HTML，但强烈建议实施者不要这样做，因为这样做：

• 需要某种版本的HTML处理器，这增加了处理语言和基础方向信息的负担。
• 在使用此数据模型时增加了安全攻击面，因为盲目处理HTML可能导致在数据生产过程中的某个时刻执行攻击者注入的`script`标签。

如果实施者觉得必须使用HTML或其他能够包含可执行脚本的标记语言来解决特定用例，建议他们分析攻击者如何使用标记发起针对标记消费者的注入攻击，然后针对已识别的攻击部署缓解措施。