Cloudentity offers CDR quickstart that you can use as a reference application to build your CDR consumer consent dashboard. Also, it showcases how you can integrate CDR workflows with the Cloudentity platform.
For guidance on how to use reference portals, see Using reference consent self-service and admin portals.
“Consent in the CDR must be voluntary, express, informed, specific as to purpose, time limited and easily withdrawn (rule 4.9)". Allowing consumers to manage their authorizations (consents) is critical in CDR.
Consumer dashboards, or consent self-service portals, are the tools consumers can use to review and manage their authorizations. They allow a consumer to see the list of all CDR data recipients they are sharing their data with, as well as the specific sharing arrangements the consumer has with the data recipients.
It allows the consumer to withdraw (revoke) their consent at any given moment. As per the CX guidelines, dashboards must provide consumers with information like:
When they gave an authorization.
The period the authorization is given for.
When the authorization is scheduled to expire.
Whether the authorization is expired or active.
A consumer dashboard must meet the following requirements:
Applications connected to consumer dashboards must be of the confidential client type to store client credentials securely. This requirement is essential since the client credentials grant type is applied to the part of API requests. For example, you can consider using the secure Backend for Frontend (BFF) design pattern.
Applications must be created within the System workspace of your Cloudentity tenant since you’ll be calling the system-level APIs.
Access to the System workspace is behind a feature flag. To request access to the System workspace, contact Cloudentity Sales Team.
Applications must have the
Add New Scope
When you have no
manage_openbanking_consentsscope available for assigning to your application, add it to the required CDR service first. Then, you can assign it to your client app.
The same scope is recommended to be explicitly defined when calling the
/tokenendpoint. Pass it as the value of the
scopeparameter to make the flow compliant with the best security practices.
Consumer dashboards must be developed according to the CDR CX Guidelines and Rules.
Consumer dashboards must display to consumers all consents they gave.
Consumer dashboards must allow the consumers to withdraw their authorization. The withdrawal journey contains, for example:
Identify the authorization to be withdrawn.
Review the implications and confirm the withdrawal.
Receive a final notification of success.
Integrate Consumer Dashboards
(consent self-service portal) participant acp as DH - Infosec provider
(Cloudentity) user->>IDP: Authenticate activate user activate IDP user->>cd: Consumer is redirected deactivate IDP deactivate user activate cd cd->>acp: POST OAuth 2.0 Token endpoint with Client Credentials grant type
& "manage_openbanking_consents" scope activate acp acp->>cd: Cloudentity Access token with "manage_openbanking_consents" scope cd->>acp: POST List CDR Arrangements with "customer_id" in request body Note over cd, acp: The request contains the token the Consumer Dashboard got in step 4 acp->>cd: List of arrangements for the consumer deactivate acp cd->>user: Display arrangements activate user user->>cd: Select arrangement deactivate user cd->>acp: GET Get CDR Arrangements activate acp Note over cd, acp: The request contains the same the token consumer dashboard
got in step 4 when it's still valid.
Otherwise, the dashboard authenticates itself again acp->>cd: Arrangement of the requested identifier deactivate acp cd->>user: Display arrangement details activate user user->>cd: Revoke (withdraw) arrangement deactivate user cd->>acp: DELETE Revoke CDR Arrangement activate acp deactivate cd deactivate acp Note over cd, acp: The request contains the same token the consumer dashboard
got in step 4, when it's still valid.
Otherwise, the dashboard authenticates itself again
To integrate your Consumer Dashboard with Cloudentity, use the following Cloudentity APIs:
- Authorization (step 3)
POSTOAuth 2.0 Token endpoint
- Authenticate your client application to Cloudentity.
- The consent application calls the
/tokenendpoint for the only purpose of authenticating itself before calling Cloudentity consent APIs.
- Authentication can be performed before steps 9 or 13 as well.
- Fetching arrangements (step 5)
POSTList CDR Arrangements
- Fetch the list of CDR arrangements.
- It returns the list of all CDR arrangements, so you can provide it to the consumer, as required by the CDR rules. To narrow the list down, pass filters in the request body.
- Getting arrangement details (step 9)
GETGet CDR Arrangement by ID
- Obtain the details of a specific consent after the consumer selects an arrangement on the consent page.
- This allows you to display the arrangement details to the consumer.
- Revocation (step 13)
DELETERevoke CDR Arrangement
- Revoke an arrangement.
- Consumer Dashboards are required to allow consent revocation (withdrawal). To revoke an arrangement, pass its identifier as the path parameter.
To provide consumers access to the consumer dashboard, you need to have an Identity Provider connected. Cloudentity allows you to manage IDPs and give your consumers the means to authenticate.