原载微信公众号 金融科技·微洞察 （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）指的是账户被网络罪犯控制，这可能会导致账户内数据的泄露，并可能因此影响到其他多个账户。

责任编辑：王超