Decision Proposal 186 - Engineering Support

[CDR-API-Stream]

As discussed on the implementation call on the 20th May the DSB is expanding the engineering team and will have the capacity to invest time in additional tools and resources. This can take the form of specific tools but also moderated open source projects.

We would appreciate feedback from the community on what tools, libraries or other technical assets would be useful to:

• Reduce implementation costs and time
• Reduce maintenance cost and time for ongoing management of CDR implementations
• Help explain or clarify the intent and requirements of the standards
• Help explore the potential value of the CDR for prospective participants who are considering participations

There is no proposal document for this consultation and there will be no change to the standards that arise from the feedback provided but the feedback provided will be used to shape the forward plan for the engineering team.

This consultation will remain open until the 2nd July.

[deboraelkin2]

The CDR Register is a key player in the CDR ecosystem. It would enormously help the development process for both Data Receivers and Data Holders to have a publicly available Register sandbox, capable of generating SSAs, providing JWKS, etc.

Similarly, I think it would help to have a data holder sandbox, to help Data Receivers develop and test, as well as prospective participants to explore and understand the regime. The sandbox could be exposed via a Developers portal, where the Open API specification is published and can be tested interactively.

Finally, having a publicly available test suite would also help development, testing and accreditation.

[CDR-API-Stream]

That's for the feedback Debora

[commbankoss]

Commonwealth Bank requests an additional 2 weeks to consult on this proposal.

[JamesMBligh]

The consultation has been extended as requested.

In the meantime, however, the engineering team will progress with the development of the following:

• A series of JSON schema that are certified by the DSB against the standards that can be used to validate data holder response payloads for banking and common end points
• A postman collection that will use these schema to execute a series of tests against banking and common end points
• Extend the above to request schemas

@deboraelkin2 - in response to your comment, the ACCC have now released an open source mock register. We will look at possibly creating a developer portal with the stubbed end points as a next step if there is broad support

[deboraelkin2]

Thanks @JamesMBligh. Having an official mock register certainly is a great contribution to the CDR ecosystem.

If it helps, Google Cloud has a Postman collection that is open source. Even though it works specifically with the Google Cloud Reference implementation for CDS, it could be used as a basis for the official Postman collection.

[damircuca]

Feels like Christmas :-) 🎄 🎁 Thanks for opening this up...

A few things:

• Interactive docs - with request response
• Reference implementation for data holders (@deboraelkin2 has shared an amazing project it would be amazing if this was extended in multiple technologies - especially important for data holders when reciprocity kicks in)
• ACCC Sandbox
• Better support / documentation for ADR and Data Holders conformance testing tools (feels like a mystery that needs to be solved at the moment - would be great to surface these and create some tools to help with automation of these)

Thanks for asking :-))

[biza-io]

As far as ideal engineering outputs, Biza.io refers to the outcomes proposed by our Founder & CEO (then Lead Engineering) who proposed, in March 2019 and initially demonstrated pending InfoSec profile finalisation in June 2019, a number of artefacts including a reference implementation and standalone conformance suite.

The DSB decided shortly after the initial production of these artefacts that 100% of engineering time was best focused on the Banking Product Comparator which while helpful for PRD and pretty for demonstration has no real usefulness for CDR Data.

Since then and with the passage of time we note there are a number of vendors and open source projects, including those produced by Biza.io, Regional Australia Bank, Google and others, which fulfill many of the desires from commenters and consequently we would suggest that the DSB consider allocating it's presumably limited available funding to the support of suitably licensed projects (ie. open source) rather than attempting to start from scratch and in essence provide competing products in the fledgling ecosystem it wishes to foster.

The use of a software development entity which provides funding/grants to eligible projects is quite common in open source projects (Linux Foundation, Apache Foundation, OpenID Foundation, Ethereum Foundation among others) and would be a welcome change to the traditional government approach of building substandard outcomes with limited funding.

[ghost]

I really like the @biza-io suggestion of supporting open sourced solutions. Perhaps it could be through both sponsorship arrangements as well as active development contributions. It not only fosters existing OS projects but encourages new ones to start, which only helps the fledgling CDR community get off the ground and run on it's own.

[JamesMBligh]

Thanks for the additional feedback. The support of existing open source projects, with suitable license, is a very attractive one. The DSB doens't have a large engineering team, which is why we reduced our ambitions over the last eighteen months. While we are scaling up, it will only be by the addition of a couple of engineers.

As a result, while we don't have the capacity for funding or grants we could help support existing projects with development support and by validating that specific releases align to the standards.

In addition, we will likely focus on artefacts that support other projects and services. We will not be seeking to compete with the services evolving in the marketplace.

We may be able to host (without SLA) of some of the open source projects for others to use (such as the mock register as Damir suggested). Would that be of value?

[biza-io]

Thanks for the additional feedback. The support of existing open source projects, with suitable license, is a very attractive one. The DSB doens't have a large engineering team, which is why we reduced our ambitions over the last eighteen months. While we are scaling up, it will only be by the addition of a couple of engineers. As a result, while we don't have the capacity for funding or grants we could help support existing projects with development support and by validating that specific releases align to the standards.

Biza.io appreciates the DSBs consideration although we note that, based on recent evidence presented to the Economics Legislation Committee, the day rates of personnel within the DSB for the government to acquire these specialist skills are quite high meaning that the addition of "a couple of engineers" full time is likely to be a reasonably large financial value - back of the napkin math at 50% of the prices quoted in estimates translates to $1500/day x 2 engineers = ~$700K+ per year. While we acknowledge that establishing a grants procedure may be structurally difficult for the government to achieve we would also highlight that such an approach is likely to have the best long term impact for the ecosystem. Additionally, an engineer reporting to uninvolved parties and proposing changes to open source projects will likely result in a lack of alignment on desired outcomes for the individual projects leadership team.

As a middle ground our suggestion, in the absence of a grants process, would be for the government to make a direct hire of engineering and/or support resource and embed them full time within the engineering and/or support teams of established open source projects such that - with sufficient integration time - these resources can be incorporated in the end to end operation of these projects. We would note that a good candidate project for this sort of involvement is the Dr G project developed by Regional Australia Bank and it's other very helpful tool myCDRdata as both these tools are being utilised heavily by current and prospective ADRs and by Data Holders themselves (including Biza's customers).

With regard to validating standards alignment we would note that the government has consistently avoided providing endorsement to any solution at any time. While we would welcome such a validation process Biza feels this is outside the scope of the DSB as it directly pertains to potential enforcement activities conducted by the ACCC. Nonetheless, should this be persued we would request the engineering team formally defines the criteria for verification, ensures there is sufficient resource to service any participant who wishes to have this verification conducted and also establishes what process will be followed to effectively "anoint" solutions in market. This is driven by observations that certain vendors (and potentially even Biza.io) have consistently used tacit endorsement from the government as promotional material.

In addition, we will likely focus on artefacts that support other projects and services. We will not be seeking to compete with the services evolving in the marketplace. We may be able to host (without SLA) of some of the open source projects for others to use (such as the mock register as Damir suggested). Would that be of value?

Biza already provides an ACCC Register at cost (and in many cases for free) to any participant of any type who wishes to join and on this basis it could be stated that the DSBs hosting of services would implicitly conflict with the services we are already offering. This Register contains all of the testing environments for both our conformance and holder customers and as a consequence has a significant number of Active market participants already. Should the government wish to provide this service to all participants Biza would happily engage in a conversation to formalise it's delivery.

Specifically with regard to the Mock Register, while it is a valuable addition to the ecosystem, a useful tool for individual developers and we applaud the ACCC team for it's delivery it is likely not feature rich enough for multi-party use as it uses a static file for loading state and does not allow dynamic state changes for testing purposes.

[JamesMBligh]

I'm obviously not going to comment on what the team members get paid. Biza seem to use bigger napkins than we do, however.

While we don't have the mandate or budget to consider grants or the formal augmentation of open source projects we do have a strong desire to contibute to, and encourage, open source projects and the team is actively looking for opportunities to do so.

The feedback on certification is very helpful and we will take it on board. Our understanding is that there is no problem with the DSB providing certification as long as it is limited to whether the standards have been correctly implemented in a technical solution and that this is never interpreted as certifying compliance under the rules, accreditation or registration obligations. That understanding could be incorrect but it may be a moot point in the medium term as there is likely to be a lot of complexity in establishing a certification process.

Thanks also for the feedback on the hosting of a mock register.

[JamesMBligh]

We have a lot of consultations open so I may close this thread for the time being. If anyone has any further suggestions feel free to raise issues on the various repos we support or reach out to me directly.