4. Data Request
Once the Consent has been given for a specific linked Service or Sink/Source services pair, the data processing/data transfer request can take place and will be regulated by Cape's Consent enforcement. In particular:
Within service case: Service will process End User's data according to status, rules and policies defined in its related Consent Record.
Sharing between services: Both Source and Sink have their own Consent Record, which contains role specific information necessary in establishing a Data Connection between Source and Sink.
Consent Record MUST be validated every time the data is processed based on the consent. It will use Cape SDK API's to either directly verify or update its local Consent Status (CR/CSR), in order to check that processing being executed on personal data complies with End User's willings described in the Consent.
Consent is valid if:
- Time of use is between not before and not after timestamps;
- Consent status in latest Consent Status Record is Active.
In addition to Consent Record enforcement, in the case of sharing between services, Sink will send to Source the actual data transfer request, in order to retrieve from it the datasets defined in Consent Record.
Authorisation Token is an cryptographically signed proof-of-possession token given to Sink and expressed in the JSON Web Token (JWT) format as described in RFC7519 specification.
Sink service will receive this token in the Consenting phase and use in data request to refer to a specific consent. If Sink does not have an Authorisation Token or the token has expired, Sink MUST request a new token before making a data request.
The figure above depicts the data transfer, consent based flow, which involves following steps:
Sink requesting data based on associated consent MUST ensure that Consent Record is Active, the intended use of data is listed in Consent Record’s purposes and that the request is made to protected resource (dataset) listed in Consent Record’s Resource Set.
Sink creates the Data Transfer Request, which contains:
Surrogate Idof the Service Link Record associated to Sink Service and CaPe's User Account
Consent Record Idof the Consent Record issued to Sink Service.
Resource Set Idof the Resource Set contained in the CR.
Dataset Idof the Dataset contained in the Resource Set.
Authorisation Tokenissued by Cape during Consenting phase (signed with private
Sink signs the Data Transfer Request above with private part of its
PoP Key(created during Service Linking phase) and sends it to the Source Service. The signature is included as
Authorization: PoPheader (see IETF specification).
In order to grant access to requested resources, Source service will perform following validation steps:
Data Request: Verify data request signature (
Authorization: PoPheader) with the public part of PoP Key, retrieved from Role Specific part of the Source's Consent Record (pop_key field).
Authorisation Token: Verify Authorisation Token signature with public part of Operator Key, retrieved from Role Specific part of the Source's Consent Record (token_issuer_key field).
Consent Record Id,
Dataset Id: Check matching Consent Record is active and the request is for a dataset listed in the CR's Resource Set.
- Check if exists active paired Consent Record for input Cr Id and Surrogate Id (latest CSR in Active status).
- Resource Set in the matching CR matches with input Resource Set Id.
- Dataset in the matching Resouce Set matches with input Dataset Id.
Based on the validation process conducted by Source, Sink either receives the data it requested or receives an error message.
For further information see Data Transfer Apiary section.
Notifications & Activity Logs
All notifications will be tracked by CaPe as Event Logs that can be viewed both by the Data Subject (via Use Self-Service dashboard) and by the Service Provider (via Data Controller dashboard). All the aforementioned phases and those relating to the request and processing of data are tracked by CaPe through a taxonomy of events that will be saved by CaPe (AuditLog Manager).
Note. Soon will be supported also asynchronous notifications both for End User and Service Provider via email, phone and other channels.
For further information see Dashboards section.