Introduce explicit language to prevent unwarranted friction in the dynamic client registration (DCR) process by data holders

[ShaneDoolanAdatree]

Description

Adatree has experienced four prominent data holders on two separate occasions performing ADR domain allowed-listing on dynamic client registration (DCR) attempts. This has resulted in product testing and product launch delays while these data holders "investigate the issue". In no part of the Consumer Data Standards or the CDR Register Design Reference does it state that this practice is a part of CDR.

On both occasions Adatree had fulfilled the pre-requisites required to register, and had already successfully registered with 46 other data holders, but our client registration attempts were blocked by the same four data holders. Adatree is aware of at least one other ADR experiencing this deliberate and unwarranted blocking action on their client registration attempts where the resolution was the same - these same four data holders added the ADR's domain to their allowed-list.

Area Affected

Security Profile > Client Registration

Change Proposed

We propose that explicit language be introduced to prevent this type of behaviour from data holders. Adatree has gone as far as to make formal complaints to the regulator on this matter as we feel these data holders have deliberately frustrated the process of disclosure of consumer data, but this will be a lengthy process. We feel prevention is better than cure and to explicitly outline that these practices are not permitted would be a better approach.

There is also precedence for such language in the standards. Under the Authentication Flows > OIDC Hybrid Flow section there is a statement which reads:

Data Holders MUST provide a one-time password (OTP) to the customer through an existing channel or mechanism that the customer can then enter into the redirected page The delivery mechanism for the OTP is at the discretion of the Data Holder but MUST align to existing and preferred channels for the customer and MUST NOT introduce unwarranted friction into the authentication process

There are also a number of similar statements about preventing unwarranted friction throughout the standards e.g. the Authorisation: Profile selection section, the Unavailable Accounts: Request sharing rights section.

We feel that allowed-listing practices amount to unwarranted friction and would ask that similar language be introduced to the Client Registration section e.g.

Data Holders MUST NOT introduce unwarranted friction into the dynamic client registration process, such as IP allowed-listing or domain allowed-listing.

[TT-Frollo]

Frollo supports an explicit direction from DSB in regard to white listing ADR networks. We appreciate that DH's with such a security policy may require additional network components, but this would be a consequence of the choice they make.