# Decentralized identifiers (DIDs) 分散式身分識別
###### tags: `Blockchain`
## DIDs 概述
* DID Documents 是一個 JSON-LD物件
* ID 將是一個永久且不可改變的 (符合區塊鏈帳本的特性_DLT)

#### 隨著科技的發展生活中越來越多是可以透過網路完成，不論是線上訂餐、網路商城購物還是信用卡申請，使用者只需依照網頁的要求，逐步填寫相關資料即可，但近年來由於個資外洩引發的事件越來越多，使得使用者們更加關注個人資料的隱私議題，由於許多個資外洩事件往往是由持有用戶資料的廠商保管不當所引起，因此近年來資料的使用權逐漸傾向於由使用者自行掌握，進而衍生出「去中心化身分識別(Decentralized Identifiers, DIDs) 技術」，讓使用者在不透漏過多私密資訊的同時，也能達到身分識別的目的，藉此減少個人資料暴露的風險。
#### 去中心化識別的最終目標為讓使用者能全權掌控資料，保護該資料的隱私，相較於過往使用者將資料交由中樞管理者，減少了資料使用權限、資料歸屬等衍生議題。去中心化識別技術可應用在區塊鏈技術上，不論是公有鏈、私有鏈、聯盟鏈皆可使用。因此全球資訊網協會(W3C)訂定了DIDs資料格式、資料型態等相關規範。

### DIDs 設計目標
| 目標 | 描述 |
| -------- | -------- |
| Decentralization | 去除中心化的單一節點身分識別管理，包含註冊一組獨一無二的身分ID、公開驗證密鑰。 |
| Control | 賦予直接控制數位身分的權限，而不需透過外部的權限。 |
| Privacy | 能夠控制資訊的隱私，包括其屬性或其他數據的最小性、選擇性和逐步公開。 |
| Security | 提供足夠的安全性，使依賴DID Documents可以獲得所需的分級保證。 |
| Proof-based | 與其他實體在互動時，DID Subjects可以提供加密證明。 |
| Discoverability | 可以發現其他實體的DID，進而了解更多實體與實體間互動的資訊。 |
| Interoperability | 提供一套可互動的標準，使DID基礎結構可以利用現有的工具和函式庫設計這套標準。 |
| Portability | 實體能夠在支持DID和DIDs的任何系統上使用數位身分，而不受到系統和網路的影響。 |
| Simplicity | 傾向於簡易的功能，使這項技術更容易理解、實作和部屬。 |
| Extensibility | 當啟用擴展性時，不會大幅影響Interoperability、Portability and Simplicity。 |

## DIDs 重要角色
* **Verifiable Claims:** 一種具備可被驗證性的聲明文件。
* **DID Authentication:** 一種**質詢-響應**的身份驗證協定。
* **User:** DID 的 Holder 和可驗證 Claim 的 Subjects 和主體。
* **Service Provider:** 充當 Claim 的 Inspector-Validators 的網站，mobile apps 和平台。
* **Claim Issuer:** 提供有關任意數量主題的 Claim 的政府機構，公司和組織。
* **Technology Providers:** 代表其他參與者建立 DID 生態系統所需的公司。
### 可驗證聲明(Verifiable Claims)
可驗證claim 只是一個 JSON 文件，規範只定義資料模型。 沒有特定的協定來記錄從一方到下一方的文件。 可驗證 claim 規範定義了另外兩個角色：
* **Holder:** 接受並持有verifiable claims的人，可能是某個**Issuer**獲得verifiable claims的使用者。
* **Inspecter-Verifier:** 某種類型的服務，接收verifiable claims並且作為服務的一部分。

(可驗證 claim 中的各種參與者（來自W3C可驗證聲明規範）)
#### Claims 分為三部分:
* **Subject:** 可以是一個使用者或公司‧‧‧寵物等任何可以描述的東西
* **Issuer:** 可以是某種組織。例如:大學、銀行、協會等。
* **Claim:** 任何描述性的陳述，通常是關於人的描述，例如**年紀幾歲，住在哪個地址或暱稱**等等。

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

#### 補充說明 (以成年人購買酒為例)
假設我想從 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/)，此API允許使用者創建可驗證 Claim 的線上錢包，並在不同的服務中輕鬆使用它們。
2. DMV 的主張是我**超過21歲**而不是我的生日。 兩者都可以讓BevMo 做出同樣的決定，但是我的生日會給 BevMo 詳細的信息，這可能會讓他們侵犯我的隱私。 例如，我的生日（與我的名字相結合）可用於唯一地識別我並在服務之間共享有關我的信息。

:::danger
上面的示例也沒有說明 BevMo 如何驗證聲明。 可驗證 Claim 中的 id 是一個 URL，在上面的示例中，它是指向 *http://example.gov/credentials/3732* 的 URL。獲取此可驗證 Claim 的公鑰是在外部 可驗證 Claim 規範的範圍，因此由Inspector-Verifier 知道在哪裡獲取該公鑰; 但是，應該注意 DID 也是 URL 的一種形式。可以想像可驗證 Claim 的 Issuer 使用 DID 作為 URL，使 Issuer-Verifier 能夠將該 DID 解析為包含其公鑰的DID documents。我們還跳過了可驗證 Claim 中非常重要的一點：Issuer 如何知道 Holder 有權要求 Claim？Inspector-Verifier 如何知道 Holder 與 CLaim 中的 ID 相關聯？
:::

:::warning
上述還跳過了可驗證 Claim 中非常重要的一點：Issuer 如何知道 Holder 有權要求 Claim？ Inspector-Verifier 如何知道 Holder 與 CLaim 中的 ID 相關聯？
:::
(可驗證 CLaim 需要身份所有權（來自 W3C 可驗證 Claim 規範）)

### DID Authentication
#### Overview of DID Authentication
An overview of DIDAuth (from the forthcoming paper from Sabadello, et al.)

### Users
我們可以從 DID 使用者的角度和他們應該從 DID 接收的價值開始。 關於 DID 值的最常見的爭論是將控制權返回給用戶。 這可以有幾種不同的類型：
#### 四種類型
1. 控制 Identifier：今天常用的 identifier 包括電子郵件地址和域名，這些是由第三方控制的，他們的利益可能與用戶不一致。 例如，電子郵件提供商可以撤銷或暫停電子郵件地址；域名可能會被關閉或接管。只要 DID 私鑰保持私密，用戶就可以控制其 DID。
2. 各種權威和聲明：目前很少有權威機構可以主張對人的主張。示例包括駕駛執照，護照，社會安全號碼，學生證，銀行賬戶等 - 所有這些都可用於向第三方證明身份。 但是，控制這些 identifier 和權利要求的當局並非絕對可靠，並且擁有更多可以發布 Claim 的權威機構會圍繞identifier 和 CLaim 創建公開的市場競爭，希望提高 Claims 的質量和可用性。
3. 集中式身份提供商：許多人使用的 Facebook，Google，Twitter，GitHub 或其他身份提供商登錄第三方服務。 這為這些公司提供了令人難以置信的控制和洞察人們的生活。通過使用 DID，用戶將不再依賴這些第三方帳戶。
4. 隱私控制：用戶經常無法控制他們的數據或共享數據。集中帳戶的一個方面是用戶必須與公司共享許多私人信息，否則他們可能不會選擇共享。

### Service Providers
服務提供商面臨的當前決策是:
1. 他們是否應該實施基於 DID 的身份和身份驗證?
1. 如果他們實施基於 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 的價值。

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

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

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

了解現有技術是否能夠實現與DID相同的結果是未來工作的領域之一。
## DIDs 規範
#### DID Document 可能包括以下內容:
* 唯一的ID Ex: "did:example:123456789abcdefghi"
* 創建時間的時間戳記
* DID Documents 有效的加密證明
* 加密公鑰列表
* DID 可用於進行身份識別的方式列表
* 可以使用 DID 的服務列表
* 任意數量的外部定義延伸

### DID Document 基本範例
DIDs的架構可以被想成是一個全球性的key-value資料庫，每個key會對應到一筆資料，而這些資料被稱為DID document，其中包含了證明身分的相關資訊，像是公鑰、生物識別碼等不同屬性的資料，同時可以證明DIDs與其擁有者的關聯。DID document是基於圖形化結構的資料，常使用 JSON-LD的格式進行儲存，當中可包含DID本身、加密資訊、加密協定、服務終端、時間戳記、JSON-LD簽章等資訊。

### DIDs 四大核心
1. 持久的身分識別碼
2. 可分辨的身分識別碼
3. 具有加密可驗證的身分識別碼
4. 分散式的身分驗證碼

### DIDs、URLs和Email addresses的比較

| 屬性 | URL | Email | DID |
| -------- | -------- | -------- | -------- |
| 永久性 |:x:|:x:|:heavy_check_mark: |
| 可分辨性 |:heavy_check_mark:|:x:|:heavy_check_mark:|
| 加密可驗證性 |:x:|:x:|:heavy_check_mark:|
| 分散式 |:x:|:x:|:heavy_check_mark:|
| 人性化 |:heavy_check_mark:|:heavy_check_mark:|:x:|

### DID的ID設計規定
根據定義DIDs須包含DID Scheme、DID Method、DID Method Specific String三個部分，其中DID Scheme為DIDs的通用格式，針對不同方法定義了不同的格式；DID Method表示該DID Scheme是以何種方式運行在區塊鏈或網路上；DID Method Specific String是由DID Method所產生出的識別符號，在所產生的集合中不與其他識別符號重複。
#### URNs(Uniform Resource Names, RFC 8141)

#### DID example

DIDs的架構可以被想成是一個全球性的key-value資料庫，每個key會對應到一筆資料，而這些資料被稱為DID document，其中包含了證明身分的相關資訊，像是公鑰、生物識別碼等不同屬性的資料，同時可以證明DIDs與其擁有者的關聯。DID document是基於圖形化結構的資料，常使用 JSON-LD的格式進行儲存，當中可包含DID本身、加密資訊、加密協定、服務終端、時間戳記、JSON-LD簽章等資訊。

#### DID document
由於DIDs的設計結構使得其擁有高度隱私性，在設計上共有三個特性:
1. Pairwise-pseudonymous DIDs
　　DIDs可以使用常見的公開識別符號(如姓名及學號)，同時也可以使用定義的其他字串，因此每個人可以擁有許多不同的DID，使得資料與使用者難以被直接關聯，同時也方便使用者管理。
2. Off-chain private data
　　若將資料放在區塊鏈或網路上會增加資料曝光的風險，因為所有人皆可對資料進行存取，即使是經過加密的資訊仍然有被破解的風險(使用量子電腦破解)，因此將資料存放在本地端，並只透過安全、經過加密的通道進行傳輸。
3. Selective disclosure
　　使用加密過的文字或零知識證明當作資料共享時的依據，有效管理資料傳輸對象，同時利用最少的資訊達到識別身分的目的，藉此減少資料曝光的風險。

## 未來發展
#### 由於網路服務的盛行，導致網路上的數位身分辨別有很大的需求和進步空間，為了解決中心化管理數位身分的安全問題，以及中心化的點對點驗證方式有許多安全及效率的問題，DIDs的設計是基於區塊鏈的技術概念上，以分散式的驗證、資料同步的方式解決現有的問題，因此DIDs在未來勢必是有很大的需求。
#### 目前DIDs的設計規範還不夠完整，例如：DIDs的長度是沒有上限的，相較於互動性最高的URL長度約為2K個字符，而QR Code則是4K個字符。此作法會導致DIDs的使用者儲存成本提高，因此DIDs未來的規範應在DID字符上設置合理的限制。
#### W3C憑證社群小組圍繞 DIDs，其開發的規範的未來進行了非常積極的對話。 大部分談討論仍在進行中，並不完全清楚 DIDs 的採用將如何發揮作用; 然而，這是一種前瞻性數位身分辨識的方法，因此DIDs規範十分值得關注。

### Keyword
#### Blockchain
一種Distributed ledger technology (DLT)，將所有交易經加密組成一個Block，由每個Block串起來成一個帳本，形成一個區塊鏈系統。而Bitcoin就是這個系統的最佳範例。

#### distributed ledger (DLT)

#### decentralized identifier (DID)

#### decentralized identity management

#### DID controller

#### DID document

#### DID fragment

#### DID method

#### DID path

#### DID query

#### DID registry

#### DID resolver

#### DID scheme

#### DID subject

#### DID URL

#### extensible data interchange (XDI)

#### JSON Pointer

#### public key description

#### service endpoint

#### Uniform Resource Identifier (URI)

#### verification method

#### Universally Unique Identifier (UUID)