CDR Rules, section 5.3.4 Temporary direction to refrain from processing consumer data requests, states that the Accreditation Registrar may, by written notice, direct a data holder not to respond to consumer data requests.
How should these be handled by any CDR infosec and resource endpoints?
Handling refusals under Rule 5.34 depends on the instruction from the Accreditation Registrar. For instance, if the instruction is to refuse all data requests and refrain from establishing new consents, then the Data Holder (DH) might refuse to grant access tokens on request, and consequently no data requests could be made.
The expectation is that, depending on the instruction, the data holder would act as if a constrained client, scope or customer is invalid. In relation to CDR Rules, section 4.7, this should also be treated as a request with dubious authentication and the appropriate security related error response should be given. HTTP Error 429 would not be appropriate for any of these circumstances and should be reserved for NFR threshold breaches only.
Should these also be counted as Refusals according to CDR Rules, section 4.7(1)(b)(i)?
If the instruction under rule 5.34 is to refrain from providing access tokens, then any subsequent attempts to access data would necessarily be with an invalid access token so these would not be counted as reportable rejections under CDR Rules, section 4.7. These count as rejections based on lack of a security credential.
Note also that the intention of error codes is to provide deterministic behaviour for ADRs, not to form the basis of regulatory reporting. The DH needs to track reporting refusals and rejections independent of a simple tally of HTTP status codes.
- CDR Rules, Main section, Part 5, division 5, subdivision 5.3, section 5.3.4 Temporary direction to refrain from processing consumer data requests
- CDR Rules, Main section, Part 4, subdivision 4.2.3, section 4.7 Refusal to disclose required consumer data in response to consumer data request