WeIdentity

分布式多中心的技术解决方案，可承载实体对象（人或者物）的现实身份与链上身份的可信映射、以及实现实体对象之间安全的访问授权与数据交换。

1. 主要模块介绍

WeIdentity DID以及WeIdentity Credential。

分布式身份标识 (WeIdentity DID)

简称WeID，WeIdentity的分布式多中心的ID***制下生成的实体的ID。

WeIdentity DID模块实现了一套符合W3C DID规范的分布式多中心的身份标识协议，使实体（人或物）的现实身份实现了链上的身份标识；同时，WeIdentity DID给与Entity（人或者物）直接拥有和控制自己身份ID的能力。

可验证数字凭证 (WeIdentity Credential)

WeIdentity Credential提供了一整套基于W3C VC规范的解决方案，旨在对身份证、行驶证、存款证明、处方、毕业证、房产证、信用报告等这一类数据进行标准化、电子化，生成可验证、可交换的「凭证」（Credential），支持对凭证的属性进行选择性披露，及生成链上存证（Evidence）

2. WeIdentity 参考场景

在WeIdentity生态中，存在着上图所示的几类角色，不同角色的权责和角色之间的关系如下表所示：

角色	说明
User (Entity)	用户（实体）。会在链上注册属于自己的WeIdentity DID，从Issuer处申请Credential，并授权转发或直接出示给Verifier来使用之。
Issuer	Credential的发行者。会验证实体对WeIdentity DID的所有权，其次发行实体相关的Credential。
Verifier	Credential的使用者。会验证实体对WeIdentity DID的所有权，其次在链上验证Credential的真实性，以便处理相关业务。
User Agent / Credential Repository	用户（实体）在此生成WeIdentity DID。为了便于使用，实体也可将自己的私钥、持有的Credential托管于此。

在实际业务里，WeIdentity可以被广泛运用在「实体身份标识」及「可信数据交换」场景中。首先，通过User Agent为不同的实体生成独立唯一的DID；其次，Issuer验证实体身份及DID所有权，为实体发行各种各样的电子化Credential。当实体需要办理业务的时候，可以直接将Credential出示给Verifier，也可以通过在链上进行主动授权 + 授权存证上链的方式，由之前授权的凭证存储机构转发给Verifier。

以上流程，保证了数据以实体用户为中心，同时实体身份、确权、授权等操作在链上完成，可追溯，可验证，不可篡改。

术语

Claim	声明	对实体的一个声明或者主张，用于装载凭证（Credential）业务数据的字段，例如电子驾照的各项信息就是存在一个Claim结构中
WeIdentity Credential	可验证数字凭证	简称“凭证”，遵循W3C Verifiable Credential规范的电子凭证，可用来抽象现实世界凭证类的对象，一个Credential可以包含一个或者多个Claim。例如电子驾照，电子学历等
CPT	凭证的声明类型	Claim Protocol Type,不同的Issuer按业务场景需要，各自定义不同类型数据结构的Claim，各种各样的Claim用不同的CPT来定义
issue	发行	一个Issuer（包括Authority Issuer）按照某种CPT定义的格式，发行Credential，这个动作叫issue
publish	发布	一个Issuer（包括Authority Issuer）发行一种新的CPT，这个动作称为publish
Issuer	凭证发行者	任意拥有WeIdentity DID的Entity都可以作为Issuer来发行Credential
Entity	实体	WeIdentity Document或Credential描述的实体，即拥有WeIdentity DID的人或者物
User Agent	用户代理	用户私钥托管机构，例如某个用户身份管理APP。依据业务场景需求，可以是云端保存机制的，也可以是客服端本地保存机制的

使用场景

通过WeIdentity对实体进行DID、凭证（Credential）的生成及绑定，可以更加准确完善地描述实体身份、实体间关系，并有效提高实体间信息流转的真实性和效率。

1 选择性披露

如何为Credential生成签名

Issuer生成Credential签名的过程：

1. Claim中的每个字段计算生成一个对应的hash值。
2. 将Claim中的每个字段的hash值以某种形式拼接起来形成一个字符串Claim_Hash，然后跟Credential原有的其他字段组成一个新的用于计算hash的Credential结构。
3. 对这个包含Claim_Hash的Credential结构计算hash，得到Credential Hash。
4. 使用Private Key对这个Credential Hash进行签名，得到签名的值Signature。

如何验证选择性披露的Credential

用户选择需要披露的字段集合（可以是一个或者几个字段，这个例子中是Field_1），需要披露的字段提供原文，其他字段提供hash值。将包含这个Claim结构的Credential披露给Verifier。下面是Verifier验证的过程：

1. Verifier从Credential提取用户披露的Claim字段。
2. Verifier对用户披露的字段分别计算hash（这个例子中是Field_1,计算出Field_1_hash）,然后得到一个包含所有字段hash值的Claim结构。
3. 对这个Claim结构中的每个字段的hash值以某种形式拼接起来形成一个字符串Claim_Hash，然后跟Credential原有的其他字段组成一个新的用于计算hash的Credential结构。
4. 对这个包含Claim_Hash的Credential结构计算hash，得到Credential Hash。
5. 使用Credential的Signature和Issuer的public key进行decrypt，得到一个签名的计算值。
6. 比较Credential的Signature与签名的计算值，看是否相等，确认这个Credential的合法性。

2 数据共享

总体流程

一般来说，WeIdentity解决方案的基本流程如下：

1. 用户根据业务需求，选择是否需要进行KYC认证。
2. 用户生成WeIdentity DID。
3. 用户向相关业务方申请Credential。
4. 相关业务方扮演Issuer的角色，发行Credential交给用户。
5. 用户成为了Credential的Holder。
6. 用户出示Credential，以完成业务需求。
7. 相关业务方扮演Verifier的角色，验证Credential有效性。

其中CPT为模板类，定义了Claim包含的数据字段及各字段属性要求。Claim为CPT的实例。Issuer将Claim进行签名，即可生成Credential。

WeIdentity Sample开发样例代码

###Claim Protocol Type（CPT）***制

不同的Issuer按业务场景需要，各自定义不同类型数据结构的Claim，所有的Claim结构都需要到CPT合约注册，以保证全网唯一。所有的CPT定义文件（JSON-LD格式）可以从CPT合约下载。

结合代码

DemoIssuerController

Issuer: Credential的发行者。会验证实体对WeIdentity DID的所有权，其次发行实体相关的Credential。

接口	含义	备注
/step2/registCpt	注册CPT	需要获得publisher,privateKey和claim才可以注册CPT
/step3/createCredential	创建电子凭证	需要提供cptId,issuer,privateKey,claimDataMap才可以创建电子凭证

DemoMemberController

Committee Member: 委员会机构成员，管理Authority Issuer的委员会机构的成员。

接口	含义	备注
/step1/member/createWeId	创建WeId	直接就可以创建一个唯一id
/step2/registerAuthorityIssuer	注册成为权威机构	需要issuer和orgId即authorityName才可以

DemoOtherCredentialController

其他相关接口-Credential
电子凭证其他相关接口。

接口	含义	备注
/step1/credential/getCredentialPoJoHash	传入Credential信息生成Credential整体的Hash值，一般在生成Evidence时调用。

DemoOtherCredentialPoJoController

电子凭证其他相关接口。
其他相关接口-CredentialPoJo

接口	含义	备注
/step1/createCredentialPoJo	传入Credential信息生成Credential整体的Hash值，一般在生成Evidence时调用。	直接调用
/step2/createSelectiveCredential	通过原始凭证和披漏策略，创建选择性披露的Credential。	直接调用
/step3/verifyEvidence	验证电子凭证。	直接调用
/step4/createPresentationPolicyE	创建PresentationPolicyE。	直接调用
/step5/createPresentation	创建Presentation。	直接调用
/step6/getCredentialPoJoHash	传入CredentialPojo信息生成CredentialPojo整体的Hash值，一般在生成Evidence时调用。	直接调用
/step7/addSignatureCredentialPojo	多签，在原凭证列表的基础上，创建包裹成一个新的多签凭证，由传入的私钥所签名。此凭证的CPT为一个固定值。在验证一个多签凭证时，会迭代验证其包裹的所有子凭证。本接口不支持创建选择性披露的多签凭证。	直接调用

DemoOtherEvidenceController

其他相关接口-Evidence
存证其他相关接口。

接口	含义	备注
/step1/createEvidence	将传入Object计算Hash值生成存证上链，返回存证地址。传入的私钥将会成为链上存证的签名方。此签名方和凭证的Issuer可以不是同一方。当传入的object为null时，则会创建一个空的存证并返回其地址，空存证中仅包含签名方，不含Hash值。可以随后调用SetHashValue()方法，为空存证添加Hash值和签名。	直接调用
/step2/getEvidence	根据传入的凭证存证Hash，在链上查找凭证存证信息。	直接调用

DemoOtherTransportationController

传输其他相关接口。

其他相关接口-Transportation

接口	含义	备注
/step1/jsonTransportationSpecify	指定transportation的认证者,用于权限控制。
/step2/jsonTransportationSerialize	用于序列化对象,要求对象实现JsonSerializer接口。

DemoOtherWeIdController

其他相关接口-WeId

WeId其他相关接口。

/step1/createWeId	通过公私钥对创建WeId。	create weId without parameters and call the settings property method. returns weId and public key

DemoUserAgentController

UserAgent相关接口 。

User Agent / Credential Repository:

用户（实体）在此生成WeIdentity DID。为了便于使用，实体也可将自己的私钥、持有的Credential托管于此。

接口	含义	备注
/step1/userAgent/createWeId	创建weid	create weId without parameters. returns weId and public key

DemoVerifierController

会验证实体对WeIdentity DID的所有权，其次在链上验证Credential的真实性，以便处理相关业务。

Verifier相关接口

Verifier: Credential的使用者。

接口	含义	备注
/step1/verifyCredential	验证凭证是否正确	返回true或者false

ToolController

小工具

含义	备注
/step1/verifyCredential	验证凭证是否正确

ToolController

小工具

含义	备注
/step1/getPublicKey	通过私钥生成公钥