Decision Proposal 245 - Enhancing Data Recipient Accreditation Negotiation

[CDR-API-Stream]

This decision proposal outlines questions to help develop a recommendation for Enhancing Data Recipient Accreditation Negotiation

The decision proposal is embedded below:
Decision Proposal 245 - Enhancing Data Recipient Accreditation Negotiation.pdf

This consultation will be open for feedback until 01st May 2022 subject to the caretaker period.

---

The consulation period for this DP has been extended to the 27th May 2022, the Friday after the caretaker period is expected to conclude.

[CDR-API-Stream]

For reference, Issue 418 discusses CDR Data Holders outbound connection whitelisting.

This is an explicit use case called out in DP 245 and we would like to encourage further discussion on this topic in the context of this Decision Proposal

[AusBanking]

The ABA makes the below submisison in relation to DP 245

220527 - ABA Submission - DP 245.pdf

[commbankoss]

Commonwealth Bank supports the ABA’s view on Decision Proposal 245,

[AdatreeCDR]

1. What additional information will the CDR Register require to convey the trust of different types of Data Recipients in the ecosystem?

Provided by "accreditation" the DSB mean passing the ASAE3150 audit and other associated activities then Adatree does not believe finer grained accreditation is required for ADR read access. Adatree does not believe accreditation by specific use case is a good or easily extensible model for accreditation of participants. Accreditation by read or write access is more appropriate and is more practically aligned to the audit process that drives accreditation. Read access to CDR data should require a certain technical standard to be met. Write access should also require certain technical standards to be met. Accreditation based on the purpose of read access is splitting hairs in our opinion. An ADR CDR environment is assessed on whether it meets the standards and controls to securely handle CDR data or not. Accreditation and audit to handle transaction data, and then separately again to handle payee data because an ADR comes up with another use case will only serve to increase time, effort and costs to entry.

Expanded access to scopes based on passing conformance testing is also not really an indicator of the ability to secure a data environment as conformance testing in its current form will only test:

• If the new scope is in the Pushed Authorization Request
• Has the correct API been called

This would be a trivial exercise and in our opinion would not prove anything worthwhile about the ADR’s ability to secure different datasets.

Continuing to accredit data recipients on an economy wide basis is the most flexible option and flexibility is badly needed when dealing with such prescriptive data access and data use rules already. Data Recipients must adhere to the data minimization principle and with the changes proposed by Adatree in #486 then allowing ADRs the ability to minimize the scopes associated with their Software products via API will further solidify this principle within the ecosystem, while still allowing them to create new Software products for different use cases and get them to market quickly.

2. How can bilateral trust and accreditation be issued by Data Holders to individual Data Recipients?

Adatree agrees with @AusBanking in that bilateral trust arrangements should be confidential in nature. We would go so far as to say involvement of the Register in such arrangements is not entirely necessary. The CDS is open and should be extensible by private arrangement.

3. What additional capability should be investigated to address current OAuth authorisation scope negotiation limitations?

Adatree again agrees with @AusBanking in that any further investment into changes to the authorization scope process should be part of FAPI 2 uplift.

4. What additional Accredited Data Recipient and associated Software Product lifecycle information should be available from the CDR Register?

Adatree believes Data Holders should be given the ability to establish trust with Data Recipient Software based on metadata available at the Register in the same way that Data Recipients establish trust based on Data Holder metadata available at the Register. Whatever "trust" means to a Data Holder is up to them, but it should not impact the ability of Data Recipients to onboard quickly to the Register and perform client registration.

Adatree polls the Data Holder Brands endpoint at regular intervals and performs Dynamic Client Registration based on endpoint metadata. In this case the Register's Data Holder metadata is trusted by Adatree because it is supplied byt a trusted entity. In a similar approach, Data Holders could in theory perform automated domain green-listing of Data Recipient Software products based on the recipient_base_uri exposed as part of ACTIVE Software Products. If they wish to do this we believe they should be automated and be given a short and specified amount of time within which this is expected to take place once the Software Product metadata appears on the Register. We would suggest 1 hour to ensure this is an automated process and not a manual one. Data Holders are already expected to poll for Data Recipient Software metadata for Software status changes so we don't think this is unreasonable. Anything longer would be detrimental to any attempt to speed up and automate the provisioning of Software Products and associated certificates via API as already suggested by Adatree and outlined in #508

[NationalAustraliaBank]

NAB supports ABA's view on this decision proposal

[WestpacOpenBanking]

Westpac supports ABA’s view on Decision Proposal 245.

[CDR-API-Stream]

Thanks to everyone who provided feedback. This conversation will now be locked while the submissions are considered.