How-tos

3 mins read

Validating Accredited Data Recipients

Data Holders have a duty to periodically check the current status of Accredited Data Recipients and act accordingly if the ADR has lost its accreditation. See how this is achieved with Cloudentity.

Validation of Accredited Data Recipients in a Nutshell

Data Holders have the responsibility to periodically check the accreditation status of Accredited Data Recipients (ADRs) and their Software Products (SPs). Cloudentity ensures that, in case the accreditation can no longer be found, all arrangements for the ADR are marked as expired, access and refresh tokens are revoked, and the client’s status in Cloudentity will change to Inactive, meaning that this application can no longer request data from the Data Holder.

Cloudentity polls the CDR registry for the current status of both ADRs and their SPs registered as Cloudentity clients regularly, as required by the CDR specification, and caches the result. Cloudentity then runs ADR validation based on its cache in the following scenarios:

  • Client registration
  • Client authorization
  • Arrangement revocation

ADR Validation in Practice

In accordance with the CDR specification, Cloudentity periodically checks the CDR Registry to verify ADRs and their Software Products. CDR Registry returns data using the Refresh ADR Metadata endpoint. The result is cached by Cloudentity.

[mermaid-begin]
sequenceDiagram autoNumber participant adr as Data Recipient participant dh as Data Holder -
Infosec Provider (Cloudentity) participant reg as CDR Register dh->>reg: Get Data Recipient Status reg->>dh: return status dh->>reg: Get Software Product Status reg->>dh: return status dh->>dh: Cache Status Metadata alt status is "removed" for ADR SP dh->>adr: Invalidate consents dh->>adr: Deactivate registered client end

If the status is removed for ADR Software Product, Cloudentity will invalidate all consents granted to this SP and remove its client application. This means that the SP users will no longer be able to request data from Data Holder.

The following validation occurs every time an Accredited Data Recipient makes a request to the Data Holder, to ensure Data Holder compliance with CDR standards before processing the request. ADR represents the Accredited Data Recipient while ADR SP represents the ADR’s Software Product.

[mermaid-begin]
sequenceDiagram autoNumber participant adr as Data Recipient participant dh as Data Holder -
Infosec Provider (Cloudentity) adr->>dh: Request data dh->>dh: Check Data Recipient Status alt Status "active" for both ADR and ADR SP dh->>adr: Disclose data or facilitate consent approval/withdrawal end alt Status "active" or "suspended" for ADR and "inactive" for ADR SP dh->>adr: Facilitate consent withdrawal end alt status removed for ADR SP dh->>adr: block request end

  1. Data Recipient sends a request to the Data Holder (for example authorization request)

  2. Data Holder uses Cloudentity to check the Data Recipient status within the registry. To that end, Cloudentity checks the workspace cache for the current status.

  3. Depending on the status of ADR and the Software Product, Cloudentity makes a decision:

    • If the status is active for both, Cloudentity processes the request.
    • If the status is active or suspended for ADR and inactive for ADR Software Product, Cloudentity will only facilitate consent withdrawal requests.
    • If the status of the ADR SP is removed, Cloudentity will block the request and return an error.

Disable ADR Validation

ADR validation is enabled in CDR-compliant workspaces by default. You have the option to disable it if it’s necessary to run a test scenario.

  1. In your CDR workspace, go to OAuth » Authorization Server.

  2. Disable the Enable ADR Validation check box.

  3. Save. Cloudentity will no longer validate requests made by clients registered in this workspace. Keep in mind that such workspace is no longer CDR compliant.

Updated: Nov 2, 2023