上期我們爲大家介紹了 Open Badges 和 Blockcerts Schema 以及兩者之間的區別，本期我們將繼續連載翻譯 Rebooting Web of Trust 組織在 RWOT IX — Prague, 2019會議上的論文《Blockcerts V3 Proposal》，探討 Blockerts 作爲可驗證憑證是如何實現的。
原文：
https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/BlockcertsV3.md
作者：
Anthony Ronning，Wong Wai Chung
1. Blockcerts 作爲可驗證憑證如何實現？
圖 | 網絡
通過前面的講述，我們瞭解了 Blockcerts 在 Open badges 的基礎上附加了一些特定內容（即 recipientProfile、 verification 以及 signature 等），我們可以將這些內容和可驗證憑證（Verifiable Credential，VC）上的內容進行對應。
1.1 receiveProfile
本質上，Blockcerts 的 recipientProfile 可以被替換爲 credentialSubject.id 和 credentialSubject.name。
"recipientProfile": {"type": ["RecipientProfile","Extension"],"publicKey": "ecdsa-koblitz-pubkey:mtr98kany9G1XYNU74pRnfBQmaCg2FZLmc","name": "Eularia Landroth"}可以變成：
"credentialSubject": {"id": "ecdsa-koblitz-pubkey:mtr98kany9G1XYNU74pRnfBQmaCg2FZLmc","name": "Eularia Landroth","alumniOf": {"id": "did:example:c276e12ec21ebfeb1f712ebc6f1","name": [{"value": "Example University","lang": "en"}, {"value": "Exemple d'Université","lang": "fr"}]}}
當前，Blockcerts中接收者使用 ecdsa-koblitz-pubkey 作爲公鑰。由於這是一個有效的 URI，因此它也可以用於可驗證憑證。理想情況下，可使用 DID 來代替，以使得其在整個 VC / DID 生態系統中得到更好的支持。
1.2 verification
就像前面提到的 Blockcerts 當前模式和示例中指出的一樣，Blockcerts 的 verification 用於驗證發行者的公鑰和用於向區塊鏈簽發交易的公鑰是否匹配。
這可能是一個冗餘屬性。因爲可驗證憑證也具有可驗證不變性的 proof 屬性，"issuer profile" 已經指定了其用於簽發的密鑰，並且在解析區塊鏈交易時將知道這密鑰是用於簽發的。
除非有很強的理由在將此屬性移到 VC 模式時將其保留在 Blockcerts 中，否則我們建議在 Blockcerts V3 中刪除 verification 屬性。
1.3 Signature / Proof Proposal
可驗證憑據需要有個 proof 屬性，該屬性用於驗證 VC 的不變性，並證明某個發行者已對該 VC 進行了簽名。在 VC 之前，Blockcerts 使用 signature 屬性來證明不變性。如果我們已經被要求實施 proof 屬性，那麼 signature 屬性將提供什麼作用？
時間戳是 proof 方法中沒有和簽名密鑰一起提供的重要屬性。一個 created 日期可應用於 proof，但由於可以與任何日期一起創建，這就不能證明它在某一時間的存在性。在這裏，使用區塊鏈可能是有好處的，因爲它證明了文件在交易發生時以高度確定性的方式存在（從技術上講，由於哈希函數的特點，碰撞仍然可能存在，從而導致文件的存在性存疑）。
爲了符合可驗證憑證的要求，我們需要使用其他簽名證明。目前，MerkleProof2019 正在規範中，並將與可驗證憑證兼容。
MerkleProof2019：
https://w3c-dvcg.github.io/lds-merkle-proof-2019/
雖然在可驗證憑證中允許多個簽名，但 Blockcerts 規範應僅規定需要區塊鏈證明的存在。同時提供諸如 RSA 簽名的數字簽名和 MerkleProof2019 簽名可能有好處，以便可以爲可能尚不支持 MerkleProof2019 的驗證者提供更好的互操作性。
下面是一個例子：
...[Cert Data Hash]..."proof": {"type": "MerkleProof2019","creator": "did:example:abcdefghij0123456789","created": "2017-09-23T20:21:34Z","domain": "example.org","nonce": "2bbgh3dgjg2302d-d2b3gi423d42","proofValue":"z76WGJzY2rXtSiZ8BDwU4VgcLqcMEm2dXdgVVS1QCZQUptZ5P8n5YCcnbuMUASYhVNihae7m8VeYvfViYf2KqTMVEH1B"}
【注意】：在新的 MerkleProof2019 中 ，proofValue 是 JSON 文件中的一個 CBOR 編碼。
以上內容解碼爲：
{"merkleRoot": "3c9ee831b8705f2fbe09f8b3a92247eed88cdc90418c024924be668fdc92e781","targetHash": "c65c6184e3d5a945ddb5437e93ea312411fd33aa1def22b0746d6ecd4aa30f20","path": [{"right": "51b4e22ed024ec7f38dc68b0bf78c87eda525ab0896b75d2064bdb9fc60b2698"}, {"right": "61c56cca660b2e616d0bd62775e728f50275ae44adf12d1bfb9b9c507a14766b"}],"anchors": [{"sourceId": "582733d7cef8035d87cecc9ebbe13b3a2f6cc52583fbcd2b9709f20a6b8b56b3","type": "BTCOpReturn"}]}
1.4 Issuer Key Revocations
除了存在性證明外，在考慮撤銷用例時，使用區塊鏈還可以帶來其他好處。舉一個使用 RSA 密鑰對基於非區塊鏈的 VC 進行簽名的例子。簽名證明具有與簽名相關聯的 createdDate，但是我們不能證明此日期在事實上是正確的，只能證明簽名密鑰的人或過程聲稱它們是簽名時間。
圖 | 網絡
在大多數情況下，使用自己密鑰簽名的頒發者應該在正確的時間簽名。但是，在簽名密鑰被盜的情況下，盜取密鑰的人可能希望頒發一個以前的證書。舉個例子，盜取密鑰的人可以爲自己頒發一個時間提前的大學畢業證書。
大學會意識到他們的密鑰被盜或者泄漏了，或者他們只是有良好的密鑰輪換習慣。在上述任何一種情況下，真正的頒發者現在都會將其密鑰的過期時間設置爲已知盜竊發生之前來撤銷該密鑰。
由於憑證日期不可信任，因此我們無法確定給定密鑰的憑證屬於 createdDate 和 revocationDate 範圍。對於由已泄漏密鑰頒發出來的憑證，需要在憑證驗證過程中因簽名密鑰驗證問題而顯示失敗（或至少發出警告）。由已泄漏密鑰頒發出來的不良憑證可能會影響從該頒發者採用此密鑰爲其他接收者頒發的憑證狀態。當涉及到終身證書時，這點還無法令人滿意。
因此，通過利用區塊鏈的可信時間戳，我們可以計算出真實的發行日期，並確定如果頒發者在特定日期撤銷了某個簽名密鑰，則在該日期之前在區塊鏈上錨定過的每個憑證都不會受到密鑰撤銷的影響。
圖 | 網絡
1.5 Additional Fields
除了上面指出的現有字段外，Blockcerts V2 中還有幾個非標準字段在生態系統中使用，因此可以使其標準化，並從中受益。
display
在 Blockcerts V2 中，我們已經非正式地建立了對 displayHtml 的大量支持，這已經在移動錢包、驗證程序以及第三方庫等中出現。
在提議對 V3 進行更改時，如果能夠爲顯示提供正式支持將會大有益處。擴展過去的 displayHtml，我們應該允許支持任何類型的顯示。有些人可能不想使用 html，而是使用 pdf、圖像等。
選項1
模式可以僅使用 type 和 data 屬性。
下面是一個例子：
"display": {"type": "html","data": "<p>hello world</p>"}
選項2
或者，我們可以改用 DATA URL：
https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs
"display": "data:text/html,%3Ch1%3EHello%2C%20World!%3C%2Fh1%3E"
最初，官方的 Blockcerts Universal Verifier 可能僅正式支持 HTML，但是它將允許其他人創建具有不同顯示類型的有效 Blockcerts。官方驗證程序在不瞭解數據 URL 時應退回到默認顯示，就像今天當缺失 displayHtml 時一樣的做法。
metadata
類似於 display / displayHtml 的問題，我們目前對使用 metadatajson 屬性沒有官方標準。儘管如此，我們在移動應用程序和驗證程序中都具有非官方支持，用於向查看器顯示一些元數據信息。
選項1
我們可以將其添加到標準中，但是允許使用不同類型的元數據格式，例如 XSD。這將允許頒發者利用不同的格式，並繼續在某些 Blockcerts 生態系統中正式支持它們。
實現可能類似於 display，添加 type 和 data：
"metadata": {"type": "json","data": "{\"test\": true}"}
選項2
我們可以完全刪除 metadatajson。相反，元數據可以由 credentialSubject 字段獲取。可驗證憑證規範對 credentialSubject 中可提及的信息類型沒有要求；因爲這是“holder”和“ subject”屬性所在的位置，所以有意義的是，任何其他類型的元數據都將位於此處。這將與其他非 Blockcerts 可驗證憑證以及其他可驗證憑證錢包保持一致並可以互操作。
選項3
我們可以保持原樣，我們根本沒有更改此項的要求。選擇選項2將消除對某些可能重複信息的需要，但是按原樣保留將允許頒發者將要顯示給用戶並由系統解析的元數據信息更加明確化。
值得注意的是，保留 metadataJson 或將其更改爲 metadata 很有可能會特定於 Blockcerts，而更廣泛的可驗證憑證生態系統則可能無法理解該屬性。
推薦的方法是僅從 credentialSubject 中提取其他元數據信息（選項2的做法）。
2. 結語
本期，我們探討了 Blockerts 作爲可驗證憑證來實現的幾種模式，相信大家一定有所收穫。下期我們將繼續爲大家連載翻譯本篇論文的最後一部分，介紹 Blockerts V3 的一些示例及相關討論，歡迎大家關注。
