第3部分 原理篇3可验证凭证（VC）（5）

3.3.6. 可验证凭证发行和验证

本聪老师：大家谁能简单回顾一下，可验证凭证包括可验证表述，都经历了哪些过程？

小云：我来说下看对不对。首先是发证方发行可验证凭证，发给持证方，持证方存有多份可验证凭证，使用时组合成可验证表述，递交给验证方。验证方根据其中的证明资料验证身份和其中的声明断言。

本聪老师：不错，基本如此。下面的图3-详细描述了可验证凭证从诞生到撤销删除的流程。首先是发证方向持证方颁发可验证凭证。持证方可能收到不止一份关于同一主体的可验证凭证，有时候还会发生持证方把部分可验证凭证转让给另一个持证方。通常持证方会根据需求选择同一主体的一个或多个可验证凭证，组合在可验证表述中，呈现presents给验证方。验证方验证所呈现的可验证表述和可验证凭证的真实性。后续管理过程中，发证方也可能会撤销可验证凭证。持证方也可能会删除可验证凭证。

本聪老师：接下来我们重点学习些其中涉及的两个行为：发行和验证。

3.3.6.1. 发行凭证

本聪老师：这里假设我们将要发行一个新的可验证凭证，那么需要考虑一下创建新的凭证类型的流程。

小明：我理解发行新类型的可验证凭证之前必须定义它的数据模型。

本聪老师：是的。我们需要经历下面的流程，首先是设计数据模型，或者自定义创建一个新的数据模型，生成JSON-LD格式@context。然后为@context选择一个发布位置。最后就可以使用@context发行新凭证。

本聪老师：我们以创建一个快递投递地址类型的可验证凭证作为示例。我们来看第一步设计数据模型。大家说下快递收件地址还包括哪些数据？

小云：我能想到的有国家、省市、区县、乡镇街道、地址，还有联系人和电话。

本聪老师：好的。我们参考中国邮政行业标准YZ/T 0143-2015快件基础数据元，其中已经对邮政快件收件人进行了建模，我们参照构造数据结构。例如收件人小明，电话号码：19991999999，详细住址为北京市海淀区长春桥路207号。使用YZ/T 0143-2015快件基础数据元规范和JSON-LD，我们可以这样像例3-17一样表示小明的凭证。

例3-17: YZ/T 0143-2015快件基础数据元收件地址凭证示例

{

“@context”: [

“https://www.w3.org/2018/credentials/v1”,

“https://www.spb.gov.cn/”

],

“credentialSubject”: {

“type”: “Person”,

“address”: {

“type”: “PostalAddress”,

“Receiver’sName”: “XiaoMing”

“Receiver’sDetailAddress”: “207 ChangChunQiao St.”

“Receiver’sAdministrativeArea”: “Haidian”,

“Receiver’sCountry”: “CN”

}

“phonenum”: {

“type”: “PhoneNumber”,

“Receiver’sMobilePhone”: “19991999999”

}

}

}

小天：这里的@context到底起什么作用呢？

本聪老师：上述JSON中的@context表明这是一个机器可读的文件，它提供了术语定义JSON-LD，相当于将将JSON中某个键对应的值，如“207 ChangChunQiao St.”，映射到一个全球唯一URL：https://www.spb.gov.cn/Receiver’sDetailAddress。这确保了当软件看到@context https://www.spb.gov.cn/，它将以全局一致的方式解释JSON中的键和类型，而不要求开发者在JSON中或在其他代码中使用完整的URL。

本聪老师：上面的例子中，我们使用了行业标准的数据模型，我们也可以参考相关标准规范自定义一个数据模型，比如命名为ExamplePostalCredential，用URL的方式进行引用和发布，比如：https://example.org/example-postal-credential-context/v1。

小天：那最后怎么发行凭证呢？

本聪老师：接下来就是发行了。发行其实就是任何人使用我们创建的的ExamplePostalCredential，补充相应属性及键值。比如例3-18。

例3-18: 带有自定义context的地址凭证示例

{

“@context”: [

“https://www.w3.org/2018/credentials/v1”,

“https://example.org/example-postal-credential-context/v1”

],

“id”: “https://example.org/credentials/0003”,

“type”: “ExamplePostalCredential”,

“issuer”: “https://example.org/people#me”,

“validFrom”: “2023-12-05T14:27:42Z”,

“credentialSubject”: {

“type”: “Person”,

“address”: {

“type”: “PostalAddress”,

“Receiver’sName”: “XiaoMing”

“Receiver’sDetailAddress”: “207 ChangChunQiao St.”

“Receiver’sAdministrativeArea”: “Haidian”,

“Receiver’sCountry”: “CN”

}

“phonenum”: {

“type”: “PhoneNumber”,

“Receiver’sMobilePhone”: “19991999999”

}

}，

“proof”: { …… }

}

3.3.6.2. 验证凭证

本聪老师：下面我们学习凭证如何验证？大家思考一下，验证方可能会验证凭证中的哪些内容？

小天：首先应该是发证方的身份，然后是主体的身份。

本聪老师：对，这两个是最主要的。验证方首先验证可验证凭证的type属性，验证方可能会根据自己的场景请求特定类型的可验证凭证。

本聪老师：其次就是凭证主体，也就是每个 credentialSubject 的 id 属性相关联的值，一般主体会是持证方。谁来说下，如果是DID标识符，怎么验证主体的身份？

小明：验证方会通过DID解析器解析出标识符对应的DID文档，其中包括公钥数据，验证凭证中存放的持证方的签名，确认其身份。

本聪老师：对。接下来还会验证发证方，就是issuer 属性的值。发证方会使用自己的公钥对凭证进行数字签名。验证方同样使用发证方的DID标识符解析出DID文档，验证数字签名。

本聪老师：接下来还有validFrom属性和validUntil属性，看是否在有效期内。还有很重要的内容是验证proof属性。proof属性使用加密机制保证可验证凭证或可验证表述中的信息未被篡改。因此验证的主要内容就是证明套件的形式，内容是否完整，验证算法在应用于数据时会产生可接受的证明。比如数字签名，验证公钥元数据是否可用，是否已经暂停、撤销或过期等等。

本聪老师：如果存在credentialStatus 属性，会验证凭证的状态是否可用。或者存在某些自定义的属性，也会被验证方进行验证。

本文内容摘自《对话去中心化数字身份》。作者：乔布施。首发平台：https://ytm.app

欢迎转载，请注明出处及作者。