Customer Data Right Quickstart

Data recipients must register with the registry first to register their software product. Once registered, recipients are issued a software statement assertion and are accredited. We will refer to these as accredited data recipients (ADR). In this reference application, mock-data-recipient takes the role of ADR and is registered with mock-register for accreditation. Once that is done, it needs to interact with SecureAuth to perform DCR to register itself to obtain data from Data Holder. SecureAuth is part of Data Holder ecosystem and provides the security profile implementation, so all the Oauth & FAPI related endpoints are exposed by SecureAuth that need to be consumed by ADR to obtain consumer consent and access tokens to access data APIs.

In the Quickstart environment, it is possible to configure the mock-data-recipient by adjusting the environment variables in the additional_configuration.sh script. The script generates a recipient.json file out of the recipient.template and mounts it as the configuration for the mock recipient when running make run-cdr-local command.

Data Holder application requires configuration of the CDR security profile provider(aka SecureAuth).

In the Quickstart environment, it is possible to configure the mock-data-holder by adjusting the environment variables in the additional_configuration.sh script. The script generates a holder.json file out of the holder.template and mounts it as the configuration for the mock holder when running make run-cdr-local command.

Now that you have all the applications deployed and connected to the SecureAuth authorization platform, you need to get into the reference data recipient application.

Once user consents to the application, SecureAuth platform stores the consents and issues relevant authorization tokens back to Data Recipient application. The user is redirected back to the mock-data-recipient application.

As the result, the data recipient obtaines the consumer consent to fetch their data from Data Holders. Data Recipient can now use the consent in the form of access tokens to call the Data Holder data APIs.

Now that we have the cdr-arrangement-id and associated accessToken, we can invoke the API's exposed by the data-holder using the accessToken..

Sample curl where the $AT environment variable stands for the access token:

curl -kv -X  'GET' \
  'https://datarecipient.mock:9001/data-sharing/proxy/cds-au/v1/banking/accounts?open-status=ALL&page=1&page-size=2' \
  -H 'accept: application/json' \
  -H 'x-v: 1' \
  -H 'x-inject-cdr-arrangement-id: c7mf3n75ajjjteq461ig' \
  -H 'x-fapi-auth-date: Fri, 01 Jan 2021 00:00:00 GMT' \
  -H 'Authorization: Bearer $AT'            

This mock data holder application does not showcase how to completely protect Data holder API. To learn more about it, see the FDX Data Provider API Protection.