22 | MyData Architecture - The Stack 23 |
24 | 25 | 26 |27 | Download paper in PDF 28 |
29 | 30 |MyData reference architecture presented in this set of specifications is a human centric approach to liberate the potential of personal data and to facilitate its controlled flow from multiple data sources to applications and services. It responds on a practical and technical level to individuals growing demand for control over their own digital identity and to organizations need to fulfill the requirements of tightening data protection regulation, especially on digital, dynamic consents. Architecture takes an attempt to provide individuals and service providers a rigid framework for consent and data authorisation management and service registration via a standard and interoperable mechanism.
31 | 32 |Download technical specifications linked to the master architecture:
33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 |The specification set is work in progress and this release (1.2.1) is open for comments and suggestions from all readers.
45 | 46 |Contact: Antti Poikola (antti.poikola@hiit.fi), Harri Honko (harri.honko@tut.fi)
47 | 48 |You can also join the Gitter chat or suggest changes via Github issues.
49 | 50 |Authors:
51 | 52 |53 | Anette Alén-Savikko Aalto University / Helsinki Institute for Information Technology HIIT 54 | Nomi Byström Aalto University / Helsinki Institute for Information Technology HIIT 55 | Harri Hirvonsalo University of Oulu 56 | Harri Honko Tampere University of Technology 57 | Antti Kallonen Tampere University of Technology 58 | Yki Kortesniemi Aalto University / Helsinki Institute for Information Technology HIIT 59 | Kai Kuikkaniemi Aalto University / Helsinki Institute for Information Technology HIIT 60 | Tuomas Paaso VTT Oy 61 | Olli Pitkänen Aalto University / Helsinki Institute for Information Technology HIIT 62 | Antti Poikola Aalto University / Helsinki Institute for Information Technology HIIT 63 | Samuli Tuoriniemi University of Oulu 64 | Sari Vainikainen VTT Oy 65 | Jani Yli-Kantola University of Oulu 66 | 67 |68 | 69 |
We are in progress of publishing a html version of the specification, but that is at the moment (Sep 2016) only experimental and not complete.
70 | 71 | 72 |
[a][b]
28 |
29 | README : [https://github.com/HIIT/mydata-stack](https://github.com/HIIT/mydata-stack)
30 |
31 | **Notice**
32 |
33 | This document has been prepared by Participants of Digital Health Revolution research program and is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
34 |
35 |
36 |
37 | Implementation or use of certain elements of this document may require licenses under third party intellectual property rights, including without limitation, patent rights. The Participants of and any other contributors to the Specification are not and shall not be held responsible in any manner for identifying or failing to identify any or all such third party intellectual property rights. This Specification is provided "AS IS," and no Participant makes any warranty of any kind, expressed or implied, including any implied warranties of merchantability, non-infringement of third party intellectual property rights, and fitness for a particular purpose.
38 |
39 | MyData Architecture defines the operations and APIs between the Operational Roles (Operator, Source, Sink etc.). Any descriptions or figures of the role’s internal structure or operations are for illustrative purposes only.
40 |
41 | # Introduction # {#intro}
42 |
43 | Applications and services collect increasing amounts of personal data about their users, and leverage it to extract valuable knowledge about them. This information can be used for providing new services and for profiling individuals, and the results are monetizable input for e.g. targeted advertising. Unfortunately, individuals themselves typically have little or no control over how their data is created or used.
44 |
45 | This document presents the MyData architecture, a human centric approach to liberate the potential of personal data and to facilitate its controlled flow from multiple data sources to applications and services. The simple core idea, the *individual in control of their own data*, is both a movement for digital human rights and an initiative for opening new business opportunities. It responds on a practical and technical level to individuals’ growing demand for control over their personal data and to organizations need to fulfill the requirements of tightening data protection regulation. Though both of these goals can be achieved within the current legal framework, the lack of interoperable implementations has kept them mostly a distant goal - a situation that we now want to change.
46 |
47 | The legal framework (NOTE: In this document we use the upcoming EU General Data Protection Regulation (GDPR) as example and detail it further in a separate info box.) for protecting personal data usually starts with a freely given, specific, informed and unambiguous consent. In order for their personal data to be processed, the individual has to make a conscious choice to give consent to the external organization to process data. The consent has to be withdrawable, readable by involved trusted parties, and it should be stored in appropriate place for validity checking by the parties using or providing person’s data. This is the exact premise chosen as key guiding rule of the developed MyData model.
48 |
49 | The architecture aims to provide a standard for implementations that
50 |
51 | * satisfy the legal requirements for processing of personal data and, thus, prevents unwanted and improper processing of the individual’s personal data
52 |
53 | * enable the individuals to easily grant and withdraw their consent for data processing
54 |
55 | * provide transparency to individuals about how their data is being used
56 |
57 | * enable flexible service creation and new business opportunities
58 |
59 | In the following sections we present an overview of the MyData architecture (Section 2), and detail the key parts of the architecture: MyData Account (Section 3), Service Registry and Service Discovery (Section 4), Service Linking (Section 5), Authorisation (Section 6), and Data Connection (Section 7). Each detail Section has a corresponding detailed technical document (see References).
60 |
61 | This is the third (v1.2) release of the specification and will be developed upon feedback.
62 |
63 | 
84 |
85 | *Figure 2.1: **Four operational roles within the MyData architecture include 1) individual as the Account Owner 2) MyData Operators, 3) Sources, and 4) Sinks. The MyData Account is hosted by the Operator. Note that the flow of authorisations to use the data is separate from the flow of data.*
86 |
87 | ### MyData Account ### {#account}
88 |
89 | A key human centric concept in MyData architecture is MyData Account, which contains individual’s digital identity or identities, linked services, and authorisations. Potentially, these are complemented with individual’s other data that help in providing additional or improved services.
90 |
91 | The Account is hosted by an independent MyData Operator, which also provides the tools for the individual to manage their account.
92 |
93 | Finally, MyData Account also enables the user to switch Operators by taking their Account with them. Portability of the MyData Account is deferred to a later architecture release.
94 |
95 | ### Operational Roles ### {#roles}
96 |
97 | There are four key operational roles in the My Data architecture: *Account Owner*, *MyData Operator*, *Source* and *Sink*. Actors (organisations and individuals) may work in one or many of the operational roles. It is e.g. very typical for an organisation to simultaneously be in the role of Source and Sink.
98 |
99 | Account Owner is the individual who created and is using the account to link new services (see *Service Linking*) and authorise data flow (see *Authorisation*). Account Owner is usually the Data Subject as defined in Data Protection legislation. One Data Subject may have multiple accounts hosted by the same or different Operators.
100 |
101 | Main purposes of the MyData Operator are to host MyData Accounts as well as the user interface for managing those accounts. Operator also has to provide the underlying mechanisms for linking Sources and Sinks to the account, and managing the account specific authorisations. The basic vision of the architecture enables the existence and use of multiple operators. Each individual can choose to use one or more operators to manage their authorisations.
102 |
103 | Source is an entity that can, when authorised, provision Account Owner’s data to one or more Sinks and, correspondingly, Sink is an entity that can, when authorised, fetch data from one or more Sources and use the data to produce the agreed services. Both Sources and Sinks need to provide the corresponding MyData-compatible interfaces. Source interfaces enable the management of data provisioning, while Sink interfaces enable the management of data usage. It is quite common that a service is working both as Source and Sink, and providing, therefore, both Sink and Source capabilities and interfaces.
104 |
105 | ### Mapping the operational roles with legal roles ### {#mapping}
106 |
107 | For clarity, it is important to map the operational roles Account Owner, Source and Sink with the corresponding legal roles - Data Subject, Data Controller and Processor. The GDPR legal framework only covers cases of personal data where the Data Subject is a natural person, but the MyData architecture technically may be used also for managing other data.
108 |
109 | When the Account Owner is a natural person and their data is being processed, the Account Owner is the Data Subject. The other legal roles in MyData system can be then determined by answering two questions:
110 |
111 | 1. Who determines the purposes and means of the processing of personal data?
112 |
113 | 2. Who actually processes the data?
114 |
115 | Two typical cases as shown in Figure 2.2 are:
116 |
117 | Delegation With Account Owner’s consent, Sink accesses personal data from the Source and processes it for the defined purpose. In this case, both the Source and the Sink are in legal terms Data Controllers.
118 |
119 | Repurposing Service is processing personal data for a specified purpose within its own scope - at some point the service may suggest for the Account Owner a new purpose or means of processing data. In this case the Service is in legal terms the Data Controller.
120 |
121 | 
122 |
123 | 
179 |
180 | *Figure 2.4: Key related standards.*
181 |
182 | The development of MyData architecture has been influenced by many existing and upcoming standards, specifications, and questions raised from reading them. Of particular importance are OAuth 2.0, User Managed Access (UMA) and OpenID Connect as well as the upcoming Kantara Initiative’s Consent Record specification (abbreviated here and in other MyData technical specifications as KI-CR). When applicable, we have used the existing technologies and terminology, but in some areas we have simplified the solution to better suit our needs.
183 |
184 | Our authorisation is based on a centralized authorisation server similar to UMA. The fact that resource servers and clients are always discoverable and trusted via their registration to the service registry enables our authorisation flow to require fewer messages compared to full UMA flow as we no longer need to introduce the parties to each other in the beginning of authorisation.
185 |
186 | The authorisation mechanism used in this architecture is similar to OAuth 2.0 Authorisation Code flow model as the communication is expected always to happen between secure servers. No other flows are supported. A strong conceptual difference is in defining Resource Sets that are finally to be authorised: Resource Set Registration is initiated in our architecture by the Resource Owner at the time of authorisation transaction, not a priori by the Resource Server.
187 |
188 | We use JSON Web Token and JSON Web Key from OpenID Connect’s model to authenticate each party (RS, AS, client, Service Registry) involved in the message exchange. Also, OpenID Connect related Identity provider & federation models for arranging the assurance levels and trust network required in the background is currently work-in-progress.
189 |
190 | Consent and assignment registry and related digital proofs (transaction records) are built on the upcoming Minimum Viable Consent Receipt specification, a work evolving in Kantara Initiative’s CISWG.
191 |
192 | W3C’s Data Catalog vocabulary and The RDF Data Cube Vocabulary are used in Service Registry specification. Both of these vocabularies are published as W3C Recommendation 2014 and they are developed for increasing findability of datasets and data items, and interoperability between datasets. They enable authorisations to be used only between compatible services.
193 |
194 | # MyData Account # {#account-transactions}
195 |
196 | Functionally, MyData Account is the key enabler in authorising, controlling and logging the data flow between multiple services. It keeps track of individual’s consents and other relevant information in a single place thus providing a unified view to all the Authorisations of data flows. Also, it makes it easier for the individual to manage the flows as they are all defined with the same tools, which makes it easier to compare different Authorisations.
197 |
198 | Typically, MyData Account constain
199 |
200 | * basic information about the Account Owner, e.g. contact detail, preferences etc
201 |
202 | * individual’s identities for both single sign-on (SSO) uses and for managing the Service Links and consents. Depending on the implementation, Account could hold just the public keys or both the public and private keys. Naturally, hosting private keys poses more stringent security requirements for the Operator.
203 |
204 | * individual’s Service Links and Authorisations as well as their respective Status Records
205 |
206 | To be operational, the Account has to be hosted by a MyData Operator. It is expected that most of the operator services will be provided by organisations, though it is also possible for individuals to run the operator software themselves thus becoming self-operators. The key difference is that organisations can potentially provide additional trust, assurance and security levels compared to a self-operator. Acceptance and audit process for an organization wishing to serve as a trusted operator are beyond the scope of this document (NOTE: It is likely to be defined along extending the criteria set for entering e.g. a regional or governmental trust network - ISO/IEC 29115 entity authentication assurance level or FICAM TFS are examples of trust and assurance level related requirements that may apply.).
207 |
208 | The information in a MyData Account is designed for portability allowing the individual to change operators by taking their account with them. The implementation of portability as a service between Operators is deferred to a later architecture release.
209 |
210 | More detailed technical information about the MyData Account can be found in the MyData Account specification [2].
211 |
212 | # Service Registration and Service Discovery # {#serviceregistration}
213 |
214 | Service Registry is part of the Operator and it provides two major functions: it maintains a database of all services accessible with this Operator (Service Registration) and it enable searching for compatible services (Service Discovery) both for the Account Owners using the services and for the developers of services. This section first introduces the different service descriptions used with the registry and then goes over the Service Registration and Service Discovery processes. More detailed technical information about the Service Registry can be found in the MyData Service Registry technical specification [3].
215 |
216 | ## Service Description ## {#servicedescription}
217 |
218 | For efficient service management, discovery, and matching, each service needs to be described in the Service Registry. In addition to the compulsory description data such as service ID and some promotional material e.g. service logo, a Service Description is an aggregation of multiple levels of service descriptions as shown in Figure 4.1:
219 |
220 | * a Human Readable Description forms a basis for promoting and introducing the services to Account Owners
221 |
222 | * a set of Technical Descriptions on the service interface functionalities need to be introduced in order to provide tools for service interoperability
223 |
224 | * Service Data Description is required for intelligent service discovery and matching
225 |
226 | 
227 |
228 | *Figure 4.1: Realization of a service registration*
229 |
230 | ### Human Readable Description ### {#humandescription}
231 |
232 | A basic Service Description contains a unique service ID, a human readable textual presentation of the service, and possible material (logo etc.) for promoting the service. These are used in various stages for presenting the service and its data in a non-technical, end-user friendly way, such as in the service store, where the Account Owner can discover services. The idea for the Human Readable Descriptions on both the service functionality and the data the service collects or manages is that the Account Owner or the developer trying to link the particular service to his own ecosystem can easily get an overview of the concept.
233 |
234 | ### Technical Service Description ### {#techdescription}
235 |
236 | The Technical Service Description is a document required only for Source services. It presents the technical API for accessing a particular resource. This document can be, for example, a WADL document presenting the API of a REST-style resource interface. WADL (Web Application Description Language) is a machine-readable XML description of HTTP-based web applications. The API is then implemented by one or more data resource instances or service instances. Each service provider specific instance is given an unique ID, which in combination with instance’s unique address enable service linking (Section 5), authorisation management (Section 6) and data access (Section 7).
237 |
238 | ### Service Data Description ### {#datadescription}
239 |
240 | Service Data Description presents the data provided through the service, and it enables finding relevant Sources based on different criteria. For service developers, it supports finding and integrating relevant Sources to a Sink, and for Account Owners it facilitates making recommendations about relevant Sources and Sinks. The description enables defining, what data elements are offered by a Source or required by a Sink. This information is also needed when showing to an end user, what kind of data elements are available in a Source, which the Account Owner uses in deciding, which data elements are made available to a Sink.
241 |
242 | Service Data Description defines metadata about data of a service. It includes general metadata such as title, description, subject and publisher. In addition, it describes what kind of data a Source produces and from where and in which format it is available. A Service Data Description for a Sink describes what kind of data it uses and needs.
243 |
244 | Linking of metadata elements to Linked Data and common classification schemes is also supported. The purpose is to establish a common understanding of various data elements, to enable correct interpretation of the data, to enable searching of data based on different criteria and relations of data elements, and to enable utilization of data in new services and applications.
245 |
246 | Different functionalities such as data transformations, semantic enrichment, and mapping of data elements are needed to support service providers in creating and validating semantic service descriptions. The descriptions are collected when Sources and Sinks are registered in a Service Registry.
247 |
248 |
249 |
250 | 
