第271期 / May 5, 2020

分享到臉書!分享到維特!分享到噗浪!分享到Google+!分享到微博!轉寄友人友善列印

告別網路個資外洩-去中心化分散式身份識別 W3C Decentralized Identifiers (DIDs)技術探討

作者/林家新

[發表日期:2020/5/5]

作者簡介

林家新,現任凌群電腦資安巨資暨智慧城市技術研發處,專長Blockchain、Fintech、IoT、Docker、Linux、Raspberry Pi,擁有OCJP、MTA、TQC等證照。

緣起
  
隨著科技的發展生活中越來越多是可以透過網路完成,不論是線上訂餐、網路商城購物還是信用卡申請,使用者只需依照網頁的要求,逐步填寫相關資料即可,但近年來由於個資外洩引發的事件越來越多,使得使用者們更加關注個人資料的隱私議題,由於許多個資外洩事件往往是由持有用戶資料的廠商保管不當所引起,因此近年來資料的使用權逐漸傾向於由使用者自行掌握,進而衍生出「去中心化身分識別(Decentralized Identifiers, DIDs) 技術」,讓使用者在不透漏過多私密資訊的同時,也能達到身分識別的目的,藉此減少個人資料暴露的風險。

去中心化身分識別(Decentralized Identifiers, DIDs)

去中心化識別的最終目標為讓使用者能全權掌控資料,保護該資料的隱私,相較於過往使用者將資料交由中樞管理者,減少了資料使用權限、資料歸屬等衍生議題。去中心化識別技術可應用在區塊鏈技術上,不論是公有鏈、私有鏈、聯盟鏈皆可使用。因此全球資訊網協會(W3C)訂定了DIDs資料格式、資料型態等相關規範。

DIDs架構與規範

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


《圖一》DID格式
圖片來源: https://w3c-ccg.github.io/did-primer/


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


《圖二》DID document
圖片來源:https://www.w3.org/TR/did-core/


由於DIDs的設計結構使得其擁有高度隱私性,在設計上共有三個特性:

一、Pairwise-pseudonymous DIDs

DIDs可以使用常見的公開識別符號(如姓名及學號),同時也可以使用定義的其他字串,因此每個人可以擁有許多不同的DID,使得資料與使用者難以被直接關聯,同時也方便使用者管理。

二、Off-chain private data
  
若將資料放在區塊鏈或網路上會增加資料曝光的風險,因為所有人皆可對資料進行存取,即使是經過加密的資訊仍然有被破解的風險(使用量子電腦破解),因此將資料存放在本地端,並只透過安全、經過加密的通道進行傳輸。

三、Selective disclosure
  
使用加密過的文字或零知識證明當作資料共享時的依據,有效管理資料傳輸對象,同時利用最少的資訊達到識別身分的目的,藉此減少資料曝光的風險。?

技術分析

DIDs也是解決網路上的數位身分辨識,與現有辨別數位身分的方式Email和URL,有許多共同點也有些許分歧點,以下表格做一個屬性比較表。


《表一》DIDs、URLs和Email addresses的比較表


DIDs扮演的重要角色主要分為以下五種,以下做更詳細的說明。

一、Verifiable Claims

一種具備可被驗證性的聲明文件。可驗證claim只是一個 JSON 文件,規範只定義資料模型。沒有特定的協定來記錄從一方到下一方的文件。可驗證 claim定義兩個角色:
  • Holder: 接受並持有verifiable claims的人,可能是某個Issuer獲得verifiable claims的使用者。


  • Inspecter-Verifier: 某種類型的服務,接收verifiable claims並且作為服務的一部分。


《圖三》可驗證 claim 中的各種參與者
圖片來源: https://www.w3.org/TR/vc-data-model/#claims


Claims 分為三部分:
  • Subject:可以是一個使用者、公司或寵物等任何可以描述的東西。

  • Issuer:可以是某種組織。例如:大學、銀行、協會等。

  • Claim:任何描述性的陳述,通常是關於人的描述,例如:年紀幾歲、住在哪個地址或暱稱等。



《圖四》Claim 範例
圖片來源: https://www.w3.org/TR/vc-data-model/#claims


二、DID Users

DID 的 Holder 和可驗證 Claim 的 Subjects 和主體。可以從 DID 使用者的角度和他們應該從 DID 接收的價值開始。 關於 DID 值的最常見的爭論是將控制權返回給用戶。這可以有幾種不同的類型:
  • 控制 Identifier:今天常用的 identifier 包括電子郵件地址和域名,這些是由第三方控制的,他們的利益可能與用戶不一致。例如,電子郵件提供商可以撤銷或暫停電子郵件地址;域名可能會被關閉或接管。只要 DID 私鑰保持私密,用戶就可以控制其 DID。


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


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


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


三、Service Providers

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

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

四、Claim Issuer

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

五、Technology Providers

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

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

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

DIDs 規範的四大核心:1.持久的身分識別碼2.可分辨的身分識別碼3.具有加密可驗證的身分識別碼4.分散式的身分驗證碼。DIDs 整體的設計目標與描述,整理成以下方表格做說明。


《表二》DIDs設計目標


未來發展

由於網路服務的盛行,導致網路上的數位身分辨別有很大的需求和進步空間,為了解決中心化管理數位身分的安全問題,以及中心化的點對點驗證方式有許多安全及效率的問題,DIDs的設計是基於區塊鏈的技術概念上,以分散式的驗證、資料同步的方式解決現有的問題,因此DIDs在未來勢必是有很大的需求。

目前DIDs的設計規範還不夠完整,例如:DIDs的長度是沒有上限的,相較於互動性最高的URL長度約為2K個字符,而QR Code則是4K個字符。此作法會導致DIDs的使用者儲存成本提高,因此DIDs未來的規範應在DID字符上設置合理的限制。

W3C憑證社群小組圍繞 DIDs,其開發的規範的未來進行了非常積極的對話。 大部分談討論仍在進行中,並不完全清楚 DIDs 的採用將如何發揮作用; 然而,這是一種前瞻性數位身分辨識的方法,因此DIDs規範十分值得關注。

參考資料

1.Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations
 https://www.w3.org/TR/did-core/

2.A Primer for Decentralized Identifiers
 https://w3c-ccg.github.io/did-primer/

3.Understanding Decentralized IDs (DIDs)
 https://medium.com/@adam_14796/understanding-decentralized-ids-dids-839798b91809

4.What are Decentralized Identifiers (DIDs)?
 https://www.evernym.com/blog/what-are-decentralized-identifiers-dids/