Web 3＆How do the Identity Models evolve into Self-Sovereign Identity
Author：Kevin Lin, NTU ECON
Published on November 4th, 2022
前言
在 2022 的這個年度，Web 3 的相關話題被炒的火熱，舉凡元宇宙、NFT 等，一進到書局印入眼簾的少說就有個兩到三本，而市面上的書籍多以了解應用端為主，若想再深入點，就需要直切其本質了，而這正是我將要在這篇文中所嘗試的。
其實我們不妨想一想最普遍大家對於 Web 3.0 的定義就是多了一個 own，這也許還不夠嚴謹，讓我們去看看以太坊共同創辦人之一及 Polkadot 創辦人 Gavin wood 所創立的 Web 3.0 Foundation ，其官網內寫著對 Web 3.0 的定義。
Web 3.0, a decentralized and fair internet where users control their own data, identity and destiny.
那為什麼我會認為了解 Web 3 本質這麼重要呢？明明我們在 Web 2 的世界一知半解也過的很開心啊。這是因為 Web 3 真正在做的是 empower 群眾，若人們只關注自己的權利而忽略自己的義務，在如同西部拓荒的時期，這將會變成一場災難。
我想來想去後發現，所謂 Web 3 精神很大一塊根本就是在講自我主權身分（Self-Sovernign Identity, 簡稱 SSI）的理念。儘管 SSI 屬於其框架下，但大家在解釋 Web 3 時都習慣將兩者分開論述，並未直接點出中間的強關連性。因此希望先讓讀者了解更具體，且與生活較為相關的 SSI 想要傳達的價值，來讓大家可以更好地去理解更大、更抽象的 Web 3 究竟是何方神聖。
為達成上述目標，本文將在開頭簡介 Web 發展史，點出各個階段的差異，並探討由 Christopher Allen 在 2016 年撰寫的文章中所歸納出互連網降世以來的四個線上身分模型之間的轉變，搭配不同模型內身分認證演化的簡介，補充完上述廣為人知且廣泛受用的體系後，再帶到本篇的主角，也就是第四個模型── SSI，並概述實現其生態系的必要工具── DID（Decentralized Identifiers）。
正文
Web 發展史
首先，在 Web1 的時代，大多數用戶只有作為資訊的需求端而不是供應端，即只有單向接收而沒有互動環節，因此那時並沒有什麼驗證的問題，但是當來到大家最熟悉的 Web2 時，用戶們也能夠成為資訊的供給端，互動的關係開始出現，社群媒體也隨之蓬勃發展成為殺手級應用。
蠻神奇的一點是在 wikipedia 找到的 Web 2 定義內有提到去中心化是其最顯著的特點之一，因為內容不再是由專業網站或特定人群所產生，而是由全體網民共同參與。內容產製上的去中心化聽來覺得很棒很合理，但細想後就會發現這根本是個天大的謊言。在 Web 2 的系統下，你產出的內容，甚至是你經營的平台、粉絲社群根本就不屬於你，而是屬於平台方的（見下圖）。
反觀 Web 3 ，整體來說可以歸類為網路後端上的革新，以區塊鏈技術作為底層架構，改變過往數據儲存的方式，也因此具備區塊鏈的幾個大特性，包含公開透明、不可竄改及「真正的」去中心化，並將個人相關數據的所有權「物歸原主」。（比起去中心化，我個人偏好解釋為多中心化，因為我認為一昧強調去中心化會有種一竿子打翻一船人的錯覺，實際上中心化並不是罪惡，這邊我們應該要思考的是一項業務，乃至當中每個環節去中心化的必要性，如此才能在可行性及追求的願景間達成平衡。）
剛剛我們理解完不同階段 Web 本質上的差異，再來就要介紹四種身分模型及驗證機制的進程了。
數位世界的身分模型
我先將我們在數位身分模型上會遇到兩大的問題整理出來：
- 身分零碎，每個身分認證者間成為數據孤島（Data Silos），導致某些「跨島」的驗證場景效率低落。
- 在個人的身分管理上，只要還沒真正將身分自主權歸還給個人，就始終存有外包驗證的第三方風險（Third-Party Risk）。
第一點問題在後續推出的身分模型會被逐漸改善，但第二點的問題卻有被逐步惡化的趨勢，直到 SSI 的架構下才真正被妥善處理。
一、中心化身分（Centralized Identity）
隨著網站數量成指數型增長，用戶得在幾十個不同的網站上處理幾十個身份，這象徵著身分的日益分裂，且同時用戶還不曾擁有任何一個身分真正的控制權，第三方風險隱隱作祟。在這之下的驗證方式有著們熟悉的靜態密碼（可搭配 2FA）與單點登入等，下方一一說明。
靜態密碼
自從 Web 2 開起雙向互動的模式後，線上身分驗證的需求也隨之出現，最簡單的方法就是直觀的密碼登入，這種方式雖然簡單易懂，但也有對應的風險與缺點存在，例如網路釣魚攻擊（Phishing）、帳密填充攻擊（Credential Stuffing）又稱撞庫攻擊，或設置過於複雜則容易忘記，及多組密碼存取不易等問題（見下圖）。
每個人在不同的需求場景下，便需要到不同的網站去完成，人均管理的線上帳號數也不斷在成長，然而人終究是懶惰又健忘的生物，同時有這麼多帳號需要管理的下場就是只使用自己記得最清楚的一至二組密碼。
根據 Lastline 在 2018 年倫敦資安會議上調查相關從業人員的結果，有 45% 的受訪者承認他們會在不同的帳號使用相同的密碼，由此可見重複使用密碼是一個連資安相關的從業人員都避免不了的「惡習」，這樣不良的密碼衛生習慣（Password Hygiene）也往往是孳息網路犯罪的養分。
除了密碼最好不要重複之外，每個密碼的設定也是不能馬虎的，這是一件近乎常識的事情，許多人卻常常不以為意，不如就先從檢視你平常用來保管帳戶的密碼到底有多安全開始。
此處參考一份 2021 年由 Statista 發布的報告，以 10 碼的密碼全小寫的密碼為例，有心人士只需要 1 小時即可破解，要是有什麼重要個資外洩就麻煩了，有鑑於此，許多網站在密碼設定之初就強制規定要符合某些安全性的條件，例如必須含有至少一個大寫字母及數字，如此一來破解所需的時間瞬間提高到 7 個月的長度，某些網站甚至還會要求要再多一個特殊符號，筆者每次遇到這種都會默默按下忘記密碼，等同於每次登入都換密碼，防護力瞬間大增，近用服務的阻力卻也變大許多。
現在我們知道一件事，沒有完全破解不了的密碼，只有要花多久時間才能破解的密碼而已，就算是強度高的密碼，也可能被木馬與鍵盤側錄程式等手法竊取，又隨著資料的串流越來越頻繁，網路早已是生活不可或缺的一部分時，我們開始思考只有傳統密碼的體系好像並不足以應付我們對於資料保護的需求。
2FA（Two Factor Authentication）
於是，為了讓使用者有更高的安全性，便有了 2FA 的解方來加強，意即僅有正確的帳號密碼是無法完成登入的，還需要搭配第二項「驗證因素」才能通過整個驗證流程。 OTP（One-time Password，又稱動態密碼）便是其中一種常見的驗證因素，最原始的方式就是 6 位數的簡訊驗證短碼（SMS-based OTP)，後來也出現 Google Authenticator 這類 APP 的驗證方案。
搭配下圖解釋更好理解，對於使用者來說，密碼是 Something I Know，寄送到事先綁定設備上的簡訊驗證短碼是 Something I Have，這就是 2FA 兩層防線的設計理念。（此處的驗證因素也可是 Something I Am，如指紋、面部辨識或虹膜等生物特徵，這比較新穎，與我們稍後會提到 FIDO 聯盟的理念可以呼應。）
但實際上，SMS OTP 所附加的安全性備受質疑，美國國家標準暨技術研究院 NIST 更在 2016 年發表的數位身分驗證指南中更直接建議不要再使用此種驗證因素，並鼓勵多加使用 APP 形式的 OTP 或其他因子來替代。
儘管暫時先撇除安全性的問題，2FA 或 MFA（Multi-Factor Authentication）最大的痛點仍是不夠便利，多了一個驗證因子意味著登入的流程需要花費更多時間，個人或許感覺還好，但就企業端的角度來說，若每位雇員每次登入時都需要多花費 30 秒，長遠來看對公司整體來說就是個損失，而 SSO 就是為了使用戶有更好的登入體驗，不必頻繁輸入密碼。
單點登入 Single Sign on（SSO）
以往沒有 SSO 的情景下，用戶永遠不能跨站保持登入記錄，就算這些網頁都由同一個 domain 所管理。這聽起來就很麻煩吧！
SSO 的核心概念就是允許用戶使用一組憑據（Credential）訪問多個同網域（domain）的應用程式。以上圖為例，使用者只需要一組 Gmail 帳號及密碼即可登入 Google Calendar, Google Docs, Google Slides 等應用程式。
若將其應用於客戶及員工端，可達成以下好處：
- 簡化登錄並優化體驗（更友善的客戶體驗可能進一步促進潛在的購買決策）
- 更好的安全性（只要使用一組密碼，以此降低用戶使用強度過低的密碼）
- 避免密碼疲勞（Password fatigue）
但在同源政策（Same-origin policy）的規範下，SSO 在跨網域的情景下仍有其限制，同一個 domain 只能存取自己網站裡的資源，無法去讀取其他 domain 內的資源。只有在某些情況下是可以允許的。
何謂同源呢？只要 scheme、domain、port 一樣，我們就會說兩個網站屬於同源的關係（見下圖）。
下方為用戶使用 SSO 跨不同 domain 登入的流程圖，可以看到即便有了 SSO ，但在跨越不同網域的使用場景下，我們仍須使用不同憑證來進行驗證。
再放個生活化一點的例子，我想多數的台大學生應該對這個頁面應該不陌生，當你在台大網域下的網頁點選「以計中帳號登入」時，就會被導到這裡，對應上圖就是 Authorization Server 或稱 Identity Provider（IdP）。
二、聯合身分（Federated Identity）
為了改善過往身分零碎的問題，於是我們形成一個聯盟，並沿續單點登入的概念，將跨網域的驗證屏障打破。
SSO （圖一）只允許訪問單個 domain 中的應用程式和資源，但透過 Federated login （圖二）則能夠支持跨 domain 或組織的應用程式單點登錄。
在同個 domain 下，n 個 SP（Service Provider）信任單個 IdP（Identity Provider），可以套用在先前的舉例，即 Google 的 Gmail 作為 IdP，其餘圍繞的應用則是 SP。
根據上面兩張圖就可以很好地看出 Federated login 與 SSO 最大的差異在於能否跨 domain 驗證。
在聯合身分的建立下，聯盟間情況的確在得到改善，但不同聯盟間各自為營，誰也不願意被歸到其他聯盟底下，島的數量明顯減少，不過跨聯盟間依舊是數據孤島的狀態，同時第三方風險卻更大了，這有點像把多個雞蛋集中到同一個籃子，若是一個大型聯盟突然中斷運營或發生數據外洩的情況，後果將會更加嚴重。
三、以用戶為中心的身份（User-Centric Identity）
該模型主要重視兩個重點：用戶許可及互操作性。用戶可以根據自己使用上需求去決定是否要從一個 SP 分享自己的身分到另一個 SP，透過讓用戶有更多身分控制權，試圖將零碎的身分在用戶端重組，OpenID 、OpenID 2.0 、OpenID Connect 、OAuth 和 FIDO 等都是圍繞著此理念而誕生的標準，此處我們簡單介紹一下近年當紅的 FIDO 聯盟。
FIDO（Fast Identity Online）
因應無密碼認證及零信任架構的風潮，FIDO 結合公開金鑰加密（Public Key Cryptography）以及生物辨識（biometrics）來登入來保護雲端帳號的個資，確保登入流程中伺服器及終端裝置協定的安全性。
不熟悉公開金鑰加密法的讀者可以閱讀此篇來快速上手 https://blog.techbridge.cc/2017/04/16/simple-cryptography/
總之，以往要記住一堆密碼太麻煩，於是 FIDO 希望打造無密碼體驗，用指紋、行動裝置，甚至掃臉就可以驗證使用者就是你本人。
FIDO 的核心創新點在於：使用者的資料都被分散保存在硬體裝置端，而非存放於網路伺服器當中，驗證資料時不存在傳輸過程，正因為如此，能夠最大化的降低資料被竊取的可能性。
簡言之，就是將登入與身分識別的系統劃分為兩套獨立的機制，以增加攻擊難度 。
舉個實際的例子，我們透過 FIDO 去做各種連結，達成一對多的驗證關係，但是當用戶希望藉由 FIDO 來實現無密碼登入時，他的 FIDO vault 仍需記錄每個網站對應的成對密鑰。
以上圖為例，假設 Kevin 現在建立一個 Google 帳戶並藉由 FIDO 來達成無密碼登入時，Google 便給 Kevin 一個對應帳戶控制權的私鑰存儲在他的 FIDO 金庫內。某天 Kevin 在另個網站 A 上選擇「用 Google 帳號登入」，就需要用到可以控制他 Google 帳戶的那把私鑰，完成登入的同時，Google 也會得知我與網站 A 建立連結，這件事非常直觀，畢竟背後是 Google 提供 Kevin 的個人信息給網站 A，但天知道 Google 會不會對 Kevin 的用戶做一些標籤以作為未來投放廣告的依據，在這次的場景中，Kevin 的隱私權也許在不知不覺間就受到侵害。
儘管在此模型中，數據孤島的情況又更好地被改善了，因為可以把上述標準都想成一個又再更大的聯盟，FIDO 的無密碼驗證更優化了使用者的體驗流程。可惜的是，除了優點被放大，缺點也不意外地被放大了，人們對中心化認證服務的依賴來到史無前例的高峰，這意味著一旦服務供給被停止，你在網路上就相當於沒有身分的人，對應的資料也將不再復反。
四、自我主權身份（Self-Sovereign Identity）
SSI 是如何與「以用戶為中心的身分」不同的
讓我們把場景轉移到 SSI 的身分模型下，要想完全實現 SSI 的理想，我們需要一系列的架構配合。
SSI 架構中四個主要的部分：
- DIDs（Decentralized Identifiers）：見下方補充
- DKMS（Digital Key Management System）：可以想像成一個可以訪問私鑰的錢包，就像現在用來買賣加密貨幣的錢包，其主要負責管理私鑰及儲存 VC。
- DID Authentication：需要證明與你會話的 DID 主體是你想做資料交換的 DID 的控制者，該證明方法將在 DID document 中做描述，例如用公鑰驗證數位簽章，或利用現有的 OpenID 系列標準都可以是一種方法。
- Verifiable Credentials（簡稱 VC）：可以是護照、駕照、員工證、疫苗小黃卡或學歷證書等數位憑證，未來要做驗證時會被包裝成 VP（Verifiable Presentation）給驗證者（在下方流程部分有更多說明）。
補充 DID 架構圖與重要角色：
- DID subject：被 DID 所識別，且被 DID document 所描繪的 entity，可以是人或組織，實體或數位的事物，甚至可以是一個抽象的概念。
- DID controller：可以更動 DID document 的 entity，DID subject 和 controller 可以是同一個，且 controller 可為複數，另外，該屬性在 DID document 中屬於選填的項目。
- DID document：一個描繪 DID 主體的資料集（或說 DID subject 的 metadata），其中包含 DID subject 或 DID delegate 該透過何種機制來做 DID Authentication。
- DID delegate（額外補充）：舉例來說一個 DID 的 subject 是小孩，而他的父母是 controller，該父母可能會允許他們的小孩透過其裝置自行進行 DID Auth，此時小孩就是 delegate，但在未經父母許可的情形下，小孩並無法添加其他設備的權限。
- Verifiable Data Registry：儲存並映射 DID 與 DID document 的地方，可以是區塊鏈、去中心化資料庫（如 IPFS）或政府 ID 資料庫等，以多中心化為目標比較可行，一次到位過於困難。
並列出 DID 幾個重要特性，並與中心化的身分解方做對比：
- 掌控性（Control）：中心化身分解方下，實質掌控身分的並非用戶，而是身分服務商；區塊鏈使用數位簽章，掌控私鑰即掌控身分，且私鑰由用戶自行保管。
- 存取性（Accessibility）：中心化身分服務商可以限制身份存取；區塊鏈是分散式帳本，用戶隨時可於任一節點存取身份。
- 透明性（Transparency）：中心化身分服務商各自形成數據孤島；區塊鏈則公開透明，可供用戶驗證。（注意！鏈上只儲存 DID & DID document 供第三方驗證資料所有權及真實性，敏感資訊，如 VC 則存在 DKMS 內。）
- 持續性（Persistence）：中心化服務會有單點故障，服務中斷的風險；區塊鏈由具經濟誘因的節點共同維護，原生抗單點故障。
再來我們來講講透過 VC 所形成的信任三角互動關係中各有哪些角色，又是怎麼互動的。
1. 首先，Holder 會送出一個 Credential Request，要求 Issuer 把對應的 VC 給他，Issuer 經確認後會將屬於該 Holder 的 VC 發送到他的 DKMS 中。
- 多數情況下 VC Holder 就是 DID Subject，但也在某些場景有例外，如父母（Holder）持有孩子（Subject）的 VC ，或飼主（Holder）有寵物（Subject）的 VC。
2. 當 Holder 需要使用某項服務時，Verifier（Service Provider）就會向他發送 Presentation Request，Holder 就可以從他現有的 VC 內排列組合，挑出驗證需要的那些資料來組成一個 VP（Verifiable Presentation）來給 Verifier 做驗證，當未來不需要在使用該服務時也可以選擇撤回 VP。
- 組成 VP 時可實現 minimum explosure 的特性，假設你去租車，現有認證模式下，租車商可能要確認你的姓名，成年與否或有無駕照，但在你提供身分證及駕照的同時，它可以知道你實際上的歲數、生日及配偶狀況等其他隱私，但透過 VC 與 VP 則可以只勾選被要求揭露的資訊即可，且因為 VP 還包含零知識證明（Zero-Knowledge Proof，簡稱 ZKP）的特性，故它只能知道你是否成年的二元答案，無法得知你實際的年紀，達成最大程度的隱私保護（Prevacy Preserving）。
3. 在 Issuer 發 VC 給 Holder 或 Holder 將 VP 發給 Verifier 時會在裡面組成部分的 metadata 上用自己的私鑰簽名，同時把對應公鑰存在 Registry 中，當 Verifier 需要驗證拿到的 VP 是否從某個 Issuer 發出或 VP 是否由特定 Holder 所提供時，只需從 Registry 拿出對應公鑰來驗證數位簽章即可。至於為何上圖 Registry 中 VC & VP 需要 hash，我個人理解為加密需求與希望得到固定長度的 output 對格式統一上比較友善。
一起來看看 VC 和 VP 內是由哪些部分組成的吧
Verifiable Credential：即一組（單個或多個）防串改的 claim 和其 metadata，且以密碼學證明發行此憑證的源頭是誰。
- Credential Metadata：描述該憑證的特質，如誰是發行者、何時被發行的、此憑證的有效日期、驗證用的公鑰及撤銷的方式等等。
Verifiable Presentation：即一個人角色子集的表達，數據源自一個或多個 VC 聚合而來，主要的設計理念是為了增加隱私保護。
了解完 SSI 生態系各個成員及組成他們的元素，他們之間的互動關係後就可以回到原先的例子了。
現在，Kevin 一樣想要建立一個 Google 的帳戶，於是他根據 Google 要求的資料，從單個或多個 VC 中挑出對應的資料做成 VP 給 Google 做驗證即可。若 Kevin 想要透過與登入 Google 相同的 Auth Template 去登入網站 A，他只需自己授權同樣的 VP，再也不必經過一個中間人 Google。
現在你已經很大程度理解 SSI 的本質了，我們最後幫大家總複習一下，身分模型究竟何以進展到 SSI ，而 SSI 又解決了什麼問題。
Recap
我們的各種身分資訊本身就像一片片拼圖，只是過往分散在各個 Identity Provider 手上，現在透過 SSI 我們可以將這些拼圖拿回手中，自己拼成一個完整的「我」，或是根據需求選擇所需資訊組成「我」的子集給其他想要驗證的人，成功解決了開頭提到的身分零碎及第三方風險的兩大問題，並同時完成過往身分認證的不可能三角：
最終，達成安全、隱私、便利三位一體的美好願景。
Reviewer
Reference
The Path to Self-Sovereign Identity
a16z前合伙人：从架构维度看Web2.0与Web3.0应用之别
科普｜RSS3 是什麼？重新帶回被 Web 2.0 遺忘的網路之花
Survey: 45% of security professionals reuse the same password
Infographic: How Safe Is Your Password?
雙重驗證/兩步驟驗證 (2FA) 是什麼？對於網路安全的重要性為何？
簡單弄懂同源政策 (Same Origin Policy) 與跨網域 (CORS)
Authentication vs. Federation vs. SSO
The Three Models of Digital Identity Relationships
【全面解析FIDO網路身分識別】無密碼新時代將至！解決網路密碼遭竊與盜用問題
網路時代的最佳資安解決方案 1：FIDO的深入解析 (上) — 偉康科技洞察室
網路時代的最佳資安解決方案 1：FIDO的深入解析 (下) — 偉康科技洞察室
Introduction to Self-Sovereign Identity
SSI Essentials: Everything you need to know about Decentralized Identities
Decentralized Identifiers (DIDs) v1.0
