Reference infrastructure and interoperability model for personal data management

@HL7 Personal Health SIG 22 March 2016Harri HonkoTampere University of Technologyhttps://fi.linkedin.com/in/harrihonko

http://bit.ly/MyData-Architecture-HL7FI-SIG

Contents1 MyData Overview

2 System Architecture View2.1 How it Works2.2 Detailed Flow Examples

Service Registry & Service Descriptions Data LinkingAuthorisation and Consent RecordData Connection

2.3 Trust & Security Model

3. Specifications and SDK

4. Extras

MyData Principles

● Human Centric: right to data, individual in control, privacy

● Usability of Data: machine readable, open formats, APIs, standards

● Transparent Relationship Management● Open Business Environment: interoperability,

possibility to change services without “data lock-ins”

Related Technology● Authorisation Mgmt● Service Discovery● Identity & Access Mgmt

● Data Storage● Personal Data API’s● Analytics to Data● Semantics & Data Standards

● UI and Tools● Relationship Mgmt● Trust Assurance● Governance model

MyData Model● Human Centric● Usability of Data● Transparent Relationship Management● Open Business Environment

Architecture for MyData Model

MyData

Data Storage

Semantics & Data

Standards

Analytics to Data

Service Discovery

Authorisa-tion Mgmt

Identity & Access Mgmt

User Interfaces and Tools

Governan-ce model

Trust Assurance

Personal Data API’s

Relation- ship Mgmt

2. System Architecture View

Service Registry - for Service DevelopersPersonal Service Management

Authorisation Management

Oauth 2.0 Profile (simplified from UMA)

MyData Infrastructure Model

Related Standards Space

MyData Operator = Integration of

● Centralised OAuth 2.0 Server● Service Registry● Consent Registry● MyData Account

2.1 How it Works

B

AAccount CreationAccount (record)

0.

A

C

Service RegistrationService Description (record)

0.

A

D

Service RegistrationService Description (record)

0.

BService Provider

Account CreationAccount (record)

0.

MyData Account Creation by the Data Subject

Operational Flow and Roles - Pre-conditions

Service Registration by the service provider(s)

D: Sink

Uses data to produce new applications, services and information

C: Source

Provides static or dynamic data, can be original source or secondary Data Store

A: MyData Operator

Provides MyData Accounts and related services

B: Account Owner

Individual Data Subject

AuthorisationConsent Records

Service LinkingLink Record

1.

Data ConnectionData transfer Log

3.

2.

BA

DC

Operational Flow and Roles - linking, authorisation and data transfer

2.2 Detailed Flow Examples

Service Providers register and describe their services to the operator’s Service Registry

Service Registration

End-user creates an account at the MyData Operator

and thus becomes an Account Owner

Service Linking

Account Owner links her compatible service(s) to her MyData Account - via Service Management

Authorisation

Account Owner defines rules and constraints between two services, resulting in a Consent Record*

Data Connection

Sink can establish authorised data transfer, based on Consent Record & Authorisation Token

Summarised MyData Architecture

2.3 Trust & Security Model

Security Technology Principles

● Architecture protects operations between parties○ Internal security of each party outside of scope

● Policy decisions define security level of any deployment

● Account Owner authorises the data flows and processing by issuing consents, supporting

○ Multiple security assurance levels and identity providers

○ Revocation of both consent and identity

Data Flow between Source and Sink

● Consent Records detail the rights and obligations for each party○ Consent Record to utilize MVCR, a draft Kantara standard (due 2016)

● Proof-of-possession tokens facilitate improved privacy○ Signed requests enable non-repudiation○ Comprehensive audit trail enables transparency

● Data flow protected with mutually authenticated TLS and OAuth 2.0 authorisation code flow

3. Specifications and SDK

Open source MyData SDK

● MyData Architecture v1.1 (this presentation’s base) is released in GitHub: https://github.com/HIIT/mydata-stack

● DHR program releases ‘old’ v1.0 MyData PoC demo as open source at https://github.com/HIIT/mydataoperator, live demo at http://dhr-demo.csc.fi

● MyData SDK Release 1.1 is going to be out in August 2016○ Adds MyData Account and IdP integration○ Used in MyData Hackathon sandbox (30 Aug 2016)

4. Extras

Authorization as a Service(MyData SDK’s Operator)

W2E

Omaprofiili.fi (VTT)

TerveystiliDhr-pilot.fi

RescueTime

Upload Portal(TTY)

Kardiokompassi(FIMM)

AS

AS = Oauth 2 Authorization Server with RS

AS

Client

DHR1 data flows

FIMM Research

DB

Client = Oauth 2 client = Does not exist

= Does not exist

Authorization as a Service(MyData SDK’s Operator)

W2E

omaprofiili.fi (VTT)

Terveystilidhr-pilot.fi

RescueTime

Upload Portal(TTY)

Kardiokompassi(FIMM)

AS

AS = Oauth 2 Authorization Server with RS

AS

Client

Accounts galore..

Client = Oauth 2 client = User Account

FIMM Research

DB

W2E

Omaprofiili.fi (VTT)

TerveystiliDhr-pilot.fi

(FIMM)

RescueTime

AS

AS

ASAS

We could EASILY just do this pure Oauth 2.0…with MVCR consents somewhere?

Kardiokompassi(FIMM)

Kickstarter(TTY)

Client

Client

Client = Oauth 2 client

AS = Oauth 2 Authorization Server with RS

- Separate consents, if recorded- Multiple Authz servers, no service register or service discovery- No single management point for end-user consents+ Simple, developers know Oauth 2.0

FIMM Research

DB

W2E

Omaprofiili.fi (VTT)

TerveystiliDhr-pilot.fi

(FIMM)

Kickstarter(TTY)

Kardiokompassi(FIMM)

MyData SDK allows us to migrate to this

Authorization as a ServiceService Registry

Consent Registry

AS

AS = MyData Authorization Server with Service Registry and

Consent/Assignment Registry

Client = MyData Sink (evolved client) = User Account

Client

Client

RS

RS

RS = Resource Server with no AS

RS

FIMM Research

DB

W2E

Omaprofiili.fi (VTT)

Kickstarter(TTY)

MyData Account +IdP federation gives…

Authorization as a ServiceService Registry

Consent RegistryIdentity Federation

+ AS

AS = MyData Authorization Server with Service Registry and

Consent/Assignment Registry

Client = MyData Sink (evolved client) = User Account

ClientRS

RS = Resource Server with no AS

RS

TerveystiliDhr-pilot.fi

(FIMM)

Kardiokompassi(FIMM)

Client RS

OIDCProvider

RescueTime

Kickstarter(TTY)

Legacy services needmigration - or brokering

Authorization as a ServiceService Registry

Consent RegistryIdentity Federation

+ AS

AS = MyData Authorization Server with Service Registry and

Consent/Assignment Registry

Client = MyData Sink and/orOauth 2.0 client

Client

RS = Resource Server with no AS

OIDCProvider

AS

Broker Service

RescueTime

RS

AS

Client

Dual-client (Oauth 2 and Sink, above) orBroker-source hiding the OAuth 2 legacy service (below)

AS = Oauth 2 Authorization Server with RS

OR