3.2.3.?DID解析

3.2.3.1.?DID解析參與方

圖3-5 DID 解析過程

本聰老師：我們之前提到過，DID 解析過程是將 DID 轉換為對應的 DID 文檔。這樣做的目的是驗證 DID 所代表的主體的身份。那么解析過程會涉及哪些概念呢？我們看圖3-，DID標識符代表DID主體行使其數字身份的職責，DID標識符有時候被包含在DID URL中，它們可以被解析（DID URL成為解引用）為DID文檔。DID標識符和DID文檔都被記錄在可驗證數據注冊表中，供查詢檢索。DID文檔的更新等操作受DID控制器管理控制。

3.2.3.2.?DID解析過程

小天：解析發生在哪些場景呢？

本聰老師：我們設想這樣的場景，小天帶著自己的數字畢業證去某公司面試，畢業證上有小天的DID標識符、學校的DID標識符和學校的數字簽名。那么公司的人力部門首先要做的是確認學校和小天的身份，如何確認呢？從DID標識符解析為DID文檔，文檔中會包括各自的公鑰和授權等信息，后續可以使用公鑰對畢業證上面的數字簽名進行驗證。

小天：明白了。DID 解析過程有哪些呢？

本聰老師：這里還要提到的是DID URL的解析，術語稱為解引用（dereference），與DID標識符的解析過程基本相同，我們在說明過程中會提到不同之處。從原理看，DID解析經歷了4個階段：首先是從DID標識符解析出?DID 方法，這個不難吧？

小明：是截取DID標識符的前兩部分就可以，就像”did:example” 是一個 DID 方法。

本聰老師：對。對于DID URL第一步是分離DID標識符和URL路徑，獲得DID方法。解析的第二階段是獲取 DID 文檔，獲取的過程其實就是從可驗證數據注冊表這樣的可信基礎設施檢索的過程。具體來講就是DID 解析函數通過使用適用的 DID 方法的“讀取”操作將 DID 解析為 DID 文檔，這里有兩個函數resolve 函數和resolveRepresentation 函數。resolve 函數以map形式返回 DID 文檔。 resolveRepresentation 函數返回的是符合表示法格式的 DID 文檔的字節流。對于DID URL解引用，同樣存在dereference函數，以DID URL等參數為輸入，除了返回DID文檔之外，還會返回URL資源，這些資源同樣用于后續的驗證過程。

本聰老師：第三階段是驗證 DID 文檔，在獲取 DID 文檔之后，需要對 DID 文檔進行驗證，以確保其是有效的、未被篡改的并且是與 DID 相關聯的實體的正確信息。這可以通過使用 DID 文檔中的驗證方法來完成。

本聰老師：最后第四階段就是訪問 DID 文檔中的信息，一旦驗證了 DID 文檔，就可以使用其中的信息來驗證 DID 所代表的實體的身份或其他目的。

小天：嗯，大致能理解了。說下我的理解，看對不對？DID 解析過程是將 DID 轉換為與之相關聯的 DID 文檔，并驗證該文檔的有效性和正確性，以便訪問其中包含的相關信息。

本聰老師：總的來說是這樣的。

3.2.4.?DID Auth協議

本聰老師：我們在介紹DID文檔結構的時候，了解文檔中存在“認證”屬性。DIF通過DID Auth協議豐富了DID文檔中“authentication”屬性的能力，我們本節詳細在討論下這個協議。

小明：是，感覺“authentication”屬性理解不是很透徹。

3.2.4.1.?構建“authentication”屬性

本聰老師：好的，我們補充下這部分內容。DID Auth協議能做什么呢？簡單說，就是身份所有者在各種組件（如網絡瀏覽器、移動設備和其他代理）的幫助下向有驗證需求的各方（成為依賴方）證明他們控制著一個DID。

小明：對，這是DID最基本的使用場景。實際場景中是不是存在多種認證模式呢？

本聰老師：對，存在單向認證和雙向認證的需求。我們假設小天持有DIDa，小明持有DIDb，單向認證就是小天向小明證明對DIDa的控制，雙向認證就是，小天向小明證明對DIDa的控制，小明向小天證明對DIDb的控制。

小云：那么可認證的DID標識符與DID標識符一樣嗎？

本聰老師：一樣的，其實真實生成環境中，每個新生成的DID標識符應該都附帶有“authentication”屬性。下面我們梳理一下創建DID 的流程。

本聰老師：第一步，用戶（DID subject）使用符合DID方法規范的客戶端創建一個DID標識符，例如：did:ytm:653ca82******45d85a47。第二步，用戶生成對應的DID文檔，將文檔中的“id”屬性設置為剛生成的did:ytm:653ca82******45d85a47。為文檔添加“authentication”屬性，增加“type”參數值（根據DID方法規定選擇），補充其他參數，比如”publicKey”等等認證材料。DID方法平臺補充其他屬性及參數。下面例子中的代碼，包含“authentication”屬性，其中有兩個type和publicKey，屬于同一個owner，但具有不同的編碼方式。

• 包含“authentication”屬性的例子

{

“@context”: “https://w3id.org/did/v1”,

“id”: “did:example:123456789abcdefghi”,

“authentication”: [{

“type”: “RsaSignatureAuthentication2018”,

“publicKey”: “did:example:123456789abcdefghi#keys-1”

}, {

“type”: “Ed25519SignatureAuthentication2018”,

“publicKey”: “did:example:123456789abcdefghi#keys-2”

}],

“publicKey”: [{

“id”: “did:example:123456789abcdefghi#keys-1”,

“type”: “RsaVerificationKey2018”,

“owner”: “did:example:123456789abcdefghi”,

“publicKeyPem”: “—–BEGIN PUBLIC KEY…END PUBLIC KEY—–\r\n”

}, {

“id”: “did:example:123456789abcdefghi#keys-2”,

“type”: “Ed25519VerificationKey2018”,

“owner”: “did:example:123456789abcdefghi”,

“publicKeyBase58”: “H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV”

}]

}

小明：嗯，接下來呢？

本聰老師：好。第三步就是把DID標識符和DID文檔存儲到可驗證數據注冊表，這里的可驗證數據注冊表可以是區塊鏈分布式賬本，也可以是其他中心化存儲系統。DID文檔的創建過程就完成了。

3.2.4.2.?認證的過程

小明：使用的過程是怎樣的？

本聰老師：使用的過程就是認證的過程。DID Auth協議認為這個過程是挑戰-響應的循環。通過這個循環，依賴方對身份所有者的DID進行認證。

小云：挑戰應該依賴方發起的吧？

本聰老師：對。身份所有者面臨挑戰的情形很多，比如點擊網站上的 “用DID Auth登錄 “按鈕、掃描二維碼或者是后臺調用API。依賴方發起挑戰時，一般不知道誰來響應，所以挑戰中不會包含DID，但會包含隨機數，用來區別后續的挑戰，并且防止重放攻擊。

小天：那么響應呢？

本聰老師：身份所有者會根據挑戰構建一個響應，響應中通常會包括一個加密數字簽名，證明自己對DID標識符的控制。接下來，響應發給依賴方。依賴方在收到響應后，會解析身份所有者的DID標識符為DID文檔，使用其中的公鑰驗證響應中包含的數字簽名。大家看下下面的圖3-6就應該明白了。我說一下基本環境，看大家能否說清楚流程。身份所有者是個人用戶，他使用web瀏覽器登陸一個網站，移動app中安裝有DID方法的客戶端（其中包含認證材料）。依賴方是網站，需要驗證用戶的登陸行為。

圖3-6 挑戰過程

小明：我說說。用戶打開login頁面，其中內嵌一個登陸二維碼（這里包含挑戰的內容給你），他用手機app掃描二維碼，將自己的DID標識符和數字簽名構建成響應發給WEB服務器，web服務器將DID標識符提交給DID解析器，得到DID文檔，獲得其中的公鑰，驗證數字簽名。網站頁面會周期性輪WEB服務器,驗證無誤，表示認證過程通過，用戶瀏覽器可以登陸進入網站。

本聰老師：基本是這樣。圖3-只是一種情形，還有上面提到的用戶登陸移動app接受認證，甚至用戶本身就是一家機構，認證方式和流程略有不同，但原理基本是這樣。

---

本文內容摘自《對話去中心化數字身份》。作者：喬布施。首發平臺：https://ytm.app

歡迎轉載，請注明出處及作者。