Juin Chiu｜作者介紹

內容目錄

Toggle

Juin Chiu

Unitychain 首席研究員 / Taipei Ethereum Meetup 共同組織者。研究領域為共識協定安全性分析 / 區塊鏈分片技術 / 去中心化身份 等。

什麼是自主身份(Self-sovereign Identity)？如何利用分散式帳本實現自主身份？

前言

每個人都有過回答「你是誰」這個問題的經驗。最近一次被問到「你是誰」時，你是怎麼介紹自己的？是回答姓名與職稱？或是身分證字號？還是某活動的報名序號？當我們在嘗試回答「你是誰」的時候，也正在定義我們的身份。身份會因情境不同而不同，有時是姓名，有時是身分證字號，也有時是某個臨時編號。

筆者將於這篇文章簡介：數位身份如何演變成現在的形式？什麼是自主身份？如何於分散式帳本之上實現自主身份？

什麼是數位身份(Digital Identity)？

數位身份就是以數位形式表現與儲存的身份。自全球資訊網被發明以來，數位身份便跟著開始發展直到今日。網站域名、電子信箱、社群帳號等等都是數位身份的一種。我們的日常生活離不開數位身份的使用：上社群網站發文、訂演唱會門票、上 PTT 看廢文、用 GMail 聯絡公事、用線上課程進修、用雲端硬碟備份資料等等。幾乎可以說沒有數位身份，就沒有現代便利的生活。

根據這篇 2016 年的文章，自主身份出現之前，數位身份的發展大致可以分為三個階段：

第一階段：中心化身份(Centralized Identity)

數位身份第一次隨著全球資訊網的流行而有了大量的需求。如雨後春筍般冒出來的各種網站顯露了一個迫切的問題：要怎麼證明你正在瀏覽的網站是可信任的？一個直覺的思路是：我們可以對可信任的網站域名頒發憑證(Certificate)。那麼由誰來頒發？由於頒發憑證的機構必須是具有公信力的機構，因此憑證機構(Certificate Authority, CA)被設立，負責域名的審核與憑證的頒發。自 1995 年發展至今，憑證機構現在仍是 Https 的骨幹。

然而，CA 是中心化且階層化的(Hierarchical)：根 CA(Root CA)頒發憑證給次級 CA，次級 CA 再頒發憑證給更次級的 CA，更次級的 CA 可以頒發憑證給註冊某域名的網站，擁有憑證的域名則可以讓用戶信任，使用戶願意於此域名註冊身份。在這樣階層化的架構下，一個用戶的身份可以一直往上追朔到根 CA，也就是說，根 CA 是身份的根基。

由此可知，這樣的數位身份非常依賴可信的根憑證機構，且用戶的身份完全掌控於註冊身份的域名擁有者，隨著使用服務的增長，一個用戶可能必須同時在數十個服務註冊身份，身份變得破碎而脆弱。

第二階段：聯合身份(Federated Identity)

為了解決身份的破碎，一個直覺的思路是：讓身份由數個組織組成的聯盟共同管理，於聯盟中任一個域名註冊的身份都可以在聯盟中通用，其中一個例子就是由昇陽(Sun)主導的自由聯盟(Liberty Alliance, 2001)。聯合身份雖然稍微解決在聯盟之間身份破碎的問題，但是於聯盟之外的身份仍然是破碎的，且身份仍由服務提供者掌控。

第三階段：以用戶為中心的身份(User-Centric Identity)

這就是我們目前所在的階段：讓不同服務、不同聯盟的身份互通以及給予用戶更多對身份的掌控，是此階段的目標。若要使某一服務的身份可以在多個服務之間通用，則各家服務需要共同制定同一套規格以跨服務驗證身份。重視用戶允許(User Consent)與互通性(Interoperability)的結果使用戶成為了身份的中心。用戶可以自行決定是否要從一個服務分享自己的身份至另一個服務，防止數位身份的破碎。例如 OpenID(2005) / OAuth (2010) / FIDO (2013) 這些開發者熟知的驗證(Authentication)協定就是遵循此原則的產物。

雖然用戶對身份擁有更多掌控以及有更好的互通性，但用戶對於中心化服務的依賴程度卻更勝以往，導致服務商擁有「濫用」用戶隱私的權力，例如以廣告營收為主要獲利來源的企業，可以在不經用戶同意下便使用或販售用戶資訊，用戶隱私有受到侵犯的風險。

身份的價值與厚度來自社交行為與頻繁的互動，在完全理想(例如非數位)的場景下，身份應當是一個整體，並能依據情境不同而揭露不同資訊，正如同當我被詢問「我是誰」時，我可以依照情境的不同給予不同的身份證明。

然而，我們當今使用的數位身份既脆弱也無法表達身份的厚度。那麼要如何實現一個不受任何中心化服務掌控的身份呢？這個問題的答案一直到最近才出現 — 分散式帳本就是實現自主身份的最後一塊拼圖。

什麼是自主身份(Self-sovereign Identity)？

自主身份就是用戶可以完全掌控且於任何服務之間互通使用的數位身份。自主身份與當今的數位身份不同 — 自主身份錨定於分散式帳本，不被任何中心化服務掌控。分散式帳本使數位身份具備下列特性，且正是這些特性保證了數位身份的自主性：

• 存在性(Existence)
  

  中心化服務可以隨時竄改數位身份的存在；分散式帳本則使身份能以去中心化識別符(DID)的形式錨定在其上且保護其不受篡改。

• 掌控性(Control)
  

  中心化服務可以完全掌控數位身份；分散式帳本使用數位簽章，掌控私鑰即掌控身份，且私鑰由用戶自行保管。

• 存取性(Access)
  

  中心化服務可以輕易限制身份存取；分散式帳本是複製狀態機，用戶可以於任一節點隨時存取身份。

• 透明性(Transparency)
  

  中心化服務多為閉源專案；分散式帳本大多為開源專案，用戶可以掌控軟體運作的細節。

• 持續性(Persistence)
  

  中心化服務有服務中斷的風險；分散式帳本多由受到經濟激勵的節點共同維護，不易中斷服務。

自主身份的技術架構

Overview of Self-sovereign Identity

數位身份由識別(Identifier)、驗證機制(Authentication)、憑證(Credential)這三個要素組成。自主身份除了這三個要素，還具備了第四個要素：私鑰與資料管理機制(DKMS)，這是由於自主身份使用數位簽章而有管理私鑰的需求。

自主身份並不是全新的發明 — 許多技術的思路基本上沿用了現有的規格，自主身份真正的創舉在於制定一套通用規格：去中心化識別符(Decentralized Identifier, DID)，使身份能夠以同一標準錨定於不同分散式帳本並且互相通用。

自主身份的四個要素之間具有如上圖所示的關係，這些要素形成一個堆疊(Stack)的架構：最底層的 #1 負責身份的錨定；第二層的 #2 需要和底層的分散式帳本互動及負責用戶資料與私鑰的儲存；第三層的 #3 則需要使用第二層的資料以進行用戶身份的驗證；成功完成驗證後，最頂層的 #4 則可以發送各種憑證以表明用戶的身份。這種上層依賴下層且同層之間互通的架構類似 TCP/IP 的七層網路協定 — 各層具有各自的協定與規格，且各層之間的運作細節是抽象的。

哪些組織在推動自主身份？

由於自主身份需要一系列協定的緊密配合，因此自主身份的進展有賴於統一的規格與設計良好的協定，這需要由業界組成的非營利組織共同推動與維護。目前有許多非營利的組織都在自主身份領域持續貢獻，例如：

• 重啟信任網路
  (Rebooting Web of Trust, RWoT)
• 全球資訊網協會的憑證社群組
  (W3C Credential Community Group, W3C CCG)
• 去中心化身份基金會
  (Decentralized Identity Foundation, DIF)
• 網際網路身份工作坊
  (Internet Identity Workshop, IIW)

這些組織在近 3 年來都有非常豐碩的產出。其中最活躍的應該就屬 RWoT：自 2016 年開始啟動以來，RWoT 發表超過 40 篇的論文、技術規格與開源程式碼；RWoT 孕育的技術規格也進一步提案給 W3C 或者 IETF 以進行標準化；DID 規格草稿有一大部分是奠基於 RWoT 的工作成果；甚至連「自主身份」這個詞彙也是在 RWoT 被創造的。

實現自主身份的技術規格

那麼自主身份架構中的各層是如何運作的？筆者接下來針對各層使用的規格做概述。

1. 去中心化識別符(Decentralized Identifier, DID)

Decentralized Identifier

DID 是自主身份技術架構中最底層、也是最關鍵的一層 — 它負責身份於分散式帳本的寫入/讀取，其對於識別符的格式以及解析方法都有明確的定義，下列簡述幾個重要的部分：

• DID(Decentralized Identifier)
  

  DID 是一個由數字與英文字母組成的識別符，其是唯一的且映射至一個位於某個帳本的 DID 文件。DID 由三個部分組成：格式(scheme)、DID 方法(DID Method)以及 DID 方法特化字串(DID Method-specific String)。DID 方法將於下一點闡述；DID 方法特化字串的產生方式則需於 DID 方法的規格中明確定義。

• DID 方法(DID Methods)
  

  為位於 DID 中的一組字串，功能為區分每個 DID 的解析方式 — 每一種帳本都有專屬該帳本的 DID 方法，且其對應位於該帳本之 DID 文件的創建/解析規則。例如註冊於以太坊的 DID 會是像 did:eth:12345 這樣的形式。DID 方法需要向 W3C 註冊以被解析器辨識。

• DID 文件(DID Document)
  

  分散式帳本可以被想像成一個鍵值資料庫(Key-value Database) — DID 是鍵值，它所對應的內容就是寫入分散式帳本的 DID 文件(DID Document)。DID 文件包含：代表身份的公鑰、驗證協定、能與此身份互動的的服務終端等等。

• DID 解析器(DID Resolver)
  

  協助更上層協定便於查詢 DID 文件，解析器能夠針對不同的 DID 方法進行解析，再將解析結果返回上層，上層協定不需要理會關於文件解析的細節。DIF 針對解析的需求開發了通用解析器(Universal Resolver)，如此該解析器只需要部署一次，日後若有新的 DID 方法被註冊，只需針對該方法進行擴充即可。

2. 去中心化私鑰管理系統(Decentralized Key Management System, DKMS)

DKMS Architecture

DKMS 是用戶使用自主身份的主要介面，除了與底層的 DID 連接之外，還需提供憑證的儲存、私鑰的備份等等，任務相當多元。規格上來說，DKMS 可以再細分成三個子層：

• DID層(DID Layer)

  負責與更底層的分散式帳本連結以執行 DID 查詢。

• 雲端層(Cloud Layer)

  負責儲存用戶的個人資料供上層協定使用，例如可驗證憑證。

• 邊緣層(Edge Layer)

  負責管理私鑰，同時也是讓用戶可以使用自主身份的去中心化應用程式(DApp)。

3. DID 驗證(DID Authentication)

Overview of DID Authentication

目前仍尚未有任何準備成為通用標準的 DID 驗證規格的提案，只有一份 RWoT 的文件深入探討了驗證流程。DID 驗證的任務只有一個：就是讓用戶證明自己擁有某身份 — 用戶只要證明自己擁有跟某個自主身份公鑰匹配的私鑰即可。進行驗證後便能使不同個體之間建立可信任且更長久的通訊管道，以利更上層協定交換其他資料，例如可驗證憑證。

現今存在許多行之有年的驗證方式，例如 OAuth / OpenID 等等。類似這些驗證方法，DID 驗證也使用挑戰-回應循環(Challenge-response Cycle)進行驗證：驗證者發出挑戰，身份擁有者根據挑戰作出回應，驗證者再檢驗回應是否有效。至於挑戰的形式則沒有明確的定義，不過我們一定都有回應挑戰的經驗— 我們在登入某帳號前都必須輸入的帳號密碼就是其中一種挑戰的方式。

4. 可驗證憑證(Verifiable Credential, VC)

Overview of Verifiable Credential

VC 是自主身份架構中發展最早、也是最成熟的規格。作為自主身份架構最頂層的協定，它只有一個目的：取代用戶皮夾裡的所有證件。VC 是基於密碼學的數位憑證，可在不同應用程式間通用，它讓身份回歸到最理想的狀態：身份是完整的且完全受用戶掌控的，用戶可以依照情境的不同而揭露不同的憑證。由於所有自主身份都能發行與保存憑證，也就沒有身份破碎的問題。

VC 包含三個部分：

• 斷言(Claims)

  為關於主體的一段陳述，表示[主體 — 性質 — 內容]之間的關係，例如：[小明 — 學生 — 有間學校]代表小明為有間學校的學生。

• 憑證後設資料(Credential Metadata)

  為有關憑證的其他資訊，例如類型、發行者、發行時間等等。

• 證明(Proof)

  為發行者對憑證內容的數位簽章。

在使用 VC 揭露身份時，要如何避免不會暴露過多的隱私？可驗證陳述(Verifiable Presentation)便是利用零知識證明(Zero-knowledge Proof)保護憑證的進階規格，細節容筆者於日後令撰文分析。

結語

本文用了相當多的篇幅在介紹自主身份的背景與發展脈絡。自主身份的發展雖然距今只有短短 4 年，卻已經有相當豐碩的成果，也能看到新的應用程式、協定、規格不斷推陳出新，生態系也趨於完整。但由於是相當新穎的領域，資訊經常散落在各處且缺乏脈絡，需要埋首於文件堆中才能偶然理出一些頭緒。期許這篇文章能夠幫助台灣的開發者快速掌握自主身份的精要。

原文連結

（本文經作者同意轉載，文內觀點皆代表原作者，不代表桑幣筆記 Zombit 立場）