Dynamic Client Registration Response Time NFR

[NationalAustraliaBank]

Description

Regarding the Dynamic Client Registration API, the response time currently set in the Data Standards is 1000ms.

Now that the NFRs are binding (as per Github 208), NAB would like to confirm how external dependencies outside of the Data Holders sphere of control (eg. time spent calling Registry API) are factored into the overall response time of this API.

Area Affected

Dynamic Client Registration API

Change Proposed

Update the Data Standards to make allowance for external dependencies outside the Data Holder's sphere of control into the response times NFR for the Dynamic Client Registration API.

[JoeGunnion]

Hi wondering if there is some generic help available We at CFCU have received an Error with Scenario 2 "Dynamic Client Registration" - the last step - Verify dynamic client registration response - is this an error we need to report to our 3rd party Core banking CTS-Scenario 2 - Dynamic Client Registration - Error.docx

Thanks ?

[CDR-API-Stream]

Hi @JoeGunnion, general advice is best submitted using the "Raise a question" feature on the CDR Support Portal. If you have an issue with CTS this can then be addressed by the ACCC.

[NationalAustraliaBank]

Could the DSB please respond to the issue above?

[CDR-API-Stream]

Hi @NationalAustraliaBank, Maintenance Iteration 10 commences next Wednesday. This issue has been added to the backlog. The first meeting will involve discussion of which change requests should be prioritised for consultation this iteration. I'd encourage you to participate in that backlog grooming and prioritisation process.

[JoeGunnion]

Hi Please remove me from further notifications

Thanks Joseph Gunnion

[CDR-API-Stream]

Hello @JoeGunnion this is a feature you control. You can unsubscribe to notifications for issues you have commented on using the "Unsubscribe" button on the right hand side underneath Assignees/Labels/Projects/Milestone/Linked pull requests.

[JoeGunnion]

Thanks

[CDR-API-Stream]

This issue was discussed in the Maintenance Iteration 11 call. It was agreed to incorporate this change request into this maintenance iteration.

It was acknowledged that the client registration APIs that perform an outbound call to the ADR's JWKS endpoint are impacted by the response time of the data recipient.

Because DCR APIs are not consumer facing, it was proposed that they should be reclassified in the Unattended tier performance requirements. This would propose a 4000ms NFR for DCR APIs. We discussed, but did not determine whether this only applied to PUT and POST operations or all DCR operations (GET, PUT, POST, DELETE).

To determine suitability of this classification, it is asked that Data Holders provide evidence of average response rates for their DCR APIs to ensure the proposed classification provides sufficient time to meet NFR compliance requirements.

There were no issues raised by ADRs - the main consideration was that the APIs still accepted, processed and updated their client registration whether that took 1000ms, 4000ms or longer.

Discussion also considered whether NFRs should be imposed on ADR software solutions to ensure timely response rates for JWKS calls. This has been taken as an action by the DSB and ACCC to investigate.

[AusBanking]

As data holders and data recipients, Australian Banking Association members believe that the NFR requirement for the initial dynamic client registration call should be at least 30 seconds (excluding the time it takes to call ADR’s JWKS endpoints)

[CDR-API-Stream]

Thanks @AusBanking, previous maintenance calls considered a response time of 4,000ms. Can you please provide further background on why a 30,000ms response time is proposed by ABA members?

[AusBanking]

Hello @CDR-API-Stream

Dynamic Client Registration is a complex process with multiple steps. For many banks, it involves the registration of the ADR in multiple systems across banks and a validation of the registrations through several firewalls.

While this is complex, many banks have worked to automate these functions and are now in a position to ensure a smooth experience for ADRs getting registered while maintaining bank security protocols. We have understood through conversations with ADRs that they are not impacted from a business perspective of a higher response time value, particularly as it is a once-off interaction and does not have any material impact on their operations. Moreover, the benefits of an automated registration process means an efficient process for both ADRs and data holders.

We note that the most important factor is the successful completion of the call without requiring manual intervention, and that a proper whitelisting process with verification protocols will ensure the best outcomes for ADRs and data holders, even if it takes a little time.

Also, there is no impact to the consumer as a result of this additional time required to whitelist, either from an experience or data quality perspective. In fact, a secure whitelisting process has broader benefits for bank customers through a more secure process to access their data.

For these reasons, the ABA supports a flexible approach to setting a reasonable time, and previously mentioned 30 seconds. We have had a rethink, and as a complex task that has no business or consumer impact, it is not clear why the time could not also be closer to 1 minute as a reasonable standard.

This time will ensure that data holders that wish to whitelist today and in the future have the time to do all the necessary checks, with a little buffer to capture the variety of data holders in the future and the level of automation and tech sophistication they can achieve.

[CDR-API-Stream]

Thanks for the additional information @AusBanking. If the increased NFRs are required to support automated whitelisting processes, it may be prudent to decouple those activities from the client registration process itself.

Whilst one option is to increase NFRs, this suggests we are solving for the symptom, not the cause. Options to accommodating this can be discussed in the maintenance iteration calls

One option is to have a mechanism where the metadata of the client is available to the Data Holder ahead of client registration to ensure there is sufficient time for whitelisting. This could be solved by supporting such functionality in the CDR Register. The downside of this approach is that it pushes more business logic into the CDR Register rather than delegating trust establishment at the client level to each ADR+DH connection. There is also the question of changes to metadata that may impact whitelisting and update operations on existing client registrations need to be considered.

A second option is a staging process where registration is accepted but processed asynchronously with the ADR checking after all processes have completed. This could be achieved either via a client registration status being introduced or a Wait-Retry pattern.

[AusBanking]

Thanks @CDR-API-Stream

We note that increasing the NFR requirement is the simplest way of resolving this issue, and other solutions you mention require a build which will involve time and expense. It is not clear why the simplest solution could not be implemented here, especially due to the absence of any real impacts for ADRs and zero impact to consumers.

We would therefore recommend an increase to the NFRs as the straight-forward solution here.

[CDR-API-Stream]

This issue was discussed in the maintenance iteration call held on 17/08/2022.

The reasons for Data Holders whitelisting outbound ADR endpoints was discussed. With some Data Holders locking down all outbound calls from their infrastructure, their security controls required a mechanism to limit outbound calls to specific locations. Given external domains are provided from a trusted source (the CDR Register) it was asked why Data Holders cannot provide passive whitelisting at the time an outbound call is made to check against the ADR endpoints registered in the CDR Register.

The solution to increase NFRs was discussed. Whilst some Data Holders preferred this option, this doesn’t appear to solve the root cause. Instead it shifts the problem. There are several outbound endpoints that an ADR can register including their logo URI, JWKS endpoint and redirect URIs. In addition, to support Pairwise Identifiers, OIDC introduces the concept of a sector_identifier_uri which allows ADRs to host a JSON document on an additional endpoint that provides a list of their redirect_uris under single administrative control. In solutions that involve affiliate models or many software products under different domains but singular administrative control, the number of external domains may be large.

As a result, whitelisting as a synchronous process is an O(n) problem whose duration will increase with the number of outbound domains to check and whitelist. Given the whitelisting processes may differ from one data holder to another, simply changing the NFR doesn’t appear to achieve the goal of compliance relief. As the number of domains to whitelist increase, the risk of timeouts also increases.

Whitelisting can occur on new registration or updated registration. There is also an ongoing need for Data Holders to check the endpoints presented in the sector_identifier_uri JSON document because the contents may change without a corresponding registration metadata update call.

Looking at the problem from a technical perspective, it would appear best to look at ways to decouple the data holder’s whitelisting security processes from accepting a client registration (new or update). Introducing a client registration status would provide an asynchronous approach that can provide clients with efficient responses to registration requests whilst enabling data holders to run their security and business processes offline. Once those processes are complete the data holder can activate the client’s registration. The time for completion of these tasks is still important but less critical from a technical interoperability perspective because we avoid timeout issues and failed registration requests.

The DSB proposes three options for consideration:

Option 1: CDR Register advertises ADR metadata

In addition to the ADR Logo URI, the CDR Register advertises the JWKS, redirect_uris and sector_identitifier_uri endpoints in the Get Data Recipients API. This allows the Data Holders to discover endpoint locations ahead of a registration request by the ADR to the Data Holder. Whitelisting activities can occur in advance of the registration request.

This option involves changes to the CDR Register, ADRs and Data Holders. This option would impact all Data Holders regardless of whether they white list outbound endpoints or not.

It also places more dependence of the CDR Register rather than delegate the trust relationship to the ADR and Data Holder.

If the Data Holder has not re-cached the ADR metadata at the time of registration there is a risk that the list of endpoints is not synced and whitelisted. As such there may be a small but reasonable chance of registration rejections.

This option is hard to administer because there is an onus on ADRs to observe a delay between updating their software product metadata with the CDR Register and calling the Data Holders. If a Data Holder cannot cache the updates in time, the registration would fail because they have not performed proactive whitelisting. This option also faces issues where the CDR Register is unavailable or offline and metadata cannot be collected by the Data Holder. In effect, it can create a race condition and it is not guaranteed that the Data Holder will have whitelisted all ADR domains. As a result, error handling would also need to be designed for when calling the DCR endpoints to update client metadata.

Option 2: Introduce a Registration Status

Client Registration introduces a “registration status” and defines a state machine that allows ADRs to register immediately but transition into a state of “in review”. The Data Holder issues the client with a client_id and their registration status.

An ADR can poll the Data Holder using the existing Get oAuth Client Registration API. This API would be updated to include the new registration status. When an ADR obtains a response where their registration status is “active” they can then proceed to make authorisation calls to the Data Holder.

With this solution, there is no requirement for a 30 second NFR. A more generous NFR, say 60 minutes, can be offered to process the client registration offline.

For Data Holders that do not perform whitelisting, they can issue an ADR with a client registration status of “active” and avoid the client registration entering an “in review” state.

This change would impact ADRs and Data Holders. The change to ADRs would be fairly minimal. They would be required to check the status of their registration request and continue to verify it until they obtain an “active” status.

This change would also provide the most extensible and future proof solution if there were other registration processes that would benefit from an asynchronous process to allow Data Holders to process certain aspects of the request offline.

Option 3: No whitelisting

In this option, Data Holders may only perform application-level whitelisting to filter external calls at the time an outbound request is made. Otherwise, Data Holders would not be permitted to perform automated whitelisting on registration if they could not satisfy existing client registration NFRs.

Summary

The DSB has indicated that the Register APIs require review in light of the introduction of Action Initiation, cross-sectoral Data Holders and community requests (see Allow ADRs to specify scopes for a Software Statement Assertion (SSA) to support cross industry software products #486) that a Decision Proposal which looks holistically at the uplift of the CDR Register and client registration is required. This Decision Proposal is expected to be published for consultation in October 2022.

In specified reference to this change request the DSB does not believe that a change to the NFRs, as proposed, would be the best solution for the stated problem or in the best interests of the regime as a whole. As a result we are not proposing to recommend a change to the standards as a result of this CR.

[CDR-API-Stream]

Closing as this issue will be considered as a Decision Proposal, see https://github.com/ConsumerDataStandardsAustralia/future-plan/issues/94.

[c799878]

CDR Registry publishing the domains (or origins) an ADR uses -- not the specific JWKS, redirect_uris, etc -- would be a decent solution. It does imply an ADR may need to wait, perhaps up to a day, after adding a new domain (which should be very rare).

Option 2: Introduce a Registration Status -- sounds like a wholesale change from DCR standards. Standard DCR software libraries may no longer be usable.