Decision Proposal 182 - InfoSec Uplift for Write

[CDR-API-Stream]

This decision captures the outcome of the consultation on Information Security uplift. The Data Standards Chair has approved this decision. The decision record is attached below:
Decision 182 - Information security uplift for write - Final.pdf

---

This decision proposal outlines a series of questions regarding the CDR Information Security profile with the intent of obtaining feedback to inform future consultations.

The consultation draft for this decision proposal is attached below:
Decision Proposal 182 - InfoSec Uplift For Write.pdf

Feedback is now open for this proposal.

[biza-io]

Given work continuing at pace for a July 1 delivery date Biza.io requests this consultation be extended by 2 weeks to allow active market participants time to sufficiently focus on the problem space.

[CDR-API-Stream]

We are happy to extend the consultation period and very conscious of the upcoming implementation dates. The issue description has been modified to extend the consultation period.

[CDR-API-Stream]

The DSB has been conducting a review of normative standards. As part of this review process, notably the Pushed Authorization Requests specification and FAPI 1.0 profile have been updated. FAPI Part 1 and Part 2 analysis is provided below.

The DSB would welcome any input on impacts and implementation considerations as well as transition approaches. A summary of the changes over the FAPI Draft 06 to FAPI 1.0 profile will be provided in coming weeks along with the PAR analysis. This feedback may be provided in response to this decision proposal or made to the ongoing consultation conducted via Decision Proposal 203. Given the overlap of subject matter with this decision proposal, the relevant analysis is cross posted here:

• FAPI Part 1 Analysis
• FAPI Part 2 Analysis

Please also note the OIDF has conducted an analysis of FAPI ID2 (essentially what the CDS refers to as Draft 06) to FAPI 1.0.

[AusBanking2]

The ABA requests a two week extension to assess and answer the additional questions raised by the DSB in the FAPI analysis ( #182 (comment)). Additionally, ABA non-major banks require additional time to consider the ABA response in light of their 1 July go-live..

[CDR-API-Stream]

Hi @mufambisi, the material was cross posted here, however we'd ask that all feedback regarding the normative standards analysis be provided directly to #203.

[CDR-API-Stream]

Hi @AusBanking, we are happy to extend it for an additional two weeks to allow non-major banks the additional time for consideration. The issue description has been updated to extend to consultation period.

[PratibhaOrigin]

Thanks for providing us the opportunity to provide feedback on this topic.

Some inputs from Origin to the questions raised by DSB in the consultation -

1. Question 1 – What are the existing gaps or concerns with the information security profile?

• The lack of JWT Secured Authorisation Response Modes to encode responses. This is useful in further protecting the integrity of authorisation server responses through signing of the response object and confidentiality through encryption.

• The lack of PKCE for all authorisation request flows. Widely accepted guidance has been to use PKCE on all flows to prevent authn code injection attacks.

2. Question 2 – What gaps or concerns with the information security profile would prevent voluntary extension to write operations by a data holder?

• The above.

3. Question 3 – What aspects of version 1.0 of the FAPI Advanced Security profile, if any, should be prioritised for adoption by the CDR?

• It appears only JARM is outstanding for the FAPI Advanced security profile.

4. Question 4 – What priority should be given to transitioning to FAPI 2.0?

• As FAPI 2.0 is still in draft, it is our view that the full implementation of FAPI 1 Advanced profile must be prioritised over adoption or move towards FAPI 2.

6. Question 6 – What additional changes, if any, that should be considered for maximising international operability?

• Alignment of the security profile to other larger schemes such as Open Banking in Europe or full alignment with a specific profile e.g. FAPI 1. This would simplify compliance by vendors from other jurisdictions as the standard is known and well understood.

7. Question 7 – What steps could be taken by the DSB to assure the efficacy of the information security profile?

• Participant certification program against the security profile.

[AusBanking2]

The ABA is pleased to submit the attached position paper for the infosec uplift for write.
Responses to the questions posed in this DP are also contained within the document.

In summary the ABA recommends:

1. Adopt FAPI 2.0 for future best practice:
   The CDR should move to adoption of the FAPI 2.0 family of specifications as soon as possible, to future-proof the entire ecosystem, future implementations and to promote the benefits of international best practise.

2. Ensure and Preserve Interoperability:
   a. CDR should support interoperability with relevant global open standards.
   b. CDR should adopt global open standards as issued and without customisation wherever possible
   c. Where deviations to the standard are deemed necessary:
   i. To request first that they be incorporated in the relevant global standard to continue to ensure interoperability.
   ii. To ensure that any unique local changes follow a robust and transparent change process and are by exception.

To support an efficient adoption of the FAPI 2.0 family, we recommend:
Immediate: Publication / clarification of timelines around the current requirements to upgrade from FAPI 1.0 (v6) to FAPI 1.0 (FINAL), in order to keep current standards up-to-date and secure.

<3 months: Consult ecosystem to confirm and publish preference and plan for adoption of the Grant Management API extension and RAR to support fine-grained consent

<6 months:
• Review maturity of proposed standards, vendor implementation plans and support, and participant development pipelines
• Confirm requirement to adopt the FAPI 2.0 family of specifications, within a suitable timescale, via a phased approach
• Confirm timescales for retirement of the unregistered Australian custom OAuth 2.0 extensions (to support international alignment and harmony).
20210723 - ABA InfoSec Standards - Position Paper - FINAL.pdf

[commbankoss]

Commonwealth Bank supports AusBanking's response.

[WestpacOpenBanking]

Westpac welcomes the opportunity to comment on the information security profile. We have the following comments on the questions posed by the Data Standards Body:

Question 1 – What are the existing gaps or concerns with the information security profile?

We do not recommend further changes to the security profile unless they are critical security defects. We are supportive of eventually migrating to the technical approach recommended by the ABA.

Question 2 – What gaps or concerns with the information security profile would prevent voluntary extension to write operations by a data holder?

We consider a robust solution to fine-grained consent to be a prerequisite to write access. Other lesser items are: idempotency behaviour for POST resources is not defined, improved provision for consent of two-to-sign accounts (or more), message signing is not defined (may not be needed - depends on the non-repudiation requirements in the liability framework)  

We also note that there are some non-technical blockers to write access, such as a clear and robust liability framework.

Question 3 – What aspects of version 1.0 of the FAPI Advanced Security profile, if any, should be prioritised for adoption by the CDR?

Westpac is supportive of the position put forward by the ABA.   We do however, recognise the value of formally adopting the FAPI conformance tests and may be supportive of small changes to make this work.

Question 4 – What priority should be given to transitioning to FAPI 2.0?

Westpac is supportive of the position put forward by the ABA.

Question 5 – What additional patterns or normative standards should be considered for adoption to reduce the risk of write operations?

Transactional signing, step-up authentication and push to approve or all implemented on the Data Holder side so we do not expect any international standards to apply.

Decoupled authentication is defined in FAPI by the CIBA flow. We are supportive of investigating CIBA as it is one of the few options of achieving a LoA 3 / Credential Level of 2 with minimal impact on the customer experience. We do not support other protocols without open standards (e.g. 3DSecure).

Potentially more pressing is the ratification of RAR. And, to allow ADRs to know the status of the payment initiation instruction, the FAPI Grant Management API.  

We remark that the UK’s approach to this – modelling a payment consent as an explicit resource – may be better solution to this because it allows interoperability between the payment consent, funds confirmation and payment execution steps.

Question 6 – What additional changes, if any, that should be considered for maximising international operability?

We understand that the DSB is engaging with the international standards bodies on standards development. Areas we would suggest to cover as part of this engagement include:

• Looking at approaches to expedite the ratification process.
• Work with the FAPI working group to close the gaps with the standards which have been found through implementing CDR in Australia.
• Seek input from the working group on how to extend the standard for requirements unique to the CDR. For example the use of Security Event Tokens (SETs) (RFC8417) and its applicability to implementing the desired enhanced participant communication changes.
• We recommend that the Data Standards Body involve AUSTRAC and APRA whilst developing technical standards in relation to write access.

Question 7 – What steps could be taken by the DSB to assure the efficacy of the information security profile?

We suggest the following steps:

• having a minimal Security Profile in the standards, instead referencing the international standards.
• focus on security conformance tests for both Data Holders and Authorised Data Recipients to ensure robust implementation of the standards

[NationalAustraliaBank]

NAB supports the ABA paper above with the following additional feedback.

• In terms of authentication, we believe that DHs should be able to "innovate within a framework" eg. some banks may want to do biometric authentication or other mechanisms. We believe it is important from the customer's perspective to maintain consistency of experience with what they are used to.
• We recommend standards to support other authentication flows like CIBA.
• NAB believes the information security profile should to be extended include data sharing by ADRs to other parties (eg. ADR-to-ADR). We believe that consistent technical standards to manage the flow of data across the entire ecosystem is necessary to promote consumer confidence that their data is safe.
• In terms of the question, what aspects of version 1.0 of the FAPI Advanced Security profile, if any, should be prioritised for adoption by the CDR? NAB believe that all mandatory items in the standard must be adopted (ie. no cherry picking) and if any of the optional items are not adopted, these should be spelt out also.

[biza-io]

Biza.io believes that this discussion is intrinsically linked to the discussions contained within DP191, NP200 and DP183 as well as more broadly related to the current Treasury Consultations on Rules V3. On this basis we intend to respond to all of these items with linked papers.

As a consequence of the volume of considerations between these items we request the closure time for submissions be extended to 30 July 2021.

[ttranatping]

Ping Identity supports the ABA paper above with the following additional feedback:

• The CDR standards have stabilised, and we’ve reached critical mass. Now is a good opportunity to introduce more rigor and governance when modifying the specifications.
• There should be a focus on global interoperability and standardisation. This will increase mindshare and ability to execute.
• For the following reasons, Ping Identity recommends transitioning to FAPI 2.0:
  • FAPI 2.0 is a (mostly) welcome simplification and rationalisation of standards.
  • Ping Identity anticipates new ‘ecosystems’ will be pressured to adopt FAPI 2.0 before finalisation or even stabilisation.
  • FAPI 2.0 provides standardised grant management and endpoints.
• For write access, the DBS should define minimum recommendations for authentication, but the standards should provide the flexibility for the participants to manage their own risk and security experience.
• Emerging standards such as RAR, as well as patterns seen globally (such as pre-authorization consent initialisation) should be considered for write access.

[anzbankau]

ANZ supports the ABA response - #182 (comment)

[CDR-API-Stream]

Hi @biza-io, the DSB is willing to extend the consultation until the COB 30 July 2021. The issue description will be updated.

[mikeleszcz]

The OpenID Foundation supports the ABA position paper. Additionally, the OpenID Foundation strongly encourages requiring FAPI conformance via FAPI certification to ensure secure and interoperable implementations. This benefits the ecosystem as a whole including establishing consumer confidence through the safe handling of consumer data. The Foundation looks forward to continuing to collaborate with our colleagues in Australia to advance the open banking ecosystem.

More Information
OIDF FAPI Working Group
OIDF Certification Program
New to FAPI and FAPI certification? The FAPI microsite is a great starting point.

[biza-io]

Please find attached the Biza.io Response to Decision Proposal 182: InfoSec Uplift for Write:
DP182 - InfoSec Uplift for Write.pdf

While the content of our submission covers a broad range of areas we restate our suggested timeline for standards adoption as follows:

Immediately:

• We do not believe these changes will have any significant impact on the ecosystem at this stage:
  • Mandate Request Object lifespan constraints immediately
  • Mandate PAR request_uri reuse restrictions
  • Mandate multiple brands as separate issuers
• Introduce PKCE support and therefore response_type of code only (without ID Token)

Within 3 months:

• Mandate PAR only Request Object submission

Within 6 months:

• Mandate PKCE+PAR support
• Align PAR adoption to Draft-09
• Introduce optional FAPI CIBA support

Within 9 months:

• Mandate complete alignment to FAPI 1.0 Part 1: Baseline (Final) and FAPI 1.0 Part 2: Advanced (Final) profiles;
• Formally adopt as Optionally supported the FAPI 2.0 specifications :
  • FAPI 2.0: Baseline Security Profile
  • Grant Management for OAuth 2.0
• Deprecate FAPI 1.0 profiles

Within 15 months:

• Mandate complete adoption of FAPI 2.0 profiles;
• Retire FAPI 1.0: Final

[CDR-API-Stream]

Thank you to everyone who has put forward feedback. Consultation has been closed and feedback will now be reviewed and considered.

[CDR-API-Stream]

The Data Standards Chair has approved this decision. The decision record is attached below:
Decision 182 - Information security uplift for write - Final.pdf