commbankoss
commented
6 years ago Commonwealth Bank is supportive of the principles that have been applied to developing the Consumer Data Standards (Standards). A summary of our recommendations are below, and have attached a document containing our detailed analysis. Data_Standards_Submission_Github.pdf
Standards
With respect to the standards, Commonwealth Bank is broadly supportive of the recommendations associated with the versioning of APIs, HTTP response code definitions, and payload extensibility. Further clarity is required around the definition of fields marked as mandatory or optional. We are partially supportive of the definition of API versions with a recommendation around standardising to HTTP header versioning only. Commonwealth Bank also has strong views around technical complications relating to pagination and recommends the use of cursor based pagination as an alternate approach. Lastly, Commonwealth Bank recommend Data61 revaluate ID permanence for its complexities.
Security
In relation to information security, Commonwealth Bank is concerned that important topics are yet to be addressed. Given the relationship between the API Standards and Security Standards, it is difficult for us to provide support around a number of topics until more clarity is provided on security.
There has been limited documentation available regarding the Information Security Standards and the lack of clarity around this is emerging as an implementation risk for the regime. Commonwealth Bank recommends that Data 61 devote additional resources towards developing standards in this area, provide additional time for review, and ensure that industry participants are able to submit separate feedback regarding the Standards for information security once they are released.
A key concern around information security is the ability for a consumer to provide fine grained consent to data being shared, and this has not been adequately reflected in the standards established to-date.
The regime should ensure that security standards define how to prevent known vulnerabilities associated with API implementations from being easily exploited through common attack vectors, such as phishing attacks. For this reason we continue to advocate for a decoupled authentication framework, as opposed to redirection frameworks from uncontrolled devices, to re-enforce safe practices and help protect consumers.
Banking APIs
Commonwealth Bank is broadly supportive of the majority of the API definitions relating to accounts. Our primary concerns are around the scope of included data. We believe the current coarse-grained approach may lead to unnecessary over-sharing of sensitive data. For particular aspects of the standard, such as the implementation of individualised account objects and bulk data, we have technical concerns around the complexity which will result in a protracted delivery timeline. As such we suggest that they are pushed to a further version of the standards to accommodate this. The product reference data API requires further assessment. Commonwealth Bank recommends Data61 continue to work collaboratively with the industry to understand how to best represent product in the regime and refine this API. We also re-iterate our concerns about the inclusion of a direct debit payload as this data is not held by the bank. Finally, we have concerns around the potential leakage of Personal Information which is included in the payee payload.
Common APIs
Commonwealth Bank are not supportive of the current definition of the customer payload. We believe description and use cases of this API are not fit for purpose and could again lead to inadvertent data leakage. We recommend the deprecation of this API in favour of an amendment to the accounts payload, and use of the OAuth 2.0 UserInfo service.
Additional Recommendations
- Testing
- The Commonwealth Bank needs adequate testing standards to ensure we are building what is required for July. This must be included in version 1 of the Standards in December.
- Reporting
- The administrative endpoint is still a pending decision proposal on GitHub (28th July 2018). Clarity on reporting requirements is necessary so we have time to build the required capability in time for 1 July 2019 compliance.
- Authorisation Flows
- We understand that these proposals will be considered more fully in the information security working groups and welcome additional workshops to facilitate this discussion.
ghost
AmexAUopenbanking
UltradataOpenBanking
JamesMBligh
ellenbroad
This thread is for feedback on the full 2 November working draft. Overarching feedback on the draft can be made here, and complete responses to the draft in .doc format can also be uploaded.
Updated 11 November 2018 Thanks to everyone who is already adding feedback to this thread. With organisations having three weeks to respond to the working draft in full, we're going to hold off on deeply engaging with this thread until after the 23rd November. We are watching and monitoring and absorbing feedback, so please do keep it coming. Cheers, Ellen