- ACCC (CDR Register, CDR JWKS). - The end points are absolutely clear. We can allow outbound traffic for this.
- Digicert CA (for OCSP checks) - The end points are made available by Digicert so we can specifically allow these calls.
- ADR (Accredited Data Recipient) (JWKS, cdr arrangement endpoint) - These URLs are not known prior to a Dynamic Client Registration (DCR) request.
- Allow all outbound traffic - which is not a sensible thing to do. The banks are unlikely to support this approach.
- Allow a DCR flow to come through and fail - Use the information in DCR (getting the ADR end points and allow egress traffic for that in some automated way) so that a subsequent request from the ADR is successful.
Have the ADR end points communicated via another mechanism to the Data Holder.
Is there a standard recommended approach to this issue?
The DSB does not give detailed guidance on internal implementation questions.
We can, however, say that:
- Giving an initial error is a non-compliant solution
- Requiring a separate path for ADR registration is a non-compliant solution
This eliminates the second and third choices you listed.
This issued was raised by at least one Data Holder during consultation on the standards. The standards are the result of combining that feedback with other feedback. This is an inherent issue with the OIDC Dynamic Client Registration protocol. This is an international standard tested by the industry.
It is also a feature of many other protocols such as internet browsing and the exchange of email. The compensating controls for these implementation models may be more appropriate than the compensating controls normally applied to B2B communication, where both endpoints are often known in advance.