Decision Proposal 023 - Initial directions to towards establishing security profiles for Australian banking

[camtepe]

UK has published a security profile based on the OpenID Foundation’s (OIDF) Financial API Read+Write specification document. This decision proposal aims to determine the way to use the UK results towards establishing security profiles for Australian banking.

Feedback is now open for this proposal. Feedback is planned to be closed on the 1st of October.

Decision Proposal 023 - InfoSec initial directions.pdf

[WestpacOpenBanking]

Westpac supports a variant of Option 1. That is, follow the UK standard with minor modifications. Any modifications should ideally be sourced from the FAPI standards and provide an increase in security. If Australian localisation is required, there should be very clear justification as why Australia is different to other geographies. This option removes the danger of needing to partially (option 2) or fully (option 3) re-invent the wheel. Specifically, Westpac supports the use of MTLS – mutually authenticated TLS – because of the security benefits this brings.

[Promysys]

Disclaimer our business Priviti, is focused solely in the area of Consent Management.
I'm also here primarily representing the AIIA and this comment whilst is relevant from an industry standpoint (to benefit the Consumer) it is biased towards the need to explicitly call out Consent as an important element in the broader Consumer Data Right which applies across all industries and not just Open Banking.

In our experience in the UK, the widespread adoption of Oauth has lead to expensive custom build projects that have not delivered a good user experience and the desired effects of increased competition and ability to share data has been very limited as evidenced by the scant array of providers and services using open banking,

To the banks who must comply with regulation, OAuth is a standard that requires a custom build from an internal team and does not easily connect with other systems particularly when it comes to managing user preferences, actions and consent. Newly regulated PISPs and AISPs have had to integrate with nine custom and different systems within the CMA9 and this has led to high barriers to entry for new service providers and as such reduced adoption.

We would recommend that Consent Management be added to the proposed Option 2 to ensure that appropriate consideration is given to bi-directional, granular consent for data sharing. Privacy should be by design rather than an afterthought as this will serve customers, TPPs and ASPSPs as we endeavour to introduce fair competition, financial choice and stability to the Australian citizens.

Attached is the relevant Consent application from the UK Open Banking standards to provide further background.

(https://www.openbanking.org.uk/wp-content/uploads/Consent-Model-Part-1-Implementation-Guide.pdf ) https://www.openbanking.org.uk/wp-content/uploads/Consent-Model-Part-2-User-Experience-Guide.pdf

[commbankoss]

CommBank is advocating for a derivative of Option 2. Option 1 presents unwarranted complexities in the Australian environment and timeframes preclude Option 3. The elimination of Option 3, whilst a practical necessity, is unfortunate from the perspective that it could provide scope to consider adoption of protocols such as UMA 2.0 that were not available to the OBIE at the time the UK standards were set, and could address the clear use case of delegated authorisation.

Accordingly, we believe the most pragmatic course is to use the FAPI specification over the top of the OIDC profile. We believe this is likely to be acceptable to both Data Holders and Data Recipients given OIDC is broadly supported across multiple programming environments. UMA 2.0 has not yet achieved the same level of mass adoption

We have the following comments on potential changes to the UK Standards:

• MTLS/MASSL should still be recommended or required between parties involved in CDR Relying purely on MTLS/MASSL makes too many assumptions on how participants have set up their network perimeter, particularly as it relates to DDoS prevention, which may negate some of the security benefits intended with MTLS use

• In addition to MTLS/MASSL, it is strongly recommended that private_key_jwt Client Authentication should be standardised to use certificate based authentication as part of OAuth Token requests in a “belt and braces approach” to identifying TPPs

• Authentication between the PSU and ASPSP Authorisation should not specify that a redirect is required (as is the case in https://openbanking.atlassian.net/wiki/spaces/DZ/pages/127009546/Account+and+Transaction+API+Specification+-+v2.0.0) and provide discretion for ASPSPs to determine their own authentication approach, including both de-coupled and redirect models.

[NationalAustraliaBank]

NAB considers the outcome of this proposal to be foundational to the overall success and integrity of the scheme, with this in mind a considered approach will need to be taken.

Customer privacy and data security are in the front of our minds, and as such we are advocating that we move at the speed of safe.

NAB broadly agrees with the feedback provided by CommBank, with the following elaborations:

• There are significant differences between what the CDR is trying to achieve in Australia as compared to the mandate of Open Banking in the UK; thus a lift and shift would not be compatible, especially given extensibility considerations for other industries. We advocate a variant of Option 2 which will allow us to leverage other proven/leading standards.

• We are not comfortable endorsing a security approach that is loosely defined. We would prefer to work through the details until their implications are well understood for consumers, providers and customers alike.

• We agree that MTLS/MASSL is required, but will not be the only security control in place.

• Of the possible authentication methods available:

  • We do not support the notion of an implicit authentication model due to a number of security vulnerabilities.

  • We agree that data providers should be allowed to innovate around variants of the redirect or decoupled approaches. In this case innovation around security and customer experience can only benefit the scheme.

• There are a number of global initiatives currently underway which we should look to leverage, of particular interest within (FAPI) is the Client Initiated Backchannel Authentication Profile (CIBA)

https://bitbucket.org/openid/fapi/src/a9e55356b5f233af804227d5001d3c32d23d1a91/Financial_API_WD_CIBA.md

• Also, please note that the FAPI Working Group's - OpenID Implementer’s Draft is open for public review until the October 15, 2018. The timing of this review period is opportunistic given our ability collectively influence its direction.

https://openid.net/2018/08/30/fapi-wg-recommends-the-part-1-2-and-jarm-drafts-for-the-implementers-draft-public-review-period-has-started/

[bazzat]

As may be inferred from the above comments the ABA Open Banking Technical Working Group did not come to a consensus position on this DP. While there was qualified support for Option 2 there were also members who stated a preference for the arguably lower risk of Option 1. There was consensus on the need for more details on the proposed use of MTLS.

[TKCOBA]

COBA supports Data61’s recommended approach to follow the UK security profile fundamentals with appropriate changes for the Australian context (Option 2).

[ellenbroad]

Thank you everyone for the feedback so far.

@WestpacOpenBanking: we understand the existing UK information security profile will be updated to reflect FAPI more closely in the near future - by supporting option 1, are you suggesting close adherence to FAPI? This is what we intended with the proposal in Option 2 but may not have articulated that clearly. I've interpreted your concerns regarding Option 2 being were we to reinvent or re-write parts of the FAPI specification (in effect creating a new standard).

@DermotMcCann consent management is very much a cross-cutting consideration for all groups. Language and expectations around consent will be explored in the user experience work stream, and the API standards working group has examined authorisation granularity in for example, 005. We'll share more information about deliverables coming up in the UX work stream over the coming week, and it's of course relevant to expectations around authorisation. Regarding the use of OAuth: OAuth is one of the core protocols underpinning FAPI, and widely used beyond the banking sector. If we choose not to use OAuth, we would be getting into Option 3 territory (designing our own solution). Am I right that of the three proposals, Option 3 is the one you support?

[WestpacOpenBanking]

@ellenbroad The UK standard is being updated to more closely reflect the FAPI read and write security profile. We are suggesting adherence to FAPI R+W, not the read only profile identified in Option 2.

[da-banking]

We support Option 2. MTLS is a necessity and we would expect "The Register" operated by the ACCC to act as a Certificate Authority in this regard for accredited data consumers.

[jh-a]

As the (until recently) Product Owner for the OBIE / UK Security Profile, it is important to understand the historical context. This profile https://bitbucket.org/openid/obuk/src/f7d1f6eb7b06658e890e9a1ee18965821f375911/uk-openbanking-security-profile.md?at=master&fileviewer=file-view-default was developed as a derivative of FAPI, Core OpenID Connect and OAuth2, as there were elements of these that the principle IAM product vendors found difficult to accommodate in March 2017. These difficulties have now been overcome.

The UK has now adopted FAPI parts 1&2 v2 (see https://openbanking.atlassian.net/wiki/spaces/WOR/pages/556335308/167 for a record of this decision); these can be viewed at https://openid.net/2018/08/30/fapi-wg-recommends-the-part-1-2-and-jarm-drafts-for-the-implementers-draft-public-review-period-has-started/ To this extent the concept of a UK specific security profile is now largely redundant, and will become increasingly so as implementers reconfigure their systems to align to FAPI.

Please note that the UK Customer Experience Guidelines have now been published and should be the current point of reference as to the approach being taken to consent management. ( @DermotMcCann pls note - those docs you've linked to have been superseded by this, and I believe now resolve to the CEG anyway) This is a separate issue, and the security profiles are relatively (or completely in the case of FAPI) agnostic of these.

The views expressed in relation to the experience building integration with each of the 9 banks in the UK do not tally with my direct experience, as the owner of the Security Profile Conformance Suite and Certification Framework in the UK, additionally now as technical advisor to the Financial Data and Technology Association (FDATA). There have undoubtedly been challenges, but these have largely resulted from incorrect interpretation of standards. If anything, the adoption of OAuth2 as the framework for consent management makes the whole piece easier, as there are so many off-the-shelf products for facilitating this.

For an in depth view of some of the challenges faced in the UK, I'd recommend a look at https://github.com/openbankingspace/tpp-issues/issues

[RalphBragg]

@ellenbroad Speaking with my Open Banking Implementation Entity - Standards and Security Architect hat: The OBIE security profile will phased out and the UK will align with the OIDC Implementors Draft 2 of the FAPI RW profile which describes primarily how Third Parties communicate, identify and authenticate themselves securly to the Authorization Servers / Open ID Provider hosted by the banks. The agreement to align to the international "gold standard" of OAuth 2.0. based security was unanimously agreed by all representatives of the CMA9 and OBIE Technical Design Authority. The timelines for the migration and conformance is being impact assessed by each of the CMA9.

For absolute clarity, the FAPI RW security profile does not describe all of the security requirements for the protection and serving of Open Banking UK APIs / resources. These requirements will be moved, as part of the FAPI Alginment, from the OB security profile into the API Definitions.

The resource security requirements of the UK API are broadly inline with the comments above, MTLS, Use of Token Bound Access Tokens (Certificate pinning) etc. These requirements will need to be detailed in the Australian functional API definitions.

Finally, the recommendations included in the position paper did not include an option for adopting FAPI RW but only FAPI Read. Significant elements of FAPI RW would need to be borrowed from the RW profile in order to "complete" the capabilities of an Authorization Server / OpenID provider necessary to address the requirements outlined in decision proposal https://github.com/ConsumerDataStandardsAustralia/open-banking/files/2327001/Decision.Proposal.005.-.Authorisation.Granularity.pdf however I note that a lot of the useful requirements and needs called out in the Customer Experience Guidelines. e.g Time Based access to resources, was removed from the final decision 005.

The removal of these considerations are material and have a direct impact on the requirements for the security and authorization** profile requirements.

Ralph Bragg Raidiam Senior Partner OBIE UK - Ecosystem Security and Trust Framework Architect Open ID Foundation FAPI WG

[jogu]

Aligning to the latest FAPI-RW drafts (and/or UK OpenBanking security profile) would make a lot of sense to me. If you stray too far from these, then the IAM vendors are unlikely to have out of the box support for it, which would extend timelines and make the roll out process far more traumatic.

The additional benefit will be that you would be able to reuse the open source conformance suite that was built by OpenBanking that covers the OpenBanking Security Profile, and is currently being extended to test FAPI-RW. The conformance suite has been a vital mechanism for helping the banks discover where they are not following the specifications correctly; the conformance suite found interoperability or security issues at every bank.

Joseph Heenan CTO, fintechlabs.io OBIE UK - lead on security profile conformance suite Open ID Foundation FAPI WG

[RalphBragg]

Hi,

As an update to my comment earlier, i note in the ACCC Consultation on the rules framework, Page 33, Chapter 8 "Consent" that the requirement for multi-dimensional consent has been called out. There are significant challenges trying to shoe-horn into a single scope, scoped access to resources that is essentially multi-dimensional. The "request object" referenced in FAPI RW is one way to tackle the requirement for complex consent.

https://www.accc.gov.au/system/files/ACCC%20CDR%20Rules%20Framework%20%28final%29.pdf

The ACCC proposes to make rules to the effect that an accredited data recipient must obtain a consumer’s consent to both collecting, and using, specified data for specified purposes and for a specified time.

Ralph Bragg Raidiam Senior Partner OBIE UK - Ecosystem Security and Trust Framework Architect Open ID Foundation FAPI WG

[JamesMBligh]

To aid workload in the Data61 team I'm helping out temporarily to facilitate the security decisions to closure for the draft standard.

This proposal has now been open longer than anticipated as the feedback was still constructive and this decision is foundational for the security working group. It will now be closed and a final decision will be provided to the Chair of the Data Standards Body for review.

Based on the feedback the decision will likely be aligned to option 2 with the following clarifications:

• An emphasis that we will only be diverted from established FAPI standards where there is a strong local need. There is no intention of creating a FAPI plus for Australia.
• We will use the FAPI Read/Write profile as a base

Much of the rest of the feedback was really commentary on specific decisions around authorisation and authentication so they will be picked up under those decisions.

-JB-

[JamesMBligh]

The finalised decision for this topic has been endorsed. Please refer to the attached document. Decision 023 - InfoSec initial directions.pdf

-JB-