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	通過私鑰生成公鑰