可验证凭证数据模型 v2.0

摘要

可验证凭证是一种表达由声明组成的集合的特定方式，这些声明由颁发者作出，例如驾驶执照或教育证书。本规范描述了可验证凭证的可扩展数据模型、它们如何防止被篡改，以及一个由颁发者、持有者和验证者组成的、用于交换这些凭证的三方生态系统。本文档还涵盖了使用本规范所述技术的生态系统在安全、隐私、国际化和无障碍方面的各种考量。

本节介绍本规范的一些基本概念，为本文档后面的第 5. 高级概念做准备。

本节为非规范性内容。

本规范旨在简化新类型可验证凭证的原型设计。开发者可以复制下面的模板，并将其粘贴到常见可验证凭证工具中，以开始颁发、持有和验证原型凭证。

开发者会将下面的 MyPrototypeCredential 更改为他们想要创建的凭证类型。由于可验证凭证讨论的是主体，因此 credentialSubject 对象中的每个属性-值对都表达凭证主体的某个特定属性。一旦开发者添加了若干这样的属性-值组合，修改后的对象就可以发送给一致性颁发者实现，并将为开发者创建一个可验证凭证。从原型设计的角度来看，这就是开发者需要做的全部。

示例 1：用于创建原型可验证凭证的模板

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiableCredential", "MyPrototypeCredential"],
  "credentialSubject": {
    "mySubjectProperty": "mySubjectValue"
  }
}

在稳定所有凭证属性之后，建议开发者在稳定 URL 上生成并发布词汇表和上下文文件，以便促进与其他开发者的互操作性。然后，上面的 https://www.w3.org/ns/credentials/examples/v2 URL 将被替换为特定于用例的上下文 URL。此过程见第 5.2 可扩展性。或者，开发者也可以复用恰好适合其用例的现有词汇表和上下文文件。他们可以查看可验证凭证扩展以寻找可复用资源。

可验证凭证用于表达一个或多个主体的属性，以及凭证本身的属性。本规范为可验证凭证定义了以下属性：

@context: 定义于第 4.3 上下文。
id: 定义于第 4.4 标识符。
type: 定义于第 4.5 类型。
name: 定义于第 4.6 名称和描述。
description: 定义于第 4.6 名称和描述。
issuer: 定义于第 4.7 颁发者。
credentialSubject: 定义于第 4.8 凭证主体。
validFrom: 定义于第 4.9 有效期。
validUntil: 定义于第 4.9 有效期。
status: 定义于第 4.10 状态。
credentialSchema: 定义于第 4.11 数据模式。
refreshService: 定义于第 5.4 刷新。
termsOfUse: 定义于第 5.5 使用条款。
evidence: 定义于第 5.6 证据。

可验证凭证可以通过第 5.2 可扩展性中定义的扩展机制，扩展为具有额外属性。

当两个软件系统需要交换数据时，它们需要使用两个系统都理解的术语。请考虑两个人如何通过使用同一种语言有效沟通，其中他们使用的词语（例如“name”和 “website”）对每个人来说都含义相同。这有时被称为 对话的上下文。本规范使用类似概念，通过建立用于通信的上下文，为软件系统实现类似结果。

处理可验证凭证和可验证呈示的软件系统，通过为每个术语使用 URL来识别术语。然而，这些 URL 可能很长且不太便于人类使用，而简短、便于人类使用的别名会更有帮助。本规范使用 @context 属性将简短别名映射到这些 URL。

可验证凭证和可验证呈示MUST 包含 @context 属性。应用开发者 MUST 理解其应用使用的每个 JSON-LD 上下文，至少要理解到其影响该应用所用术语含义的程度。一种实现机制见可验证凭证数据完整性 1.0规范中验证上下文一节。其他基于本规范构建的规范 MAY 要求 JSON-LD 上下文通过使用第 5.3 相关资源的完整性中描述的 relatedResource 功能或任何实质等效机制进行完整性保护。

@context: @context 属性的值 MUST 是一个有序集合，其中第一项是值为 https://www.w3.org/ns/credentials/v2 的URL。有序集合中的后续项 MUST 由 URL和对象的任意组合构成，其中每一项都可作为 JSON-LD 上下文处理。

示例 2：@context 属性的使用

{
  "@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"],
  "issuer": "did:example:2g55q912ec3476eba2l9812ecbfe",
  "validFrom": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  }
}

上面的示例使用基础上下文 URL （https://www.w3.org/ns/credentials/v2），以确定数据交换是关于可验证凭证的。此概念在第 5.2 可扩展性中进一步详述。位于 https://www.w3.org/ns/credentials/v2 的数据是一个可永久缓存的静态文档，其处理说明见附录 B.1 基础上下文。可验证凭证数据模型的相关人类可读词汇表文档可在 https://www.w3.org/2018/credentials/ 获取。

第二个 URL（https://www.w3.org/ns/credentials/examples/v2）用于展示示例。实现不应将此 URL 用于任何其他目的，例如用于试点或生产系统。

注：有关 @context 的更多信息，请参见 JSON-LD。

@context 属性在 JSON-LD 1.1规范的第 3.1 节：上下文中有进一步阐述。

处理本文档所规定对象类型的软件系统使用类型信息来确定所提供的可验证凭证或可验证呈示是否适合预期用例。本规范定义了一个 type 属性，用于表达对象类型信息。此类型信息可在确认过程中使用，如附录 A. 验证中所述。

可验证凭证和可验证呈示MUST 包含一个 type 属性及其相关联的值。

type: type 属性的值 MUST 是一个或多个术语和绝对 URL 字符串。如果提供多个值，则顺序无关紧要。

关于本规范，下表列出了 MUST 指定type 的对象。

对象	类型
可验证凭证对象	`VerifiableCredential`，并可选地指定一个更具体的可验证凭证类型。例如： `"type": ["VerifiableCredential", "OpenBadgeCredential"]`
可验证呈示对象	`VerifiablePresentation`，并可选地指定一个更具体的可验证呈示类型。例如： `"type": "VerifiablePresentation"`
credentialStatus 对象	有效的凭证状态类型。例如： `"type": "BitstringStatusListEntry"`
termsOfUse 对象	有效的使用条款类型。例如： `"type": "TrustFrameworkPolicy"`
evidence 对象	有效的证据类型。例如： `"type": "Evidence"`
refreshService 对象	有效的 refreshService 类型。例如： `"type": "VerifiableCredentialRefreshService2021"`
credentialSchema 对象	有效的 credentialSchema 类型。例如： `"type": "JsonSchema"`

注：可验证凭证数据模型基于 JSON-LD

可验证凭证数据模型的type 系统与 JSON-LD 1.1 的类型系统相同，并在第 3.5 节：指定类型和第 9 节：JSON-LD 语法中有详细说明。当使用 JSON-LD 上下文（见第 5.2 可扩展性）时，本规范将 @type 关键字别名化为 type，以便使 JSON-LD 文档更易理解。虽然应用开发者和文档作者不需要理解 JSON-LD 类型系统的细节，但希望支持可互操作扩展性的本规范实现者需要理解。

所有凭证、呈示以及被封装的对象 SHOULD 指定额外的、更狭义的类型（例如 ExampleDegreeCredential），或与这些类型关联，以便软件系统能够更容易地检测和处理此附加信息。

在处理本规范中定义的被封装对象时，例如与 credentialSubject 对象关联或深度嵌套其中的对象，软件系统 SHOULD 使用层级中更高位置的封装对象中指定的 type 信息。具体而言，封装对象（例如凭证）SHOULD 传达相关对象的类型，以便验证者能够基于封装对象的类型快速确定相关对象的内容。

例如，一个 type 为 ExampleDegreeCredential 的凭证对象，会向验证者表明，与 credentialSubject 属性关联的对象包含以下内容的标识符：

id 属性中的主体。
type 属性中的学位类型。
name 属性中的学位名称。

这使实现者能够依赖与 type 属性相关联的值进行验证。对象类型及其相关联的值预期至少记录在可在人类可读规范中找到的类型 URL 处。例如， BitstringStatusList 类型的人类可读定义可在 https://www.w3.org/ns/credentials/status/#BitstringStatusList 找到。还建议在同一 URL 处通过 HTTP 内容协商提供机器可读版本。

注：有关创建新凭证类型，请参见实现指南

说明如何创建新类型的可验证凭证超出了本规范的范围。有兴趣这样做的读者建议阅读可验证凭证实现指南 1.0中的创建新凭证类型一节。

在显示凭证时，由颁发者提供文本，为该凭证提供名称和对其目的的简短描述，可能会很有用。 name 和 description 属性即用于这些目的。

name: 一个 OPTIONAL 属性，用于表达凭证的名称。如果存在，name 属性的值 MUST 是字符串或如 11.1 语言和基方向中所述的语言值对象。理想情况下，凭证的名称应简洁、便于人类阅读，并能使个人快速将一个凭证与他们可能持有的任何其他凭证区分开来。
description: 一个 OPTIONAL 属性，用于传达关于凭证的具体详情。如果存在，description 属性的值 MUST 是字符串或如 11.1 语言和基方向中所述的语言值对象。理想情况下，凭证的描述长度不超过几句话，并传达足够的关于该凭证的信息，使个人无需浏览全部声明即可回想起其内容。

示例 5：name 和 description 属性的使用

名称和描述还支持以不同语言表达内容。要使用语言和基方向信息表达字符串，可以使用包含 @value、@language 和 @direction 属性的对象，分别表达文本值、语言标签和基方向。更多信息请参见 11.1 语言和基方向。

注：单语言字符串不要求使用 @direction

下面示例中的 @direction 属性对于相关的单语言字符串并非必需，因为其默认方向与 @direction 值所设置的方向相同。我们在此包含 @direction 属性，是为了清晰展示，并使复制+粘贴+编辑能得到可用结果。鼓励实现者阅读 JSON-LD 1.1 规范中关于字符串国际化的章节。

示例 6：name 和 description 属性的使用

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/3732",
  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
  "issuer": {
    "id": "https://university.example/issuers/565049",
    "name": [{
      "@value": "Example University",
      "@language": "en"
    }, {
      "@value": "Université Exemple",
      "@language": "fr"
    }, {
      "@value": "جامعة المثال",
      "@language": "ar",
      "@direction": "rtl"
    }],
    "description": [{
      "@value": "A public university focusing on teaching examples.",
      "@language": "en"
    }, {
      "@value": "Une université publique axée sur l'enseignement d'exemples.",
      "@language": "fr"
    }, {
      "@value": ".جامعة عامة تركز على أمثلة التدريس",
      "@language": "ar",
      "@direction": "rtl"
    }]
  },
  "validFrom": "2015-05-10T12:30:00Z",
  "name": [{
    "@value": "Example University Degree",
    "@language": "en"
  }, {
    "@value": "Exemple de Diplôme Universitaire",
    "@language": "fr"
  }, {
    "@value": "مثال الشهادة الجامعية",
    "@language": "ar",
    "@direction": "rtl"
  }],
  "description": [{
    "@value": "2015 Bachelor of Science and Arts Degree",
    "@language": "en"
  }, {
    "@value": "2015 Licence de Sciences et d'Arts",
    "@language": "fr"
  }, {
    "@value": "2015 بكالوريوس العلوم والآداب",
    "@language": "ar",
    "@direction": "rtl"
  }],
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": [{
        "@value": "Bachelor of Science and Arts Degree",
        "@language": "en"
      }, {
        "@value": "Licence de Sciences et d'Arts",
        "@language": "fr"
      }, {
        "@value": "بكالوريوس العلوم والآداب",
        "@language": "ar",
        "@direction": "rtl"
      }]
    }
  }
}

本规范定义了 credentialStatus 属性，用于发现与可验证凭证状态相关的信息，例如其是否被暂停或撤销。

如果存在，与 credentialStatus 属性关联的值是单个对象或由一个或多个对象组成的集合。以下属性为每个对象定义：

id: id 属性是OPTIONAL。它MAY 用于为凭证状态对象提供唯一标识符。如果存在，则 4.4 标识符一节中的规范性指导MUST 被遵循。
type: type 属性是REQUIRED。它用于表达由该对象表示的状态信息类型。 4.5 类型一节中的相关规范性指导MUST 被遵循。

凭证状态信息的精确内容由具体的 credentialStatus 类型定义决定，并且会因实现是否简单或是否增强隐私等因素而有所不同。该值将提供足够的信息来确定凭证的当前状态，以及机器可读信息是否可从 URL 中检索。例如，该对象可以包含一个指向外部文档的链接，该文档说明凭证是否被暂停或撤销。

示例 12：status 属性的使用

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/3732",
  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "credentialStatus": {
    "id": "https://university.example/credentials/status/3#94567",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://university.example/credentials/status/3"
  }
}

一个凭证可以具有与其关联的多个状态，例如它是否已被撤销或暂停。

示例 13：status 属性的多个条目的使用

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://license.example/credentials/9837",
  "type": ["VerifiableCredential", "ExampleDrivingLicenseCredential"],
  "issuer": "https://license.example/issuers/48",
  "validFrom": "2020-03-14T12:10:42Z",
  "credentialSubject": {
    "id": "did:example:f1c276e12ec21ebfeb1f712ebc6",
    "license": {
      "type": "ExampleDrivingLicense",
      "name": "License to Drive a Car"
    }
  },
  "credentialStatus": [{
    "id": "https://license.example/credentials/status/84#14278",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "14278",
    "statusListCredential": "https://license.example/credentials/status/84"
  }, {
    "id": "https://license.example/credentials/status/84#82938",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "suspension",
    "statusListIndex": "82938",
    "statusListCredential": "https://license.example/credentials/status/84"
  }]
}

实现者需注意，具有多个状态条目的凭证可能包含相互冲突的信息。调和此类冲突是验证过程的一部分，因此是验证者业务逻辑的一部分，从而不在本规范范围内。

定义状态方案的数据模型、格式和协议不在本规范范围内。Verifiable Credential Extensions 文档包含了可供希望实现可验证凭证状态检查的实现者使用的可用状态方案。

凭证状态规范MUST NOT 允许跟踪个人，例如当验证者对特定持有者或主体感兴趣时，颁发者会收到通知（直接或间接）。不可接受的方法包括“回传”，即每次使用凭证都会联系该凭证的颁发者以检查特定个人的状态；或“降低假名性”，即每次使用凭证都会导致向颁发者请求信息，而该颁发者可以利用这些信息推断验证者对特定个人的兴趣。

在对给定数据集合强制执行特定结构时，数据模式很有用。本规范考虑至少两种类型的数据模式：

数据验证模式，用于确定凭证或可验证凭证的结构和内容符合已发布的模式。
数据编码模式，用于将可验证凭证的内容映射到替代表示格式，例如零知识证明中使用的格式。

重要的是要理解，数据模式与 @context 属性具有不同目的；后者既不强制执行数据结构或数据语法，也不能定义到替代表示格式的任意编码。

本规范定义了以下属性来表达数据模式，颁发者可以将其包含在其颁发的可验证凭证中：

credentialSchema

credentialSchema 属性的值MUST 是一个或多个数据模式，它们向验证者提供足够的信息，以判断所提供的数据是否符合所提供的模式。每个 credentialSchema MUST 指定其 type（例如 JsonSchema）以及一个 id 属性，该属性MUST 是标识模式文件的 URL。具体类型定义决定每个数据模式的精确内容。

如果存在多个模式，则有效性根据每个关联的 type 属性所概述的处理规则来确定。

注：可以进行凭证类型特定的语法检查

credentialSchema 属性允许对类型定义进行注释，或将它们锁定到词汇表的特定版本。可验证凭证的作者可以使用 credentialSchema 包含其词汇表的静态版本，并通过某种内容完整性保护机制进行保护。credentialSchema 属性还使得可以对凭证进行语法检查，并使用 JSON Schema 等验证机制 [VC-JSON-SCHEMA] 验证。

示例 14：使用 credentialSchema 属性执行 JSON 模式验证

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/3732",
  "type": ["VerifiableCredential", "ExampleDegreeCredential", "ExamplePersonCredential"],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    },
    "alumniOf": {
      "name": "Example University"
    }
  },
  "credentialSchema": [{
    "id": "https://example.org/examples/degree.json",
    "type": "JsonSchema"
  },
  {
    "id": "https://example.org/examples/alumni.json",
    "type": "JsonSchema"
  }]
}

在上面的示例中，颁发者指定了两个 credentialSchema 对象，每个对象都指向一个 JSON Schema [VC-JSON-SCHEMA] 文件，验证者可以使用该文件来判断该可验证凭证是否格式良好。

本规范认可两类保护机制：使用封套证明的机制，以及使用嵌入式证明的机制。

封套证明会包装此数据模型的一种序列化。 Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] 中定义了一种此类 RECOMMENDED 的封套证明机制。

嵌入式证明是一种将证明包含在数据模型序列化中的机制。Verifiable Credential Data Integrity 1.0 [VC-DATA-INTEGRITY] 中定义了一种此类 RECOMMENDED 的嵌入式证明机制。

这两类保护机制并不相互排斥。还可以根据 5.13 保护机制规范一节中的规则定义其他保护机制规范。

示例 15：使用嵌入式证明的可验证凭证

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.gov/credentials/3732",
  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
  "issuer": "did:example:6fb1f712ebe12c27cc26eebfe11",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "https://subject.example/subject/3921",
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2021-11-13T18:19:39Z",
    "verificationMethod": "https://university.example/issuers/14#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z58DAdFfa9SkqZMVPxAQp...jQCrfFPP2oumHKtz"
  }
}

上述嵌入式证明通过 proof 属性使用数字签名修饰原始数据，从而保护原始凭证。这生成了一个可验证凭证，易于在现代编程环境和数据库系统中管理。

示例 16：使用 SD-JWT 格式的封套证明的可验证凭证

eyJhbGciOiJFUzM4NCIsImtpZCI6IkdOV2FBTDJQVlVVMkpJVDg5bTZxMGM3U3ZjNDBTLWJ2UjFTT0
Q3REZCb1UiLCJ0eXAiOiJ2YytsZCtqc29uK3NkLWp3dCIsImN0eSI6InZjK2xkK2pzb24ifQ
.
eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwcz
ovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6
Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLT
AxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiX3NkIjpbIlNFOHp4bmduZTNNbWEwLUNm
S2dlYW1rNUVqU1NfOXRaNlN5NDdBdTdxRWMiLCJjT3lySEVrSlZwdEtSdURtNkNZVTREajJvRkExd0
JQRjFHcTJnWEo1NXpzIl19LCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJh
Y2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsibVNfSVBMa0JHcTIxbVA3Z0VRaHhOck
E0ZXNMc1ZKQ1E5QUpZNDFLLVRQSSJdfSwiX3NkIjpbIlhTSG9iU05Md01PVl9QNkhQMHNvMnZ1clNy
VXZ3UURYREJHQWtyTXk3TjgiXX0sIl9zZCI6WyJQNE5qWHFXa2JOc1NfRzdvdmlLdm1NOG0yckhDTm
5XVVV2SXZBbW9jb2RZIiwieFNvSHBKUXlCNGV1dmg4SkFJdDFCd1pjNFVEOHY5S3ZOTmVLMk9OSjFC
QSJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2
lzc3VlcnMvNTY1MDQ5IiwiaWF0IjoxNzAzNjI1OTAxLCJleHAiOjE3MzUyNDgzMDEsImNuZiI6eyJq
d2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsImFsZyI6IkVTMzg0IiwieCI6Inl1Zlo1SFUzcU
NfOTRMbkI3Zklzd0hmT0swQlJra0Z5bzVhd1QyX21ld0tJWUpLMVNfR0QySVB3UjRYUTZpdFEiLCJ5
IjoiRmEtV2pOd2NLQ1RWWHVDU2tCY3RkdHJOYzh6bXdBTTZWOWxudmxxd1QyQnRlQ0ZHNmR6ZDJoMF
VjeXluTDg0dCJ9fX0
.
M7BFJB9LEV_xEylSJpP00fd_4WjrOlXshh0dUv3QgOzw2MEGIfSfi9PoCkHJH7TI0InsqkD6XZVz38
MpeDKekgBW-RoDdJmxnifYOEJhKpJ5EN9PvA007UPi9QCaiEzX
~
WyJFX3F2V09NWVQ1Z3JNTkprOHNXN3BBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbG
UvY3JlZGVudGlhbHMvMTg3MiJd
~
WyJTSEc4WnpfRDVRbFMwU0ZrZFUzNXlRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIi
wgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d
~
WyJqZzJLRno5bTFVaGFiUGtIaHV4cXRRIiwgImlkIiwgImh0dHBzOi8vZXhhbXBsZS5vcmcvZXhhbX
BsZXMvZGVncmVlLmpzb24iXQ
~
WyItQmhzaE10UnlNNUVFbGt4WGVXVm5nIiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyJ0SEFxMEUwN
nY2ckRuUlNtSjlSUWRBIiwgImlkIiwgImRpZDpleGFtcGxlOjEyMyJd
~
WyJ1Ynd6bi1kS19tMzRSMGI0SG84QTBBIiwgInR5cGUiLCAiQmFjaGVsb3JEZWUiXQ

上述封套证明通过将原始数据封装在数字签名封套中来保护原始凭证，从而生成一个可验证凭证，可使用理解 SD-JWT 格式的工具处理。

可验证呈示MAY 用于聚合来自多个可验证凭证的信息。

可验证呈示SHOULD 极为短暂，并绑定到验证者提供的质询。完成这一点的细节取决于保护机制、传输协议以及验证者策略。除非特定保护机制或嵌入协议定义了额外要求，否则验证者通常不能假设该可验证呈示与所呈示的可验证凭证相关联。

可验证呈示的默认图也称为可验证呈示图。

以下属性为可验证呈示定义：

id: id 属性是可选的。它MAY 用于为可验证呈示提供唯一标识符。如果存在，则 4.4 标识符一节中的规范性指导MUST 被遵循。
type: type 属性MUST 存在。它用于表达可验证呈示的类型。此属性的一个值MUST 是 VerifiablePresentation，但也MAY 包含其他类型。 4.5 类型一节中的相关规范性指导MUST 被遵循。
verifiableCredential: verifiableCredential 属性MAY 存在。其值MUST 是一个或多个可验证凭证和/或封套式可验证凭证对象（这些值MUST NOT 是数字、字符串或 URL 等非对象值）。这些对象称为可验证凭证图，并且 MUST 表达使用保护机制保护的信息。更多细节见5.12 可验证凭证图一节。
holder: 可验证呈示MAY 包含 holder 属性。如果存在，其值MUST 是一个URL或一个包含 id 属性的对象。RECOMMENDED： holder 或其 id 中的 URL应为一种在解引用时会生成包含关于持有者的机器可读信息的文档的 URL，该信息可用于验证可验证呈示中表达的信息。如果不存在 holder 属性，关于持有者的信息要么通过保护机制获得，要么与可验证呈示的验证无关。

下面的示例展示了一个可验证呈示：

示例 17：呈示的基本结构

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "type": ["VerifiablePresentation", "ExamplePresentation"],
  "verifiableCredential": [{ ... }]
}

上面所示 verifiableCredential 属性的内容是可验证凭证图，如本规范所述。

可验证呈示可以包含一个或多个使用某种保护机制保护的可验证凭证，该机制会对载荷进行“封套”，例如 Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]。这可以通过将 verifiableCredential 属性关联到一个 type 为 EnvelopedVerifiableCredential 的对象来完成。

EnvelopedVerifiableCredential: 它们用于将包含封套式可验证凭证的对象与可验证呈示中的 verifiableCredential 属性相关联。该对象的 @context 属性MUST 存在，并包含一个上下文，例如本规范的基础上下文，该上下文至少定义 id、type 和 EnvelopedVerifiableCredential 术语，如本规范提供的基础上下文所定义。该对象的 id 值MUST 是 data: URL [RFC2397]，它使用封套式安全方案表达受保护的可验证凭证，例如 Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]。该对象的 type 值MUST 是 EnvelopedVerifiableCredential。

下面的示例展示了一个包含封套式可验证凭证的可验证呈示：

示例 18：呈示的基本结构

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiablePresentation", "ExamplePresentation"],
  "verifiableCredential": [{
    "@context": "https://www.w3.org/ns/credentials/v2",
    "id": "data:application/vc+sd-jwt,QzVjV...RMjU",
    "type": "EnvelopedVerifiableCredential"
  }]
}

注：将封套内容作为 RDF 处理

实现者可能希望在 RDF 环境中处理本节所描述的对象，以及由 id 值表达的封套式呈示，并在与 RDF 相关的对象之间创建链接。这样做的需求和机制取决于用例，因此也取决于具体实现。

可以表达一个使用某种会“封套”载荷的机制保护的可验证呈示，例如 Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]。这可以通过使用一个 type 为 EnvelopedVerifiablePresentation 的对象来完成。

EnvelopedVerifiablePresentation: 用于表达封套式可验证呈示。该对象的 @context 属性MUST 存在并包含一个上下文，例如本规范的基础上下文，该上下文至少定义 id、type 和 EnvelopedVerifiablePresentation 术语，如本规范提供的基础上下文所定义。该对象的 id 值MUST 是 data: URL [RFC2397]，它使用封套式保护机制（例如 Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]）表达受保护的可验证呈示。该对象的 type 值MUST 是 EnvelopedVerifiablePresentation。

下面的示例展示了一个封套式可验证呈示：

示例 19：封套式可验证呈示的基本结构

{
  "@context": "https://www.w3.org/ns/credentials/v2",
  "id": "data:application/vp+jwt,eyJraWQiO...zhwGfQ",
  "type": "EnvelopedVerifiablePresentation"
}

某些零知识密码学方案可能使持有者能够间接证明其持有来自可验证凭证的声明，而无需披露该可验证凭证中的所有声明。在这些方案中，可验证凭证可用于派生可呈示数据，该数据以密码学方式断言，使得验证者在信任颁发者时也可以信任该值。

某些选择性披露方案可以共享从可验证凭证派生的声明子集。

注：使用零知识证明的呈示是可能的

关于包含派生数据而不是直接嵌入的可验证凭证的 ZKP 风格可验证呈示示例，请参见 5.7 零知识证明一节。

Pat 有一个属性
overAge，其值为 21 — 图 11 一个基本声明，表达 Pat 年龄超过 21 岁。

持有者MAY 在可验证呈示中使用 verifiableCredential 属性来包含来自任何颁发者的可验证凭证，包括他们自己。当可验证凭证的颁发者就是持有者时，该可验证凭证中的声明被视为 自断言的。此类自断言声明可以通过保护包含它们的可验证呈示的同一机制来保护，也可以通过可用于其他可验证凭证的任何机制来保护。

这些自断言声明的主体不受限制，因此这些声明可以包含关于持有者、其他包含的可验证凭证之一，甚至包含自断言可验证凭证的可验证呈示的陈述。在每种情况下， id 属性都用于在作出关于该主体的声明的对象中标识特定主体，正如在非自断言可验证凭证中所做的那样。

包含一个自断言可验证凭证的可验证呈示，如果该凭证仅使用与该可验证呈示相同的机制进行保护，则MUST 包含 holder 属性。

为可验证凭证定义的所有规范性要求都适用于自断言可验证凭证。

当可验证呈示中的可验证凭证的 issuer 属性的值与可验证呈示的 holder 属性的值相同时，该可验证凭证被视为自断言的。

下面的示例展示了一个可验证呈示，它嵌入了一个使用与该可验证呈示相同的机制保护的自断言可验证凭证。

示例 20：一个使用嵌入式 Data Integrity 证明保护、并包含自断言可验证凭证的可验证呈示

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiablePresentation", "ExamplePresentation"],
  "holder": "did:example:12345678",
  "verifiableCredential": [{
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "type": ["VerifiableCredential", "ExampleFoodPreferenceCredential"],
    "issuer": "did:example:12345678",
    "credentialSubject": {
      "favoriteCheese": "Gouda"
    },
    { ... }
  }],
  "proof": [{ ... }]
}

下面的示例展示了一个可验证呈示，它嵌入了一个持有关于该可验证呈示的声明的自断言可验证凭证。它使用与该可验证呈示相同的机制进行保护。

示例 21：一个使用嵌入式 Data Integrity 证明保护、并包含关于该可验证呈示的自断言可验证凭证的可验证呈示

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiablePresentation", "ExamplePresentation"],
  "id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b",
  "holder": "did:example:12345678",
  "verifiableCredential": [{
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "type": ["VerifiableCredential", "ExampleAssertCredential"],
    "issuer": "did:example:12345678",
    "credentialSubject": {
      "id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b",
      "assertion": "This VP is submitted by the subject as evidence of a legal right to drive"
    },
    "proof": { ... }
  }],
  "proof": { ... }
}

基于第 4. 基本概念中介绍的概念，本节探讨关于可验证凭证的更复杂主题。

本节为非规范性内容。

可验证凭证信任模型基于以下预期：

验证者预期颁发者以可验证方式颁发其收到的凭证。这可以通过满足以下任一条件来确定：
- 颁发者使用保护机制保护凭证，该机制确定颁发者生成了该凭证。换言之，颁发者颁发了一个可验证凭证。
- 凭证以一种清楚确定颁发者生成了该凭证，并且该凭证在传输或存储过程中未被篡改的方式进行传输。根据验证者的风险评估，这一预期可能会被弱化。
所有实体都预期可验证数据注册表具有篡改留痕性，并且正确记录哪些数据由哪些实体控制。这通常通过其发布方法来实现。这可以通过来自可信发布者的点对点协议、公开可访问且知名的网站（带有内容哈希）、区块链等实现。当实体发布关于自身的元数据时，该发布可以通过使用实体私钥进行保护而获得完整性保护。
持有者和验证者预期颁发者对其在凭证中作出的关于主体的声明负责，并在其不再支持这些声明时迅速撤销凭证。
持有者可能信任颁发者的声明，因为该持有者与颁发者已有信任关系。例如，雇主可能向雇员提供一份就业可验证凭证，或者政府可能向公民颁发电子护照。
在不存在既有信任关系的情况下，持有者可能通过某种带外方式来判断颁发者是否有资格颁发所提供的可验证凭证。

注：持有者并不总是必须信任颁发者，因为所颁发的可验证凭证可能是关于一个并非持有者的主体的断言，或者不关于任何人，并且持有者可能愿意将此信息转发给验证者，而不对其真实性负责。
持有者预期凭证库安全地存储凭证，不向除持有者以外的任何人释放凭证（持有者随后可以将其呈示给验证者），并且在其保管期间不损坏或丢失凭证。

该信任模型通过确保以下内容而区别于其他信任模型：

颁发者和验证者不需要了解关于凭证库的任何信息。
颁发者不需要了解关于验证者的任何信息。

验证者如何决定信任哪些颁发者，以及针对哪些数据或目的进行信任，超出了本推荐标准的范围。一些颁发者，例如知名组织，可能仅因其声誉而受到许多验证者的信任。一些颁发者和验证者可能属于一个社区，在该社区中，所有成员因成员资格规则而相互信任。一些验证者可能信任特定的信任服务提供者，该提供者负责审查颁发者并将其列入信任列表，例如 Electronic Signatures and Infrastructures (ESI); Trusted Lists [ETSI-TRUST-LISTS] 中指定的信任列表，或 Adobe Approved Trust List。

通过解耦颁发者和验证者之间的预期，创建了一种更灵活、更动态的信任模型，从而增加市场竞争和客户选择。

有关此信任模型如何与工作组研究的各种威胁模型交互的更多信息，请参阅 Verifiable Credentials Use Cases [VC-USE-CASES]。

注：信任模型不同于传统证书颁发机构系统

本规范中详述的数据模型并不意味着一种传递式信任模型，例如更传统的证书颁发机构信任模型所提供的信任模型。在可验证凭证数据模型中，验证者要么直接信任某个颁发者，要么不信任。虽然可以使用可验证凭证数据模型构建传递式信任模型，但强烈建议实现者了解以证书颁发机构系统所采用的方式广泛委托信任所引入的安全弱点。

在可验证凭证中包含指向外部资源的链接时，最好知道该资源自可验证凭证颁发以来是否已被修改。这适用于存在远程检索的外部资源的情况，也适用于颁发者和/或验证者可能拥有资源的本地缓存副本的情况。同样也可能需要知道可验证凭证中使用的 JSON-LD 上下文的内容，在验证者使用时，与颁发者使用时相同。

为了将完整性保护扩展到相关资源，颁发者在颁发可验证凭证时 MAY 包含 relatedResource 属性：

relatedResource

relatedResource 属性的值 MUST 是一个或多个以下形式的对象：

属性	描述
`id`	资源的标识符为 REQUIRED，并符合第 4.4 标识符中定义的格式。该值 MUST 在相关资源对象列表中唯一。
`mediaType`	一个 OPTIONAL 的有效媒体类型，如 IANA 媒体类型注册表中所列。
`digestSRI`	一个或多个密码学摘要，如 Subresource Integrity 规范中定义的 `hash-expression` ABNF 语法所定义，第 3.5 节： `integrity` 属性。
`digestMultibase`	一个或多个密码学摘要，如 Verifiable Credential Data Integrity 1.0 规范中的 `digestMultibase` 属性所定义，第 2.6 节：资源完整性。

与 relatedResource 关联的每个对象 MUST 至少包含一个 digestSRI 或 digestMultibase 值。

如果列出了 mediaType，则使用 HTTP Semantics 检索由 id 属性标识的资源的实现 SHOULD：

在 Accept HTTP Header 中使用该媒体类型，并且
如果响应包含具有不同媒体类型的 Content-Type HTTP Header，则拒绝该响应。

可验证凭证中任何包含 id 属性的对象，都 MAY 通过添加 digestSRI 或 digestMultibase 属性来标注完整性信息；其中任一属性 MAY 伴随额外可选的 mediaType 属性。

任何希望实现选择性披露或不可关联披露的对象 SHOULD NOT 作为对象包含在 relatedResource 数组中。

如果一致性验证者实现基于一致性文档中 relatedResource 对象的 id 使用某个资源，并且对应的密码学摘要出现在 relatedResource 对象值中，则该实现 MUST 计算所检索资源的摘要。如果颁发者提供的摘要与所检索资源计算出的摘要不匹配，则一致性验证者实现 MUST 产生错误。

强烈建议实现者查阅适当来源，例如 FIPS 180-4 安全哈希标准和 Commercial National Security Algorithm Suite 2.0，以确保他们选择的是当前且可靠的哈希算法。在撰写本文时， sha384 SHOULD 被视为供实现者使用的最低强度哈希算法。

一个引用 JSON-LD 上下文的相关资源完整性对象示例。

示例 25：使用 digestSRI 属性（base64 编码的 SHA2-384）

"relatedResource": [{
  "id": "https://www.w3.org/ns/credentials/v2",
  "digestSRI":
    "sha384-Ml/HrjlBCNWyAX91hr6LFV2Y3heB5Tcr6IeE4/Tje8YyzYBM8IhqjHWiWpr8+ZbYU"
},{
  "id": "https://www.w3.org/ns/credentials/examples/v2",
  "digestSRI":
    "sha384-MzNNbQTWCSUSi0bbz7dbua+RcENv7C6FvlmYJ1Y+I727HsPOHdzwELMYO9Mz68M26"
}]

示例 26：使用 digestMultibase 属性（base64-url-nopad 编码的 SHA2-256）

"relatedResource": [{
  "id": "https://www.w3.org/ns/credentials/v2",
  "digestMultibase": "uEiBZlVztZpfWHgPyslVv6-UwirFoQoRvW1htfx963sknNA"
},{
  "id": "https://www.w3.org/ns/credentials/examples/v2",
  "digestMultibase": "uEiBXOT-8adbvubm13Jy2uYgLCUQ2Cr_i6vRZyeWM8iedfA"
}]

系统启用对已过期可验证凭证的手动或自动刷新是有用的。有关可验证凭证有效期的更多信息，请参见第 A.7 有效期。本规范定义了 refreshService 属性，该属性使颁发者能够包含指向刷新服务的链接。

如果刷新服务面向验证者或持有者（或二者），则颁发者可以将刷新服务作为元素包含在可验证凭证中；如果刷新服务仅面向持有者，则可以包含在可验证呈示中。在后一种情况下，这使持有者能够在创建要与验证者共享的可验证呈示之前刷新该可验证凭证。在前一种情况下，将刷新服务包含在可验证凭证中，使持有者或验证者能够在将来更新该凭证。

刷新服务预计仅在以下情况下使用：凭证已过期，或颁发者未发布凭证状态信息。建议颁发者不要将 refreshService 属性放入不包含公开信息或其刷新服务未以某种方式受保护的可验证凭证中。

refreshService: refreshService 属性的值 MUST 是一个或多个刷新服务，它们向接收方软件提供足够信息，使接收方能够刷新该可验证凭证。每个 refreshService 值 MUST 指定其 type。每个刷新服务的精确内容由特定的 refreshService 类型定义确定。

示例 27：颁发者使用 refreshService 属性

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/age/v1"
  ],
  "type": ["VerifiableCredential", "AgeVerificationCredential"],
  "issuer": "did:key:z6MksFxi8wnHkNq4zgEskSZF45SuWQ4HndWSAVYRRGe9qDks",
  "validFrom": "2024-04-03T00:00:00.000Z",
  "validUntil": "2024-12-15T00:00:00.000Z",
  "name": "Age Verification Credential",
  "credentialSubject": {
    "overAge": 21
  },
  "refreshService": {
    "type": "VerifiableCredentialRefreshService2021",
    "url": "https://registration.provider.example/flows/reissue-age-token",
    "refreshToken": "z2BJYfNtmWRiouWhDrbDQmC2zicUPBxsPg"
  }
}

在上面的示例中，颁发者指定了一个自动 refreshService，可以通过将可验证凭证 POST 到刷新服务 url 来使用。注意，此特定可验证凭证并不打算与原始颁发者之外的任何人共享。

注：未经认证的凭证刷新

将 refreshService 属性放入可验证凭证中，使其可供验证者使用，可能会从持有者手中移除控制权和同意权，并允许将可验证凭证直接颁发给验证者，从而绕过持有者。

使用条款可由颁发者或持有者用来传达可验证凭证或可验证呈示的颁发条件。颁发者将其使用条款放在可验证凭证中。持有者将其使用条款放在可验证呈示中。本规范定义了 termsOfUse 属性，用于表达使用条款信息。

termsOfUse 属性的值可用于告知验证者以下任一项或全部内容，以及其他事项：

颁发可验证凭证时使用的程序或策略，例如通过提供指向公共位置的指针（以避免“回呼”隐私问题），在该位置可以找到这些程序或策略，或提供定义它们的标准名称
适用于向验证者呈示此可验证凭证的颁发者规则和策略，例如通过提供指向公共位置的指针（以避免“回呼”隐私问题），在该位置可以找到这些规则或策略
颁发者在其授权下颁发此特定可验证凭证的实体身份

termsOfUse: termsOfUse 属性的值 MUST 指定一个或多个使用条款策略，创建者在这些策略下颁发了该凭证或呈示。如果接收方（持有者或验证者）不愿遵守指定的使用条款，则其自行承担责任，并且如果违反所述使用条款，可能承担法律责任。每个 termsOfUse 值 MUST 指定其类型，例如 TrustFrameworkPolicy，并且 MAY 指定其实例 id。每个使用条款的精确内容由特定的 termsOfUse 类型定义确定。

示例 28：颁发者使用 termsOfUse 属性

{
  {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/undefined-terms/v2"
    ],
    "id": "urn:uuid:08e26d22-8dca-4558-9c14-6e7aa7275b9b",
    "type": [
      "VerifiableCredential",
      "VerifiableAttestation",
      "VerifiableTrustModel",
      "VerifiableAuthorisationForTrustChain"
    ],
    "issuer": "did:ebsi:zZeKyEJfUTGwajhNyNX928z",
    "validFrom": "2021-11-01T00:00:00Z",
    "validUntil": "2024-06-22T14:11:44Z",
    "credentialSubject": {
      "id": "did:ebsi:zvHWX359A3CvfJnCYaAiAde",
      "reservedAttributeId": "60ae46e4fe9adffe0bc83c5e5be825aafe6b5246676398cd1ac36b8999e088a8",
      "permissionFor": [{
        "schemaId": "https://api-test.ebsi.eu/trusted-schemas-registry/v3/schemas/zHgbyz9ajVuSProgyMhsiwpcp8g8aVLFRNARm51yyYZp6",
        "types": [
          "VerifiableCredential",
          "VerifiableAttestation",
          "WorkCertificate"
        ],
        "jurisdiction": "https://publications.europa.eu/resource/authority/atu/EUR"
      }]
    },
    "termsOfUse": {
      "type": "TrustFrameworkPolicy",
      "trustFramework": "Employment&Life",
      "policyId": "https://policy.example/policies/125",
      "legalBasis": "professional qualifications directive"
    },
    "credentialStatus": {
      "id": "https://api-test.ebsi.eu/trusted-issuers-registry/v5/issuers/did:ebsi:zvHWX359A3CvfJnCYaAiAde/attributes/60ae46e4fe9adffe0bc83c5e5be825aafe6b5246676398cd1ac36b8999e088a8",
      "type": "EbsiAccreditationEntry"
    },
    "credentialSchema": {
      "id": "https://api-test.ebsi.eu/trusted-schemas-registry/v3/schemas/zCSHSDwrkkd32eNjQsMCc1h8cnFaxyTXP5ByozyVQXZoH",
      "type": "JsonSchema"
    }
  }
}

在上面的示例中，颁发者断言可验证凭证被颁发所依据的法律基础是 “professional qualifications directive”，使用的是 “Employment&Life” 信任框架，并提供了指向该策略的特定链接。

预计此功能将由政府颁发的可验证凭证使用，用于指示数字钱包将其使用限制在类似的政府组织内，以试图保护公民免受敏感数据的意外使用。类似地，私营行业颁发的一些可验证凭证预计会将使用限制在组织内部的部门内，或限制在营业时间内。强烈建议实现者在 Verifiable Credentials Implementation Guidelines [VC-IMP-GUIDE] 文档的适当章节中进一步了解此不断演进的功能。

证据可由颁发者包含，用于在验证者中向其提供可验证凭证中的额外支持信息。这可以由验证者用于确定其依赖可验证凭证中声明的置信度。例如，颁发者可以在颁发凭证之前，检查主体提供的实物文件，或执行一组背景核查。在某些场景中，当验证者确定依赖给定凭证所关联的风险时，此信息很有用。

本规范定义了 evidence 属性，用于表达证据信息。

evidence

如果存在，evidence 属性的值 MUST 是单个对象，或由一个或多个对象组成的集合。以下属性为每个证据对象定义：

id: id 属性是 OPTIONAL。它 MAY 用于为证据对象提供唯一标识符。如果存在，则 MUST 遵循第 4.4 标识符中的规范性指导。
type: type 属性是 REQUIRED。它用于表达该对象所表示的证据信息类型。MUST 遵循第 4.5 类型中的相关规范性指导。

注：有关提供证据的策略，请参见实现指南

有关规范如何支持附件以及对凭证和非凭证数据的引用的信息，请参见第 5.3 相关资源的完整性。

示例 29：支持技能成就凭证的证据示例

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
  ],
  "id": "http://1edtech.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "OpenBadgeCredential"
  ],
  "issuer": {
    "id": "https://1edtech.edu/issuers/565049",
    "type": "Profile"
  },
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": "AchievementSubject",
    "name": "Alice Smith",
    "activityEndDate": "2023-12-02T00:00:00Z",
    "activityStartDate": "2023-12-01T00:00:00Z",
    "awardedDate": "2024-01-01T00:00:00Z",
    "achievement": [{
      "id": "urn:uuid:d46e8ef1-c647-419b-be18-5e045d1c4e64",
      "type": ["Achievement"],
      "name": "Basic Barista Training",
      "criteria": {
        "narrative": "Team members are nominated for this badge by their supervisors, after passing the Basic Barista Training course."
      },
      "description": "This achievement certifies that the bearer is proficient in basic barista skills."
    }]
  },
  "evidence": [{
      // 指向外部托管证据文件/制品的 URL
      "id": "https://videos.example/training/alice-espresso.mp4",
      "type": ["Evidence"],
      "name": "Talk-aloud video of double espresso preparation",
      "description": "This is a talk-aloud video of Alice demonstrating preparation of a double espresso drink.",
      // mp4 视频文件的摘要哈希
      "digestMultibase": "uELq9FnJ5YLa5iAszyJ518bXcnlc5P7xp1u-5uJRDYKvc"
    }
  ]
}

在上面的 evidence 示例中，颁发者断言其拥有凭证主体展示该成就的视频。

注：证据的目的不同于保护机制

evidence 属性提供的信息不同于所使用的保护机制的信息。evidence 属性用于表达与可验证凭证相关的支持信息，例如文件证据。相比之下，保护机制用于表达与颁发者真实性以及可验证凭证完整性相关的机器可验证数学证明。有关保护机制的更多信息，请参见第 4.12 保护机制。

零知识证明是一种保护机制，它使持有者能够证明其持有一个包含某个值的可验证凭证，而不披露实际值，例如能够证明某人已超过 25 岁而不透露其生日。此数据模型支持使用零知识证明进行保护。

一些由零知识证明机制实现、并且与可验证凭证兼容的能力包括：

选择性披露：由持有者向验证者披露可验证凭证中的属性。这允许持有者向验证者提供他们所需的精确信息且不提供更多信息。这还能够生成一个派生的可验证凭证，该凭证按验证者的数据模式格式化，而无需在呈示期间让颁发者参与。这为持有者使用其已颁发的可验证凭证提供了很大的灵活性。
不可关联披露：由持有者向验证者披露可验证凭证中的属性。盲签名允许不可关联披露，这移除了在向一个或多个验证者进行多次呈示时持有者关联的一个常见来源。这允许持有者在每次呈示中共享不同的签名值，从而减少共享的数据量。
对持有者和/或主体进行不可关联识别。这允许持有者证明某个凭证颁发给了他们，或允许主体证明某个凭证是关于他们颁发的，而无需共享可关联的标识符。这也减少了必须共享的数据量。此能力还可用于将来自多个颁发者的多个可验证凭证合并为单个可验证呈示，而不向验证者透露可验证凭证或主体标识符。

创建保护机制的规范作者 MUST NOT 以会泄露信息的方式设计这些机制，因为这些信息会使验证者能够在面向不同验证者的多个可验证呈示之间关联持有者。

并非所有能力都在所有零知识证明机制中受到支持。关于特定零知识证明机制所提供能力和技术的具体细节，以及将其与可验证凭证一起使用的任何规范性要求，可以在使用该零知识证明机制保护可验证凭证的规范中找到。有关此类规范的示例，请参见 Data Integrity BBS Cryptosuites v1.0。

我们注意到，在大多数情况下，为了让持有者将零知识机制与可验证凭证一起使用，颁发者需要以支持这些能力的方式保护该可验证凭证。

下图突出说明了数据模型如何可用于以零知识方式颁发和呈示可验证凭证。

左侧的 Verifiable
Credential 1 和 Verifiable Credential 2 映射
到右侧 Presentation 内的 Derived Credential 1 和
Derived Credential 2。Verifiable Credential 1
包含 Context、Type、ID、Issuer、Issue Date、Expiration
Date、CredentialSubject 和 Proof，其中
CredentialSubject 包含 GivenName、FamilyName 和
Birthdate，Proof 包含 Signature、Proof of
Correctness 和 Attributes。Verifiable Credential 2
包含 Context、Type、ID、Issuer、Issue Date、Expiration
Date、CredentialSubject 和 Proof，其中
CredentialSubject 包含 University，后者包含
Department，后者包含 DegreeAwarded，Proof 包含 Signature、Proof of
Correctness 和 Attributes。右侧的 Presentation 图
包含 Context、Type、ID、
VerifiableCredential 和 Proof，其中
VerifiableCredential 包含 Derived Credential 1 和
Derived Credential 2，Proof 包含 Common Link
Secret。Derived Credential 1 包含 Context、Type、ID、
Issuer、Issue Date、CredentialSubject 和 Proof，其中
CredentialSubject 包含 AgeOver18，Proof 包含
Knowledge of Signature。Derived Credential 2 包含
Context、Type、ID、Issuer、Issue Date、CredentialSubject
和 Proof，其中 CredentialSubject 包含 Degree，
Proof 包含 Knowledge of Signature。一条线将
Verifiable Credential 1 中的 Birthdate 连接到
Derived Credential 1 中的 AgeOver18。一条线将
Verifiable Credential 2 中的 DegreeAwarded 连接到 Derived Credential 2 中的 Degree。 — 图 12 ZKP 呈示中凭证与派生凭证之间关系的可视化示例。

下面展示了一个使用 Data Integrity BBS Cryptosuites v1.0 不可关联选择性披露保护机制的可验证凭证和可验证呈示示例。

示例 30：使用带有基础证明的 Data Integrity BBS Cryptosuite 的可验证凭证

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v3"
  ],
  "type": ["VerifiableCredential", "PermanentResidentCard"],
  "issuer": {
    "id": "did:web:credentials.utopia.example",
    "image": "data:image/png;base64,iVBORw0KGgo...YII="
  },
  "identifier": "83627465",
  "name": "Permanent Resident Card",
  "description": "Government of Utopia Permanent Resident Card.",
  "validFrom": "2024-08-01T00:00:00Z",
  "validUntil": "2029-12-01T00:00:00Z",
  "credentialSubject": {
    "type": ["PermanentResident", "Person"],
    "givenName": "JANE",
    "familyName": "SMITH",
    "gender": "Female",
    "image": "data:image/png;base64,iVBORw0KGgoAA...Jggg==",
    "residentSince": "2015-01-01",
    "lprCategory": "C09",
    "lprNumber": "999-999-999",
    "commuterClassification": "C1",
    "birthCountry": "Arcadia",
    "birthDate": "1978-07-17"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "verificationMethod": "did:web:playground.alpha.chapi.io#zUC75LjjCLGKRxSissX1nAebRDmY4Bv4T6MAbzgaap9Q8rAGf6SEjc2Hf4nH6bUPDwky3GWoYcUjMCcEqRRQfXEiNwfeDwNYLoeqk1J1W2Ye8vCdwv4fSd8AZ1yS6UoNzcsQoPS",
    "cryptosuite": "bbs-2023",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0ChVhQjYs9O7wUb3KRSMaIRX7jmafVHYDPYBLD4ta85_qmuXTBU_t2Ir7pNujwRE6fERsBUEZRSjJjtI-hqOqDs3VvBvH6gd3o2KeUS2V_zpuphPpYQEkapOeQgRTak9lHKSTqEQqa4j2lyHqekEeGvzPlqcHQGFccGifvLUXtP59jCuGJ86HDA9HL5kDzUT6n4Gi50HlYYIzNqhbjIxlqOuxO2IgIppSTWjQGeer34-PmKnOzKX8m_9DHPhif7TUf5uTV4OQWdhb0SxHnJ-CPu_z9FJ5ACekBQhz6YWS0_CY6j_ibucXzeVfZwLv1W47pjbt-l1Vl5VggSn2xVt69Q0GD9mPKpOhkKV_hyOL7i6haf7bq-gOKAwWDZy9pc3N1ZXJtL2lzc3VhbmNlRGF0ZW8vZXhwaXJhdGlvbkRhdGU"
  }
}

上面的示例是一个可验证凭证，其中颁发者启用了基于 BBS 的不可关联披露方案，以创建一个基础证明，随后持有者可以使用该基础证明来创建一个派生证明，该派生证明只披露原始可验证凭证中的特定信息片段。

示例 31：使用带有派生凭证和证明的 Data Integrity BBS Cryptosuite 的可验证呈示

{
  @context: "https://www.w3.org/ns/credentials/v2"
  type: "VerifiablePresentation",
  verifiableCredential: {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://w3id.org/citizenship/v3"
    ],
    "type": ["VerifiableCredential", "PermanentResidentCard"],
    "issuer": {
      "id": "did:web:issuer.utopia.example",
      "image": "data:image/png;base64,iVBORw0KGgo...YII="
    },
    "name": "Permanent Resident Card",
    "description": "Government of Utopia Permanent Resident Card.",
    "validFrom": "2024-08-01T00:00:00Z",
    "validUntil": "2029-12-01T00:00:00Z",
    "credentialSubject": {
      "type": ["PermanentResident", "Person"],
      "birthCountry": "Arcadia"
    },
    "proof": {
      type: "DataIntegrityProof",
      verificationMethod: "did:web:issuer.utopia.example#zUC75LjjCLGKRxSissX1nAebRDmY4Bv4T6MAbzgaap9Q8rAGf6SEjc2Hf4nH6bUPDwky3GWoYcUjMCcEqRRQfXEiNwfeDwNYLoeqk1J1W2Ye8vCdwv4fSd8AZ1yS6UoNzcsQoPS",
      cryptosuite: "bbs-2023",
      proofPurpose: "assertionMethod",
      proofValue: "u2V0DhVkCkLdnshxHtgeHJBBUGPBqcEooPp9ahgqs08RsoqW5EJFmsi70jqf2X368VcmfdJdYcYJwObPIg5dlyaoBm34N9BqcZ4RlTZvgwX79ivGnqLALC0EqKn2wOj5hRO76xUakfLGIcT4mE-G7CxA1FTs8sRCWy5p6FozelBYiZU2YlhUpJ7pBwelZ9wnlcbj4q-KyxAj5GU2iWp7-FxU-E624DmdT-yvCkAGRRrYej6lMwg7jB9uCHypOXXH2dVZ-jpf74YBaE4rMTxPFh60GN4o3S65F1fMsJbEMLdrXa8Vs6ZSlmveUcY1X7oPr1UIxo17ehVTCjOxWunYqrtLi9cVkYOD2s9XMk1oFVWBB3UY29axXQQXlZVfvTIUsfVc667mnlYbF7a-ko_SUfeY2n3s1DOAap5keeNU0v2KVPCbxA2WGz7UJy4xJv2a8olMOWPKjAEUruCx_dsbyicd-9KGwhYoUEO3HoAzmtI6qXVhMbJKxPrhtcp8hOdD9izVS5ed4CxHNaDGPSopF_MBwjxwPcpUufNNNdQwesrbtFJo0-P-1CrX_jSxKFMle2b3t24UbHRbZw7QnX4OG-SSVucem5jpMXTDFZ8PLFCqXX0zncJ_MQ-_u-liE-MwJu3ZemsXBp1JoB2twS0TqDVzSWR7bpFZKI9_07fKUAmQNSV_no9iAgYRLuPrnnsW1gQgCV-nNqzbcCOpzkHdCqro6nPSATq5Od3Einfc683gm5VGWxIldM0aBPytOymNz7PIZ6wkgcMABMe5Vw46B54ftW-TN5YZPDmCJ_kt7Mturn0OeQr9KJCu7S0I-SN14mL9KtGE1XDnIeR-C_YZhSA3vX4923v1l3vNFsKasqy9iEPHKM0hcogABAQCGAAECBAUGhAMJCgtYUnsiY2hhbGxlbmdlIjoiNGd2OFJyaERPdi1OSHByYlZNQlM1IiwiZG9tYWluIjoiaHR0cHM6Ly9wbGF5Z3JvdW5kLmFscGhhLmNoYXBpLmlvIn0"
    }
  }
}

上面的可验证呈示包含一个可验证凭证，其中包含来自前一示例信息的不可关联子集，以及一个派生证明，验证者可以使用该证明来验证这些信息源自预期的颁发者，并绑定到本次特定的信息交换。

强烈建议实现者理解，表示和处理时间值并不像看起来那样简单，并且存在各种并非立即显而易见、也并非在世界不同地区都被一致遵循的特殊情况。例如：

除公历之外的历法系统在各个地区仍被积极使用。
在处理夏令时/夏令时间时，必须理解： 1）并非所有地区都采用它；2）它不一定在同一天或同一时刻开始或结束； 3）调整的幅度或方向并不总是与其他类似地区一致。
闰秒可能并未在所有软件系统中被考虑，尤其是对于早于闰秒引入时间的日期和时间。闰秒可能会影响依赖相对于纪元的精确毫秒偏移量的高度敏感系统。不过，请注意，对于大多数应用程序，受影响的唯一时间点是闰秒本身的那一秒。也就是说，最近一次闰秒之后的时刻始终可以表示为下一天的第一个时刻（例如 2023-01-01T00:00:00Z），无论相关系统是否理解闰秒。

这些只是几个示例，用以说明实际的时刻，即墙上时钟所显示的时间，可能在一个地区存在，而在另一个地区不存在。出于这个原因，强烈建议实现者使用更通用的时间值，例如锚定到 Z 时区的值，而不是受夏令时/夏令时间影响的值。

本规范试图通过使用最初由 [XMLSCHEMA11-2] 规范确立的 dateTimeStamp 构造，增加可被普遍识别的日期和时间组合数量，并减少时间值被误解的可能性。为了减少不同时区之间的误解，在一致性文档中表达的所有时间值 SHOULD 以 dateTimeStamp 格式指定，要么采用协调世界时（UTC），即在值末尾以 Z 表示，要么采用相对于 UTC 的时区偏移量。未带偏移量而错误序列化的时间值 MUST 被解释为 UTC。相对于 UTC 的有效时区偏移量示例包括 Z、+01:00、 -08:00 和 +14:00。有关所有可接受值的形式化定义，请参见本节末尾的正则表达式。

时区定义偶尔会被其管理机构更改。在替换或颁发新的可验证凭证时，建议实现者确保本地时区规则的更改不会导致意外的有效性空档。例如，考虑 America/Los_Angeles 时区，该时区的原始偏移量为 UTC-8，并已投票决定在 2024 年停止采用夏令时。某个可验证凭证如果有一个 validUtil 值 2024-07-12T12:00:00-07:00，则在重新颁发时可能具有 validFrom 值 2024-07-12T12:00:00-08:00，这会产生一个小时的空档，在此期间该可验证凭证将无效。

希望检查 dateTimeStamp 值有效性的实现者可以使用下面提供的正则表达式；为方便起见，该表达式转载自 [XMLSCHEMA11-2] 规范。为避免疑义， [XMLSCHEMA11-2] 中的正则表达式是规范性定义。建议实现者注意，并非所有通过以下正则表达式的 dateTimeStamp 值都是有效时间点。例如，下面的正则表达式允许每个月有 31 天，这允许闰年和闰秒，也允许某些地方不存在的日期。尽管如此，生成 dateTimeStamp 值的现代系统库通常能够无误地生成有效的 dateTimeStamp 值。下面显示的正则表达式（去除为提高可读性而包含的空白）在现代系统上处理由库生成的日期和时间时通常足够。

示例 32：用于检测有效 XML Schema 1.1：第 2 部分 dateTimeStamp 的正则表达式

-?([1-9][0-9]{3,}|0[0-9]{3})
-(0[1-9]|1[0-2])
-(0[1-9]|[12][0-9]|3[01])
T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?|(24:00:00(\.0+)?))
(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))

本节为非规范性内容。

可验证凭证旨在作为可靠识别主体的一种手段。虽然承认基于角色的访问控制（RBAC）和基于属性的访问控制（ABAC）依赖这种识别作为授权主体访问资源的一种手段，但本规范并不为 RBAC 或 ABAC 提供完整解决方案。若没有配套的授权框架，授权并不是本规范的适当用途。

工作组在创建本规范期间确实考虑了授权用例，并正在将该工作作为构建在本规范之上的架构层推进。

本规范保留了一些属性，用作可能的扩展点。虽然一些实现者表示了对这些属性的兴趣，但将它们纳入本规范被认为还为时过早。需要注意的是，这些属性均未由本规范定义。因此，提醒实现者注意，使用这些属性被视为实验性的。

实现者 MAY 使用这些属性，但 SHOULD 预期它们和/或其含义会在对其进行规范性指定的过程中发生变化。实现者 SHOULD NOT 在没有公开披露的规范描述其实现的情况下使用这些属性。

为避免以下属性使用方式发生冲突，实现 MUST 在与保留属性相关联的值中指定 type 属性。有关添加 type 信息的更多内容，请参见第 4.5 类型。

保留属性	描述
`confidenceMethod`	用于指定一种或多种方法的属性，验证者可以使用这些方法提高其对可验证凭证或可验证呈示中或其属性值准确性的置信度。关联的词汇表 URL MUST 是 `https://www.w3.org/2018/credentials#confidenceMethod`。
`renderMethod`	用于指定一种或多种方法，将凭证渲染为视觉、听觉、触觉或其他格式的属性。关联的词汇表 URL MUST 是 `https://www.w3.org/2018/credentials#renderMethod`。

与本规范中定义的扩展点以及本节中定义的保留扩展点相关联的非官方规范列表，可在 Verifiable Credential Extensions 中找到。目录中引用保留扩展点的项目 SHOULD 被视为实验性项目。

有许多数字凭证格式并不原生使用本文档提供的数据模型，但与本规范中的若干概念保持一致。在发布时，这些数字凭证格式的示例包括 JSON Web Tokens（JWT）、 CBOR Web Tokens（CWT）、 JSON Advanced Electronic Signature（JAdES）、 ISO-18013-5:2021 （mDL）、 AnonCreds、 Gordian Envelopes，以及 Authentic Chained Data Containers（ACDC）。

如果概念上保持一致的数字凭证格式可以根据本节提供的规则转换为一致性文档，则它们被认为“兼容 W3C 可验证凭证生态系统”。建议规范作者在记录实现与可验证凭证生态系统兼容的转换时遵循以下规则。转换规范 —

MUST 标识到此数据模型的转换是仅单向还是可往返。
在执行可往返转换时，MUST 保留 @context 值。
按本规范描述的数据模型进行转换时，MUST 产生一致性文档。
MUST 为输入文档指定已注册的媒体类型。
SHOULD 提供测试套件，以证明指定的转换算法转换到本规范中的数据模型后会产生一致性文档。
SHOULD 确保经转换的一致性文档中使用的所有语义都遵循 Linked Data 最佳实践。更多指导请参见第 4.1 入门、第 5.2 可扩展性，以及 Linked Data Best Practices [LD-BP]。

注：什么构成可验证凭证？

建议读者注意，只有当数字凭证是一致性文档并且按本规范中各自要求所述使用至少一种保护机制时，才认为该数字凭证兼容 W3C 可验证凭证生态系统。虽然某些社区可能会把一些并非一致性文档的数字凭证格式称为 “可验证凭证”，但这样做并不使该数字凭证符合本规范。

在表达可验证凭证时（例如在呈示中），必须确保一个可验证凭证中的数据不会被误认为是另一个可验证凭证中的相同数据。例如，如果有两个可验证凭证，每个都包含以下形式的对象：{"type": "Person", "name": "Jane Doe"}，则无法判断一个对象是否描述的是与另一个对象相同的人。换言之，在未确认两个可验证凭证讨论的是相同实体和/或属性之前，在它们之间合并数据可能会导致数据集损坏。

为确保来自不同可验证凭证的数据不会被意外混合，使用可验证凭证图这一概念来封装每个可验证凭证。对于简单的可验证凭证，即当 JSON-LD 文档包含单个凭证以及可能关联的证明时，该图就是默认图。对于呈示，与该呈示的 verifiableCredential 属性相关联的每个值，都是一个类型为 VerifiableCredentialGraph 的单独命名图，其中包含单个可验证凭证或信封式可验证凭证。

在执行 JSON-LD 处理时，使用这些图具有具体效果，即可以正确地将一个图中的图节点标识符与另一个图中的节点标识符分开。将输入限制为特定于应用程序的 JSON-LD 文档的实现者，在将一个可验证凭证中的数据与另一个凭证中的数据合并时也需要牢记这一点，例如当两个可验证凭证中的 credentialSubject.id 相同，但对象可能包含上一段所述的 “Jane Doe” 形式的对象时。重要的是，不要合并那些看起来具有相似属性、但不包含使用全局标识符（例如 URL）的 id 属性的对象。

如第 4.12 保护机制所述，实现者在保护一致性文档时可以使用多种策略。为了最大化实用性和互操作性，本节为希望创作新的方式来保护一致性文档的规范作者提供指导。

保护机制规范 MUST 记录为一致性文档提供内容完整性保护的规范性算法。这些算法 MAY 具有通用性质，并且 MAY 用于保护除一致性文档之外的数据。

保护机制规范 MUST 提供一种验证算法，该算法返回已被保护的一致性文档中的信息，且该信息是隔离的，不包含任何保护机制信息，例如 proof 或 JOSE/COSE 标头参数和签名。验证算法 MAY 返回可能有帮助的额外信息（例如，在确认或调试期间），例如保护机制的详细信息。验证算法 MUST 提供一个接口，该接口接收媒体类型（字符串 inputMediaType）和输入数据（字节序列或映射 inputData）。保护机制规范 MAY 提供除本文档中指定的算法和接口之外的算法和接口。验证算法返回一个验证结果，其中至少包含以下项：

布尔值 verified: 一个验证状态；如果验证成功，其值为 true，如果未成功，其值为 false。
映射 verifiedDocument: 仅包含已成功受保护信息的文档。
字符串 mediaType: [RFC6838] 中定义的媒体类型。

保护机制规范 SHOULD 为任何由 URL 引用且对确认至关重要的信息提供完整性保护。能够实现这种保护的机制在第 5.3 相关资源的完整性和第 B.1 基础上下文中讨论。

创建新类型嵌入式证明的保护机制规范 MUST 指定一个属性，用于将可验证凭证或可验证呈示关联到证明图。对该保护机制的要求如下：

保护机制 MUST 定义证明图所使用的所有术语。例如，该机制可以像本规范使用词汇表规范和 @context 文件那样定义它们。
保护机制 MUST 保护可验证凭证或可验证呈示中的所有图，但保护该可验证凭证或可验证呈示本身的任何证明图除外。

注

最后一项要求意味着该保护机制会保护默认图，并且对于可验证呈示，会保护该呈示中的每个可验证凭证及其各自的证明图。另请参见图 9或图 14。

嵌入式保护机制 MAY 使用 [VC-DATA-INTEGRITY] 中定义的 proof 属性。

保护机制规范 SHOULD 在 Verifiable Credential Extensions 文档的 Securing Mechanisms 部分注册该保护机制。

注：保护机制的选择取决于用例

存在多种可接受的保护机制，本规范并不强制要求可验证凭证或可验证呈示使用任何特定的保护机制。制定本规范的工作组确实标准化了两种保护机制选项，分别是： Verifiable Credential Data Integrity 1.0 [VC-DATA-INTEGRITY] 和 Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]。社区已知的其他保护机制可以在 Verifiable Credential Extensions 文档的 Securing Mechanisms 部分找到。

如第 3. 核心数据模型、 4. 基本概念和 5. 高级概念所述的数据模型，是可验证凭证或可验证呈示的规范结构表示。所有语法都是该数据模型在特定格式中的表示。本节规定如何以 JSON-LD 为 application/vc 和 application/vp 序列化数据模型，这两者分别是可验证凭证和可验证呈示的基础媒体类型。尽管只为 JSON-LD 提供了语法映射，应用程序和服务也可以使用任何其他能够映射回 application/vc 或 application/vp 的数据表示语法（例如 XML、YAML 或 CBOR）。由于验证和确认要求是以数据模型来定义的，因此所有序列化语法都必须确定性地转换为数据模型，以便进行处理、确认或比较。

本规范中属性值的预期基数，以及保存这些值所产生的数据类型，可能因属性而异。如果存在，以下属性表示为单个值：id （第 4.4 标识符）、issuer（第 4.7 颁发者）以及 validFrom/validUntil（第 4.9 有效期）。所有其他属性在存在时，表示为单个值或值数组。

本规范使用 JSON-LD 1.1 对本规范中描述的数据模型进行序列化。JSON-LD 很有用，因为它能够表达基于图的数据模型，而可验证凭证正是基于该模型，同时还能表达机器可读语义，并且在扩展数据模型时也很有用（见第 3. 核心数据模型和第 5.2 可扩展性）。

JSON-LD 是一种基于 JSON 的格式，用于序列化 Linked Data。Linked Data 使用资源描述框架（RDF）[RDF11-CONCEPTS] 建模。 RDF 是一种用于对语句图进行建模的技术。每个语句都是一个单一的 主体→属性→值（也称为 实体→属性→值）关系，在本规范中称为声明。 JSON-LD 是一种能够使用惯用 JSON 表达 RDF 的技术，使熟悉 JSON 的开发者能够编写以 JSON 形式消费 RDF 的应用程序。更多细节见 JSON-LD 与 RDF 的关系。

一般而言，本文档中描述的数据模型和语法使开发者基本上可以将可验证凭证视为 JSON 文档，从而允许他们将示例复制并粘贴到其软件系统中，只需进行少量修改。这种方法的设计目标是提供较低的入门门槛，同时仍确保一组异构软件系统之间的全局互操作性。本节描述一些用于实现这一点的 JSON-LD 特性，这些特性很可能不会被大多数开发者注意到，但其细节可能会引起实现者的兴趣。本规范使用的 JSON-LD 1.1 中最值得注意的特性包括：

@id 和 @type 关键字分别别名为 id 和 type，使开发者能够将本规范作为惯用 JSON 使用。
数据类型，例如整数、日期、计量单位和 URL，会被自动赋予类型，以便为需要它们的用例提供更强的类型保证。
verifiableCredential 属性被定义为 JSON-LD 1.1 图容器。这要求创建命名图，用于隔离由不同实体断言的数据集。例如，这确保了由每个颁发者提供的数据图与由呈示可验证凭证的持有者提供的数据图之间具有适当的密码学隔离，以确保保留每个图中信息的来源。
JSON-LD 1.1 的 @protected 属性特性用于确保本规范定义的术语不能被覆盖。这意味着只要在可验证凭证或可验证呈示顶部进行相同的 @context 声明，对于数据模型用户所理解的所有术语，无论其是否使用 JSON-LD 1.1 处理器，互操作性都得到保证。

为了提高互操作性，本规范限制数据模型的 JSON-LD 表示的使用。对于使用 application/vc 或 application/vp 媒体类型的数据模型的所有表示， MUST 使用 JSON-LD 紧凑化文档形式。

如第 6.3 特定类型凭证处理中详述，某些软件应用程序可能不会执行通用 JSON-LD 处理。建议一致性文档的作者注意，如果使用 @context 值中的 JSON-LD 关键字来全局影响可验证凭证或可验证呈示中的值，例如通过设置 @base 或 @vocab 关键字中的一个或两个，则互操作性可能会降低。例如，设置这些值可能会在执行特定类型凭证处理、且不预期在 @context 值中表达 @base 和/或 @vocab 值的实现中，触发错误实现的 JSON Schema 对 @context 值的测试失败。

为了提高互操作性，敦促一致性文档作者不要使用在执行特定类型凭证处理时不易检测的 JSON-LD 特性。这些特性包括：

在 @context 值中内联声明会全局修改文档术语和值处理的 JSON-LD 关键字，例如设置 @base 或 @vocab
使用会覆盖先前上下文中声明的 JSON-LD 上下文，例如重置 @vocab
在 @context 属性中内联声明 JSON-LD 上下文
对 JSON-LD 术语和类型使用完整 URL（例如 https://www.w3.org/2018/credentials#VerifiableCredential 或 https://vocab.example/myvocab#SomeNewType），而不是使用此类值在 JSON-LD @context 映射中明确定义的短形式（例如 VerifiableCredential 或 SomeNewType）（例如，在 https://www.w3.org/ns/credentials/v2 中）

虽然本规范警告不要使用 @vocab，但该特性也有合法用途，例如便于实验、开发和本地化部署。如果应用开发者希望在生产中使用 @vocab，而这是不建议的，因为要减少术语冲突并利用语义互操作性的好处，则敦促他们理解，任何对 @vocab 的使用都会禁用“未定义术语”错误的报告，并且后续使用会覆盖任何先前的 @vocab 声明。不同的 @vocab 值可能改变文档中所含信息的语义，因此理解这些变化是否以及如何影响正在开发的应用程序非常重要。

使用 JSON-LD 1.1 时，可以使用列表、数组，甚至列表的列表。我们鼓励希望在需要列表和数组的用例中使用 RDF 语义的人员遵循 JSON-LD 1.1 中列表的指导。

一般而言，JSON 数组是有序的，而 JSON-LD 数组是无序的，除非该数组使用 @list 关键字。

注：数组顺序可能并不重要

虽然可以通过执行特定类型凭证处理来使用此数据模型，但这样做并使用数组的人员需要知道，除非遵循上述指导，否则 JSON-LD 中数组项的顺序不能得到保证。这可能导致意外行为。

如果 JSON 结构或顺序对你的应用很重要，我们建议你通过特定于用例的 @context 将此类元素标记为 @json。下面显示了这种声明的示例。

示例 33：将矩阵定义为嵌入式 JSON 数据结构的 @context 文件

{
  "@context":
    {
      "matrix": {
        "@id": "https://website.example/vocabulary#matrix",
        "@type": "@json"
      }
    }
}

在下面的示例中使用上面显示的上下文时，通过在 @context 属性中包含 https://website.example/matrix/v1 上下文， credentialSubject.matrix 中的值会保留其 JSON 语义；二维矩阵中所有元素的确切顺序都会被保留。

示例 34：带有嵌入式 JSON 数据结构的可验证凭证

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2",
    "https://website.example/matrix/v1"
  ],
  "id": "http://university.example/credentials/1872",
  "type": [
    "VerifiableCredential",
    "ExampleMatrixCredential"
  ],
  "issuer": "https://university.example/issuers/565049",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "matrix": [
      [1,2,3,4,5,6,7,8,9,10,11,12],
      [1,1,1,1,1,1,1,1,0,0,0,0],
      [0,0,1,1,1,1,1,1,1,0,0,0]
    ]
  }
}

媒体类型，如 [RFC6838] 中所定义，用于标识表达可验证凭证所使用的语法，以及其他有用的处理指南。

用于表达本规范中数据模型的语法SHOULD由媒体类型标识，并且在定义或使用带有可验证凭证的媒体类型时， SHOULD遵循本节概述的约定。

与核心数据模型关联的媒体类型有两个，它们列在第 C. IANA 考量中： application/vc 和 application/vp。

application/vc 和 application/vp 媒体类型并不隐含任何特定的保护机制，但旨在与保护机制结合使用。需要应用保护机制来保护这些媒体类型的完整性。不要因为用于传达内容的媒体类型而假定内容是安全的。

本节为非规范性内容。

有时，开发者或系统可能会使用较低精度的媒体类型来传送可验证凭证或可验证呈示。使用较低精度媒体类型的一些原因包括：

当文件扩展名不可用且 Web 服务器无法确定媒体类型时，Web 服务器默认为 text/plain 或 application/octet-stream。
开发者添加了会导致媒体类型不如文件内容具体的文件扩展名。例如，.json 可能导致媒体类型为 application/json，而 .jsonld 可能导致媒体类型为 application/ld+json。
协议要求在特定事务中使用较不精确的媒体类型；例如， application/json 而不是 application/vp，

敦促实现者在能够从载荷确定预期媒体类型时不要抛出错误，前提是所使用的媒体类型在给定协议中是可接受的。例如，如果应用程序只接受符合 application/vc 媒体类型相关规则的载荷，但该载荷被标记为 application/json 或 application/ld+json，则应用程序可以执行以下步骤来确定该载荷是否也符合更高精度的媒体类型：

将载荷解析为 JSON 文档。
确保 @context 属性的第一个元素匹配 https://www.w3.org/ns/credentials/v2。
如果 JSON 文档包含顶层 type 属性，并且其中包含 VerifiablePresentation 元素，则假定为 application/vp 媒体类型。仍然预期会执行额外的后续检查（根据本规范），以确保载荷表达一个符合要求的可验证呈示。
如果 JSON 文档包含顶层 type 属性，并且其中包含 VerifiableCredential 元素，则假定为 application/vc 媒体类型。仍然预期会执行额外的后续检查（根据本规范），以确保载荷表达一个符合要求的可验证凭证。

在可能的情况下，建议实现者对本规范定义的所有载荷使用最精确（最高精度）的媒体类型。还建议实现者认识到，标记有较低精度媒体类型的载荷并不意味着该载荷不满足用更高精度类型标记所需的规则。同样，标记有较高精度媒体类型的载荷也不意味着该载荷一定满足该媒体类型相关的要求。载荷接收者无论其关联的媒体类型如何，都应执行适当检查，以确保载荷符合其在给定系统中使用的要求。

HTTP 客户端和服务器在 accept 头以及指示内容类型时，使用与可验证凭证和可验证呈示相关联的媒体类型。提醒实现者注意，HTTP 服务器可能会忽略 accept 头并返回另一种内容类型，或者返回错误代码，例如 415 Unsupported Media Type。

本节为非规范性内容。

由于 JSON 可用于表达不同种类的信息，特定 JSON 文档的消费者只有在拥有能够将作者意图置于上下文中并与其他可能表达消歧的信息时，才能正确解释作者的意图。协助这种解释的信息可以完全位于 JSON 文档之外，也可以从文档内部链接。紧凑化 JSON-LD 文档包含一个 @context 属性，该属性在内部表达或链接到用于表达声明的上下文信息。这些特性使得可以编写通用处理器，将 JSON-LD 文档从一个上下文转换到另一个上下文，但当消费者接收的 JSON-LD 文档已经使用他们预期的上下文和形状时，并不需要这样做。 JSON-LD 文档的作者，例如可验证凭证的颁发者，需要提供适当的 JSON-LD 上下文并遵循这些规则，以促进互操作性。

下面的文本帮助消费者理解如何确保 JSON-LD 文档以其应用程序已理解的上下文和形状来表达，从而不需要为了消费其内容而转换该文档。值得注意的是，这并不意味着消费者根本不需要理解任何上下文；相反，消费应用程序只需要理解一组选定的上下文和文档形状来与之协作，而不需要理解其他上下文和形状。颁发者可以发布上下文以及有关其可验证凭证的信息，以帮助不使用通用处理器的消费者，就像任何其他 JSON 格式数据都可以做到的那样。

通用 JSON-LD 处理定义为一种机制，它使用 JSON-LD 软件库，通过执行各种转换来处理一致性文档。特定类型凭证处理定义为一种用于处理一致性文档的轻量级机制，它不需要 JSON-LD 软件库。某些可验证凭证消费者只需要消费特定类型的凭证。这些消费者可以使用特定类型凭证处理，而不是通用处理。适合使用特定类型凭证处理的场景包括但不限于：

在将保护机制应用于一致性文档之前，或在验证由保护机制保护的一致性文档之后，以确保数据完整性。
在执行 JSON Schema 确认时，如第 4.11 数据模式中所述。
当将可验证凭证或可验证呈示序列化或反序列化到存储或索引其内容的系统中时。
当在软件应用程序中操作可验证凭证或可验证呈示时，在对需要通用 JSON-LD 处理的保护机制执行验证或确认之后。
当应用程序选择使用 +json 结构化媒体类型后缀来处理媒体类型时。

也就是说，只要被消费或生成的文档是一致性文档，就允许特定类型凭证处理。

如果希望使用特定类型凭证处理，建议实现者遵循此规则：

确保与 @context 属性关联的所有值都按预期顺序排列，上下文文件内容与每个文件已知良好的密码学哈希相匹配，并且领域专家已认定其内容适合预期用例。

将静态上下文文件与 JSON Schema 结合使用，是实现上述规则的一种可接受方法。这可以在执行特定类型凭证处理时，确保适当的术语标识、类型和顺序。

上述规则通过 @context 机制将字面 JSON 键映射到 URI，从而保证两种处理机制之间的语义互操作性。虽然通用 JSON-LD 处理可以使用其算法中提供的先前未见过的 @context 值来验证所有术语是否被正确指定，但仅执行特定类型凭证处理的实现只接受该实现事先被工程化为能够理解的特定 @context 值，从而在不调用任何 JSON-LD API 的情况下得到相同的语义。换言之，数据交换发生的上下文通过使用 @context 对两种处理机制都是明确声明的，其方式会导向相同的一致性文档语义。

本节包含可供实现用于执行常见操作（例如验证）的算法。以算法形式表述的一致性要求使用 Infra Standard [INFRA] 中的规范性概念。有关实现要求的更多指导，见 Infra Standard 中关于算法一致性的章节。

注：实现者可以包含额外的检查、警告和错误。

建议实现者注意，本节中的算法只包含实现用于测试与本规范一致性的最小检查集合。实现应提供额外检查，向开发者报告有用的警告，以帮助调试潜在问题。类似地，实现可能会提供额外检查，这些检查可能导致报告新类型的错误，以阻止有害内容。这些额外检查中的任何一项都可能被整合到本规范的未来版本中。

本节包含一个算法，一致性验证者实现在验证可验证凭证或可验证呈示时MUST运行该算法。该算法接收媒体类型（字符串 inputMediaType）和受保护的数据（字节序列 inputData），并返回一个包含以下内容的映射：

状态（布尔值 status）
一致性文档（映射 document）
媒体类型（字符串 mediaType）
与保护机制相关联的验证方法的控制者（字符串 controller）
与用于验证保护机制的验证方法相关联的受控标识符文档（映射 controlledIdentifierDocument）
零个或多个警告（列表，其中包含 ProblemDetails warnings）
零个或多个错误（列表，其中包含 ProblemDetails errors）

验证算法如下：

通过执行以下步骤，确保保护机制已正确保护一致性文档：
1. 使用 inputMediaType 以及 Verifiable Credential Extensions 文档的 Securing Mechanisms 章节，或实现已知的其他机制，来确定验证保护机制时要使用的密码学套件，并设置 verifyProof 函数。verifyProof 函数MUST 实现 5.13 保护机制规范中描述的接口。
2. 如果 verifyProof 函数期望一个字节序列，则向该算法提供 inputMediaType 和 inputData。如果 verifyProof 函数期望一个映射，则提供 inputMediaType 以及给定 inputData 后将 JSON 字节解析为 Infra 值的结果。将 result 设置为调用 verifyProof 函数的结果。如果调用成功，result 将包含 status、document、mediaType、 controller、 controlledIdentifierDocument、warnings 和 errors 属性。
3. 如果 result.status 被设置为 false，则向 result.errors 添加一个 CRYPTOGRAPHIC_SECURITY_ERROR。
如果 result.status 被设置为 true，则确保 result.document 是一个一致性文档。如果不是，将 result.status 设置为 false，从 result 中移除 document 属性，并向 result.errors 添加至少一个 MALFORMED_VALUE_ERROR。可以包含其他警告和错误以帮助调试过程。
返回 result。

验证保护机制状态以及验证输入文档是否为一致性文档的步骤 MAY以不同于上述顺序的方式执行，只要实现对相同无效输入返回错误即可。实现MAY产生与上述不同的错误。

当实现程序在处理文档时检测到异常时，可以使用 ProblemDetails 对象向其他软件系统报告该问题。这些对象的接口遵循 [RFC9457] 来编码数据。ProblemDetails 对象由以下属性组成：

type: type 属性MUST存在，且其值 MUST是一个用于标识问题类型的URL。
title: title 属性SHOULD为问题提供一个简短但具体的人类可读字符串。
detail: detail 属性SHOULD为问题提供一个更长的人类可读字符串。

本规范定义了以下问题描述类型：

https://www.w3.org/TR/vc-data-model#PARSING_ERROR: 解析输入时发生错误。
https://www.w3.org/TR/vc-data-model#CRYPTOGRAPHIC_SECURITY_ERROR: 文档的保护机制已检测到文档内容自创建以来发生了修改；检测到潜在篡改。见第 7.1 验证。
https://www.w3.org/TR/vc-data-model#MALFORMED_VALUE_ERROR: 与特定属性关联的值格式不正确。属性名称以及到该属性的路径SHOULD在 ProblemDetails 对象中提供。见第 7.1 验证。
https://www.w3.org/TR/vc-data-model#RANGE_ERROR: 提供的值超出了关联值的预期范围，例如给定的数组索引值大于数组的当前大小。

实现MAY通过指定额外类型或属性来扩展 ProblemDetails 对象。有关使用此机制的进一步指导，见 [RFC9457] 中的扩展成员章节。

本节为非规范性内容。

本节详细说明将可验证凭证数据模型部署到生产环境中的一般隐私考量和具体隐私影响。

本节为非规范性内容。

重要的是要认识到，隐私存在一个从假名到强身份识别的谱系。根据用例不同，人们对其愿意提供的信息以及可从这些信息中推导出的信息有不同的舒适程度。

水平条，左侧为
红色，中间为橙色，右侧为绿色。红色部分有文字“高度可关联（全局
ID），例如政府 ID、收货地址、信用卡号”。橙色部分有文字“可通过串通关联
（个人可识别信息），例如姓名、生日、邮政编码”。绿色部分有文字“不可关联
（假名），例如年龄超过 21 岁”。 — 图 13 从假名到完全识别的隐私谱系。

隐私解决方案是特定于用例的。例如，许多人在购买酒类时会更愿意保持匿名，因为法规只要求验证购买者是否超过特定年龄。相比之下，在为医疗专业人员给患者开具的处方配药时，药房依法需要更强地识别开方者和患者。没有任何一种隐私方法适用于所有用例。

注：年龄证明对某些用例可能不足

即便是希望在购买酒类时保持匿名的人，也可能需要提供带照片的身份证明，以便让商家得到适当保证。商家可能不需要知道你的姓名或除你超过特定年龄之外的任何细节，但在许多情况下，简单的年龄证明可能不足以满足法规要求。

可验证凭证数据模型力求支持完整的隐私谱系，并且不对任何特定交易的正确匿名级别采取哲学立场。以下各节将指导希望避免特定敌视隐私场景的实现者。

本节为非规范性内容。

在本规范描述的生态系统中存在多种信任关系。使用 Web 浏览器的个人信任该 Web 浏览器（也称为用户代理）能够通过不将其个人信息上传给数据经纪商来维持这种信任；类似地，在本规范描述的生态系统中扮演各角色的实体，信任代表这些角色运作的软件。示例包括：

颁发者的用户代理（颁发者软件），例如在线教育平台，预期仅向颁发者断言已完成其教育项目的个人颁发可验证凭证。
验证者的用户代理（验证软件），例如招聘网站，预期仅允许对平台提供的可验证凭证和可验证呈示具有有效验证状态的个人访问。
持有者的用户代理（持有者软件），例如数字钱包，预期仅在持有者同意发布该信息时，才向验证者披露信息。

上述示例并不详尽，这些角色中的用户还可以对他们用于实现目标的软件有各种其他期望。简而言之，用户期望软件以用户的最大利益行事；任何违反这种期望的行为都会破坏信任，并可能导致该软件被更可信的替代品取代。强烈鼓励实现者创建维护用户信任的软件。此外，还鼓励他们包含审计功能，使用户或可信第三方能够验证软件是否以符合其最大利益的方式运行。

建议读者注意，某些软件，例如向单一验证者和多个持有者提供服务的网站，可能对这两种角色都作为用户代理运行，但可能并不总是能够同时以所有各方的最大利益运行。例如，假设某网站在多个持有者之间检测到欺诈性可验证凭证使用企图。在这种情况下，它可能会向验证者报告此类异常，这可能被认为不符合所有持有者的最大利益，但会符合验证者以及任何未实施此类违规行为的持有者的最大利益。当软件以这种方式运行时，必须通过网站使用政策等机制明确说明该软件是在为谁的最大利益运行。

本节为非规范性内容。

存储在 credential.credentialSubject 属性中的与可验证凭证相关的数据，在与验证者共享时容易发生隐私侵犯。个人识别数据，例如政府颁发的标识符、收货地址或全名，可以很容易被用于确定、跟踪和关联一个实体。即使看似并非个人可识别的信息，例如生日和邮政编码的组合，也具有强大的关联和去匿名化能力。

强烈建议供持有者使用的软件实现者在持有者共享具有这些特征的数据时对其发出警告。强烈建议颁发者在可能时提供保护隐私的可验证凭证——例如，当验证者希望确定某个实体是否至少 18 岁时，颁发 ageOver 可验证凭证，而不是 dateOfBirth 可验证凭证。

由于可验证凭证通常包含个人可识别信息（PII），强烈建议实现者在存储和传输可验证凭证时使用机制，保护数据免受不应访问该数据者的访问。可以考虑的机制包括传输层安全性（TLS）或其他在传输中加密数据的方式，以及在可验证凭证静态存储时保护其数据的加密或访问控制机制。

一般而言，建议个人假定可验证凭证像大多数实体凭证一样，在共享时会泄露个人可识别信息。为对抗这种泄露，需要仔细设计可验证凭证及其保护机制，以防止关联。已经有专门设计用于防止个人可识别信息泄露的可验证凭证。鼓励个人和实现者选择这些凭证类型，而不是未设计用于保护个人可识别信息的类型。

本节为非规范性内容。

可验证凭证可能包含可用于关联个人的长期标识符。这些标识符包括主体标识符、电子邮件地址、政府颁发的标识符、组织颁发的标识符、地址、医疗生命体征以及许多其他长期标识符。鼓励供持有者使用的软件实现者检测可验证凭证中可能用于关联个人的标识符，并在持有者共享这些信息前对其发出警告。本节其余部分详细说明与使用长期标识符相关的指导。

可验证凭证的主体使用 id 属性来标识，如第 4.4 标识符所定义，并在诸如 credentialSubject.id 属性等位置使用。用于标识主体的标识符在长期存在或跨多个 Web 域使用时会产生更大的关联风险。属于这一类别的其他类型标识符包括电子邮件地址、政府颁发的标识符和组织颁发的标识符。

类似地，披露凭证标识符（如示例 3 中所示）可能导致多个验证者，或颁发者和验证者串通来关联持有者的情况。

鼓励旨在减少关联的持有者使用来自支持在可验证呈示中选择性披露关联标识符的颁发者的可验证凭证。这些方法预期持有者生成标识符，甚至可能允许通过盲签名等技术向颁发者隐藏标识符，同时仍将该标识符嵌入并签入可验证凭证中。

建议保护机制规范作者通过设计其技术避免使用无法选择性披露的关联标识符，从而避免启用基于标识符的关联。

如果在可验证凭证系统中需要强抗关联属性，则标识符必须满足以下一个或多个标准：

可选择性披露
绑定到单一来源
单次使用
不使用，而是由短期、单次使用的持票人令牌替代。

本节为非规范性内容。

可验证凭证的内容使用保护机制来保护。表示保护机制的值在多个会话或域之间保持不变时，会带来更大的关联风险。这些值的示例包括：

数字签名的二进制值
与数字签名创建相关联的时间戳信息
与数字签名相关联的密码学材料，例如公钥标识符

当需要强抗关联属性时，鼓励颁发者生成签名值和元数据可为每个可验证呈示重新生成的可验证凭证。这可以通过支持不可关联披露的技术实现，例如 Data Integrity BBS Cryptosuites v1.0 规范。在可能的情况下，鼓励验证者优先选择使用此技术的可验证呈示，以增强持有者和主体的隐私。

注：不可关联性并不是完整解决方案

即使使用不可关联签名，可验证凭证也可能包含其他信息，这些信息会削弱所用密码学的抗关联属性。见第 8.3 个人可识别信息、 8.4 基于标识符的关联、8.6 基于元数据的关联、 8.11 确认期间的关联以及第 8. 隐私考量的大多数其他小节。

本节为非规范性内容。

不同的扩展点，例如第 4. 基本概念和第 5. 高级概念中描述的扩展点，如果相对较少的颁发者使用特定扩展类型或类型组合，可能无意或不期望地成为关联机制。例如，使用某些特定于国家的密码学方法、特定于某些司法辖区的撤销格式，或特定地方使用的凭证类型，都可能作为机制，降低持有者在向验证者选择性披露信息时可能期待的假名性。

鼓励颁发者在颁发意图用于假名使用的可验证凭证时，通过限制可能降低持有者假名性的扩展类型，尽量减少基于元数据的关联风险。具有全球采用度的凭证类型、扩展和技术配置文件最为可取，其次是具有国家级使用范围的那些；仅具有本地使用范围的最不理想。

本节为非规范性内容。

存在外部于可验证凭证的机制，会在 Internet 和 Web 上跟踪并关联个人。这些机制包括 Internet 协议（IP）地址跟踪、 Web 浏览器指纹识别、evercookies、广告网络跟踪器、移动网络位置信息以及应用内全球定位系统（GPS）API。使用可验证凭证无法防止这些其他跟踪技术的使用；相反，将这些技术与可验证凭证一起使用可能会揭示新的可关联信息。例如，生日与 GPS 位置结合可以强烈地跨多个网站关联一个个人。

尊重隐私的系统应当旨在防止其他跟踪技术与可验证凭证相结合。在某些情况下，代表持有者传输可验证凭证的设备上可能需要禁用跟踪技术。

Oblivious HTTP 协议 [RFC9458] 是实现者在获取与可验证凭证或可验证呈示相关联的外部资源时可以考虑使用的一种机制。 Oblivious HTTP 允许客户端向源服务器发出多个请求，而该服务器无法将这些请求链接到该客户端，甚至无法识别这些请求来自同一客户端，同时只对用于转发消息的节点放置信任。 Oblivious HTTP 是一种可以降低设备跟踪和指纹识别可能性的隐私保护机制。下面是一些 Oblivious HTTP 能够使生态系统参与者受益的具体方式示例。

使用数字钱包的持有者在访问其数字钱包中存储的可验证凭证中的外部链接时，可以降低被第三方跟踪的可能性。例如，数字钱包可能会获取并渲染链接图像，或者可能通过获取外部链接的撤销列表来检查可验证凭证的有效性。
验证者可以降低其向颁发者发出信号、表明该验证者已收到特定可验证凭证的可能性。例如，验证者可能在对可验证凭证执行状态检查时获取外部链接的撤销列表。

本节为非规范性内容。

鼓励颁发者将可验证凭证中包含的信息限制为预期目的所需的最小集合，以便接收者可在各种情境中使用这些信息，而不会披露超过必要范围的个人可识别信息（PII）。避免在可验证凭证中放置 PII 的一种方式，是使用满足验证者需求、但不会提供关于主体的过于具体信息的抽象属性。

例如，本文档使用 ageOver 属性而不是具体生日，后者会表示更敏感的 PII。如果特定市场中的零售商通常要求购买者年龄超过某个年龄，则该市场中受信任的颁发者可以选择提供声称主体已满足该要求的可验证凭证，而不是提供包含关于顾客生日的声明的可验证凭证。这种做法使个人顾客能够在不披露超过必要范围的 PII 的情况下进行购买。

本节为非规范性内容。

当在一个上下文中披露的信息泄漏到另一个上下文时，就会发生隐私侵犯。防止这种侵犯的一种公认最佳实践是，让验证者将请求和接收的信息限制为特定交易所绝对必需的最低限度。多个司法辖区的法规，包括美国的 Health Insurance Portability and Accountability Act（HIPAA）和欧盟的 General Data Protection Regulation（GDPR），都要求采用这种数据最小化方法。

对于可验证凭证而言，颁发者的数据最小化意味着将可验证凭证的内容限制为潜在验证者为预期使用所需的最低限度。对于验证者，数据最小化意味着限制访问服务所请求或要求的信息范围。

例如，以可验证凭证表示的驾驶执照，如果包含驾驶员 ID 号码、身高、体重、生日和家庭住址，则包含了超出确定某人是否超过特定年龄所需的信息。

对颁发者而言，原子化信息或使用允许选择性披露的保护机制被认为是最佳实践。例如，驾驶执照的颁发者可以颁发一个包含驾驶执照上每个属性的可验证凭证，并允许持有者选择性披露每个属性。它也可以颁发更抽象的可验证凭证（例如，只包含 ageOver 属性的可验证凭证）。一种可能的适配方式是让颁发者提供安全 HTTP 端点，以获取促进可验证凭证假名使用的单次使用持票人凭证。认为这种做法不切实际或不安全的实现者，可以考虑使用选择性披露方案，这些方案在证明时消除对颁发者的依赖，并降低颁发者造成时间关联的风险。

敦促验证者只请求特定交易发生所严格必要的信息。这至少有两个重要原因：

这降低了验证者处理其不需要处理的高度敏感信息的责任。
这通过仅请求特定交易所必要的信息，增强主体和/或持有者的隐私。

鼓励供持有者使用的软件实现者披露验证者所请求的信息，允许持有者拒绝共享交易所不必要的特定信息。还建议供持有者使用的软件实现者向持有者提供与验证者共享信息的日志访问权限，使持有者在认为自己遭受信息过度索取或被胁迫共享超过特定交易所需的信息时，能够将此类信息提供给主管机关。

注：最小披露仍可能导致唯一识别

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

本节为非规范性内容。

在处理可验证凭证时，验证者在依赖相关声明之前会对其进行评估。只要满足执行确认的验证者的要求，这种评估可以采用任何所需方式进行。许多验证者会执行附录 A. 确认中列出的检查，以及各种特定业务流程检查，例如：

持有者的专业执照状态。
执照续期或撤销日期。
个人的子资格。
持有者与其试图交互的实体之间是否存在关系。
与持有者相关联的地理位置信息。

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

敦促颁发者不要在验证过程中使用可能导致隐私侵犯的机制，例如每个凭证唯一的凭证撤销列表。向持有者提供软件的组织，在凭证包含可能在验证过程中导致隐私侵犯的信息时，应当发出警告。敦促验证者考虑拒绝产生隐私侵犯或启用低劣隐私实践的凭证。

本节为非规范性内容。

当持有者从颁发者接收可验证凭证时，可验证凭证需要存储在某处（例如存储在凭证存储库中）。持有者需要意识到可验证凭证中的信息可能敏感且高度个体化，使其成为数据挖掘的主要目标。提供“免费”存储可验证凭证的服务可能会挖掘个人数据，并将其出售给有兴趣建立关于个人和组织的个体化画像的组织。

持有者需要了解其凭证存储库的服务条款，特别是针对将其可验证凭证存储在该服务提供商处的用户所采取的关联和数据挖掘保护措施。

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

不向第三方出售你的信息的服务提供商。
加密可验证凭证的软件，使服务提供商无法查看凭证的内容。
将可验证凭证本地存储在你控制的设备上，并且不会超出你的预期上传或分析你的信息的软件。

除上述缓解措施之外，民间社会和监管机构参与供应商分析和审计，可以帮助确保为受到不符合其最大利益的做法影响的个人制定并执行法律保护。

本节为非规范性内容。

拥有关于同一主体的两条信息，往往会比这两条信息的组合本身揭示出更多关于该主体的信息，即使这些信息通过不同渠道传递。聚合可验证凭证会带来隐私风险，生态系统中的所有参与者都需要意识到数据聚合的风险。

例如，假设向同一个验证者在多个会话中提供了两个持票人凭证，一个用于电子邮件地址，一个声明持有者超过 21 岁。该信息的验证者现在拥有该个人的唯一标识符（电子邮件地址）以及与年龄相关（“超过 21 岁”）的信息。现在很容易为该持有者创建画像，并随着更多信息随时间泄露而不断添加信息来构建该画像。这类凭证的聚合也可以由多个网站相互串通执行，从而导致隐私侵犯。

从技术角度来看，防止信息聚合是一个具有挑战性的隐私问题。虽然新的密码学技术，例如零知识证明，正被提出作为聚合和关联问题的解决方案，但长期标识符和浏览器跟踪技术的存在会击败即使是最现代的密码学技术。

关联或聚合所带来的隐私影响的解决方案往往并非技术性质，而是由政策驱动。因此，如果持有者希望避免其信息被聚合，他们需要在其传输的可验证呈示中表达这一点，并由持有者和接收其可验证呈示的验证者来落实。

本节为非规范性内容。

尽管所有相关方都尽力确保隐私，使用可验证凭证仍可能导致去匿名化和隐私丧失。当发生以下任何情况时，就可能出现这种关联：

同一个可验证凭证被多次呈示给同一个验证者。该验证者可以推断持有者是同一个个人。
同一个可验证凭证被呈示给不同的验证者，并且这些验证者串通，或第三方能够访问来自两个验证者的交易记录。细心的参与方可以推断呈示该可验证凭证的个人在两个服务中是同一个人。也就是说，同一个人控制两个账户。
凭证的主体标识符在多个呈示或验证者中指向同一个主体。即使呈示的是不同的凭证，如果主体标识符相同，验证者（以及能够访问验证者日志者）可以推断这些凭证的主体是同一个实体。
凭证中的底层信息可用于跨服务识别个人。在这种情况下，通过使用其他来源的信息（包括持有者直接提供的信息），验证者可以使用凭证中的信息将个人与既有画像关联起来。例如，如果持有者呈示的凭证包含邮政编码、年龄和性别，验证者可能将该凭证的主体与既有画像相关联。更多信息见 [DEMOGRAPHICS]。
将凭证的标识符传递给集中式撤销服务器。该集中式服务器可以跨交互关联凭证的使用。例如，如果凭证以这种方式用于证明年龄，集中式服务可能知道该凭证被呈示的所有地方（所有酒类商店、酒吧、成人用品店、彩票销售商等等）。

在一定程度上，可以通过以下方式缓解这种去匿名化和隐私丧失：

持有者软件为任何给定可验证凭证的主体提供一个全局唯一标识符，并且绝不重复使用该可验证凭证。
颁发者使用全球分布式撤销服务，使其在执行撤销检查时不会被联系。
规范作者设计不依赖于将可验证凭证的唯一标识符提交给查询 API 的撤销机制，而是使用例如保护隐私的撤销列表。
颁发者避免将个人可识别信息与任何特定长期主体标识符关联起来。

遗憾的是，这些缓解技术只有在某些情况下才实用，甚至可能与必要使用不兼容。有时，关联是一项要求。

例如，在某些处方药监测项目中，监测处方使用是一项要求。执法实体需要能够确认个人没有通过欺骗系统获得多份受管制物质处方。关联处方使用的这种法定或监管需要，会压倒个人隐私顾虑。

可验证凭证也会被用于有意跨服务关联个人。例如，当使用共同身份登录多个服务时，这些服务上的所有活动都会有意链接到同一个个人。只要这些服务以预期方式使用这种关联，这就不是隐私问题。

与使用可验证凭证相关的隐私侵犯，发生在这些可验证凭证的呈示产生非预期或意外关联时。

本节为非规范性内容。

法律程序可以强制颁发者、持有者和验证者向执法机关等主管机关披露私人信息。同样的私人信息也可能因软件漏洞或安全故障而意外披露给未授权方。建议法律程序和合规制度的作者起草指南，要求在所涉主体的私人信息被有意或意外披露给第三方时通知其本人。建议软件服务提供商透明说明可能导致此类私人信息与第三方共享的已知情形，以及任何此类第三方的身份。

本节为非规范性内容。

可验证凭证和可验证呈示中表达的数据具有价值，因为它们包含由受信任第三方（例如颁发者）或个人（例如持有者或主体）做出的真实陈述。这些数据的存储和可访问性可能无意中为恶意行为者形成敏感数据的蜜罐。这些对手通常试图利用这种敏感信息储藏库，旨在获取并交换这些数据以谋取经济利益。

建议颁发者仅保留向持有者颁发可验证凭证以及管理这些凭证的状态和撤销所必要的最少数据。类似地，建议颁发者避免创建包含个人可识别信息（PII）或其他敏感数据的公开可访问凭证。建议软件实现者使用稳健的同意和访问控制措施保护可验证凭证，确保其无法被未授权实体访问。

建议持有者使用能够适当加密传输中和静态数据、并以不易从硬件或其他设备中提取的方式保护敏感材料（例如密码学秘密）的实现。进一步建议持有者仅在其控制的设备上存储和操作其数据，远离集中式系统，以降低其数据遭受攻击的可能性，或在攻击成功时被纳入大规模盗窃的可能性。此外，鼓励持有者严格控制对其凭证和呈示的访问，只允许具有明确授权者访问。

建议验证者只请求特定交易所必要的数据，且不保留超出任何特定交易需要的数据。

建议监管者重新考虑现有审计要求，以便使用更好保护隐私的机制来实现类似的执法和审计能力。例如，坚持收集和长期保留个人可识别信息的审计导向法规，如果同一信息后来被攻击者泄露并访问，可能对个人和组织造成伤害。本规范描述的技术使持有者能够更容易地证明关于自身和他人的属性，从而减少验证者长期保留数据的需要。替代方案包括保留信息已被收集和检查的日志，以及进行随机测试以确保合规制度按预期运行。

本节为非规范性内容。

如第 8.14 使用模式所详述，使用模式可与某些类型的行为相关联。当持有者在颁发者不知情的情况下使用可验证凭证时，这种关联会得到部分缓解。然而，颁发者可以通过使其可验证凭证短期有效且自动续期来击败这种保护。

例如，ageOver 可验证凭证有助于进入酒吧。如果颁发者以非常短的有效期和自动续期机制颁发这样的可验证凭证，则该颁发者可能以对持有者产生负面影响的方式关联持有者的行为。

向持有者提供软件的组织，如果其反复使用寿命较短的凭证，可能导致行为关联，则应当向其发出警告。颁发者应避免颁发使其能够关联使用模式的凭证。

本节为非规范性内容。

理想的尊重隐私系统只会要求持有者披露与验证者交互所必要的信息。然后验证者记录披露要求已满足，并丢弃已披露的任何敏感信息。在许多情况下，监管负担等相互竞争的优先事项会阻止采用这种理想系统。在其他情况下，长期标识符会阻止单次使用。任何可验证凭证生态系统的设计者都应努力通过在可能时偏好单次使用可验证凭证，使其尽可能尊重隐私。

使用单次使用可验证凭证提供若干好处。第一个好处是对验证者而言，他们可以确信可验证凭证中的数据是新鲜的。第二个好处是对持有者而言，他们知道如果可验证凭证中没有长期标识符，那么该可验证凭证本身不能用于在线跟踪或关联他们。最后，攻击者没有什么可窃取，使整个生态系统运行起来更安全。

本节为非规范性内容。

在理想的隐私浏览场景中，不会泄露任何 PII。由于许多凭证包含 PII，向持有者提供软件的组织应当警告他们，如果在隐私浏览模式下使用凭证和呈示，这些信息可能会被泄露。由于每个浏览器供应商处理隐私浏览的方式不同，并且某些浏览器可能没有此功能，因此实现者不得依赖隐私浏览模式来提供任何隐私保护。相反，建议实现者依赖其软件可直接使用的工具来提供隐私保证。

本节为非规范性内容。

可验证凭证高度依赖对颁发者的信任。持有者能够利用可能的隐私保护的程度，往往强烈取决于颁发者对此类特性的支持。在许多情况下，使用零知识证明、数据最小化技术、持票人凭证、抽象声明以及防止基于签名关联的保护等隐私保护，都需要颁发者的主动支持，颁发者需要将这些能力纳入其颁发的可验证凭证中。

关键需要注意的是，持有者不仅依赖颁发者参与以提供有助于保护持有者和主体隐私的可验证凭证能力，还依赖颁发者不故意破坏这些隐私保护。例如，颁发者可能使用防止基于签名关联的签名方案签署可验证凭证。这将保护持有者在其与验证者共享时，不被签名值关联。然而，如果颁发者为每个已颁发的凭证创建唯一密钥，则无论验证者是否无法这样做，颁发者都可能跟踪该凭证的呈示。

除前文所述颁发者可能提供的隐私保护之外，颁发者还需要意识到他们在颁发凭证时，与他们使用的标识符和声明类型相关联而泄漏的数据。一个例子是颁发者颁发驾驶执照，该执照既透露其拥有管辖权的位置，也透露主体的居住地点。验证者可能会利用这一点，请求凭证来检查主体是否获得驾驶许可，但实际上他们感兴趣的是关于该凭证的元数据，例如哪个颁发者颁发了该凭证，以及该颁发者可能泄漏的边缘信息，例如主体的家庭住址。为了缓解此类泄漏，颁发者可以使用通用标识符来掩盖具体位置信息或其他敏感元数据；例如，在州或国家级别使用共享颁发者标识符，而不是在县、市、镇或其他较小市政级别使用。进一步地，验证者可以使用持有者证明机制来保护隐私，即证明某个颁发者存在于一组受信任实体中，而无需披露确切的颁发者。

基类	目的
`CredentialEvidence`	作为放入 evidence 属性中的特定证据类型的超类。
`CredentialSchema`	作为放入 credentialSchema 属性中的特定模式类型的超类。
`CredentialStatus`	作为放入 credentialStatus 属性中的特定凭证状态类型的超类。
`ConfidenceMethod`	作为放入 `confidenceMethod` 属性中的特定置信方法类型的超类。
`RefreshService`	作为放入 credentialRefresh 属性中的特定刷新服务类型的超类。
`RenderMethod`	作为放入 `renderMethod` 属性中的特定呈现方法类型的超类。
`TermsOfUse`	作为放入 termsOfUse 属性中的特定使用条款类型的超类。

类型名称：	application
子类型名称：	vc
必需参数：	无
编码考量：	使用 `application/vc` 媒体类型的资源需要符合 `application/ld+json` 媒体类型的所有要求，因此受 The JavaScript Object Notation (JSON) Data Interchange Format 第 11 节中指定的相同编码考量约束。
安全考量：	如 Verifiable Credentials Data Model v2.0 中定义。
联系人：	W3C Verifiable Credentials Working Group public-vc-wg@w3.org

类型名称：	application
子类型名称：	vp
必需参数：	无
编码考量：	使用 `application/vp` 媒体类型的资源需要符合 `application/ld+json` 媒体类型的所有要求，因此受 The JavaScript Object Notation (JSON) Data Interchange Format 第 11 节中指定的相同编码考量约束。
安全考量：	如 Verifiable Credentials Data Model v2.0 中定义。
联系人：	W3C Verifiable Credentials Working Group public-vc-wg@w3.org

JSON-LD 文档和哈希
URL： https://www.w3.org/2018/credentials# 解析后的文档： https://www.w3.org/2018/credentials/index.jsonld SHA2-256 摘要： `9db03c54d69a8ec3944f10770e342b33e58a79045c957c35d51285976fc467c4`
URL： https://w3id.org/security# 解析后的文档： https://w3c.github.io/vc-data-integrity/vocab/security/vocabulary.jsonld SHA2-256 摘要： `689af6f393b55c9b35c37cfad59d13cc421e0c89ce97cf0e8234f9b4a3074104`

可验证凭证数据模型 v2.0

摘要

本文档状态

1. 引言

1.1 什么是可验证 凭证？

1.2 生态系统概览

1.3 一致性

2. 术语

3. 核心数据模型

3.1 声明

3.2 凭证

3.3 呈示

4. 基本概念

4.1 入门

4.2 可验证凭证

4.3 上下文

4.4 标识符

声明： id

声明： type

声明： id

声明： type

4.5 类型

声明： id

声明： type

声明： id

声明： type

4.6 名称和描述

声明： id

声明： type

声明： id

声明： id

声明： type

4.7 颁发者

声明： id

声明： type

声明： id

声明： type

声明： id

声明： type

声明： id

声明： id

声明： type

4.8 凭证主体

声明： id

声明： type

声明： id

声明： type

4.9 有效期

声明： id

声明： type

声明： id

声明： type

4.10 状态

4.11 数据模式

4.12 保护机制

4.13 可验证呈示

封套式可验证凭证

封套式可验证呈示

使用派生凭证的呈示

包含持有者声明的呈示

5. 高级概念

5.1 信任模型

5.2 可扩展性

声明： id

声明： type

声明： id

语义互操作性

5.3 相关资源的完整性

5.4 刷新

5.5 使用条款

5.6 证据

5.7 零知识证明

5.8 表示时间

5.9 授权

5.10 保留扩展点

5.11 生态系统兼容性

5.12 可验证凭证图

5.13 保护机制 规范

6. 语法

6.1 JSON-LD

1.1 什么是可验证凭证？

5.13 保护机制规范

6.3 特定类型凭证处理

8.3 个人可识别信息

8.7 设备跟踪和指纹识别

8.9 数据最小化原则

8.12 存储提供商和数据挖掘

8.16 与错误方共享信息

8.21 颁发者合作对隐私的影响

9.1 密码学套件和库

9.5.1 中间人（MITM）攻击

11. 国际化考量

11.2 提供默认语言和方向

A.11 “人工智能”和“机器学习”

B. 上下文、词汇表、类型和凭证模式