1 of 11

可验证凭证

Weili Yang, Tech Lead @KEN Labs

SSI 课程：第七章

1

2 of 11

使用可验证凭证的用例

使用电子处方

处方是以可验证凭证的形式写的，你是主体，医生是签发人，内容是开给你的药物。

银行开户

银行信任政府，接受你的可验证凭证，并向你发放新的可验证凭证，这个凭证提供了你的银行账户信息，之后你会将其加入你手机上的一套可验证凭证当中。

2.5 days

领取免费的本地通行证

你有当地老人中心发放的可

验证凭证，你的手机将你的公交卡的可验证凭证副本传输给运营商，然后运营商给予你免费乘车的权利。

因为可验证凭证是数字化的，所以它们的用途更广泛

2

我们每天都会多次使用实物版的可验证凭证（VCs）（尽管你可能没有意识到）。例如，塑料信用卡、驾照、护照、会员卡、公交卡等等。我们不能没有它们，因为它们为我们提供了许多好处。

不幸的是，你可能会丢失或误放纸质证书，或者被盗。更糟糕的是，它们可以在你不知情的情况下被复制或克隆。但最重要的是，你不能在网上使用它们--除非你把它们的所有细节输入一个网络表格，这很费时间，容易出错，而且侵犯隐私。可验证凭证创业板现在是一个完整的万维网联盟（W3C）开放标准（https://www.w3.org/TR/vc-data-model），将允许发行商把他们今天生产的可验证凭证实体转换成数字可验证凭证，这样你就可以把它们放在你的手机、平板电脑、笔记本电脑和其他设备中，并通过简单的操作在线使用它们。

再加上这种易于使用的优势，你还可以通过数字可验证凭证获得其他好处：

它们不能被复制或克隆。
它们极难被盗（攻击者需要窃取你的电子设备和你用来验证设备的方法）。
它们更加保护隐私，因为它们支持选择性披露（只披露一些可验证数据的一部分）。
它们更安全，因为它们支持最小权限（也被称为最小权限：只拥有做所需任务的权限，而不是其他）。
它们的发行几乎没有成本。
它们不像塑料卡那样笨重，可以随身携带。
你可以把它们委托给其他人使用（前提是发行人允许这样做）。

可验证凭证风险投资不仅可用于所有我们几乎每天都在使用的物理凭证，还可用于更多场景，因为它们是数字的。以下是一些典型的使用场景。

想象一下，你想在BigBank开一个银行账户。你来到BigBank的当地分行，助理要求你提供两种正式的身份证明--所谓的了解你的客户（KYC）检查。你有一本护照和各种符合条件的公用事业账单，但不幸的是，你把它们留在了家里。幸运的是，该银行支持使用W3C可验证凭证，而且你总是随身携带你的手机，你在手机上存储了几十个风可验证凭证。

你选择你的政府签发的护照可验证凭证，它确认你的国籍、姓名和年龄；以及你的健康保险可验证凭证，它确认你目前的居住地址。这两份文件还包含你的面部数字图像。因为银行信任政府和保险公司，所以它愿意接受这些可验证凭证证明作为你的姓名和地址的证明，并证明提出申请的人确实是你。

因此，银行给你发了一个新的可验证凭证，提供你的银行账户信息，你把它添加到你手机上的一组可验证凭证。你可以以各种方式使用这个新的可验证凭证。

你是养老金领取者。你有当地养老中心发放的VC，上面写着你有权免费乘坐当地都市区的公交车。每当你乘坐当地公交车时，你只需将你的手机放在NFC近距离读卡器上，它就会将你的公交卡的VC副本传输给运营商，然后运营商就会准许你免费无限制地进入公交车。

你生病了。你去看医生，医生诊断为感染，她为你开了青霉素。处方是以VC的形式写的，你是主体，医生是发行者，内容是开给你的药物。你觉得自己不够好，不能亲自去药店取药，所以你让你的妻子代替你去取药。你把处方的VC转移到她的手机上，并为你的妻子发布了一个关系VC，她是主体，你是发布者，还有一个属性，说她是你的妻子。

3 of 11

Lead

发行人

向用户发放可验证凭证的实体。

主体

其属性被存储在可验证凭证中的实体。

持有人

目前持有可验证凭证的实体，并将其提交给验证人。

验证人

从持有人那里接受可验证凭证并提供利益回报的实体。

钱包

为持有人持有可验证凭证的实体。

持有人的代理

代表持有人与可验证凭证生态系统互动的软件。

可验证的数据注册表

一个可通过互联网访问的注册处，拥有使可验证凭证生态系统运作的所有基本数据和元数据。

可验证凭证生态系统

可验证凭证生态系统中的实体和角色

在可验证凭证的整体架构中，持有人位于中心位置——本质是以用户为中心的设计。

3

VC架构的组成部分如下：

发行人--向用户签发VC的实体。在大多数情况下，用户是主体，但在某些情况下，可能不是；例如，如果主体是一只宠物猫，而VC是一份疫苗接种证书，那么发行人将向猫的主人发放VC。
主体--其属性被存储在VC中的实体。主体可以是任何有身份的东西：人、组织、人造物、自然物、逻辑物，等等。
持有人--目前持有VC并将其提交给验证人的实体。在大多数情况下，主体和持有者是同一个实体；但正如你在前面的处方和猫的例子中所看到的，情况并不总是这样。
验证人--从持有人那里接收可验证凭证风险投资并提供利益回报的实体。
钱包-为持有人持有可验证凭证风险投资的实体。在许多情况下，钱包是持有人的代理人的组成部分，但该模型允许存在一个远程钱包，如云存储钱包。
持有人的代理--代表持有人与VC生态系统互动的软件。这可能是一个你加载到手机上的应用程序，或者是你在笔记本电脑上运行的程序。
可验证的数据注册表--从概念上讲，是一个可通过互联网访问的注册处，它拥有使VC生态系统得以运行的所有基本数据和元数据。可以存储在该注册表中的数据和元数据类型的例子如下：
发行人的公钥
VC可能包含的所有属性的模式或本体；被撤销的VC的撤销列表
发行人说他们具有权威性的主题属性（例如，一个国家政府可能列出社会安全号码和护照细节；一所大学可能列出其学位和成绩单）。

4 of 11

可验证凭证信任模型

可验证凭证信任模型中的具体信任关系

可验证凭证的信任模式：持有者处于中心位置，验证者只需信任发行人（可验证的数据注册表受到所有各方的信任）。

联合身份架构将IDP置于生态系统的中心，而可验证凭证架构则将持有人置于生态系统的中心。

凭证可以被数字签名，数字签名可以被加密验证

联合身份管理

4

5 of 11

语法表述

可验证凭证数据模型1.0规范定义的两种语法表示是基于JavaScript对象符号（JSON），这是一种简化的语法，用于表示JavaScript编程语言中的数据项集合。

JSON-LD

JWT

Server

JSON-LD表述和JWT表述

5

VC数据模型1.0规范定义的两种语法表示是基于JavaScript对象符号（JSON）的，它是对JavaScript编程语言中用于表示数据项集合的语法的简化。

JSON-LD是 JavaScript Object Notation for Linked Data的缩写，是一种基于JSON表示和传输互联数据（Linked Data）的方法。可用于实施结构化数据。JSON-LD描述了如何通过JSON表示有向图，以及如何在一个文档中混合表示互联数据及非互联数据。

JSON-LD使得纳入被称为模式的结构化模板中定义的属性变得容易。JSON-LD的命名方法非常灵活，因为任何人都可以创建一个新的模式（称为上下文），将其发布在互联网上，然后在VC中引用其属性。规范的细节请参考官网json-ld.org。

JSON网络令牌，是以前使用JSON表示可签名的索赔或证明的标准化方式。该语法便于转换为二进制表示，在使用空白空间方面很精确，并且容易压缩，以减少存储和传输成本。鉴于基于JWT的生态系统的广泛性，找到一种在JWT中表示VC和VP的方法是有意义的。

6 of 11

基本的可验证凭证属性

VC claim

VC metadata

Proof

最基本的可验证凭证只需要容纳六条信息

基本可验证凭证的结构：元数据部分、声明部分和证明部分。

Context — 当人们交流时，他们需要知道使用什么语言和词汇。

Type — 类型属性包含一个URI列表，声明这是什么类型的可验证凭证。

ID — ID属性是该可验证凭证的唯一标识符，由发行方创建。

Issuer — 发行人属性唯一地标识了发行人。

Credential Subject—该属性包含发行人对主体的声明。它由主体的ID和发行人对主体所声明的一组属性组成。

Proof—为了使凭证可以被验证，它需要一个签名，这在可验证凭证数据模型规范中更多地被称为证明。

6

现在我们已经涵盖了语法表示，我们可以解释数据模型所定义的属性。最基本的VC只需要持有六条信息（编码为JSON属性）

接下来将介绍这些JSON属性中的每一个内容：

@context- @context属性告诉我们哪些信息被用来构建这个VC。从语法上讲，@context包括一个或多个统一资源标识符（URI）的序列。理想情况下，每个URI应该指向一个机器可读的文件，其中包含验证者可以自动下载和配置的信息。请注意，@context本身提供的信息（词汇）可能比验证者希望使用的多。因此，VC还包含一个类型属性。
type-类型属性包含一个URI列表，用于声明这是什么类型的VC。第一个类型必须始终是https://www.w3.org/2018/credentials/ v1，可以使用JSON- LD @context机制将其缩写为VerifiableCredential。验证器可以读取类型列表并快速确定它们是否可以理解和处理这个VC。如果该VC是验证器不认识的类型，验证器可以立即拒绝它，而无需进一步处理。
id-id属性是该VC的唯一标识符，由发行者创建。它由一个单一的URI组成。这允许任何实体毫不含糊地引用该VC。
发行人-发行人属性唯一地标识了发行人。它是一个URI。这个URI可以指向完全描述发行人的文档--例如，指向DID文档的DID，或者它可以包含发行人的DNS名称，可验证数据注册表可以包含关于发行人的进一步细节，例如其X.509公钥证书。
credentialSubject-该属性包含发行人对主体的声明。它由主体的ID和发行人对主体的一系列属性组成。在某些情况下，ID可能会丢失：例如，如果这是一个不记名的VC（如音乐会门票），可以属于任何人。由于VC的设计是为了保护主体的隐私，ID是以URI形式存在的主体的别名。一个主体可以有无数个别名，而每个VC可以包含一个不同的ID。这样一来，如果没有额外的信息，验证者就不能知道两个具有不同主体ID的VC属于同一个人。
证明--为了使一个凭证可以被验证，它需要一个签名，在VC数据模型规范中更多地被称为证明。这在密码学上证明了发行者发行了这个VC，并且自发行以来没有被篡改过。每个VC都必须包含证明属性。

其他的基本属性是可选的，但通常非常有用，包括以下内容：

issuanceDate-以ISO 8601的格式表示的合并日期和时间，在此日期之后，VC才有效。请注意，它不一定是VC的实际发行日期，因为发行者可能在此日期之前或之后发行VC，但它是VC无效的日期。
过期日期：ISO 8601格式的组合日期和时间，过了这个日期，VC就无效了。
credentialStatus-向验证者提供VC当前状态的细节：自其签发日期以来是否被撤销、暂停、取代或发生其他变化。

7 of 11

可验证表示

Set of VCs

VP metadata

Proof

VP是持有人将几个可验证凭证组合起来发送给验证人的一种方式

一个基本的VP，包含一组可验证凭证和关于它们的元数据。

可验证表示与可验证凭证非常相似，因为它包含关于表示的元数据以及由持有人签署的证明。VC和VP之间的显著区别是：

VP缺少发行人属性
VP的ID属性是可选的

可验证表示与可验证凭证非常相似，因为它包含关于展示的元数据，加上持有人签署的证明。然而，现在的内容是一组可验证凭证，而不是声明。

与可验证凭证类似，一个VP可以包含多个证明。

7

8 of 11

更高级的可验证凭证属性

可验证凭证是采用开放世界模型开发的，这意味着任何人都可以向可验证凭证添加适合其应用需求的任何属性。尽管如此，VCWG认为上述几个属性对一系列的应用普遍有用。

证据

证据属性是为发行者设计的，以帮助验证者确定其对可验证凭证内的声明的信任程度。.

当持有人不是主体时

为了安全起见，主体和发行人都应该允许可验证凭证被转让。VCWG正在对发行人授权不得转让可验证凭证的方式进行标准化。

使用条款

目前，大多数实体可验证凭证都受到使用条款的约束。

争议

在某些情况下，一些可验证凭证是虚假的，而合法的主体希望它们被撤销。

刷新服务

可验证凭证被设计为具有有限的寿命，有几个原因。

任何人都可以以任何方式扩展可验证凭证——互操作性问题

8

VC是采用开放世界的模式开发的，这意味着任何人都可以向VC添加适合其应用需求的任何属性。

refreshService属性允许发行人控制并提供关于如何刷新或更新当前VC的细节。刷新服务属性包含两个强制性属性：

id-查询者可以获得刷新的VC的URL。
type-表示这是什么类型的刷新服务，并控制刷新服务属性应该包含哪些其他属性。

有时，发行人持有关于某个主体的过时信息--但该主体不能强迫发行人更新其数据库并签发修订的可验证凭证风险投资。其他时候，一个人是身份盗窃的受害者，而攻击者通过使用虚假获得的可验证凭证风险投资来伪装成他们。在这两种情况下，存在的可验证凭证风险投资都是虚假的，而合法的主体希望撤销它们。如果发行人在这些情况下行动迟缓，合法主体应该怎么做？答案是DisputeCredential。

在合法主体持有过时或不正确的VC的情况下，有争议的VC和DisputeCredential都可以被发送给验证者。然后，验证者可以验证该主体在两份VC中是相同的，并确定有争议的属性。

今天，大多数实体可验证凭证都受使用条款的约束。向 VC（或 VP）添加使用条款的标准方式是通过 termsOfUse 属性。发行人指定的条款--适用于持有人和任何验证人--通常在 VC 中。持有人指定的条款--只适用于验证人--在VP内。像所有对基本VC（或VP）的扩展一样，termsOfUse属性必须包含它的类型，因为这制约着它的内容。id属性是可选的，但如果存在，它应该指向一个可以获得该VC（或VP）的使用条款的网页。

证据

证据属性是为发行者设计的，以帮助验证者确定其对可验证凭证内的声明的信任程度。.

当持有人不是主体时

为了安全起见，主体和发行人都应该允许可验证凭证被转让。VCWG正在对发行人授权不得转让可验证凭证的方式进行标准化。

9 of 11

其他议题

如果这种扩展性没有得到适当的控制，将导致缺乏互操作性。

可扩展性和模式

当可验证凭证在强隐私保护的背景下或生态系统中使用时，零知识证明（ZKP）是非常有帮助的。

零知识证明

9

转移和使用可验证凭证的协议被故意放在了范围之外，以保持创建规范的工作可控。

协议和部署

预测客户行为并提供实时的个性化促销活动。

安全和隐私评估

9

10 of 11

面临的障碍

今天的联合身份管理基础设施给予发行人（IDP）很大的权力，因为他们处于生态系统的中心。可验证凭证将这种模式颠覆，将用户置于中心位置。因此，发行商需要看到一些经济利益，才愿意转移。

10

11 of 11

Pando DID: pando.network

KEN Labs Research: kencloud.com

info@pando.network

twitter.com/KenLabs_Web3

感谢您的观看！

11