Guidance on Dynamic Client Registration (DCR)

Introduction

Accredited Data Recipients (ADRs) register with Data Holders (DHs) according to Dynamic Client Registration protocol (DCR).  Using DCR, ADRs obtain client credentials to retrieve consumer data on behalf of a consumer. DCR is an OAuth 2.0 standard. 

See:

• CDS Client Registration
• OAuth 2.0, DCR, RFC7591

The following notes describe DCR usage in the context of the Consumer Data Standards (CDS). They are gathered from Subject Matter Expert guidance and responses to participant support issues.

DCR validation for redirect_uris in sector_identifier_uri endpoint

For a DCR request with redirect_uris, the outer JWT is optional.

For a DCR request with redirect_uris, an inner JWT with SSA is required. The SSA is generated by the CDR Register based on the redirect_uris configured against the software product. As this field is mandatory, it is invalid for an SSA to be generated without these values.

For DCR request with sector_identifier_uri, an inner JWT with SSA is optional. The SSA is generated by the CDR Register based on the sector_identifier_uri configured against the software product. As the sector_identifier_uri is an optional field, if it is not configured, the SSA will simply be generated without this value.

The values of the registered redirect_uris MUST be included in the elements of the array. This means that the published values are a superset of those used in the DCR process.

Published redirect_uris are a superset of those in the SSA and the JWT. Therefore, they should match the set that is included in the published redirect_uris

During registration, if the sector_identifier_uri is unreachable, POST and PUT requests to the register endpoint should fail. Accredited Data Recipient's sector_identifier_uri hosted endpoints are checked during the DCR validation process.

LegalEntityID and LegalEntityName in DCR Request

legalEntityId and legalEntityName will always be returned as a part of the DCR request.

Accredited Data Recipients without a Software Product

For Accredited Data Recipients (ADRs) that do not have a Software Product. DHs should expect empty arrays for data_recipient_brand_ID and software_product_ID fields.

For responses from the CDR Register to the ADR. The arrays for data_recipient_brand_ID and software_product_ID fields may be empty. The Consumer Data Standards (CDS) imply that this is possible, hence any software solutions built in accordance with the CDS must be tolerant to this.

JWS algorithm support for Data Holders

As per the CDS, a DH has the discretion to choose their preferred algorithm, either PS256 or ES256. The DH may support both algorithms if desired. ADRs must support both algorithms because different DHs may support different algorithms.

JSON Web Token usage for Client Authentication and Dynamic Client Registration

Both the SSA and DCR JWTs require validation. The JWKS URI defined in the SSA belongs to the software product. Therefore, this is not a known set of values and is published and maintained by the Accredited Data Recipient (ADR). It is a requirement to retrieve these keys to validate the JWT request. This is also covered in the sequence diagram.

It is recommended that participants generate their own JWTs to cover the different variations that they may encounter. Numerous libraries can be found at JWT.IO that can be leveraged for this purpose.

There are non-normative examples provided in the CDR Register for reference. These are not designed to be used in testing, instead they can be used in conjunction with JWT.IO to understand the composition of the JWTs.

A mock register is also provided which participants can interrogate the code on: https://github.com/ConsumerDataRight/mock-register

ADR legal entity name modification

The legal_entity_name for an ADR is optional in accordance with the SSA definition for DCR, but once provided is it immutable.

Any modification to the ADR’s legal_entity_name needs to be updated with ACCC and Data Holder registrations and in these cases the previous legal_entity_name cannot be used for DCR.

However, as far as rebranding is concerned, the org_name within SSA definitions which is a reflection of the ADR brand name is classified as mutable.

Data holder scope validation for authorisation requests received

The Data Holder must validate for all scopes within the authorisation requests received. The SSA represents a whitelist of scopes supported for a given client.

OIDC Core requirements outlines the scope validation required for an authorisation request.

Updating ADR Registry metadata

The management of metadata is at the discretion of the participant and the DSB and ACCC do not provide specific guidance.

In general, however, any metadata received from the Registry should be seen as definitive and should be used when presenting consent and dashboard screens to the customer.

When the ADR updates their CDR registry information, they are not required to update the same information with Data Holders by calling the DH Update Client Registration endpoint. The ADR may update with each DH if they want the change to take place immediately.

DHs are required to do a slow poll to periodically update ADR metadata from the Register. 

softwareProductDescription maximum length

The softwareProductDescription field is returned in the SSA (Software Statement Assertion) and used for DCR. The Register supports up to 4000 characters.

Deleting ADR Client Registration

After an ADR registration deletion request there should be no active consents for that ADR. The DH is required to expire all consents at the time the ADR status is set to revoked or surrendered. The status of the Software Product changes to inactive.