MyDataShare component provides IHAN testbed's consent management environment. The service provides an identity layer, allowing users to authenticate using another IHAN component, SisuID, and provides the consent management layer to allow user to grant consents for data transfers between IHAN Data Providers and Service Providers.
Core Functions – Identity, Consents and Connectivity
MyDataShare has three core functions:
- MyDataShare Identity (an identity provider that can be combined with external identity provider services),
- Consent (Permission) Management and
- Connectivity services.
Regarding the integration of the MyDataShare functions to an existing digital service or system, a Data Provider or Service Provider can use the product embedded under their own user interface, context and branding. But they can as well link their individual users to a separate privacy dashboard service a.k.a. MyDataShare Wallet application that collects together user's consents across any personal data management contexts they may have linked to this operator instance.
Identifier and authentication management function, powering end-user onboarding and operator's core functions, i.e. consent management, usage logging, linking user's active identities, and other available features for e.g. user profile management in the wallet.
Ability to bind an identity is essential to personal data management. Identity must link simultaneously to
- The consents and data authorisations of a natural person, and
- A known user identifier at the impacted services (Data Provider and Service Provider) holding personal data linked to this identity.
This is required to serve both the benefits of the individual and the regulatory interests of the services (as controllers, defined in GDPR) involved. Core purpose of a person's identifier in the component is to act as a root identifier between linked services, and to map the user's local user identifiers in these services with their consents hosted in MyDataShare under the first-mentioned root identifier.
In IHAN testbed the MyDataShare Identity is integrated with SisuID component, and SisuID is used as an Identity Provider for consent management services.
Level of end user authentication assurance (LoA) required for authorisation of data transactions can vary based on the type of personal data in question, and this is usually linked to user-perceived complexity of the authentication and the following authorisation management process. Thus, MyDataShare ID must have the capability to serve identity authentication demands with various LoAs.
Component is built originally to depend on strong authentication in authenticating the person onboarding the relying party service for managing data shares and consents. The solution works through several federated electronic identity (eID) providers with eIDAS substantial-level LoA (e.g. BankID, Finnish Trust Network FTN). Once established onto the MyDataShare, this person's base identity can be linked with other common identity provider services, e.g. the social login IDs – Google, Facebook, Twitter, Office365, GitHub, etc. to simplify use of the app. MyDataShare Identity works as a custom OpenID Connect Provider (OP) service with the most relevant authentication federations brought into the service's ID portfolio. Data Providers and Service Providers will get the necessary credentials through onboarding & registration.
Identity component API descriptions are available at https://www.mydatashare.com/dev.
The MyDataShare Consent Management functionality forms the data access control and the auditing function of the system. The function is responsible for all lifecycle management, actions and data persistence (permanent storage of critical data). The data transport and related authorisation mechanism on the Connectivity layer (APIs) is built to rely on validating the status of Individual-provided consent at each data request. These requests come from a known, identified Service Provider, and are linked to data available from a known, identified Data Provider. For meeting the regulatory requirements of a valid consent (freely given, specific, informed consent), the consent request will contain complete information of the identities of the controllers, specific processing purposes and other required information It is brought (both visually and textually) to the individuals for an explicit decision making through a consent request. This consent request can be approved or declined – and the consent withdrawn easily later. The consent request function can be used by the Service Provider to check the status of consent requests it has initiated via MyDataShare.
Actions and decisions that need to take place on side of a service or entity that is considering their consent management to be provisioned with MyDataShare are listed below:
- A Data Povider (service with outbound-available data and API of its own) is provided with an alternative, MyDataShare -provided trusted authorisation layer (an API proxy) to complement their existing local API access control. Alternatively, the data provider can adapt their existing API and authorisation layer within to additionally to rely on MyDataShare on consent status validation prior to providing Service Providers access to this data.
- The Data Provider has to decide which data is to be opened for consent-based authorisation via MyDataShare. This data needs to be registered with MyDataShare.
- Any Service Provider will have to register itself to the MyDataShare system as a client to enable secure communications between services within the ecosystem; they also are expected to deliver meta-level information of the data consumption use case for construction of the consent request with necessary end-user descriptions. These include declaring identities of the Data Provider and Service Provider, specific purpose of processing, lawful basis of intended processing and other information that is required for freely given, specific and informed consent.
Consent management component API descriptions are available at https://www.mydatashare.com/dev.
Consent Token Explained
After the individual's consent is acquired, the Consent Management layer documents this down as an active consent record and provides the Service Provider behind the request a token for consequent use. This token, resolving to the Data Provider and the individual it includes, is thereafter used by the Service Provider as a 'key' in data access requests towards the Data Provider, similar to OAuth2 access tokens used in context of OAuth2-protected data resources.
More detailed information about the MyDataShare service can be found in the whitepaper: https://mydatashare.com/whitepaper