去中心化身份（Decentralized ID, DID）介紹

去中心化身份（Decentralized ID, DID）介紹

DID可以說是區塊鏈領域一個偏冷門的方向，但是其實它看上去有不小的價值的。
1 背景與現狀

1.1 數字身份認證背景

中心化身份 => 聯盟身份 => 中心化身份（DID）
一開始的數字認證始是中心化的，比如ICANN管理的域名與IP地址分配，以及PKI（Public Key Infrastructure）系統中的CA（Certificate Authority）證書機構管理的數字證書。

中心化身份系統的本質就是，中央集權化的權威機構掌握着身份數據，因爲圍繞數據進行的認證、授權等也都由中心化的機構來決定。身份不是由用戶自己控制的。

而且不同的中心化網站（比如淘寶、知乎、豆瓣等等）上有一套自己的身份系統，所以都需要你重新註冊一個賬戶。而不同網站自己用的身份系統（及賬戶對應的數據）之間是不互通的。

爲了解決這個問題，不同的網站自己聯合起來推出了聯盟身份（這個概念是首先由微軟在1999年提出的）。在聯盟身份體系下，用戶的在線身份有了一定的可移植性。如今的不少網站註冊都可以支持第三方登錄，比如微信、QQ、新浪微博等。

在聯盟身份提出後，身份系統就開始走向去中心化了。期間也有很多去中心化的標準、方案出現，比如OpenID。其實就算是一些網站支持的微信、QQ第三方登錄，其用戶體驗也不是很好，而且往往還是需要你用手機號 + 驗證碼進行註冊的。

綜上所述，中心化身份主要的問題就是兩個，一是個人並不是真正意義上擁有自己的身份，二是身份無法互通。

1.2 Decentralized IDentity（DID）現狀

發展前景、已經提出的標準、已經出現的項目
DID可以說是區塊鏈領域一個偏冷門的方向。目前只有很少的團隊在研究DID，開發的項目也不多，屈指可數，而關於DID行業的研究報告也幾乎沒有（只找到一份）。DID的熱度和擴容、跨鏈、DeFi這些熱門概念是無法相比的。但是其實它看上去有不小的價值的，微軟佈局DID或許就是從側面說明了這點。

基於區塊鏈或者說是分佈式賬本（DLT）技術的DID有望解決前面提到的問題（但是也會引進新的問題，新的問題會在3 uPort項目部分提到）。

（1）標準

目前（2019年）已經提出的標準主要有：

W3C的DID標準：A Primer for Decentralized Identifiers
DIF（Decentralized Identity Foundation）的DID Auth：DIF官網
接下去以W3C的DID標準以及以太坊ETH上的實際項目uPort進行簡要分析。

（2）項目

目前已經有的比較知名的DID項目有：MicrosoftDID、Sovrin、uPort、Evernym、Civic、ShoCard。

項目名稱    大致內容
MicrosoftDID    微軟的DID
Sovrin    位於HyperLedger
uPort    位於ETH
Evernym    用於交易
Civic    使生物識別的多因素身份認證、移動身份平臺
ShoCard    移動身份平臺、保護隱私
2 W3C DID 標準

去中心化身份標識(Decentralized Identifier，DID)是一種新類型的標識符，具有全局唯一性、高可用性可解析性和加密可驗證性。DIDs通常與加密材料(如公鑰)和服務端點相關聯，以建立安全的通信信道。DIDs對於任何受益於自管理、加密可驗證的標識符(如個人標識符、組織標識符和物聯網場景標識符)的應用程序都很有用。例如，當前W3C可驗證憑據的商業部署大量使用DIDs來標識人員、組織和事物，並實現許多安全和隱私保護保證。
——W3C 文檔
W3C的DID標準下的DID系統主要包括以下層次要素：

基礎層：DID規範
DID標識符（Identifier）
DID文檔（Document）
應用層：可驗證聲明
可驗證聲明（Verifiable Claims 或 Verifiable Credentials，本文接下去都簡稱VC）
2.1 DID 規範

DID標識符，是一個全局唯一的表示你身份的東西，就像你的身份證號碼一樣。其形式大致如下：

DID示例：did:eth:123456789abcdefg

DID標識符不容易記憶。根據Zooko三角形理論，沒有任何標識符能夠同時實現易記憶、安全、去中心化。在這裏，W3C的DID取了後兩者。

DID Infrastructure是一個全局鍵值對數據庫，這個數據庫要麼是某個DID兼容的區塊鏈，要麼是某個DID兼容的分佈式賬本，或者是某個DID兼容的去中心化網絡（其實這個數據庫的位置就是DID標識符中的example字段，目前已經有非常多的合法地址）。在這個數據庫中，DID標識符是鍵，而DID文檔是值。

DID文檔是一個JSON-LD Object，包括6個部分（都是optional的）：

DID標識符。
一個加密材料的集合。比如公鑰。
一個加密協議的集合。
一個服務端點的集合。
時間戳。
一個可選的JSON-LD簽名。用來證明這個DID文檔是合法的。
文檔內容示例：

{
  "@context": "https://w3id.org/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    // used to authenticate as did:...fghi
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }],
  "service": [{
    // used to retrieve Verifiable Credentials associated with the DID
    "id":"did:example:123456789abcdefghi#vcs",
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}

這裏需要注意的是，DID文檔中沒有任何和你個人真實信息相關的內容，比如你的真實姓名、地址、手機號等。因此光靠DID規範是無法驗證一個人的身份的，必須要靠DID應用層中的VC。

2.2 可驗證聲明

W3C認爲前面的DID規範是基礎，而把可驗證聲明視作是next higher layer，並認爲這一層纔是建立DID整個體系的價值所在。因爲在這個應用層中，DID既可以用來標識個體的身份、也可以用來標識組織的身份，甚至標識物品的身份（言外之意是不僅可以改變當前的互聯網，還可以改變物聯網？）。

接下去我將可驗證聲明簡稱之VC。VC有點類似於數字簽名，要是實現數字簽名，需要有PKI體系。這裏要實現VC也是一樣，需要用一套系統來支持它。在VC的這套系統中，有以下幾種參與者（列出了其功能）：

發行者（Issuer）：擁有用戶數據並能開具VC的實體，如政府、銀行、大學等機構和組織。
驗證者（Inspector-Verifier，IV）：接受VC並進行驗證，由此可以提供給出示VC者某種類型的服務。
持有者（Holder）：向Issuer請求、收到、持有VC的實體。向IV出示VC。開具的VC可以放在VC錢包裏，方便以後再次使用。
標識符註冊機構（Identifier Registry）：維護DIDs的數據庫，如某條區塊鏈、分佈式賬本（差不多就是前面提到的DID裏的example字段）。
之所以需有Identifier Registry，是因爲IV要驗證VC，也要驗證用戶。驗證VC用VC和發VC的Issuer，驗證用戶用DID和存DID的數據庫。

因爲DID對應的DID文檔裏沒有用戶的真實信息，所以當用戶進行某個操作時，網站需要用戶出示證明。比如，要求你證明“我XXX年齡已經大於18週歲”。這個時候你就需要Issuer幫你發出（並簽名）這樣一個VC給網站，網站做作爲Inspector就可以進行驗證。驗證之後你可以進行操作了。

這裏有一點要注意，那就是Issuer只需要給出你是超過18歲的VC，而不需要給出你的生日是多少的的VC，前者泄露你更少的信息。最理想的VC應該是一個回答是否的回覆，而不是回答多少和什麼的回覆。這樣能泄露最少的信息給IV。

VC的格式也是JSON的。示例如下：

{
  // set the context, which establishes the special terms we will be using
  // such as 'issuer' and 'alumniOf'.
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  // specify the identifier for the credential
  "id": "http://example.edu/credentials/1872",
  // the credential types, which declare what data to expect in the credential
  "type": ["VerifiableCredential", "AlumniCredential"],
  // the entity that issued the credential
  "issuer": "https://example.edu/issuers/565049",
  // when the credential was issued
  "issuanceDate": "2010-01-01T19:73:24Z",
  // claims about the subjects of the credential
  "credentialSubject": {
    // identifier for the only subject of the credential
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    // assertion about the only subject of the credential
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  // digital proof that makes the credential tamper-evident
  // see the NOTE at end of this section for more detail
  "proof": {
    // the cryptographic signature suite that was used to generate the signature
    "type": "RsaSignature2018",
    // the date the signature was created
    "created": "2017-06-18T21:19:10Z",
    // purpose of this proof
    "proofPurpose": "assertionMethod",
    // the identifier of the public key that can verify the signature
    "verificationMethod": "https://example.edu/issuers/keys/1",
    // the digital signature value
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
      PAYuNzVBAh4vGHSrQyHUdBBPM"
  }
}

這裏講講IV該如何來驗證VC。因爲VC中是沒有Issuer的公鑰的（也不應該有，因爲就算有了，IV還是得親自驗證公鑰是否是真的）。這裏VC的id是一個URI，而VC中的Issuer字段也是一個URI。而Issuer也可能是使用DID來作爲其身份的。因此通過VC中的Issuer字段——URI地址得到其DID，然後從DID對應的DID文檔裏就可以得到其公鑰了。用公鑰驗證對VC的簽名就能驗證VC是否Issuer發的。

當然IV驗證用戶的方法也是如此：用Holder（即用戶）的DID對應的DID文檔裏的公鑰來驗證其數字簽名的合法性。

3 uPort項目

uPort是用於構建以用戶爲中心的去中心化應用的工具和協議的集合。它建立在開放標準和開放源代碼庫之上。 ——uPort官網
uPort項目方認爲，一般的DApp用起來有諸多侷限，用戶的使用門檻較高：

你必須下載一個錢包
理解和錢包、密鑰有關的各種概念
你必須申請一個對應的區塊鏈上的賬號
你必須購買一些平臺幣，比如ETH上必須買ETH來支付交易gas、EOS上必須買EOS來抵押CPU、RAM、NET資源。購買平臺幣至少意味着兩件提高用戶使用成本的事情：
需要一個交易所來買入加密貨幣，因此需要註冊一個交易所賬戶，還需要弄懂加密貨幣的交易所其實和證券交易所是有所不同的
需要付費購買。不像其他互聯網服務一樣是免費的
理解區塊鏈、P2P網絡的各種概念
其實以上就是去中心化身份相比於中心化身份的缺點（優點在前面早就講過了哈）。因此uPort的目標就是解決這些問題，解決這些問題，去中心化身份纔會真正便利於用戶。

值得一提的是，uPort是儘可能符合W3C制定的關於DID的標準的。這裏需要說明的是DID完全還是區塊鏈行業中，或者說是Web3生態中處於萌芽狀態的事物，W3C的標準也只是v0.13，標準還處於完善之中。因此，作爲已經在開發產品的uPort其實在使用DID的一些情況下，W3C DID標準可能是還沒有相應的Spec，或者是和實際情況不符的。因此uPort此時必須自己想出解決方案。

3.1 uPort App

uPort現在已經有一款移動端的產品了，名字也叫uPort。如下圖片所示。

uPort App類似於一款加密貨幣的錢包，你需要現在這個App上註冊一下，註冊完了之後你會有一個uPort ID，這個uPort ID（上圖最左）其實就是由DID + 以太坊賬戶組成的。而且看山去骨DID後面的幾位是和你你以太坊賬戶的數字一樣的（我無法看到我DID標識符的全部內容，不知道是不是App的bug… ）。

一個uPort賬戶關聯了以下內容，這些內容都在uPort App中顯示出來了：

一個uPort ID：包括一個DID和一個ETH Mainnet Address
個人基本信息：可選填Name、Email、Country、Phone四個字段，其中Name是你在申請賬號時必填的，自己任取
Credentials：Credentials就是在W3C標準裏提到的Claims，就是VC。前面說了VC被Issuer發了以後，Holder可以存在自己的錢包裏，等下次用的時候直接出示，而可以省去讓Issuer重開的成本。uPort App自然可以幫你存儲VC。
其他輔助信息：如賬號的二維碼、賬戶頭像等等
3.2 uPort是如何運轉的

當你開始使用uPort App後（也就是你已經有一個uPort賬戶了），當你使用某個支持uPort的DApp時，你就可以使用uPort賬戶來登錄。如果這個DApp需要你出示一些證明，你就可以用uPort來幫你把存在uPort賬戶裏對應的VC發給DApp。這和你要進行加密貨幣交易是，拉起錢包來幫你進行交易簽名類似。一個VC就像一個對交易的數字簽名。

當然，VC需要事先備在你的uPort賬戶。獲取VC到uPort賬戶的流程是：用戶上傳證明材料到uPort賬戶，比如證明駕駛證的照片。然後uPort作爲代理去Issuer出示證明材料，獲取VC到你的uPort賬戶進行關聯。

因此uPort運行起來最重要的當然是要有Issuer的支持。Issuer必須支持和uPort的合作。試想某個網站要求Holder出示駕駛證的證明。就算用戶真的把駕駛證拍照作爲VC上傳到uPort賬戶上，作爲IV也無法通過照片來驗證，VC是Issuer發的，因此必須由Issuer來告訴IV如何正確驗證VC。

3.3 關於uPort App的疑問

1）uPort賬戶數據是存在uPort的中心化服務器上的還是存在區塊鏈上的?

說實話，相關文件裏似乎沒有寫明。但是，可以肯定的是有部分數據上鍊了，而其他數據沒上鍊。
uPort ID中的DID和ETH賬號肯定是上鍊的，上的是ETH主網。但是用戶頭像、二維碼這些輔助數據應該是存在服務器了吧（個人推測，這種無關緊要的數據沒必要上鍊）。
而最關鍵的VC是否上鍊了呢？應該沒上鍊。VC是不能上鍊的，作爲用戶的隱私，如果上鍊了那就相當於公開了。VC其實和加密貨幣錢包裏的私鑰一樣，應該都是存在本地的，也就是隻存在你手機上的。而從使用uPort App的實際來看，應該也是存在本地的。因爲uPort App裏有一個選項是幫你備份VC，備份方案只有一個，那就是備份到uPort的服務器上的（如下圖所示）。默認情況下VC是不備份的，由此看來是VC就是存在本地的（當然我並未看過uPort App的源碼）。

2）IV（Inspector-Verifier）是uPort還是需要VC的DApp？

uPort App這個App幫你從Issuer那兒拿到了VC，它自然有能力幫你驗證（如何驗證VC在W3C體系下的DID中講過了嗷，不過有文章聲稱uPort是靠取出電子檔案數據庫裏的數據來進行比對的…這個待查證，暫時認爲uPort驗證VC就是和W3C DID標準裏是一樣的）。其實我也不清楚到底是uPort驗證的還是DApp驗證的。這個問題也留給我自己，以後去搞清楚。
3.4 DApp如何使用uPort

首先說一下DApp對uPort支持的現狀，uPort作爲ETH上的DID服務提供者之一，一般肯定是服務於ETH上的DApp的。而使用DID的DApp非常少，並且DID也不是ETH上熱門之物 —— 在2018年以太坊的全年總結之中也沒有提到DID的任何內容。所以實際是支持uPort的DApp應該是很少了。

在uPort App裏關於VC有一個Demo —— 通過uPort官網上的一個應用：uPortlandia來獲取VC。但是其在和uPort App交互時似乎也有bug導致VC出示沒有反應，這應該是個bug。

因此現在應該是沒有什麼DApp使用uPort來着，而且感覺uPort本身的軟件也並不是非常成熟。

其開發文檔在這裏。

4 疑問

區塊鏈上的賬戶，比如ETH、EOS上的主網賬號是否是DID？

首先，DID和區塊鏈中的賬戶有不少類似的地方：賬號的數據都存在區塊鏈上、都通過公私鑰對進行控制。
但是也有不同的地方：DID都有一個全局唯一的標識符，符合一定的標準，本文講的是W3C的標準。而且上鍊的賬戶數據是JSON格式的某種文件。
只能說因爲區塊鏈主網的賬戶有DID的思想在裏面，但是不能說它是DID。因爲區塊鏈主網上的原生賬戶都不是互通的。
使用了DID，用戶自己掌控賬號的問題是否解決？

首先，自己的信息還是存在中心化機構，如政府、銀行、教育機構上的。這似乎是沒辦法改變的。
其次，如果你在某個中心化網站註冊了一個賬戶，那你使用這個賬號在這個網站上產的數據自然還是全部被這個網站所擁有的。
但是，你的最關鍵的信息——存在政府的那些信息，只要你不想透露，就不會透露給中心化網站，你可以使用VC的方式來出示證明。
因此，總的看來，DID確實有保護個人隱私的作用。而且DID是由公私鑰控制的，和區塊鏈上的賬戶體系類似。你的私鑰只有你一個人知道。所以用戶對於DID是掌控住的。但是前面也說了，DID裏不包含真實的個人信息。你掌控的只是這個DID而已。
最重要的一個疑問：DID會流行嗎？

如果DID無法流行起來，那如何談論它都是空談。DID能否推行起來，
一就要看DID體系下的參與者們——Issuer、Holder、IV、IR（這裏可以視爲區塊鏈服務提供者）是否願意使用了。毫無疑問，Holder肯定想要DID，如此一來Issuer和IR應該也不會不願意。但是希望能多獲取用戶信息的IV估計就不願意了。
二要看是否有公司願意開發DID的技術。一般來說客戶有需求，肯定會有人願意開發。不過也有一些技術公司覺得，是否需要用 Blockchain + VC 來實現DID？使用已經成熟的技術比如 PKI + JWTs(JSON Web Tokens) + OpenID 好像也不賴。
5 結語

在多數用到了區塊鏈的解決方案上，往往都能用目前比較成熟的技術的另一個方案（除了數字貨幣本身）。而且區塊鏈往往確實沒有特別的優勢。只要是這樣，由於惰性的存在，區塊鏈的落地就很難進行。

其實我覺得可能區塊鏈的應用確實是比較小衆的，它就是一個分佈式賬簿數據庫，並不是所有應用都要使用這種數據庫的。區塊鏈之所以熱門起來也是因爲比特幣大漲，而似乎不是技術本身。那些本身需要用到分佈式系統的應用，因爲區塊鏈熱門而使用區塊鏈，其實他們直接使用分佈式系統就可以了。不應該是世界適應區塊鏈，而應該是區塊鏈適應世界。

我個人目前最看好的還是DeFi。在區塊鏈向各個領域擴張嘗試後，也是時候收斂回最有可能落地的某幾個場景了，反正目前業界普遍認爲最有可能落地的是金融和遊戲。

參考文獻:

[1]Decentralized Identifiers (DIDs) v0.13——Data Model and Syntaxes
[2]Understanding Decentralized IDs (DIDs). Adam Powers.
[3]去中心化身份研究報告.時戳資本.
[4]uPort概述.uPort官網
[5]uPort解讀1.簡書
[5]uPort解讀2.medium

————————————————
版權聲明：本文爲CSDN博主「treaser」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/treaser/article/details/99004355