Use of CDR Authorisation Scope to Manage the Data thats Being Shared and its Change
Consumer Data standards uses the concept “CDR authorisation scope” to define the range and depth of consumer data that customer is willing to share.
The CDR authorisation scope is the attribute that is being exchanged between ADR (accredited data recipient)and DH (data holder) which define the data sharing scope.
ADR defines the data scope requested on the ADR dashboard as shown below.
The authorisation scope first start appearing on the payload exchanged on the /authorise request which initiates the consent flow.
On the Data Holder (DH) side the banking products are attached to the authorisation scope when building the consent as shown below.
Consent attaches data sharing scope that was agreed on the ADR dashboard to the accounts on Data Holder’s consent flow as shown below.
As you can see above the “bank:transaction:read” scope would allow the third party to access transaction data for accounts. This scope is effectively additional authorisation to the Basic Bank Account Data scope. Granting this authorisation only makes sense if the Basic Bank Account Data scope is also authorised.
Consent Amendment and CDR Authorisation Scope
ADR can request a change to the consent that has been already established. ADR uses “cdr_arrangement_id” to refer to the existing consent arrangement. In the following diagram the additional data sharing scope is added as a auth scope in PAR endpoint payload.
Once the consent amendment request is made the consent flow need to highlight the additional data clusters requested as shown below.
Data holder will apply security layer to validate the authorisation scope baked on to the OAuth 2.0 access token as shown below in the API validation flow. As an example if the request came for the API : GET /banking/accounts/{accountId}/transactions/{transactionId} Data Holder need to validate whether the consent has actually allowed sharing of the transaction details through the scope “bank:transactions:read”.
