CDR Data Recipient Client Registration & Management

This article provides an overview of Cloudentity enabling the Data Holders to be CDR complaint by providing the Security Profile requirements implementation especially for Dynamic Client Registration for Data Recipients.

CDR Data Recipient Client Registration & Management

As per CDR specifications, Data Recipients must register with Data Holder according to OAuth 2.0 Dynamic Client Registration protocol. Cloudentity platform is part of Data Holder ecosystem facilitating all the security profile requirements for the Data Holder system. Cloudentity platform provides all the OAuth capabilities to handle the dynamic client registration of Data recipient entities. Once registered, Data recipients can utilize the registered client information to mint CDR compliant tokens from Cloudentity authorization platform to retrieve consumer data from the Data Holder in a secure manner.

Register Data Recipient with CDR registry

CDR registry acts as the central registry where all the Data Recipients must first register their software. CDR registry issues software statement assertion about a client software. A Software Statement Assertion(SSA) is a digitally signed JSON Web Token (JWT) created in accordance with JWT that asserts metadata values about the client software.

A sample SSA(decoded view) issued by the CDR registry looks like this:


{
  "alg": "PS256",
  "kid": "542A9B91600488088CD4D816916A9F4488DD2651",
  "typ": "JWT"
}

{
  "recipient_base_uri": "https://tpp1.cdr.cloudentity-se.com:9001",
  "legal_entity_id": "18b75a76-5821-4c9e-b465-4709291cf0f4",
  "legal_entity_name": "Mock Software Company",
  "iss": "cdr-register",
  "iat": 1647997920,
  "exp": 1647998520,
  "jti": "5bf24030a32641c099f741d4286027d1",
  "org_id": "ffb1c8ba-279e-44d8-96f0-1bc34a6b436f",
  "org_name": "Mock Finance Tools",
  "client_name": "MyBudgetHelper",
  "client_description": "A product to help you manage your budget",
  "client_uri": "https://mocksoftware/mybudgetapp",
  "redirect_uris": [
    "https://tpp1.cdr.cloudentity-se.com:9001/consent/callback",
    "https://tpp1.cdr.cloudentity-se.com:9001/consent/callback2"
  ],
  "logo_uri": "https://mocksoftware/mybudgetapp/img/logo.png",
  "tos_uri": "https://mocksoftware/mybudgetapp/terms",
  "policy_uri": "https://mocksoftware/mybudgetapp/policy",
  "jwks_uri": "https://tpp1.cdr.cloudentity-se.com:9001/jwks",
  "revocation_uri": "https://tpp1.cdr.cloudentity-se.com:9001/revocation",
  "software_id": "c6327f87-687a-4369-99a4-eaacd3bb8210",
  "software_roles": "data-recipient-software-product",
  "scope": "openid profile bank:accounts.basic:read bank:accounts.detail:read bank:transactions:read bank:payees:read bank:regular_payments:read common:customer.basic:read common:customer.detail:read cdr:registration introspect_tokens revoke_tokens"
}

The CDR Register has chosen to use PS256 as the signing algorithm, conforming to FAPI-RW Section 8.6 for signing the Software Statement Assertion(SSA). Cloudentity platform will verify the signature of this PS256 signed SSA presented by the Data Recipient to Data Holder in DCR workflows.

Register Data Recipient with Data Holder

To register with a Data Holder, the Data Recipient sends an HTTP POST to the Data Holder registration endpoint. Cloudentity platform, the InfoSec provider of the Data Holder ecosystem, is responsible for providing the registration endpoint.

[mermaid-begin]
sequenceDiagram participant adr as Data Recipient participant dh as Data Holder -
Infosec Provider (Cloudentity) participant cdrregister as CDR Register adr->>cdrregister: Configure software product with CDR register adr->>cdrregister: Download software statement cdrregister-->>adr: software statement adr->>dh: GET /.well-known/openid-configuration dh-->>adr: OIDC configuration adr->>adr: Create DCR signed JWT request
with SSA, claims etc in payload adr->>dh: Dynamic client registration request
POST /register alt CDR Registry JWKS cache expired dh->>cdrregister: Retrieve CDR register JWKS cdrregister-->>dh: cdr registry jwks end dh->>dh: look up SSA key in cdr registry jwks dh->>dh: Verify SSA JWT signatures
against an associated JWK retrieved above dh->>adr: Retrieive DR JWK
from the jwks_uri extracted from the SSA adr-->>dh: Data recipient JWKS dh->>dh: Verify the registration request JWT signature
against the JWK published by the Data Recipient retrieved above dh->>dh: Validate multiple active registrations
for same software_id does not exist dh->>dh: Validate registration scope claims in request dh->>dh: Register Data Recipient as an OAuth Client dh-->>adr: Return client id and details adr-->adr: Store client id and details for Data holder

Data recipient must:

  • provide the request in the format of a RFC7519 compliant JWT.

  • The request MUST use the HTTP POST method, using the application/jwt content type.

  • The JWT MUST be signed using one of the algorithms specified in FAPI-RW Section 8.6

Data recipients have the choice to choose the signing algorithm they use when interacting with data holders. Cloudentity platform supports following signing algorithms as specified in FAPI-RW Section 8.6.

  • PS256

  • ES256

Some of the key validations as per CDR specifications for the OAuth Client being registered are:

  • the ONLY token endpoint auth method allowed must be private_key_jwt

  • id_token must be encrypted

  • id_token must be signed as constrained by FAPI-RW Section 8.6

  • SSA assertion issued by the CDR register must be present and signature must be validated using the JWKS published by CDR register

More detailed client validations can be found in CDR specifications for DCR

Registration management

As the Infosec provider component of a Data Holder, Cloudentity platform exposes all the Data Recipient Client Registration Management endpoints as defined in the DCR APIs. Client Registration endpoint is exposed in the OIDC Discovery configuration endpoint of the provider.

OIDC configuration endpoints can be located easily within the Cloudentity administrative portal. As a short hand, for a tenant with name cdr-demo that has an authorization server workspace with name cdr, it can be located at https://cdr-demo.us.authz.cloudentity.io/cdr-demo/cdr/.well-known/openid-configuration

Within the OIDC Discovery configuration endpoint, DCR endpoint location is specified under registration_endpoint key

"registration_endpoint":"https://cdr-demo.us.authz.cloudentity.io/cdr-demo/cdr/oauth2/register"

Cloudentity provides all the CDR compliant DCR APIs as in the specification for Data recipient dynamic client registration within the Data Holder ecosystem.

DCR API specification Cloudentity API Implementation
Register Data Recipient oAuth Client OAuth 2.0 Dynamic Client Registration
Get Data Recipient oAuth Client Registration OAuth 2.0 Dynamic Client Registration Get
Update Data Recipient oAuth Client Registration OAuth 2.0 Dynamic Client Registration Update
Delete Data Recipient oAuth Client Registration OAuth 2.0 Dynamic Client Registration Delete