Noting Paper 289 - Register Standards Revision

[CDR-API-Stream]

This is a consultation on the architecture and future direction of the Register, as it is exposed systemically to CDR participants (ie. it will not include aspects of the Register outside the purview of the Register Standards such as the CDR Portal, CTS, etc). It asks for input into high level questions related to how the Register acts as a source of trust and as a provider of essential meta data to the CDR ecosystem.

It is published as a Noting Paper as it is intended to solicit feedback that will steer a schedule of more detailed Decision Proposals on specific topics and will not lead to a decision of the Chair directly. It is still an open consultation and feedback will be responded to and noted for future planning.

The noting paper is attached below: Noting Paper 289 - Register Standards Revision.pdf

The consultation will be open until the 12th May.

[CDR-API-Stream]

The opening comment has been updated and the Noting Paper is now attached.

The Data Standards Body welcomes your feedback.

[CDR-API-Stream]

The Data Standards Body has published a video summarising Noting Paper 289.

[AusBanking-Christos]

Dear DSB,

The Australian Banking Association kindly requests a two-week extension to the existing feedback conclusion date (i.e., 28Apr23), to provide a response on behalf of our Member banks by 12 May 2023.

With Kindest Regards, Australian Banking Association

[CDR-API-Stream]

The consultation has been extended to 12th May as requested

[TT-Frollo]

Question 1 - Should a Shallow or Deep data model approach be adopted? The DSB is seeking feedback on whether it is better for participants to rely on the CDR Register for all meta data related to CDR participants or if the CDR Register should provide data specifically required to establish trust and leave all other data to be discovered or provided directly by the participants themselves. If a specific direction is adopted it could substantially impact many technical features of the Register Standards such as the use of Software Statement Assertions, Dynamic Client Registration and participant discovery.

Whilst this is important, any decision can be non-optimal in different situations. A shallow directory would benefit clarity, speed, and not overload or centralise information where it shouldn’t. This would be preferred. The caveat is creating the need to access distributed information where real time access is required should be avoided.

Question 2 - Should the possibility of multiple registers be accommodated? The DSB is seeking feedback on whether there is a strong desire by participants to leverage their CDR implementations for non-CDR use cases and, if that desire exists, whether the ability to leverage other trust providers would be of value. Feedback on this topic would be specifically useful in relation to the possible incorporation of government data sets or action initiation (including payment instructions) into the CDR regime.

Whilst Frollo does not have a specific use case in mind to implement non-CDR use cases, it is likely that in the future we would seek other sources of information and using the CDR framework (registry, authentication, authorisation, api standards framework) would be desirable. Incorporating the ability to use Multiple registers would make architectural sense to de-risk future changes. Even if only one register is used, incorporating early could protect costly future changes.

Question 3 - Should the CDR Register adopt a Real-Time or Batch approach? The DSB would like to understand if there is consensus that the Register Standards align to a RealTime approach - ensuring that data is always current but making the CDR Register a single point of operational failure - or to a Batch approach - increasing ecosystem resilience but allowing that data will become consistent over time rather than immediately. The Register Standards are currently heavily skewed to a Batch model and there is understood to be minimal appetite to support the service levels required for a Real-Time model. It is therefore the current assumption of the DSB that a Batch model is preferable.

The definition of real time vs batch appears to be centred around the latency of updates not the real time access of the information. Our preference would be for infrastructure that supported real time with resilience, once again thinking of the future. Noting though it may not be every flow or interaction that requires real time or near real time latency of updated data in the registry.

Question 4 - Should international standard alignment be actively pursued? Is there an international standard that can be used to reduce the custom nature of the Register Standards? Alternatively, should the DSB seek to work with international bodies (such as the OpenID Foundation) to define a generic, international, standard for a central trust provider?

We should be mindful of international standards where they are reasonably applicable and trusted. We do not believe that with the extensive nature CDR an off the shelf standard exists. Frollo would support the DSB seeking to work with standards bodies to define important standards relating to trust.

Question 5 - Should a normalised or denormalised API design be adopted? Feedback would be welcome on whether the current, normalised, nature of the Register Standards endpoints should be maintained or whether a denormalised model that simplifies caching would be preferred. This question relates closely to the Real-Time vs Batch question. A Real-Time model would be best served by more normalised endpoints with smaller payloads. A Batch model would be best served by denormalised endpoints that are easier to call and parse on a regular schedule.

Our preference is for the current normalised model. It would be useful for the DSB to call out where issues are occurring or could arise with the current model. I don’t believe an architectural decision should be taken that changes the current model at this time.

Question 6 - Should the CDR Certificate Authority be retained? The DSB would like to understand if the role of the CDR Certificate Authority, as the sole provider of certificates in the CDR regime, should be revisited by a dedicated consultation. For feedback supporting an alternate approach, suggestions for compensating information security controls that could provide similar or better risk mitigation would be helpful. Whilst not a problem for Frollo, it is reasonable to think that it must be painful for Data Holders to configure new CA's in their systems. Frollo would support re-visiting via a dedicated consultation Current Recommendation The DSB is of the opinion that changes to the Register Standards, in some form, will be required in 2023. Beyond this, there is no current recommendation for the consultations to be undertaken or any specific changes to the Register Standards. The consultation plan for the revision of the Register Standards will be based on the feedback obtained from this consultation.

My overall view of the register is that its function is important and should be considered together with the standards for its implementation. Whilst there is a division of responsibilities, the overall design and requirements are worthy of a dedicated consultation. In my experience this is not an area where potential problem should be kicked down the road. Tony Thrassis

[ttranatping]

In general, we at Ping Identity, believe the specifications have reached a point of stability, and that maintaining that stability should be prioritised. Any changes moving forward should be in alignment with international standards.

Question 1 - Should a Shallow or Deep data model approach be adopted? The DSB is seeking feedback on whether it is better for participants to rely on the CDR Register for all meta data related to CDR participants or if the CDR Register should provide data specifically required to establish trust and leave all other data to be discovered or provided directly by the participants themselves. If a specific direction is adopted it could substantially impact many technical features of the Register Standards such as the use of Software Statement Assertions, Dynamic Client Registration and participant discovery.

• We believe that the Shallow Data Model strikes the best balance between coordinating trust between the participants and providing the participants speed and agility in advertising capabilities, without ongoing changes to the CDR Register implementation to meet the demands of the sectors.
• The DSB should continue to document the data model to help participants discover allowances when communicating to other participants.

Question 2 - Should the possibility of multiple registers be accommodated? The DSB is seeking feedback on whether there is a strong desire by participants to leverage their CDR implementations for non-CDR use cases and, if that desire exists, whether the ability to leverage other trust providers would be of value. Feedback on this topic would be specifically useful in relation to the possible incorporation of government data sets or action initiation (including payment instructions) into the CDR regime.

• We agree that non-CDR use cases for existing CDR investments should be allowed, but having multiple registers may not be the answer.
  • Achieving non-CDR use cases with CDR implementations is already possible today. This has been the case since the well-known and JWKS endpoints were adjusted to be public endpoints earlier on.
  • The characteristics of non-CDR participants may not align with the characteristics of CDR participants. For example, ADR’s are frequently being added and removed from the CDR ecosystem - this would warrant a register to control participants as they come and go. The example provided “Australians access government service” does not appear to share the same kind of characteristics, and may be best managed differently e.g. manually.

Question 3 - Should the CDR Register adopt a Real-Time or Batch approach? The DSB would like to understand if there is consensus that the Register Standards align to a RealTime approach - ensuring that data is always current but making the CDR Register a single point of operational failure - or to a Batch approach - increasing ecosystem resilience but allowing that data will become consistent over time rather than immediately. The Register Standards are currently heavily skewed to a Batch model and there is understood to be minimal appetite to support the service levels required for a Real-Time model. It is therefore the current assumption of the DSB that a Batch model is preferable.

• The batch model should be maintained as it provides the best performance and resilience for status updates/enforcement and participant metadata retrieval. The batch model allows implementations to retrieve participant status updates asynchronously, where a status is retrieved and processed prior to an incoming CDR request. This approach can result in near zero latency when adding status validation for consent flow and API calls.

Question 4 - Should international standard alignment be actively pursued? Is there an international standard that can be used to reduce the custom nature of the Register Standards? Alternatively, should the DSB seek to work with international bodies (such as the OpenID Foundation) to define a generic, international, standard for a central trust provider?

• Ping Identity will always advocate for international alignment. There are many advantages to this; shared improvement opportunities, access to international brains trust, and it also provides customers of software vendors with greater leverage when requesting enhancements for local initiatives like CDR.
• OpenID Connect Federation Trust Chains provides promise, but does not have provisions for management and revocation of participants. https://openid.net/specs/openid-connect-federation-1_0.html

Question 5 - Should a normalised or denormalised API design be adopted? Feedback would be welcome on whether the current, normalised, nature of the Register Standards endpoints should be maintained or whether a denormalised model that simplifies caching would be preferred. This question relates closely to the Real-Time vs Batch question. A Real-Time model would be best served by more normalised endpoints with smaller payloads. A Batch model would be best served by denormalised endpoints that are easier to call and parse on a regular schedule.

• We do not have a strong opinion on this, but it seems practical to apply a more normalised endpoint with smaller payloads if a Real-Time model were to be implemented. The payload should contain enough information to perform common procedures, only requiring additional API calls on selective events (such as if a participant status has updated recently).

Question 6 - Should the CDR Certificate Authority be retained? The DSB would like to understand if the role of the CDR Certificate Authority, as the sole provider of certificates in the CDR regime, should be revisited by a dedicated consultation. For feedback supporting an alternate approach, suggestions for compensating information security controls that could provide similar or better risk mitigation would be helpful.

• We believe the CDR Certificate Authority should be retained for confidential endpoints. It 1) supports revocation, 2) is commonly implemented, and 3) it allows implementations to inject a second form of authentication outside of the application. Public endpoints should be presented with certificates issued by a public authority to avoid SSL errors.

[ACCC-CDR]

We welcome the opportunity for the CDR Community to provide input on this important subject, and look forward to reviewing comments on the specific questions posed by the DSB in the noting paper. In advance of this – we’d like to provide some high-level feedback to highlight some potential risks and opportunities relating to the Register.

Our view is that the Register APIs are generally fit for purpose in their current form. Incremental changes may be appropriate, to support new sectors, streamline the operation of the Register, and align it with the published Standards.

However, any changes to the Register Standards should be closely evaluated to understand the costs, the benefits, and whether other alternatives exist to deliver the desired benefit at a lower cost to participants and regulators. For example, other avenues (such as the Service Management Portal, or Participant Guidance) can provide low-cost methods to improve participant experiences. Changes to the way the ACCC displays information via the public register may also address participant confusion regarding brand/legal entity relationships. Any significant changes to the Register should be evaluated against these, and other options to ensure they deliver value to the ecosystem.

While we appreciate the need to anticipate changes to support Action Initiation, it is premature to consider changes to the Register Standards to accommodate Action Initiation ahead of the Rules being published. We suggest that this continues as planning and scoping work, rather than informing decision proposals at this time.

In a similar vein, aligning the Register Standards with International regimes is desirable. However, we note that this alignment will need to be carefully managed, to avoid increasing the burden on existing participants. As such we suggest that this occur over a much longer timeframe than any incremental changes proposed.

We look forward to seeing the community response to the questions posed by the DSB, and to working with the DSB and the community to set the future direction of the Register.

[AusBanking-Christos]

12 May 2023

Submitted on Friday, 12 May 2023 via: [Consumer Data Standards Australia - GitHub site] (https://github.com/ConsumerDataStandardsAustralia/standards/issues/289)

Dear @CDR-API-Stream

RE: ABA Response to Noting Paper 289 - Register Standards Revision

The Australian Banking Association (ABA) welcomes the opportunity to respond to Noting Paper 289 – Register Standards Revision on behalf of its member banks.

We note and welcome the fact that the scope of this consultation is to identify areas for potential change to the Register Standards that would then be “targeted with detailed and more specific consultations”.

We also welcome the acknowledgement in the Noting Paper that “with an existing implementation base in place, the cost of any change is always non-zero, so the value of the proposed change needs to be of sufficient value, over a reasonable period of time, to justify the cost”. It is certainly true that ABA members among many other participants in the CDR ecosystem have invested significant amounts of time and money in implementing CDR solutions that conform to the current Register Standards. Any proposed changes to the standards should be assessed not only from the perspective of the cost/benefit implications of the additional investment but also ensuring that there is sufficient stability in the CDR ecosystem to ensure that existing investments in CDR are actually able to achieve their original cost/benefit outcomes.

The paper identifies 7 potential reasons that may be appropriate reasons for changes in the Register Standards and calls for feedback on the validity and completeness of this list. The ABA suggests that the sequencing of the list could be re-ordered to reflect the prioritisation of reasons for change and the boundaries of an appropriate scope for further consultation.

We suggest that an appropriate sequencing would be: • Increase trust and security • Reduce ongoing maintenance and overheads • Reduce implementation costs for new ADRs • Reduce implementation costs for new Data Holders • Facilitate CDR ecosystem scalability • Facilitate CDR functional expansion • Facilitate non-CDR specific use cases.

The first two items on the list support the maturation and strengthening of existing CDR capability and would assist the current process of increasing CDR uptake in a cost-efficient and appropriately secure manner for participants.

Reducing implementation costs for new participants – without unreasonably burdening existing participants with new costs – is a logical next step. Similarly, changes in the registry standards designed to facilitate ecosystem scalability should not impose substantial change costs on existing participants.

ABA members consider that the final two reasons to consider change to the Registry Standards are not presently appropriate grounds to consider changing the registry standards. Any changes to the standards to facilitate CDR functional expansion to support action initiation should be conducted as part of - and timed in conjunction with - the overall action initiation program. Finally, changes ‘on spec’ to facilitate possible but unidentified non-CDR use cases should only be contemplated when there is a clearly defined use case supported by an endorsed policy rationale and overall economic productivity business case. Changes to the current registry standards that might support presently undefined non-CDR use cases would be an unreasonable imposition of costs on existing CDR participants for no clearly defined benefit.

Accordingly, the ABA suggests that the immediate scope of any consultation on potential changes to the Register Standards should currently be limited to changes intended to increase trust and security and/or reduce ongoing maintenance costs and overheads. For this reason, we have not provided detailed responses to the identified questions in the paper. Those issues should be examined through the lens of the purpose for change rather than without context the other way around.

Finally, the ABA notes the acknowledgement in the discussion paper that one of the drivers of cost and complexity in current implementations of the Register Standards has been the lack of “vendor supported international standards”. Accordingly, the ABA encourages the DSB to actively engage with relevant software vendors as part of any consultation process to ensure alignment with such emerging standards and minimise the risk of requiring further bespoke implementations. ABA members stand ready to help facilitate any such discussions at an appropriate time.

Again, we thank the DSB for the opportunity to provide feedback on behalf of our members. As we also acknowledge and thank the DSB for kindly extending this consultation to allow us more time to prepare our response.

Yours sincerely

Australian Banking Association

[jayden-basiq]

General response

Basiq’s position is to recommend the CDS maintain the consistency of the existing implementation as long as ongoing usability, extensibility, stability, security and scalability is possible. These five factors we view as the only triggers for a change to the existing implementation.

With this in mind we have some specific recommendations we propose to simplify the existing implementation. We have also included some questions we would like to propose for further discussion.

Basiq recommendations

Automated API Services for Software Product Setup and Maintenance Overview

The current process for setting up a software product is laborious, necessitating human intervention, which can lead to inefficiency and potential errors. The introduction of API services to facilitate programmatic setup of product services is proposed to streamline and automate the process. This capability would allow Accredited Data Recipients (ADRs) to automate setup and integrate it seamlessly into their core platforms, thus eliminating the manual nature of the onboarding process and setup.

Suggested API Services

The proposed API services would focus on creating software products, requesting and renewing production certificates, and adding and updating authentication details and software product endpoints.

Creating Software Product

Automated services would allow for the creation and updating of:

• The Legal Entity Name
• The Company Description

Requesting a Production Certificate

APIs for the production certificate would enable:

• Uploading a generated Certificate Signing Request (CSR)
• Receiving the Production Certificate

The current process, which requires manual review on the CDRTechOps side, could be automated for increased efficiency. A discussion on whether this manual review is necessary might be beneficial.

Adding and Updating Authentication Details and Software Product Endpoints

API services could facilitate updates to:

• JWKS URL
• Redirect URL
• Client URI
• Logo URI
• Revocation URI
• Sector Identifier URI, etc.

Incorporating these services into the API suite would significantly streamline the setup and maintenance process for software products within the CDR ecosystem.

Why is an API important for Streamlining Software Product creation and management in the CDR Ecosystem?

APIs play a pivotal role in creating an efficient, automated, and interconnected CDR ecosystem. Having an API would allow better alignment with the [CDR Register]. Not all ADRs have the same process and use case as Basiq, however some Ecosystem improvements for all may include:

• Automated Software Product Creation: APIs allow for programmatic creation of a software product. This means once a company is listed on the register, an API could automatically generate a corresponding software product. This not only saves time but also ensures data consistency, as information such as Legal Entity Name, Logo URL, CDR use case, etc., is replicated from the register accurately.

• Reduced Administrative Overhead: An API-driven approach significantly reduces the need for administrative involvement. Instead of manually inputting data to set up each software product, APIs can handle these tasks programmatically, freeing up the admin to focus on more critical tasks and strategic initiatives.

• Synchronized Updates: With APIs, any update made on the ACCC register can trigger the creation or update of a SoftwareProduct. This synchronization ensures that the software product information remains up-to-date with the company register, minimizing data discrepancies.

Basiq Questions for discussion

Should Dynamic Client Registration (DCR) Be Removed from the CDR Ecosystem?

Dynamic Client Registration (DCR) functions as a key communication medium within the CDR ecosystem, enabling banks and other entities to synchronize with the register. Despite its importance, certain aspects of DCR may lead to unnecessary complexities and inefficiencies. For instance, situations have arisen where SoftwareProducts failed to register with Data Holders (DHs), necessitating the creation of individual JIRA tickets. This process falls outside of standard SLAs, potentially causing delays and impacting CDR data usage.

The proposal here is whether DCR's elimination could streamline operations within the CDR ecosystem. Given that Data Holders already communicate with the register, bypassing DCR could lead to a more efficient and straightforward synchronization process.

However, it's crucial to note that DCR does provide valuable response information. Therefore, any alternative solution should ensure the accessibility of this information. Moreover, DCR permits specific industry activation for a software product, fostering a more purpose-driven use case rather than a blanket "enable me for everything" scenario.

One potential solution could be the implementation of an API request for activating specific industries. For example, a request could be made to activate a software product for Open Banking, encompassing all available Data Holders. In the event of a new DH being introduced and added, it would be sensible to automatically register a SoftwareProduct for this DH if it’s industry-specific. Following this, a webhook could notify the listener of the new DH for their internal system integration. This approach could maintain the specificity provided by DCR while potentially simplifying the process.

How Does the Current Onboarding Process Impact Time Efficiency in the CDR Ecosystem?

The current onboarding process within the CDR ecosystem can prove time-consuming, with specific stages requiring a significant duration to complete. To provide a clearer picture, let's consider the practical steps involved in this process.

In the absence of automation on our side, requesting the Production Certificate (Prod Cert) generally takes between 2 to 10 business days, averaging around 5 days. This is the time required to complete and receive the Prod Cert.

Following this, the approval of the activation of a SoftwareProduct takes an additional 2 to 10 business days to complete, averaging another 5 days. This stage involves verifying and validating the information provided during the onboarding process.

Therefore, these two stages alone could potentially amount to 20 business days, or roughly one month of waiting time. This duration could extend even further in the event of any delays or complications. This extended timeline for onboarding could potentially hinder the efficient operation and expansion of the CDR ecosystem.

How Can the Complexity of Certificates and Secrets Management Be Simplified in the CDR Ecosystem?

The management of certificates and secrets is a crucial aspect of ensuring security within the CDR ecosystem. Although it's essential, it's also complex and can be time-consuming, especially when handled manually. The question that arises is - could there be a simpler way to handle this process, while still maintaining the required level of security?

Personally, I appreciate the added layer of security that comes with the need to create certificates and secrets. However, the manual nature of this process can be cumbersome and might benefit from some degree of automation.

Consider the benefits of an API-based approach:

• Automation: With APIs, the certificate request, issuance, and renewal process can be automated, saving time and reducing the potential for human error.

• Integration: APIs would allow for smoother integration into existing infrastructure or tools. For example, continuous integration/continuous deployment (CI/CD) pipelines or configuration management systems could seamlessly incorporate these APIs.

However, we must also consider the potential drawbacks:

• Complexity: Setting up and managing API integrations might require technical expertise and additional development effort. This could prove challenging, especially for organisations with limited resources or technical know-how.

It's worth noting that many Accredited Data Recipients (ADRs) may not have the volume of operations that necessitates API automation, and for them, the manual Portal approach may be sufficient. However, for larger entities or those with a high volume of operations, exploring automated, API-based solutions could prove beneficial.

Responses to Noting Paper Questions

Question 1 - Should a Shallow or Deep data model approach be adopted?

In regards to the data model approach, Basiq would support a shift towards a shallow model. This would allow for the CDR Register to focus on providing crucial trust data, while other data can be discovered or provided directly by the participants themselves. This approach would likely enhance efficiency and reduce complexity in the CDR ecosystem.

Question 2 - Should the possibility of multiple registers be accommodated?

Basiq believes that maintaining existing implementations should be a priority. The inclusion of government data sets and action initiation could be treated similarly to an industry vertical, thus not necessitating multiple registers. The concept of failover could be accomplished within a single register setup, ensuring stability and continuity of services.

Question 3 - Should the CDR Register adopt a Real-Time or Batch approach?

Basiq suggests that maintaining existing implementations should be prioritized. While a real-time approach may have its benefits, it might introduce additional latency, which could impact the overall efficiency and effectiveness of the CDR Register. The batch model, which the Register Standards currently heavily favor, has proven to be effective and may still be the preferable choice.

Question 4 - Should international standard alignment be actively pursued?

Basiq proposes that the current CDR ecosystem could suggest our outcome state as a standard for other countries, such as New Zealand. While it could be valuable to discuss international standards that may enhance the current implementation, a complete adoption of a different standard might disrupt current CDR participants. Therefore, any changes should be carefully considered and possibly introduced at a maintenance iteration level.

Question 5 - Should a normalised or denormalised API design be adopted?

The decision on whether to adopt a normalized or denormalized API design is largely dependent on the answer to Question 3. Depending on whether a real-time or batch approach is selected, the API design should be adapted to best support that choice.

Question 6 - Should the CDR Certificate Authority be retained?

Basiq is satisfied with the current role of the CDR Certificate Authority. The Certificate Authority plays a crucial role in maintaining the security of the CDR regime, and its continuation would be beneficial for the integrity of the system.

[CDR-API-Stream]

Thanks everyone for feedback. We will be closing this thread now and reviewing the feedback received.

No decision will be made from this thread but the expected ongoing consultation plan will be published here in due course.