a DID 系統實現計畫

mingderwang
3 min readOct 1, 2020

如何架構一個 (a) 分散式 (Distributed) ID (身份) 系統, 以下說明我的想法:

我想依據 (follow) 一個業界 W3C 定義的 DIDs 規格, 來實作一些工具, 它可以用來提供 “證明”, 至少能提供以下幾個功能:

  1. 使用者 (user), 自己可以生成自己的 IDs, 內含一些鑰匙 (用來做數位簽章)
  2. 可以生成任何 ID 文件 (document), 但都必須由所有人, 創始人簽章
  3. 認證發行單位 (ID issuers)(例如:“駕照” 是由監理所發照, “身份證” 是由內政部發照, “護照” ??), 可以提供證明文件 (documents) 並負責驗證 (verify) 其真偽
  4. 任何人或任何單位, 都可以讀取任何 ID 文件, 但必須由 ID 的所有人同意才能讀取內容
  5. 文件擁有者及發行人, 可以修改文件內容
  6. 當然, 所有功能必須跟其他 DID 相容系統, 共同運作無疑

“為何寫系統需要 follow 一些標準或業界標準呢?”

因為, 就像電子郵件網路, 大家都 follow POP3 以及 SMTP 與 IMAP 協定來開發 email servers 或 email clients (像 Gmail, Yahoo mail, 微軟 Exchange 等), 因此全世界所有 email 使用者, 不管用哪一家的軟體, 在哪一家 email 服務商 開的 email 帳號, 都得以正常接收信件.

同樣的道理, 身份辨識, 以及個資保密與認證的問題, 將會跟 email ㄧ樣(包括加密保護你的 email 內容, 確認信件的真偽), 都會有標準可循.

DID 是定義給一種叫 user self-sovereign (使用者自主) 的數位 id 平台. 反觀現今社會決大部分 ID 與 ID 內容, 是受控於第三方. 也就是某個單位來發照或發行. 除了 “發行” (create), 連 “控制” (control) 例如:修改, 刪除, 還有 “驗證” (validation), 都由某一個單位或公信單位或國家或政府單位等來執行.

廣義來說, 在銀行開戶, 新的 “帳戶” (account) 與銀行帳號, 也都是由該銀行控管. 這樣造成現今才需要 ATM (提款機) 的跨行, 需先選 “銀行” -> “密碼” -> “轉帳” -> “轉入銀行” -> “轉入帳號” -> “金額” -> “確認”, 這麼多步驟, 這麼複雜的操作流程. 都是因為 ID 之間沒有標準. 國際間的 “護照” 也是一樣的問題.

DID 使用者自己生成的 ID, 再去給別人或認證單位認證你是本人, 而且發行某些你的相關訊息 (例如, 戶籍, 出生年月日, 駕照, 畢業證書, 結婚證書, 出生證明, 薪資證明, 等等…) 這樣一來, create, control 所有的控制全都在你手上, 你個資的提供與否, 也每次且單筆的需要你本人同意, 別人才能看的到. (而且有你的加密, 其他人無法看到同一筆資料的內容)

由於這些 DID 相容的應用軟體, 都是數位的. 也可以儲存在去中心化的資料庫裡 (例如:區塊鏈), 因此也更容易用程式來控制或手機 app 來操作. 未來的應用, 更是無限廣泛 (例如: 個人病例, 健康情況與保險, 基因序列, 國際護照, 國際駕照, 你可以想想需要保密的東西, 都可以用到)

所以, 讓我們一起來研究如何實作 DID 系統, 為了要讓系統能有最大的彈性與二次開發空間 (大陸用語), 我們先以 library (程式庫) 搭配著測試與演示 (demo) 方式呈現. 也能讓應用程式開發者 (developers) 能利用這些程式庫與範例, 有效且快速的開發出 DID 的應用實例來.

  • 參考資料

Decentralized Identifiers (DIDs) v1.0

Verifiable Credentials (DID Credential Flows) : Technical Overview

SSI-DID Github Repositories

--

--