原載微信公眾號 金融科技·微洞察 （ID：weinsights）

1. 數據傳輸項目（DTP）產生的背景

在當下的信息化社會中，每個人都在使用不同的服務供應商所提供的互聯網服務，因此都將自己的信息數據存儲在不同的服務供應商中，如蘋果、谷歌等。為了更好地保護消費者個人數據隱私，歐美出臺了一系列用戶隱私保護法規如GDPR，規定用戶擁有嚴格的個人數據權利——包括但不限于訪問權（right of access）、更正權（right to rectification）、擦除權（“被遺忘權”）（right to erasure）等權利。更好地保證用戶對數據的相關權益、避免違反相關法律法規就成為當下世界各國互聯網服務供應商急需解決的問題。一個簡單直接的解決方法就是開發出一個數據傳輸系統，允許用戶在不同服務供應商之間方便、快捷且安全地傳遞自己的數據，完全實現對個人數據的自主掌控權。數據傳輸項目（Data Transfer Project,下文簡稱為DTP）因此應運而生。

2. 什么是DTP

DTP項目由Google、Facebook、Microsoft、Twitter四大互聯網巨頭聯合發起于2018年，目的是創造一個服務對服務的開源數據遷移平臺。DTP擴展了數據的便攜性，為用戶提供了在參與項目的服務供應商之間傳輸數據的平臺。

DTP采用開源的目標是鼓勵盡可能多的服務供應商參與。它減少了服務供應商和用戶的基礎設施負擔，增強了數據便攜性生態系統，這樣就會增加提供數據遷移服務的數量，進而形成一個服務質量與數量不斷提高的循環過程。目前的主要參與者、貢獻者包括蘋果公司，Facebook，Google，微軟集團和Twitter。

下圖展示了理想情況下的DTP工作過程：

/upload/resources/image/2021/06/15/181296_700x20000.png"/>

在這個例子中，一位Google用戶希望將他的一些照片轉移至微軟的OneDrive中。用戶打開Google 的文件傳輸界面，選擇目的地，然后點擊"發送"。在這之后，他必須授予微軟公司讀寫照片的權限，如上圖所示。其中授權認證使用了OAuth協議。所選照片會自動復制并傳輸到目的地，而無需使用用戶的帶寬或硬件。

3. DTP是如何工作的

DTP的系統主要由三個部分構成：數據模型文件（Data Models），適配器（Adapters）和任務管理庫（Task Management Library）。

3.1 數據模型文件（Data Models）

DTP在數據模型文件的框架模型中規范了如何傳輸數據的具體格式。

數據模型文件包括兩個部分：一是文件格式，二是接收方準確接收數據所需要的額外元數據。數據模型文件通常按照類別分組聚集在一起，形成垂直系統（Verticals）。垂直系統的文件格式類似于一個棧（stack）。服務供應商可以在一個或多個垂直系統中擁有數據，每個垂直系統擁有自己的一組數據模型文件，可以無縫傳輸相關數據。

理想情況下，一個垂直系統的數據模型文件應該有通用的標準，有良好的、被廣泛接納的定義，這樣不同服務供應商的數據模型就能互通。然而實際情況并非如此，各種數據模型文件沒有通行標準，整個生態系統互不聯通。

DTP的一個主要目標是希望各個服務供應商使用標準的、通用的數據模型文件結構，這樣可以顯著減少維護和更新相關API的需求。另外，DTP在開發期間應該與外部標準化機構合作，商定標準化的數據模型文件結構。如果沒有標準化的數據模型文件結構，各個公司或服務供應商之間就會采用是完全不同的數據模型文件結構，這毫無疑問將極大地影響DTP的可用性。在制訂出標準數據模型文件結構后，各個服務供應商之間還需要繼續合作，持續進行API的維護，來更新功能、應對變化的標準或格式，各大服務供應商之間的合作依然是一個長期的，持續互利的過程。

/upload/resources/image/2021/06/15/181297_700x20000.png"/>

在上圖中，左圖是未參與DTP時，各個服務供應商間傳輸數據的情況。每一個服務供應商必須構建和維持API專用的適配器，并且可能還要提供數據格式給不同的服務供應商。右圖是參與DTP時，各個服務供應商間傳輸數據的情況。每一個服務供應商只需要構建和維持基于公開可用標準格式的，支持DTP數據模型文件的API即可。

3.2 適配器（Adapters）

在DTP的系統中主要有兩種適配器：數據適配器（Data Adapters）和身份認證適配器（Authentication Adapters）。這些適配器存在于各個服務供應商的核心架構之外，可以由服務供應商自己編寫，也可以由需要傳輸數據的第三方進行編寫。

3.2.1數據適配器（Data Adapters）

數據適配器是一段代碼，它將數據通過API在供應商與DTP中的數據模型文件之間轉移。數據適配器都是成對出現的，一個負責將服務供應商中的數據通過API轉入至數據模型文件，另一個負責將數據從數據模型文件中轉出至接收方服務供應商。

3.2.2身份認證適配器（Authentication Adapters）

身份認證適配器是一段代碼，負責在傳出或接收來自其他服務供應商的數據之前認證賬戶身份。DTP并不關心服務供應商采用何種方式進行身份認證。目前大部分服務供應商選擇使用OAuth協議。

服務供應商之前使用適配器傳輸數據的過程如下圖所示：

/upload/resources/image/2021/06/15/181298_700x20000.png"/>

3.3任務管理庫（Task Management Library）

任務管理庫負責處理后臺任務，例如適配器之間的呼叫聯系、安全數據存儲、重試邏輯（retry logic）、速率限制（rate limiting）、分頁管理（pagination management）、故障處理（failure handling）、單獨通知（individual notifications）等。

DTP已經研發出一系列的任務管理庫，作為利用適配器進行數據傳送的參考標準。各個服務供應商也可以開發自己的任務管理庫來使用DTP中的數據模型文件和適配器。

/upload/resources/image/2021/06/15/181299_700x20000.png"/>

上圖是DTP系統組件之間交互的概述。網關服務器通過身份驗證適配器為用戶數據進出授權，并存儲數據庫中用于傳輸請求的加密憑證和元數據。一個叫Worker[1]的流程會被創建出來，分配到特定的轉移請求中，調用任務管理庫來協調和執行進出數據的任務，然后可以選擇在數據庫或Blob Store[2]之間以加密形式存儲數據。

任務管理庫建立在通用云接口之上，因此DTP托管平臺可以在本地生產環境或云平臺上運行（詳見下一節介紹）。這些云接口必須要高度抽象化以便其在各個服務供應商的云平臺上運行。

4. DTP的部署架構4.1 托管平臺部署（Deploying a Host Platform）

部署DTP實例需要多個步驟才能最終滿足DTP的所有要求。首先是要獲取API密鑰，這不僅允許托管實體決定它與哪些服務供應商進行交互，并且允許每個服務供應商自己決定給其他哪些托管實體密鑰。其次進行部署工作，DTP應用docker 鏡像進行構建。最后是創建UI界面，當托管平臺部署完成后，DTP會設置一個RESTful接口，允許用戶通過HTTPs協議發送請求來開始或管理傳輸數據的工作，創建一個UI界面能夠使用戶更輕松地與DTP系統進行交互。

4.2 部署模型

DTP托管平臺可以通過三種模型部署使用，分別是分布式，集中式和自我管理（self-managed）。

4.2.1分布式

分布式的優點是數據永遠不會由第三方處理。只有源數據服務供應商和接收服務供應商才能訪問數據本身。缺點是它限制了向運行托管平臺的服務供應商的數據傳輸，并且每個服務供應商還需要額外負責在維護單獨的托管平臺過程中產生的高額間接費用。

分布式部署時，DTP系統傳輸數據時具體流程如下圖所示：

/upload/resources/image/2021/06/15/181300_700x20000.png"/>

當用戶希望在Google和Apple兩個服務供應商之間傳輸數據時，他們作為托管實體（Hosting Entity），使用DTP適配器、數據模型文件傳輸數據。當用戶希望在其他服務供應商與Google或Apple之間傳輸數據時，Google與Apple作為托管實體搭建并運行托管平臺（Host Platform），完成數據的傳輸。

4.2.2集中式

集中式系統的優點是，在集中式系統的框架下，許多沒有資源或專業知識來運行托管平臺的小公司，只需要編寫和維護適配器就可以加入DTP。缺點是需要集中數據的第三方值得信賴，并且在數據保護方面技術成熟。

集中式部署時，DTP系統傳輸數據時的具體流程如下圖所示：

/upload/resources/image/2021/06/15/181301_700x20000.png"/>

集中式部署指的是由第三方作為托管實體（Hosting Entity）搭建并運行托管平臺（Host Platform）。不同的服務供應商通過編寫和維護適配器加入到第三方DTP系統的托管平臺中，之后由第三方作為托管實體幫助他們傳輸數據。

4.2.3自我管理（self-managed）

在自我管理的環境中，用戶可以在本地或在其專用云實例中下載和運行 DTP 副本。自我管理的好處是，它允許用戶完全控制傳輸過程?？梢酝ㄟ^端到端加密在服務供應商之間傳輸數據，而不必上傳或共享其私鑰。還可確保在服務供應商停止運行托管平臺的情況下，用戶仍能夠將數據傳輸到該服務供應商，或從該服務供應商處接收數據。缺點是運行托管平臺需要更多資源，并且大多數用戶無法承擔復雜的維護工作。

5.DTP系統中的安全與隱私

用戶數據的安全和隱私是數據傳輸項目的根本，因為在數據傳輸的過程中涉及到的人、公司或實體實在是太多了，沒有哪一方面能夠單獨保證整個系統中數據的安全與隱私。DTP項目中的數據傳輸的安全要求是十分嚴格的。DTP 設計的一個重要目標是，托管實體無法在非授權情況下訪問用戶的數據，并確保每一個管理員都無法獲得訪問用戶數據的密鑰。

托管實體決定了可以交互的服務供應商范圍。每個托管實體固定要從某個服務供應商處請求 API 密鑰，每個提供商選擇授予 API 密鑰給某個托管實體。這些做法可以確保數據得到適當的、安全的存儲及使用。

以下是一些有助于確保DTP中數據安全和隱私的一些主要責任和做法：

數據最小化（Data Minimization）

速率限制（Rate Limiting）

用戶通知（User Notification）

令牌撤銷（Token Revocation）

認證令牌范圍最小化（MinimalScopes forAuth Tokens）

數據保留（DataRetention）

防濫用（Abuse）

詳情請參見附錄：共享責任表：安全與隱私（Shared Responsibilities Table: Security and Privacy）

6. DTP生態系統事務（Ecosystem Issues）

6.1 項目治理

隨著DTP的成熟，它可能受益于中立治理機構的成立。治理機構的目標應包括：

a）項目的宣傳方案

b）發布和維護有助于其他服務供應商發現參與的注冊網站

c）管理開源存儲庫

d）建議和報告安全和隱私最佳做法和執行機制。

6.2 多種不一致的API（Inconsistent API Landscape）

盡管DTP項目強調使用開放的標準和網絡技術，但仍存在技術和公共政策方面的問題。DTP 面臨的一個問題是多種API之間的不一致[3]，尤其是在提供服務的靈活性方面。這個問題會導致用戶無法按照他們自己的意愿去隨時更換服務供應商，或者無法直接在不同的服務供應商間傳輸數據。

6.3互惠性

健康的數據便攜性生態系統中的服務供應商應當具有同等的數據進出功能。如果服務供應商允許導入數據但不允許類似級別導出數據，這可能會導致數據用被保留在某些服務中無法刪除，從而給用戶帶來風險?？梢酝ㄟ^以下幾個方面來促進DTP生態系統的互惠性。

源代碼方面：鼓勵向GitHub中的源代碼做出貢獻，代碼中需要包括配對的數據導出和接收功能。

透明度方面：鼓勵每個服務供應商提供用戶在向服務供應商導入和導出數據時遇到的問題，并匯總統計相關情況。這有助于確保將不同服務供應商的導入導出數據功能維持在相同的可靠性水平。

自動可信度測試（Automated fidelity test）：托管實體可以與各個服務供應商建立測試賬戶，并定期向每個服務提供進出數據，以確保數據以適當的可信度、保真度導出。在導入時，可以再次以透明的方式向用戶提供此信息，以確保用戶在選擇服務供應商時能夠做出明智的決定。

數據便攜性供應商承諾（Data Portability Provider Pledge）：服務供應商可以共同努力，協定他們共同可接受并遵循的有關數據遷移的最佳實踐承諾。托管平臺可以選擇去支持遵循相關承諾的服務供應商，用戶界面可以展示給用戶遵循相關承諾的服務供應商，并且關于生態系統互惠狀況的報告也將發送給用戶。

7. DTP合作伙伴在數據傳輸時共同的標準與原則

為用戶構建：數據便攜性工具應當很容易找到，使用方便，并且隨時準備為用戶服務。

隱私和安全：在數據傳輸兩端的服務供應商必須有強力的安全和隱私保護措施。

互惠性：雖然DTP為用戶提供了在傳輸移植數據方面的更多靈活的選擇，但重要的是要防止與用戶利益不一致的激勵措施。例如當用戶將數據轉移至其他服務供應商平臺服務時，不應導致用戶失去對數據的控制。

關注用戶數據：數據的便攜性工作應強調支持單獨用戶的數據和使用情況。專注于用戶創建、導入、收集或控制的數據內容。服務供應商可以通過減少在產品或服務之間切換的復雜性，或用戶以新方式使用數據的難度，更好的為用戶提供數據傳輸服務。

關注每一個用戶：數據便攜性工具應僅專注于提供他們直接相關的數據給請求傳輸數據的用戶。這樣在便攜性、隱私性和嘗試新服務之間取得了適當的平衡。

8. 總結

DTP系統通過數據模型文件，適配器以及任務管理庫三個主要模塊之間的分工與合作，完成了對在不同服務供應商上數據的相互傳輸與移植；服務供應商通過分布式，集中式或自我管理這三種方式中的一種完成了對托管平臺以及相關服務器的部署；通過開源互惠的開發方式完成了對數據傳輸移植時相關標準與原則的制定，最終實現了數據在不同服務供應商之間能夠做到安全，便捷的傳輸和移植。

DTP的主要參與者與貢獻者們鼓勵業界對數據移植生態系統采取更大膽、更廣闊的視角。DTP項目一直在計劃與更多的貢獻者合作，繼續迭代更新相關系統的設計，培養便攜性的思想和想法?？梢韵胂蟮氖?，如果未來這個項目有了足夠多的服務供應商或參與者，DTP項目將會成為我們在不同的電子設備之間傳輸數據的一種極其便捷的方式，甚至有可能會成為大多數人傳輸數據時的首選。

9. 附錄：共享責任表：安全與隱私（Shared Responsibilities Table: Security and Privacy）

以下是關于確保DTP數據安全和隱私的主要做法詳細介紹：

a)數據最小化（Data Minimization）：當數據在服務供應商之間傳輸時，只能保留能夠完整為用戶提供服務的最小數據集。在向其他服務供應商提供相關信息時，只應提供他們所需要的相關信息。

b) 速率限制（Rate Limiting）：托管實體或服務供應商應當控制傳輸數據給用戶的頻率。通過這種方式能夠減少賬戶入侵（Accountcompromise）[4]的發生概率和影響。

c) 用戶通知（User Notification）：當傳輸某些重要數據時，系統會在傳輸開始前通知源用戶和目的用戶，并且適當延遲傳輸。以便用戶在需要時可以及時取消傳輸進程。

d) 令牌撤銷（Token Revocation）：數據傳輸完成后，DTP會撤銷用于傳輸數據的令牌。這樣可以防止在令牌泄露后，更多的數據泄露，確保了安全性。

e) 認證令牌范圍最小化（Minimal Scopes for Auth Tokens）：服務供應商只為認證令牌提供一個比較小的權力范圍，而且不會授予認證令牌讀寫數據的權限，以此來防止數據遭到不正當篡改或丟失。

f) 數據保留（Data Retention）：DTP只在傳輸數據的過程中保留數據，并且一切數據的保留都是加密的，這有保護了用戶數據的安全與隱私。

g) 防濫用（Abuse）：服務供應商或托管實體應該在API中內置強大的防濫用保護程序，例如在授予訪問權限之前先提出安全問題等，防止數據被濫用。

/upload/resources/image/2021/06/15/181302_700x20000.jpeg"/>

/upload/resources/image/2021/06/15/181303_700x20000.png"/>

關注公眾號并回復：DTP下載DTP項目的英文白皮書PDF

【注釋】

[1] "Worker"是一個孤立的虛擬機，利用任務管理庫來操控適配器，在啟動數據傳輸時創建，并在傳輸完成時銷毀。Worker在創建時生成一個臨時密鑰，當被銷毀時，該密鑰也被銷毀。

[2] Blob store是基于文件系統的，可以簡單的理解為一個文件夾。Blob store可以被一個或者多個倉庫組使用。一個倉庫只可以使用一個Blob Store，一個Blob Store可以對應多個倉庫。

[3]導致有多種不一致的API的原因是：一些公司缺乏開放式 API，而另一些公司沒有充分支持或維護它們的能力，無法大規模實現服務到服務的數據便攜性。即使公司提供不同類型的開放 API，它們的服務條款也可能有限制，例如禁止使用 DTP 等相關條款，或通過限制用戶遷移其數據阻止消費者嘗試新服務。

[4]賬戶入侵（Account compromise）指的是賬戶被網絡罪犯控制，這可能會導致賬戶內數據的泄露，并可能因此影響到其他多個賬戶。

責任編輯：王超