# Understanding Decentralized IDs (DIDs) (中譯)

原文：[Understanding Decentralized IDs (DIDs)](https://medium.com/@adam_14796/understanding-decentralized-ids-dids-839798b91809)

## 了解 Decentralized IDs (DIDs)
在上一次[網際網路身份研討會（IIW）](https://www.internetidentityworkshop.com/) 上，我發現了 Decentralized identifiers (DIDs)，其中 30％ 的發表似乎都是關於 DID 的。 我覺得我是派對的後起，但是因為我找不到關於 DID 的維基百科頁面或任何關於他們的歷史或者什麼時候開始的事情，也許我根本不會太遲。

DID 建議使用區塊鏈來註冊用戶可以用來標識自己的 identifiers。 這篇文章是為了記錄我在過去幾個月裡學到的關於 DID 的知識 - 既幫助其他有興趣參與 DID 的人，也讓人們可以告訴我，我錯了，我可以學到更多東西。 事先說明，我不贊成 DID 也不反對 DID; 我也不支持或反對區塊鍊和/或中央政府。 我現在必須說，因為所有這些事情似乎都是非常熱門的話題非常兩極分化，很多人對它們有非常強烈的看法。 我希望接下來的內容是客觀和中立的。

本文首先概述了 DID, DID Documents, Verifiable Claims 和 DIDAuth - 基本上闡述了該技術的工作原理。 然後，探討 DID 的經濟學，試圖了解他們建議解決的問題，為誰以及如何解決這些問題。

## DID 技術概述
我不會深入探討 DID 的架構 - 部分原因是因為我不是專家，但部分是因為我認為我可以在高階解釋而不會讓所有 bits 和 bytes 混淆。 [W3C分Decentralized Identifiers（DIDs）規範](https://w3c-ccg.github.io/did-spec/)目前的版本為0.10 - 因此我確信這一切都非常流暢且可能會發生變化。

首先，使用者可以隨時以任何理由創建新的 DID。 DID 代表兩件事：1. 唯一 identifier 和關聯的 DID Documents。 唯一 identifier 看起來像 ```did：example：123456789abcdefghi``` ，並且可以將其視為查找 DID Documents 的唯一 ID。 [DID Documents](https://w3c-ccg.github.io/did-spec/#x4-did-documents) 是一個 [JSON-LD](https://json-ld.org/) 物件，存儲在某個中心位置，以便可以輕鬆查找。 預計DID 將是 **[持久且不可變的](https://w3c-ccg.github.io/did-spec/#x3-6-did-persistence)** ，因此它不受其所有人的影響。

DID Documents 必須包含 DID。 它可能包括以下內容：

* 創建時間的時間戳記
* DID Documents 有效的加密證明
* 加密公鑰列表
* DID 可用於進行身份驗證的方式列表
* 可以使用 DID 的服務列表
* 任意數量的外部定義延伸

(一個 DID Documents 的範例（來自 W3C DID 規範）)

請注意，DID Documents 中沒有個人身份資訊：沒有使用者名稱，沒有地址，沒有電話號碼。 這是通過可驗證的聲明，我將在下一節中解釋。 但在我們到達那里之前，我應該再提兩件事。

首先，似乎大多數人對 DID Documents 中的公鑰感到興奮 - 我沒有聽過很多關於其他領域如何被使用，或者為什麼人們會對它們感到興奮的對話。

第二，對 DID 的格式我撒謊了。 它實際上是 ```“did:” + <method> + “:” <method-specific-identifier>```。 上面，我的方法是 **範例** ，我的方法特定 identifier 是 ```123456789abcdefghi```。 實際上，該方法定義了您將如何/在何處找到 DID。 目前有 9 種註冊方法，包括比特幣，以太坊，Sovrin，IPFS 和 Veres One - 所有這些都是區塊鏈（或**分佈式分類帳技術**更準確）。 DID 中的方法將定義您正在使用的那些方法，並且您應該知道使用 DID 獲取 DID Documents 的協議。 如果您聽說 **解析器(resolvers)** ，這只是查找 DID 的協議的通用術語，**通用解析器(universal resolver)** 可以通過任何方法查找 DID。

## 可驗證的 Claims

圍繞 DID 的大多數對話以及它們如何被使用，似乎是可驗證的聲明 (verifiable claims)。 可驗證 Claims 通常有三部分：

* **Subject**：可能是一個使用者（像你一樣），但它可能是公司，寵物或其他任何可以描述的東西
* **Issuer**：可能是某種組織，如DMV，大學，銀行等。
* **Claim**：任何可以作出的陳述，通常是關於人的例子，包括 **超過21歲**，**住在這個地址......** 或 **有這個名字** 之類的東西。 可以是任何描述性陳述。

因此，可驗證的 claim 是指某些 Issuer 就某一 Subject 提出 Claim。 **可驗證** 部分是它值得信賴和防篡改，因為它已由 Issuer 加密簽名。

(可驗證的 claim 範例（來自 W3C 可驗證 claim 規範）)

請注意，可驗證的 claim 只是一個 JSON 文件，規範只定義資料模型。 沒有特定的協定來記錄從一方到下一方的文件。 可驗證 claim 規範定義了另外兩個角色：

* **Holder**：接收並持有可驗證 claim 的人，可能是某個 Issuer 獲得可驗證 claim 的使用者（如您）。
* **Inspecter-Verifier**：可能是某種類型的服務，如 Facebook 或 BevMo，它接收可驗證的 claim 並將其用作其服務的一部分。

(可驗證 claim 中的各種參與者（來自W3C可驗證聲明規範）)

或許通過一個例子可以幫助澄清這些術語。假設我想從 BevMo 購買酒，BevMo 想知道我是 21 歲還是超過 21 歲。 我將使用 DMV（發行人）的可驗證 claim，該聲明稱 Adam Powers（Subject）已超過 21 歲（claim）。 我將從 DMV 下載可驗證的 claim documents（Adam Powers 現在是 Holder）並將其上傳到 BevMo（Issuer-Verifier）。 BevMo 將驗證 claim，然後允許我購買酒。

這個例子中有一些有趣的點值得強調：

1. 現在我正在下載一堆可驗證的 Claim，我必須弄清楚如何管理它們。 為此，還有 [Credential Handler API](https://w3c-ccg.github.io/credential-handler-api/)，它允許使用者創建可驗證 Claim 的線上錢包，並在不同的服務中輕鬆使用它們。

2. DMV 的主張是我 **超過21歲** 而不是我的生日。 兩者都可以讓BevMo 做出同樣的決定，但是我的生日會給 BevMo 詳細的信息，這可能會讓他們侵犯我的隱私。 例如，我的生日（與我的名字相結合）可用於唯一地識別我並在服務之間共享有關我的信息。

<font color="ff0000">
上面的示例也沒有說明 BevMo 如何驗證聲明。 請注意，可驗證 Claim 中的 id 是一個 URI，在上面的示例中，它是指向 http://example.gov/credentials/3732 的 URL。獲取此可驗證 Claim 的公鑰是在外部 可驗證 Claim 規範的範圍，因此由Inspector-Verifier 知道在哪裡獲取該公鑰; 但是，應該注意 DID 也是 URI 的一種形式。可以想像可驗證 Claim 的 Issuer 使用 DID作為 URI，使 Issuer-Verifier 能夠將該 DID 解析為包含其公鑰的DID documents。
</font>

我們還跳過了可驗證 Claim 中非常重要的一點：Issuer 如何知道 Holder 有權要求 Claim？ Inspector-Verifier 如何知道 Holder 與 CLaim 中的 ID 相關聯？

(可驗證 CLaim 需要身份所有權（來自 W3C 可驗證 Claim 規範）)

為此，有基於 DID 的授權，稱為 DIDAuth。

## DIDAuth
DIDAuth 的細節仍在不斷湧現，規範仍在整合中。 最近的工作來自Markus Sabadello，他目前正在整理[範例和架構列表](https://github.com/peacekeeper/rebooting-the-web-of-trust-spring2018/blob/master/draft-documents/did_auth_draft.md)。

在它的核心，DIDAuth 是一種 **質詢-響應** 身份驗證協定：您登錄的服務發送隨機質詢，您使用私鑰進行簽名，然後將質詢，簽名和 DID 發送回服務器。

(DIDAuth 的概述（來自 Sabadello 等人的即將發表的論文）)

接收 DIDAuth 響應的服務可以通過將 DID 解析為 DID Documents 並使用該 Documents 中的公鑰來驗證挑戰上的簽名來驗證用戶是否與提供的 DID 相關聯。

## DID 的經濟學
有了這個技術概述，我們現在可以深入探討有關 DID 的更多令人興奮的問題，例如：

* DID 解決了哪些問題以及如何解決這些問題？
* DID 需要區塊鏈嗎？ 現有技術可以實現相同的目標嗎？
* 誰將受益於 DID？

當我與 Disney，SONY 影業等人合作時，我最喜歡的一本書是[娛樂產業經濟學](https://www.amazon.com/dp/B008P91ZT8)，它描述了娛樂業如何做出決策。 遵循同樣的精神，我認為值得從經濟角度審視 DID 生態系統。 這涉及識別參與 DID 的生產，分配和消費的利益相關者以及他們做出的理性決策。 請注意，我是一個不是經濟學家的技術人員，所以希望這種分析不會冒犯任何經濟學家。

請注意，這是事情可以引起爭議的地方，人們對我即將討論的事情有很強烈的感受。 請記住，在本文開頭我說過我會嘗試保持中立和客觀。 如果我事實上歪曲了任何事情，請告訴我。

DID 生態系統中的角色似乎是：

* **User**：DID 的 Holder 和可驗證 Claim 的 Subjects 和主體
* **Service Provider**：充當 Claim 的 Inspector-Validators 的網站，mobile apps 和平台。
* **Claim Issuer**：提供有關任意數量主題的 Claim 的政府機構，公司和組織。
* **Technology Providers**：代表其他參與者建立 DID 生態系統所需的公司。

需要明確的是，這些類別在現實世界中並不明顯：像 Google 和Facebook 這樣的公司是 Service Provider，Clsim Issuer 和 Technology Providers; 政府機構（如DMV）經常充當 Service Provider 和 Claim Issuer。 這種分段仍然很有用，因為執行這些角色之一時的選擇可以推動共同決策。

我們可以從考慮 DID 使用者的觀點開始。

## DID Users
我們可以從 DID 使用者的角度和他們應該從 DID 接收的價值開始。 關於 DID 值的最常見的爭論是將控制權返回給用戶。 這可以有幾種不同的類型：

1. 控制 Identifier：今天常用的 identifier 包括電子郵件地址和域名。 不幸的是，這些是由第三方控制的，他們的利益可能與用戶不一致。 例如，電子郵件提供商可以撤銷或暫停電子郵件地址; 域名可能會被關閉或接管。 只要 DID 私鑰保持私密，用戶就可以控制其 DID。

2. 各種權威和聲明：目前很少有權威機構可以主張對人的主張。 示例包括駕駛執照，護照，社會安全號碼，學生證，銀行賬戶等 - 所有這些都可用於向第三方證明身份。 但是，控制這些 identifier 和權利要求的當局並非絕對可靠，並且擁有更多可以發布 Claim 的權威機構會圍繞identifier 和 CLaim 創建公開的市場競爭，希望提高 Claims 的質量和可用性。

3. 集中式身份提供商：今天，許多人使用 Facebook，Google，Twitter，GitHub 或其他身份提供商登錄第三方服務。 這為這些公司提供了令人難以置信的控制和洞察人們的生活。 通過使用 DID，用戶將不再依賴這些第三方帳戶。

4. 隱私控制：用戶經常無法控制他們的數據或共享數據。 集中帳戶的一個方面是用戶必須與公司共享許多私人信息，否則他們可能不會選擇共享。

讓我們依次考慮每一個，看看 DID 是否以及如何實現這些目標。

首先，用戶可以控制其唯一 identifier。 通過使用區塊鏈作為基礎技術，分類賬演算法可以防止那些有訪問權限和控制權進行更改的干擾。 即使當局要求對分類賬進行變更，負責管理分類賬的人也不可能做出這些變更。

對此的後續問題是：對 identifier 的控制真的重要嗎？ 丟失電子郵件地址或域名的例子不是大多數人可以聯繫到的事情; 然而，在專制政權中，撤銷 identifier 會使記者或自由尋求者沉默，控制 identifier 可能會產生重大影響。

第二，DID 會為使用者提供各種權限和 Claim 嗎？ DID 的一個主要論點似乎是當局脆弱和腐敗，提供 identifier 和 Claim 的政府機構過度信任和過度授權。可驗證的 Claim 似乎有更多權威機構出現的承諾，最有可能以商業實體的形式出現（注意：這看起來像行動貨幣 **wakala** 的類似願景，作為 Tigo Pesa，Mpesa 和其他提供商的代理商）。

目前還不完全清楚這一願景是否會成真。 我想不出很多經濟體系，特別是在已開發國家，它們在很長時間內仍然存在很大程度上的支離破碎。 看起來營銷，網絡外部性，收購等將導致市場匯聚到僅提供 Claim 的少數商業機構。 如果這成為現實，那麼大型商業機構和 Claim 提供商對使用者來說會更好是不明白的 - 也許這是一個關於是否更信任政府或商業實體的觀點。

三，使用者將受益於不被鎖定為充當其身份提供者的大型服務。 這似乎是一個特別有問題的論點：幾乎所有服務都可以立即設置 OAuth 或OpenID Connect 並充當身份提供者，因此它似乎不會阻止更多商業身份提供商。 相反，用戶似乎已經根據他們使用服務的頻率以及他們對服務提供商的信心來選擇他們的身份提供商，從而將他們帶到通過其他方式變得更大的公司。

第四也是最後，DID 讓使用者可以控制他們的隱私。 DID 從根本上改變了用戶的隱私並不完全清楚，因為使用者已經可以控制他們向哪些服務提供商提供的信息。 服務提供商經常要求用戶提供比必要更多的信息，並且 DID 沒有任何限制可以限制使用者所需信息的數量，範圍或細節。

另一個隱私問題是跨服務的使用者信息的連接能力。 如果 DID 可能阻止使用者提供詳細信息（如姓名和生日），那麼 DID 將承諾減少服務之間發生的侵犯隱私的數據共享量。 此外，創建新 DID 的低成本和高可靠性使得更容易確保不使用唯一 identifier（例如電子郵件地址或社會安全號碼）來跨服務連接使用者。 事實上，一些 DID 實現建議為每個服務創建一個新的 DID（稱為 **成對 DID**），以幫助加強這種隱私。 成對 DID 不是絕對保護，但它是朝著隱私頻譜改善隱私的一個漸進步驟。

## DID Service Providers
服務提供商面臨的當前決策是：1）他們是否應該實施基於 DID 的身份和身份驗證; 2）如果他們實施基於 DID 的身份，他們會接受什麼樣的聲明。

服務提供商採用 DID 的最佳理由可能是圍繞風險轉移。 通過使用 DID，身份證明的風險，Claim 的有效性等轉移回使用者和 Claim Issuer。 由於這些 claims 在加密方面是可驗證的，因此服務提供商有一個強烈的論據，即如果 claims 最終出錯，他們就有理由相信 claims。 此外，使用可驗證 claims 為服務提供商提供了不保留 claims 數據，減少其暴露於 GDPR 以及其他數據和隱私風險的選項。

如果服務提供商選擇與 DID 生態系統整合，那麼最困難的挑戰似乎是選擇他們將接受的權限和 Claim。 與大量 Claim 提供商整合對於使用者來說可能更方便，但可能需要圍繞理解索 Claim Issuer 的質量，與 Issuer 建立法律關係以及可能開發不同提供商的技術接口方面的大量工作。

## Claims Issuers
如果使用者和服務提供商選擇採用 DID，那麼 Claim Issuer 就沒有理由不啟用生態系統。 通過向系統提供可加密驗證的 Claim，使其便於將它們傳輸給任意數量的範例，Claim Isssuer 只會增加其影響力和它們提供的 Claim 的價值。

## DID Technology Providers
DID 生態系統中的最終參與者是構建區塊鏈，身份管理系統，身份驗證系統等的技術提供商。一些技術提供商熱衷於支持 DID，因為他們相信它為用戶提供的價值，但是也是為了建立一個新市場的豐厚回報。

事實證明，其他技術提供商對 DI D生態系統持懷疑態度。乍一看，似乎DID 正在對現有技術表現良好的新技術進行大量投資：區塊鏈的功能可以由 PKI 執行;可驗證的聲明可能只是 JSON Web token（JWT）之上的新數據模型;使用者信息的交換可以通過 OpenID Connect 進行，特別是使用它的 Discovery 和 UserInfo 機制。

擺脫現有技術不僅僅是虛榮和/或浪費精力的問題。現有技術已經知道通過多年的成熟和第三方研究已經建立的安全和隱私模型。放棄已知技術會帶來一些新的風險，某些市場可能難以採取。

了解現有技術是否能夠實現與DID相同的結果是未來工作的領域之一。

## 未來的工作
對 DID 有很大的熱情，技術和生態系統正在迅速發展。 W3C 憑證社群小組圍繞 DID，其用例以及已開發的規範的未來進行了非常積極的對話。 大部分談討論仍在進行中，並不完全清楚 DID 的採用將如何發揮作用; 然而，這是一種有趣的身份和 identifier 方法，值得觀察。