TWI838145B

TWI838145B - 資料交換系統

Info

Publication number: TWI838145B
Application number: TW112107433A
Authority: TW
Inventors: 翁仲和
Original assignee: 金壹金融科技有限公司
Filing date: 2023-03-01
Publication date: 2024-04-01

Abstract

一種資料交換系統，至少包含有一用戶節點、一第一服務節點，以及一第二服務節點，其中該第一服務節點與該第二服務節點皆與該用戶節點資訊連接。該用戶節點持有一公鑰及一私鑰；該第一服務節點保管有一用戶資料，且使用該用戶節點提供的該公鑰處理該用戶資料，藉以產生一可驗證憑證以及一憑證資訊，並將該憑證資訊傳送給該用戶節點留存；該第二服務節點利用該憑證資訊取得該可驗證憑證，並要求該用戶節點以該私鑰驗證該可驗證憑證的可信度。若該用戶節點成功驗證該可驗證憑證的可信度，則該第二服務節點便能取得該用戶資料的至少一部份。

Description

資料交換系統

本發明關於一種分享資料的方法，尤指一種基於身分自主權（Self-sovereign identity，SSI）架構的資料交換系統。

在Web 2.0時代，數位身份的驗證係以平台為中心，例如臉書（Facebook）和谷歌（Google）都提供有相關服務，能替第三方單位代為驗證使用者的身份。但是中心化管理的數位身份所有資訊皆由平台負責管理，其安全性幾乎完全仰賴中心化平台維護，在商業實體應用方面具有安全風險，且即使風險再低，個人資料仍有機會在集中驗證的過程中受到直接或間接識別。

為進一步降低此一風險，有些技術開發單位提議使用碎片化的個人資料，輔以區塊鏈技術進行分散式驗證。然而，透過區塊鏈進行分散式驗證，需要耗費更多的算力，也會額外產生區塊鏈的服務費（gas fee），因此雖然降低了風險，但卻提高了成本。

目前亦有基於單一區塊鏈架構，搭配去中心化身份（Decentralized Identity，DID）及可驗證憑證（Verifiable Credential，VC）進行驗證的做法，能夠有效提高安全性，不過卻有區塊鏈整體網路負擔過大、VC檔案可能肥大，以及VC可能乘載機敏資料等問題，在實際運用層面上無法達成經濟效益，無法滿足現行金融法規及個資保護法規的要求，是以缺乏產業上的利用價值。

另外，使用者的資料常常由不同公司分別管理，資料內容多有重複，也可能有不一致之處。若在公司之間需要進行資料同步或交換，通常會牽涉到許多手動進行的程序，資料流通既不安全，操作起來更是費時，不符合網路世代對便利性及安全性的要求。

有鑑於此，本發明欲提供一種資料交換系統，能夠結合集中驗證與分散驗證的優點，成為一個可重複實施且經濟安全的驗證手段，並能夠有效地交換資料。

根據一實施例，本發明揭露一種資料交換系統，至少包含有一用戶節點、一第一服務節點，以及一第二服務節點。該用戶節點持有一公鑰及一私鑰，其中該公鑰及該私鑰為對應。該第一服務節點與該用戶節點資訊連接，且保管有一用戶資料；該第一服務節點使用該用戶節點提供的該公鑰以及該用戶資料產生一可驗證憑證（Verifiable Credential，VC）以及一憑證資訊，並將該憑證資訊傳送給該用戶節點留存。該第二服務節點與該用戶節點資訊連接；該第二服務節點利用該用戶節點提供的該憑證資訊取得該可驗證憑證，進而要求該用戶節點使用該私鑰驗證該可驗證憑證的可信度。若該用戶節點遵照該第二服務節點之要求而成功驗證該可驗證憑證的可信度，該第二服務節點獲准取得該第一服務節點所保管之該用戶資料的至少一部份。

於一實施例中，該可驗證憑證包含有一驗證訊息，且該第二服務節點在要求該用戶節點驗證該可驗證憑證的可信度時，係以該公鑰加密該可驗證憑證的該驗證訊息後傳送給該用戶節點，該用戶節點使用該私鑰解出該可驗證憑證的該驗證訊息，再回傳給該第二服務節點比對，若比對正確，則該數位身份得到驗證。

於一實施例中，該第一服務節點更將該可驗證憑證上鏈至一聯盟鏈，且該憑證資訊即是該可驗證憑證的一區塊鏈位址；該第二服務節點係利用該區塊鏈位址於該聯盟鏈取得該可驗證憑證。

於一實施例中，該聯盟鏈採用權威共識證明（proof-of-authority，POA）為其共識演算法。

於一實施例中，該聯盟鏈另透過一側鏈與一公鏈連接。

於一實施例中，該第一服務節點係將該可驗證憑證保存於一星際檔案系統（InterPlanetary File System，IPFS），且該憑證資訊是該可驗證憑證的一內容辨識碼（content identifier，CID）；該第二服務節點係利用該內容辨識碼取得該可驗證憑證。

於一實施例中，該第一服務節點所保管之該用戶資料的至少一部份係包含於該可驗證憑證中；該第二服務節點係由該可驗證憑證中取得該用戶資料的該至少一部份。

於一實施例中，該第一服務節點所保管之該用戶資料的至少一部份係透過一加密通道或使用一加密信封傳送給該第二服務節點。

於一實施例中，該第一服務節點係將該用戶資料保存於一星際檔案系統（InterPlanetary File System，IPFS），該第二服務節點係由該星際檔案系統取得該用戶資料的至少一部份。

於一實施例中，該用戶節點所持有的該公鑰為一實體金鑰。

前述的資料交換系統能夠滿足現行相關法規及個資保護的需求，且其安全性高，亦有效減輕於區塊鏈上運作的負擔；另外，本系統能夠安全方便地進行資料的交換，省去不必要的手動程序。有關本發明之前述及其他技術內容、特點與功效，在以下配合參考圖式之實施例的詳細說明中，將可清楚地呈現。

為使本領域技術人員能更進一步瞭解本發明，以下特列舉本發明的優選實施例，並配合附圖詳細說明本發明的構成內容及所欲達成的功效。

請參閱第1圖，為本發明一實施例之資料交換系統100的示意圖，包含有一用戶節點10、一第一服務節點20，以及一第二服務節點30，其中用戶節點10於本實施例中係以手機APP為例，但並不以此為限，實務上亦可以是由使用者操作的電腦軟體、網頁瀏覽器、雲端工具，或是通用型或客制化的智慧裝置；只要能夠執行如後文所述之用戶節點10的各項功能者，皆應視為落入本發明的範圍之內。第一服務節點20與第二服務節點30於本實施例中則皆為終端伺服器，但這同樣不是本發明的限制所在；於其他實施例中，第一服務節點20與第二服務節點30也可能是其他種類的計算設備，或甚至由多台計算設備組成，例如分散在有線或無線網路不同位置的多個模組、元件或裝置等等，應皆屬於本發明的等效範圍之內。

其中，第一服務節點20與第二服務節點30都是構成一聯盟鏈（consortium blockchain）C的節點，唯需說明的是，實務上一個聯盟鏈通常不會只包含二個節點，此處所示例只是為了便於說明，並非暗示聯盟鏈C具有任何節點數量上的限制。本發明所提供的資料交換系統100係基於W3C提出的可驗證憑證（verifiable credential，VC）協議而運作，而在本實施例中提及的第一服務節點20與第二服務節點30之命名係以其在協議中所扮演的角色區分，更明確來說，第一服務節點20扮演的是可驗證憑證核發者（VC issuer），而第二服務節點30扮演的則是可驗證憑證驗證者（VC verifier）。換句話說，在任何可驗證憑證協議運作的情境下，負責可驗證憑證核發者之工作者，即為本發明所稱的第一服務節點20；而負責可驗證憑證驗證者之工作者，則為本發明所稱的第二服務節點30。需清楚理解的是，由於同一個終端伺服器於實務上可能同時俱備可驗證憑證核發者及可驗證憑證驗證者之功能，因此當其在一使用情境下做為可驗證憑證核發者時，即視為本發明的第一服務節點20；但當其在另一使用情境轉為擔任可驗證憑證驗證者時，同一個終端伺服器則轉而被視為本發明的第二服務節點30。此些敘述，純粹為解釋本發明元件命名的背後邏輯，是以，於解讀本發明之範圍時，不應囿於第一服務節點20及第二服務節點30的相關說明，進而錯誤地認定凡做為第一服務節點20者便不可能在另一情境下成為第二服務節點30，或者第二服務節點30便沒有在另一情境下轉為第一服務節點20之可能，合先敘明。

用戶節點10持有成對的一公鑰12及一私鑰14，較佳者，為提供更高的安全性，公鑰12可以是一實體金鑰，例如經過特殊設計的硬體晶片或USB裝置，但其實際實作方式並不以此處所舉例為限。另外，用戶節點10亦持有一數位身份16，其中數位身份16可以對應至用戶節點10使用者的身份證字號或真實姓名，亦可以是用戶節點10本身的機碼或序號，同樣不以此處所述為限；於本實施例中，數位身份16係為一去中心化身份（Decentralized Identity，DID）。需說明的是，數位身份16係對應至用戶節點10的使用者；換言之，也就是真實存在的使用者於本發明提供的資料交換系統100內所使用的對應身份，在本系統100內即代表了該位使用者。該去中心化身份以及與其對應的一去中心化身份文件（DID document，圖未示）可以共同或分別儲存於多種儲存媒介上，例如用戶節點10所具有的一分散金鑰管理系統（Distributed Key Management System，DKMS，圖未示）、本地或遠端伺服器上的一星際檔案系統（InterPlanetary File System，IPFS），或一般資料庫等等，較佳者，可儲存並映射於一區塊鏈，其中該去中心化身份文件是一個描繪該去中心化身份所識別之對象（即用戶節點10的使用者）的後設資料，亦包含認證方式之說明，供不特定第三方用以認證該去中心化身份之用。

第一服務節點20與用戶節點10資訊連接（亦即，二元件之間可以有資訊上的聯絡及流通），且保管有一用戶資料22。此處所述的用戶資料22指的是與用戶節點10的使用者有關的不特定資料，實務上可以是該使用者的醫療資料、保單資料、金融資料，或基本個人資料，其種類並不以此處所示例為限。實務上，前述用戶節點10所持有的該去中心化身份及對應的該去中心化身份文件可以是由第一服務節點20所產生，或者也可能是透過某個主管機關或權威單位產生，但此些技術相關並非本發明的重點所在。如前所述，第一服務節點20所扮演的便是可驗證憑證核發者的角色，更明確來說，第一服務節點20係使用用戶節點10所提供的公鑰12及該用戶資料22而產生一可驗證憑證24，同時亦對應產生一憑證資訊26，並傳送予用戶節點10留存。較佳者，第一服務節點20產生可驗證憑證24及憑證資訊26的動作係由用戶節點10所發動，舉例來說，可以是用戶節點10提出需要可驗證憑證24的請求，並傳送數位身份16（該去中心化身份）及公鑰12予第一服務節點20；第一服務節點20參照對應的該去中心化身份文件所載的認證方法，對該去中心化身份加以認證，並在認證成功、確定該去中心化身份確實代表用戶節點10的使用者後，再去產生可驗證憑證24及憑證資訊26；其中可驗證憑證24可以包含用戶資料22全部或部份之內容，並且可以包含或不包含該去中心化身份，端視需求而定。在本實施例中，第一服務節點20係將可驗證憑證24上鏈至聯盟鏈C，達成替可驗證憑證24存證之目的，而憑證資訊26就是可驗證憑證24的一區塊鏈位址。用戶節點10收到第一服務節點20傳來的憑證資訊26（此例中為區塊鏈位址）後，便將其留存，留待日後對可驗證憑證24的可信度進行驗證之用。需說明的是，用戶節點10可以將憑證資訊26保存於內部的一儲存空間（例如前述的該DKMS），亦可視情況保存於外部的一虛擬空間，其實際的儲存方式並不是本發明的限制所在。

於另一實施例中，第一服務節點20並不是將可驗證憑證24上鏈至聯盟鏈C，而是將其保存於一星際檔案系統（InterPlanetary File System，IPFS）。在這樣的實施例中，憑證資訊26自然就不是一個區塊鏈位址，取而代之的是可驗證憑證24的一內容辨識碼（content identifier，CID）。同樣地，當用戶節點10收到第一服務節點20回傳的憑證資訊26（本例中為該內容辨識碼），用戶節點10便將憑證資訊26保存起來留待日後使用。另值得一提的是，第一服務節點20可以進一步利用一去中心化身份解析器（DID resolver）對可驗證憑證24進行雜湊運算以產生一雜湊值，並將該雜湊值上鏈至聯盟鏈C，如此除了可以替可驗證憑證24存證，還能藉由解析包含在可驗證憑證24中的該去中心化身份而找出該去中心化身份文件。

當需要對可驗證憑證24的可信度進行驗證時，便是前述扮演可驗證憑證驗證者的第二服務節點30運作的時候。第二服務節點30同樣與用戶節點10資訊連接，二元件之間亦能進行資訊上的聯絡及流動，是以，第二服務節點30可以藉由用戶節點10所留存的憑證資訊26取得可驗證憑證24。更明確來說，在憑證資訊26為該區塊鏈位址的實施例中，第二服務節點30便是利用該區塊鏈位址於聯盟鏈C上取得可驗證憑證24；而在憑證資訊26為該內容辨識碼的實施例中，第二服務節點30則是利用該內容辨識碼，於第一服務節點20使用的該星際檔案系統中取得可驗證憑證24。當然，第一服務節點20也可能使用其他方式保存可驗證憑證24，但無論其所採用的方式為何，皆應可以對應產出憑證資訊26，使第二服務節點30能夠據以取得可驗證憑證24。

其中，可驗證憑證24包含有一驗證訊息24A，當第二服務節點30要驗證可驗證憑證24的可信度時，第二服務節點30便使用用戶節點10所提供的公鑰12對驗證訊息24A進行加密，並將加密後的驗證訊息24A傳送給用戶節點10，要求用戶節點10進行解密。由於用戶節點10持有對應的私鑰14，用戶節點10能夠使用私鑰14解開加密後的驗證訊息24A，進而得知驗證訊息24A的內容。待用戶節點10解出驗證訊息24A，便可以將驗證訊息24A回傳給第二服務節點30進行比對，若比對正確，即證明用戶節點10為持有私鑰14的正確使用者，也就是驗證了可驗證憑證24的可信度。

若第二服務節點30成功驗證可驗證憑證24的可信度，那麼便獲准取得第一服務節點20所保管之用戶資料22的至少一部份，藉此可以將用戶資料22的至少一部份交換給第二服務節點30，供第二服務節點30進行資料更新或同步等用途。其中，在該用戶資料22的至少一部份已包含於可驗證憑證24的情況下，第二服務節點30可直接由可信度已通過驗證的可驗證憑證24中取得；或者，第二服務節點30也可以透過其他方式，自第一服務節點20處取得所需資料。可以理解的是，若用戶節點10的使用者不希望讓第二服務節點30得知用戶資料22中的某些部份，該使用者可以透過操作用戶節點10，要求第一服務節點20只把部份的用戶資料22製成可驗證憑證24，如此便能在不透露不必要資訊的情況下將必要資訊傳送給第二服務節點30，藉此達到自主掌控用戶資料22揭露程度的目的，實務上更可能可以達成零知識證明（Zero Knowledge Proof）的需求；反過來說，本系統100實際的運作方式，當然也有可能是由第二服務節點30主動要求某些部份的用戶資料22，再由用戶節點10轉達給第一服務節點20，使得第一服務節點20能夠據以產生可驗證憑證24，並在其中只包含第二服務節點30所要求的該些部份的用戶資料22，如此也能避免過度透露資訊的情況。於本實施例中，第一服務節點20所保管的用戶資料22的至少一部份係透過一加密通道T傳送給第二服務節點30，其中加密通道T可以具有（但不限於）三層防護，其第一層防護為採用AES 256加密通道，第二層防護係對用戶資料22進行AES 256之文件加密，而第三層防護則是採用非開放式的通道協定。於另一實施例中，第一服務節點20也可以將用戶資料22保存於該星際檔案系統，而第二服務節點30則是透過該星際檔案系統取得用戶資料22的至少一部份。需理解的是，當然也可能有其他交換資料的實作方法，只要用戶資料22的至少一部份能夠安全傳送至第二服務節點30即可，並不以此處所示例者為限。

另外，為了確保聯盟鏈C上的所有節點皆參與運算及記錄，較佳者，聯盟鏈C係採用權威共識證明（proof-of-authority，POA）為其共識演算法。若需要進一步提高聯盟鏈C的開放性，聯盟鏈C也可以另外透過一側鏈S與一公鏈P連接，其中公鏈P可以是比特幣或以太幣所運作之區塊鏈，但並不以此為限。

亦需說明的是，雖然在前述說明中只有用戶節點10具有該非中心化身份，但這並不是本發明的限制所在；實務上在聯盟鏈C上的所有節點也可以都具有一個以上的非中心化身份，便於本系統100中的各個參與者能夠互相確認彼此之身份。不過非中心化身份的申請及取得並非本發明的重點所在，容此略過不述。

以下，本發明將以兩個使用情境來說明資料交換系統100的實際運作方式。請先參照第2圖，為第一種使用情境的步驟流程圖，其係在不同的保險公司之間傳送保戶個人資料之情境，其中用戶節點10為一保戶所使用的手機APP，第一服務節點20為一保險公司（下文稱保險公司A）之終端伺服器，第二服務節點30則為另一保險公司（下文稱保險公司B）之終端伺服器，而保戶希望透過本系統100將第一服務節點20上保存的用戶資料22傳送至第二服務節點30，此處所述的用戶資料22可以包含該保戶的身份證字號、基本個人資料，以及去中心化身份（DID）等等，但並不以此為限。

最初始的步驟S11是本系統100首次運作之時，於此時點尚不存在有可驗證憑證24，故尚需要由扮演可驗證憑證核發者的第一服務節點20負責產生可驗證憑證24。為達到此一目的，該保戶操作用戶節點10產生一對金鑰，即前文所稱之公鑰12及私鑰14，並將公鑰12傳送給保險公司A所擁有的第一服務節點20；於步驟S12，第一服務節點20使用用戶節點10傳送過來的公鑰12，將其所保存的用戶資料22製成可驗證憑證24。接下來，第一服務節點20於步驟S13，利用該去中心化身份解析器運算出可驗證憑證24的該雜湊值，並將該雜湊值上鏈至聯盟鏈C，藉以對可驗證憑證24進行存證。

請參照緊接的步驟S14，這個使用情境中的第一服務節點20係將可驗證憑證24保存於該星際檔案系統，因此憑證資訊26便是可驗證憑證24位於該星際檔案系統內的該內容辨識碼，且第一服務節點20會將該內容辨識碼傳送給用戶節點10留存，留待後續對用戶節點10所代表的該數位身份進行驗證時使用。在步驟S15，該保戶操作用戶節點10要求進行身份驗證，因此用戶節點10便將公鑰12以及該內容辨識碼傳送至保險公司B所擁有的第二服務節點30；藉由該內容辨識碼，第二服務節點30於第一服務節點20所使用的該星際檔案系統取得可驗證憑證24。接著，於步驟S16，第二服務節點30取出可驗證憑證24中所包含的驗證訊息24A，使用公鑰12對其加密，再將加密後的結果傳送給用戶節點10，要求用戶節點10協助驗證可驗證憑證24的可信度。

由於用戶節點10係正確的身份持有人，因此自然具有對應的私鑰14。在步驟S17，用戶節點10便使用私鑰14解出驗證訊息24A，再回傳給第二服務節點30。接下來的步驟S18，第二服務節點30比對自己持有的驗證訊息24A與用戶節點10回傳的驗證訊息24A，若二者完全相同，就證明了用戶節點10確實持有私鑰14，為具有合格身份者，因此可驗證憑證24的可信度便得到了驗證。最後在步驟19，第二服務節點30透過加密通道T自第一服務節點20取得用戶資料22的至少一部份或全部，至此成功完成了資料的交換。

基於這樣的運作邏輯，本系統100還可以進行更複雜的動作。舉例來說，該保戶可以對保險公司B的終端伺服器所保存的用戶資料加以更動，並在用戶節點10（即手機APP）上勾選將更動的資料同步至又另一保險公司（下稱保險公司C）的終端伺服器。需清楚理解的是，在進行此一動作時，是由保險公司B的終端伺服器負責對更動後的用戶資料生成可驗證憑證，而保險公司C的終端伺服器則負責身份驗證，因此保險公司B的終端伺服器此時應視為前文所述的第一服務節點20，而保險公司C的終端伺服器則成為前文所述的第二服務節點30。這一輪動作的第一服務節點20與第二服務節點30進行的各項步驟概如前述，請容此不再贅述，總之當保險公司C的終端伺服器（即此輪的第二服務節點30）完成身份驗證後，即可透過加密通道向保險公司B的終端伺服器（即此輪的第一服務節點20）取得更新後的用戶資料，以此進行資料的同步更動。由此例和第2圖所示之前例中可發現，保險公司B的終端伺服器在不同的情境下先後扮演了第二服務節點30及第一服務節點20；事實上，這樣具備雙重身份的節點並非特例，在實務操作上，聯盟鏈C上的所有節點都可以同時具有可驗證憑證核發者及可驗證憑證驗證者的功能，如此能更便利於實際的使用情境。

再請參照第3圖，為第二種使用情境的步驟流程圖，其係一保戶於一醫院完成治療後向一保險公司申請理賠，其中該保戶所使用的手機APP為前述的用戶節點10，醫院的終端伺服器為第一服務節點20，而保險公司的端終伺服器則為第二服務節點30。同樣地，在最初始的步驟S21之時點尚不存在有可驗證憑證24，需由第一服務節點20負責核發之。為達此一目的，該保戶操作用戶節點10，使其產生成對的公鑰12及私鑰14，且用戶節點10將公鑰12傳送至第一服務節點20。接著，在步驟S22，第一服務節點20便使用公鑰12及其所保存的用戶資料22產生可驗證憑證24，其中用戶資料22於此一使用情境中可能包含該保戶的身份證字號、基本個人資料、病歷、診斷證明，以及去中心化身份（DID）等等，但並不以此為限。

與前一使用情境不同的是，於步驟S23，第一服務節點20係將用戶資料22保存於該星際檔案系統，接著於步驟S24將可驗證憑證24上鏈至聯盟鏈C，而此時回傳給用戶節點10的憑證資訊26就是可驗證憑證24的區塊鏈位址。當保險公司收到該保戶的理賠申請，保險公司便需要對用戶節點10代表的該數位身份進行驗證，是以，在步驟S25，用戶節點10傳送公鑰12及憑證資訊26（於此例中為區塊鏈網址）給第二服務節點30，而第二服務節點30則透過憑證資訊26，於聯盟鏈C上取得可驗證憑證24。在取得可驗證憑證24之後，第二服務節點30於其中取出驗證訊息24A，並在步驟S26使用公鑰12對驗證訊息24A進行加密，將結果傳送給用戶節點10。

用戶節點10持有對應的私鑰14，因此可以在步驟S27解出驗證訊息24A的內容，並回傳給第二服務節點30。接下來的步驟S28，第二服務節點30比對用戶節點10回傳的驗證訊息24A以及自身持有的驗證訊息24A，若二者完全相同，即可證明用戶節點所持有的私鑰14確實與其公鑰12成對，換言之，用戶節點10具有合格的身份，可驗證憑證24的可信度得到驗證。最後的步驟S29，第二服務節點30獲准由第一服務節點20的星際檔案系統取得用戶資料22的至少一部份或全部，做為後續理賠之判斷依據。當然，保險公司的終端伺服器（即第二服務節點30）也可以與前一使用情境一樣，透過加密通道T自醫院的終端伺服器（即第一服務節點20）取得用戶資料；換言之，實際的資料交換方式於其他使用情境中也可以有更多的變化。

依據此處所述的使用情境，應能清楚理解，若該保戶同時於二家以上的保險公司投保，那麼其餘保險公司亦可以透過同樣或同理的步驟，向醫院取得用戶資料22。另外，為認證理賠申請動作為該保戶本人授權，實務上還可以選用自然人憑證、晶片金融卡，或MID行動身分識別加上生物特徵辨識之雙因認證等等，皆可整合至本發明所提供的資料交換系統100。值得一提的是，若依照習用的理賠申請程序，保戶需視投保之保險公司數量，向醫院申請多份診斷證明書紙本，再透過郵寄或業務人員代送等手動程序才能完成理賠送件，對照之下，本系統100能提供更安全、更隱私，也更便利的解決方案。

接著請參照第4圖，為本案第三種使用情境的步驟流程圖，同樣是一保戶於一醫院完成治療後向一保險公司申請理賠的情境。為方便日後的各種操作，該保戶可以加入一服務平台而成為其會員，再使用平台會員身分登入多家保險公司，分別成為各家保險公司之會員。該保戶所使用的手機APP就是前述的用戶節點10，該服務平台的一平台主機則為前述的第一服務節點20，至於各家保險公司的終端伺服器皆可分別視為前述的第二服務節點30。於步驟S31，該平台主機（即第一服務節點20）使用保戶手機APP（即用戶節點10）提供的公鑰12，將其所保存的用戶資料22生成可驗證憑證24及對應的憑證資訊26。其中可驗證憑證24的內容包含了用戶節點10所持有的該去中心化身、該平台主機的一去中心化身份，以及用戶資料22的至少一部份，包含但不限於該保戶是否為平台會員、是否已年滿十八歲、是否擁有會員公司保險紀錄等相關資訊。於本例中，憑證資訊26的內容為用戶節點10所指定的一去中心化身份地址，可驗證憑證24依照指示傳送至該去中心化身份地址，如步驟S32所述，憑證資訊26交由用戶節點10保存。當任何一家保險公司欲檢查該保戶的會員身份時，便於步驟S33，由其終端伺服器（即第二服務節點30）向用戶節點10要求憑證資訊，並據以取得可驗證憑證24。接著於步驟S34，第二服務節點30要求用戶節點10協助使用其私鑰14對可驗證憑證的可信度加以驗證，若驗證通過，在步驟S35，第二服務節點30就可以根據可驗證憑證24的內容，確認使用用戶節點10的該保戶是否為公司會員。

第5圖為本發明第四種使用情境的步驟流程圖，此一使用情境的背景係接續前一使用情境，惟此時是該保戶於完成治療後意欲申請理賠之時。在這樣的情境下，醫院的一醫療主機便成為前述的第一服務節點20，該保戶所使用的手機APP同樣是用戶節點10，而保險公司的終端伺服器也同樣是做為第二服務節點30。於步驟S41，該醫療主機（即第一服務節點20）製作電子診斷，並發行這一次的可驗證憑證24，其中可驗證憑證24包含用戶節點10的該去中心化身份、該醫療主機的一去中心化身份，以及用戶資料22的至少一部份，包含但不限於事故發生月份、該保戶是否已痊癒、是否使用健保看診、是否有自費用藥等資訊。於此例中，可驗證憑證24對應的憑證資訊26同樣是用戶節點10指定的一去中心化身份地址，憑證資訊26於步驟S42交由用戶節點10保管。接著於步驟S43，保險公司的終端伺服器（即第二服務節點30）根據憑證資訊26取得可驗證憑證24，並於接下來的步驟S44要求用戶節點10協助以其私鑰14驗證可驗證憑證24的可信度。一旦可信度得到驗證，保險公司的終端伺服器便能進行以下動作，包含但不限於進入該醫療主機資料集查詢可驗證憑證24的簽發紀錄、查詢該保戶的該去中心化身份、驗證該醫療主機金鑰簽章等等，之後便放行並進行保險公司內部的理賠收件流程。至於理賠服務所需要的個人醫療隱私資料（即用戶資料22的其中一部份），則於步驟S45透過一加密信封，由該醫療主機（第一服務節點20）出發，經由前述的該平台主機，送抵保險公司的終端伺服器（第二服務節點30）。

同樣依據第5圖所示意的流程，實務上還可以延續前二種使用情境進行後續動作，例如該保戶要求已接受理賠的該保險公司將理賠資料轉給另一保險公司。在這樣的情境下，已接受理賠的該保險公司的終端伺服器成為前述的第一服務節點20，該保戶使用的手機APP仍然是擔任用戶節點10，至於要接受資料轉達的該另一保險公司的終端伺服器自然就成為前述的第二服務節點30。一樣如步驟S41所示，已接受理賠的該保險公司的終端伺服器（第一服務節點20）使用用戶節點10的公鑰12來產生可驗證憑證24，其中可驗證憑證24包含該用戶節點10所持有的該去中心化身份、第一服務節點20所持有的一去中心化身份，以及用戶資訊22的至少一部份，包含但不限於是否為副本理賠、理賠金額是否未超過新台幣一百萬元等等。本例中的憑證資料26仍然是用戶節點10指定的一去中心化身份地址，憑證資訊26同樣於步驟S42交由用戶節點10保管，且可驗證憑證24依照指示儲存於憑證資料26所示的該去中心化身份地址。藉此，當該保戶要求將理賠資料傳送給該另一保險公司時，該另一保險公司的終端伺服器（即第二服務節點30）便可藉由憑證資料26按圖索驥取得可驗證憑證24，如步驟S43所述。緊接著，第二服務節點30於步驟S44要求用戶節點10使用其私鑰14協助確認可驗證憑證24的可信度，一旦得到驗證，第二服務節點30便可進行以下動作，包括但不限於進入第一服務節點20的資料集查詢可驗證憑證24的簽發紀錄、查詢用戶節點10的該去中心化身份，以及驗證前一使用情境所提及的醫療主機的金鑰等等。接著此處所述的該另一保險公司便放行並進行系統理賠流程。同樣地，理賠流程所需要的個人醫療隱私資料，如步驟S45所示，採用一加密信封由第一服務節點20（接受理賠的該保險公司的終端伺服器）發出，經由前述的該平台主機，再送達第二服務節點30（預備接受資料轉移的該另一保險公司的終端伺服器）。

再請參照第6圖，為本發明第五種使用情境的流程示意圖，其係應用於保險業務員遠距簽署保單之需求。依現行法規，保險業務員在處理保單簽署時，需要親晤親簽或視訊簽署，但由於本發明提供的資料交換系統100系基於身分自主權（SSI）架構而設計，因此可以藉以驗證線上的保戶為本人，進而達到本人親簽的法律效力。假設在聯盟鏈C內有一保險公司（下稱保險公司A）已經完成一保戶的詳盡KYC流程，並將相關資料結構化存放在公司內部的一伺服器內。若此時同一保戶欲向另一保險公司（下稱保險公司B）購買保險產品，保險公司B的業務員需要驗證該保戶是否為本人，該業務員可以透過一手持裝置（如平板電腦）發送要求驗證項目至該保戶的手機，這時該手機可以依序、同時或擇一執行以下三個動作：

一、檢查聯盟鏈C上有無相同驗證的上鏈紀錄，若有，便將公鑰提供予保險公司B業務員的該手持裝置，供其進行驗證運算，若驗算成功，便可認證為本人。

二、檢查手機自身儲存空間有無可做為驗證的可驗證憑證，若有，便傳送給保險公司B業務員的該手持裝置，此時該手持裝置會要求該手機以其私鑰解密，解密後的文本若確認為同，則確認為本人。

三、使用本發明所提供的資料交換系統100，亦即，該手機為前述的用戶節點10、保險公司A的伺服器為前述的第一服務節點20，而保險公司B業務員的該手持裝置則成為前述的第二服務節點30。於步驟S51，用戶節點10要求第一服務節點20產生合適的可驗證憑證24，此一可驗證憑證24包含用戶節點10所持有的該去中心化身份，以及用戶資料22的其中一部份，包括但不限於前述的KYC流程相關資料、有無既往症、有無購買其他保險公司保險產品、理賠總額度是否超過新台幣三百萬元等等。步驟S52，第一服務節點20遂使用用戶節點的公鑰12製作可驗證憑證24；於步驟S53，可驗證憑證24儲存至用戶節點10指定的一去中心化身份地址（此即為本例中的憑證資訊26）。接下來的步驟S54中，第二服務節點30根據憑證資訊26取得可驗證憑證24；步驟S55中，第二服務節點30要求用戶節點10以其私鑰12協助驗證可驗證憑證24的可信度，若驗證成功，則同樣可以確認為本人。

最後，請參照第7圖，為本發明第六種使用情境的流程示意圖，其情境係關於保險招攬市場上的業務員資格驗證機制，目的在於克服業務員與保戶間的資訊不對等問題，並有助於保戶挑選良好的業務員。業務員的水準能夠透過金融法規要求的相關資格、共同考試而確保，法規也要求業務需要每年進行教育訓練，取得證照後才能招攬業務。傳統的驗證方法雖可幫助保戶確定業務員的資格，但卻會過度曝露業務員的個人隱私資料，對業務員而言是一種權利侵害，而這個問題能夠透過使用本發明提供的資料交換系統100得到解決。

假設現在有一業務員於一考試及訓練機構通過考試，並完成相關教育訓練，此時該業務員所使用的手機APP即為前述的用戶節點10，而該考試及訓練機構的終端伺服器便可扮演前述的第一服務節點20，並且就該業務員的考試及訓練結果，使用用戶節點10的公鑰12製作可驗證憑證24（步驟S61），其中可驗證憑證24的內容包含該業務員的一非中心化身份以及其用戶資料的至少一部份，包括但不限於某年度業務員資格考試結果、某年度金融市場與道德考試結果、某年度投資型保單業務員資格考試結果、某年度法遵六小時教育訓練結果等等。於步驟S62，可驗證憑證24係傳送至該業務員使用的手機APP（用戶節點10）而留存於該處。

若現在有一保戶欲驗證該業務員之資格，該保戶所使用的手機APP即為前述的第二服務節點30。此一需求可以簡單透過掃描第一服務節點20產生的QR code而完成，或者，在步驟S63，第二服務節點30要求用戶節點10提供可驗證憑證24，接著在步驟S64，第二服務節點30要求用戶節點10以其私鑰14驗證可驗證憑證24的可信度。若可驗證憑證24的可信度得到驗證，那麼第二服務節點30便能從中取得用戶資料22的至少一部份（步驟S65），藉此確認該業務員是否為合格。除此之外，為加強該保戶的信任，還可以進一步利用聯盟鏈C對該業務員的數位證書進行驗證，二次確認發證方（該考試及訓練機構）的資格。

實務上，因應使用者欲進行之動作可能具有不一樣的安全需求等級，用戶節點10也可以具有多層的安全架構，在不同的層級上套用本發明所提供的資料交換系統100。舉例來說，檢視保單或查看存摺等動作一般來說對安全的需求較低，用戶節點10可以透過FIDO（Fast IDentity Online）架構搭配前述身份驗證方法或其它身份自主權（Self-sovereign identity，SSI）做法進行驗證；理賠或小額支付等動作相對需要較高一些的安全等級，用戶節點10可以對應加上區塊鏈金鑰驗證；最後，保單購買、大額轉帳及支付等動作需要最高的安全等級，那麼用戶節點除了區塊鏈金鑰驗證，還可以再加上基於時間的一次性密碼演算法（Time-based One-Time Password，TOTP）來進行驗證。這裡以實際的使用情境略加說明：若有一保戶欲向一保險公司投保，習用的做法需經過業務員或電銷客服協助填寫個人資料，轉送核保部門進行紙本審核；即使轉用較新的線上投保流程，投保產品較為受限，且仍需要耗時填入個人資料，而驗證手段多採用MID行動身分識別，驗證時間長，成本又高。

相較之下，該保戶可以先經過詳細的KYC流程，接著採用本發明提供的資料交換系統100，保戶使用的用戶節點10能向保險公司的終端伺服器（即第一服務節點20）傳送高階交易金鑰中的公鑰12、身份證字號等資訊，再由第一服務節點20產生可驗證憑證24。若現有另一保險公司欲取得該保戶的用戶資料22，便可透過其終端伺服器（即第二服務節點30）進行身份驗證，再向第一服務節點20取得，俾利於進行其後續的內部核保作業。

另外，僅管上述所有使用情境中的資料交換行為皆發生在單一聯盟鏈C上，實務上當然不能排除有跨鏈驗證之需求。詳細來說，在目前的商業應用下，為兼顧隱私及法規要求，有時會有一項完整服務需要仰賴超過一個以上的聯盟鏈之情形，例如醫療資料可能存證在一醫療聯盟鏈上、教育憑證存證在一教育鏈上、KYC認證則存證在一金融鏈上等等，各種資料有可能需要跨鏈驗證。在不同的聯盟鏈上會有不同的資料結構，有可能透過妥善利用本發明提供的資料交換系統100，在不需要散佈個人資料的狀況下進行整個區塊鏈網路和發證方的背書認證。

總結來說，本發明所提供的資料交換系統100可以在滿足現行法規及個資保護的前提下，以安全便利的方式進行身份驗證，並能有效交換資料，且由於其運作於聯盟鏈C上，還可以減輕使用公鍵P的負擔，節省區塊鏈使用的服務費，實為一自動化、高安全性、適用情境廣泛，且成本低廉的良好解決方案。

以上所述僅為本發明較佳可行實施例而已，舉凡應用本發明說明書及申請專利範圍所為之等效結構或方法變化，理應包含在本發明之專利範圍內。

100:資料交換系統

10:用戶節點

12:公鑰

14:私鑰

20:第一服務節點

22:用戶資料

24:可驗證憑證

24A:驗證訊息

26:憑證資訊

30:第二服務節點

C:聯盟鏈

S:側鏈

P:公鏈

T:加密通道

S11-S19:步驟

S21-S29:步驟

S31-S35:步驟

S41-S45:步驟

S51-S55:步驟

S61-S65:步驟

第1圖為本發明一實施例之資料交換系統的示意圖；第2圖為本發明第一種使用情境的步驟流程圖；第3圖為本發明第二種使用情境的步驟流程圖；第4圖為本發明第三種使用情境的步驟流程圖；第5圖為本發明第四種使用情境的步驟流程圖；第6圖為本發明第五種使用情境的步驟流程圖；以及第7圖為本發明第六種使用情境的步驟流程圖。