Decision Proposal 209 - Transition to FAPI 1.0 Advanced Profile

[CDR-API-Stream]

December 16 2021: Decision Made
This decision was approved by the Data Standards Chair on 16 December 2021. The decision record is attached below:
Decision 209 - Transition to FAPI 1.0 Advanced Profile.pdf

---

10th November 2021: Decision Proposal 209 Feedback Consultation Date:
The feedback consultation date has been extended to the 19th of November 2021.

18th October 2021: Decision Proposal 209 Published:

This decision proposal outlines a a proposal for the transition of the CDR Information Security profile to adopt FAPI 1.0: Baseline and Advanced (Final) profiles as well as RFC9126 (Pushed Authorization Requests).

The decision proposal is attached below:
Decision Proposal 209 - Transition to FAPI 1.0 Advanced Profile.pdf

This consultation will be open for feedback until the 19th November 2021 16th November 2021.

---

2nd September 2021 placeholder requesting early feedback was published:
Placeholder for a decision proposal outlining the transition of the CDR Information Security profile from Financial-Grade API (FAPI) Implementer's Draft v06 (ID2 Draft 06) to FAPI 1.0 Final. Further details are available in Future Plan Item 46.

A decision proposal will be posted here once developed. In the meantime any feedback suggestions for inclusion in the decision proposal are welcome.

Some initial feedback has been received in submissions to Decision Proposal 182 and Normative Standards Review 203. A preliminary gap analysis has also been conducted:

• FAPI Part 1 Analysis
• FAPI Part 2 Analysis
• Pushed Authorization Requests (PAR)

[da-banking]

From the part 1 review:

5.2.3 (10) token response scope value shall verify that the scope received in the token response is either an exact match, or contains a subset of the scope sent in the authorization request

This is part of a sublist which is clarified with “If openid is not in the scope value, then the public client”, and appears to be referring to the requested scope – since open banking requires openid anyway, this change does not apply.

Note: Although this now requires clients to explicitly validate the scopes returned 5.2.2 (15) essentially overrides this from the perspective that the CDR uses token responses in the back channel that integrity protected. In this situation, ADR clients would not receive a list of scopes and this leaves consent in a somewhat ambigous state. There is also clearly an onus on the DH to only grant the client the scopes that it supports and not additional scopes it doesn't support. With the phasing of obligations in the ecosystem creates something of an undefined behaviour.

The ambiguity only exists if ADRs are not limiting the scopes they request to what is listed in the data holder’s discovery document when constructing the authorisation request.
For what reason is scopes_supported mandatory to implement if not for an ADR to know exactly what scopes a DH is currently supporting?

From the part 2 review:

PKCE offers some significant advantages vs hybrid flow most notably simplifying the client implementation

I do not understand this statement. As far as I understand it, PKCE is added on top of the request and does not remove requirements on validating the response at the client.
i.e. there will still be hybrid flow, just with PKCE being mandatory instead of optional.
Is this meant to be about the proposal to use JARM instead of hybrid flow later in the analysis?

NOTE: there is a current issue with loss of authorisation code in exchange for tokens causing real production issues in the CDR. Could the introduction of PKCE and the code verifier method alleviate this? Because the code_challenge_method is bound to the authorisation code can the authorization_code be re-usable where it has not been successfully exchanged. Within a window - say 60 seconds or 5 minutes, the authorisation code can be replayed with the code verifier (as proof the client requesting tokens is the client that initiated the request) and the authorization_code is expired upon an authorization_code lifetime. If the authorization_code is replayed the AuthZ Server would issue the same tokens it did (or thought it had) issued the first time.

This would go against the requirement to reject an authorization_code if it has already been used and could potentially open the server to security holes.
A malicious party that somehow obtains a verifier (such as a lookup via a rainbow table on the hashed value) can wait until nearing the end of such a time limit and then “redo” the exchange – it looks fine to the data holder, and the original ADR may not become aware of it until much later (if at all).

8.9 (3) does not allow the same kid to be used by multiple keys within a JWKS

8.9 (3) is a recommendation that the kid is not reused, not a requirement. I am not against it being a requirement for open banking – just that it’s not mandatory by FAPI 1.0 Advanced

From the PAR review:

Should the CDS explicitly define the request_uri must only be used once and cannot be replayed?
Should the CDS explicitly define the upper lifetime of the request_uri?

Yes

Determine the appropriate HTTP status code and oAuth error code to respond with when the request_uri is re-used. Currently presumed this is a 400 (Bad Request) and oAuth error invalid_request or access_denied.

It should be invalid_request_uri, originally defined by OIDC – assuming that enough of the request_uri exists to identify the redirect_uri. Some implementations may have deleted request_uri data immediately after use, so may not be able to redirect back and would instead have to display an error page.

Introduces the new OIDD metadata parameter require_pushed_authorization_requests. Recommended that DHs can choose whether to require this and if so ADRs MUST only use PAR if true. This would give DHs more discretion over security and simplification of implementation. The CDS doesn't need to override or preclude this. If there is a desire to simplify the CDS, it may be preferred to limit the CDS to always require PAR for better interoperability in a many-to-many ecosystem and reduce interoperability choices.

PAR is already required for amendments, and ADRs may need to support it anyway if a DH uses require_pushed_authorization_requests=true
It seems simpler to just mandate PAR for all requests.

2.2.: Drops mention that the request_uri is intended for one time use. There is currently no clause in FAPI 1.0 that restricts this meaning that Authorisation Servers MAY implement the request_uri in such a way that it can be re-used within its lifetime or be recycled. This is still cryptographically bound to the oAuth client however there may be issues where it could be replayed within a short period of time.
Old clause
Since the request URI can be replayed, its lifetime SHOULD be short and preferably limited to one-time use.
NOTE: Should the CDS prevent this, or is this replay not seen as an issue - it may be useful where the client attempts to go through the authorisation flow but encounters a technical issue and can replay the request_uri without re-staging it though this seems to be of little benefit. It is pre-authentication so again, there is limited opportunity for malicious use/replay attack. The only question is whether a simplified authentication flow may be impacted if the consumer is not required to authenticate.

FAPI requires the use of PKCE for PAR requests.
Allowing PAR reuse could potentially allow a situation where two requests are being handled at the token endpoint during authorization_code exchange, the verifier for the second would effectively be known in advance.
Potential security hole.

7.5 Request URI Swapping

Clients SHOULD make use of PKCE [RFC7636], a unique "state" parameter [RFC6749], or the OIDC "nonce" parameter [OIDC] in the pushed request object to prevent this attack.
Hybrid flow already requires the use of a nonce, so this is already covered.
The addition of FAPI 1.0 requiring PKCE does not alter existing implementations WRT to mitigating this (but doesn't hurt either)

[CDR-API-Stream]

The decision proposal has now been published and is attached below:
Decision Proposal 209 - Transition to FAPI 1.0 Advanced Profile.pdf

This consultation will be open for feedback until the 16th November 2021.

[AusBanking]

Hello team,

The Australian Banking Association requests a small extension for the due date for this consultation until Friday 19 November. Would this be possible?

Kind regards
ABA

[CDR-API-Stream]

Hi @AusBanking, we are happy to extend it for an additional three days to the 19th. The issue description has been updated to extend to consultation period.

[PratibhaOrigin]

Thank you for the opportunity to provide feedback on this paper. Please find below our responses to the questions raised in the paper.

1 (a) - Should Refresh token expiry time be pegged to consent duration?
Yes. Under no circumstances should the refresh token be misaligned to the consent duration and having this coupling between the refresh token and consent duration facilitates that. What kind of constraints are experienced with the current coupling of refresh token expiry and consent duration?

1 (b) - Should CDR authorization input parameters be registered or otherwise moved out of the authorization request object? If so, where should they be moved to for better Identity & Access Management (IAM) software supportability?
As energy has not yet commenced development, we are ambivalent about this change. We are however, supportive of moving away from custom extensions to internationally adopted standards . As there is a plan to eventually adopt FAPI 2 (when finalized), this will be resolved. We do not see any urgent need to change the current request. Any immediate change will be temporary and the benefits of such changes may not be realized before the adoption of FAPI 2.

1 (c) - Should CDR token response parameters be registered or otherwise moved out of the parent token endpoint response JSON / ID token JWT? If so, where should they be moved to for better Identity & Access Management (IAM) software supportability?
As energy has not yet commenced development, we are ambivalent about this change. We are however, supportive of moving away from custom extensions to internationally adopted standards . As there is a plan to eventually adopt FAPI 2 (when finalized), this will be resolved. We do not see any urgent need to change the current request. Any immediate change will be temporary and the benefits of such changes may not be realized before the adoption of FAPI 2.

Phase 1
2 (a) - Should the CDS explicitly define the request_uri must only be used once and cannot be replayed?
The request_uri must be used once as this is a more secure and limits the possibility of an attacker successfully reusing the redirect_uri. The possibility of an end user refreshing the page mid-flow is an edge case that must be addressed through UX/CX in a graceful manner without allowing duplicate request_uris.

2 (b) - Should the CDS explicitly define the upper lifetime of the PAR request_uri? If yes, what is the acceptable lifespan (e.g., 60 minutes)?
Yes. The expires_in parameter must be set to a time that we reasonably expect the customer to be present e.g.10mins.

2 (c) - Should the Data Standards make requiring PAR mandatory for all Data Holders and Data Recipients?
Yes. This allows for more complex use cases that may require complex requests in the future.

Phase 3
3 (c) - Should the CDS mandate that the same "kid" is not allowed to be used by multiple keys within a JWKS?
Yes.

[EnergyAustraliaBA]

Please find below EnergyAustralia’s feedback:

We understand that FAPI standards are not the current standard within the energy sector. We recognise the benefits/desirability of moving to FAPI standards, and generally support their adoption. However, Energy Sector Data Holders will need to undertake further detailed analysis on our existing security protocols and frameworks, to understand the complexity of uplifting to FAPI standards in the CDR timeframe.

Re: FAPI 2.0 vs. FAPI 1.0
FAPI 1.0 contains known vulnerabilities and complexity with the implementation. Our understanding is that FAPI 2.0 addresses these concerns and would therefore provide a preferred option in terms of meeting our security goals and reducing attack surface (risks).

FAPI 2.0 provides a higher degree of interoperability and is easier to use while maintaining a comparable security level. FAPI 2.0 aims at on-the-wire compatibility between compliant implementations and to this end removes optional and alternative features.

Delivering FAPI 1.0 does not provide an incremental path to meeting future FAPI 2.0 standards, which are not backwards compatible. We therefore believe that investing in FAPI 1.0 would represent 'regret spend' and 'technical debt', given that FAPI 2.0 will need to be delivered relatively shortly after. Refer to --> DSSB Item - FAPI 2.0 Profile Transition · Issue #47 · ConsumerDataStandardsAustralia/future-plan (github.com)

If FAPI 2.0 is not sufficiently finalised to implement to (although we understand it's at baseline level), we would recommend that the DSB not require any uplift to current requirements until FAPI 2.0 is ready.

[perlboy]

Re: FAPI 2.0 vs. FAPI 1.0 FAPI 1.0 contains known vulnerabilities and complexity with the implementation. Our understanding is that FAPI 2.0 addresses these concerns and would therefore provide a preferred option in terms of meeting our security goals and reducing attack surface (risks).

Complexity agreed but known vulnerabilities? Such as? The FAPI Working Group would be keen to hear these concerns as would CDR participants especially around any not already mitigated through counter-measures prescribed in the Standards.

Delivering FAPI 1.0 does not provide an incremental path to meeting future FAPI 2.0 standards, which are not backwards compatible.

Actually achieving FAPI 1.0, particularly the use of PKCE which would be required since CDR mandates PAR, gets implementers 80% of the way there to FAPI 2.0 Baseline. It is unclear how this isn't an incremental path.

FAPI 2.0 will need to be delivered relatively shortly after. Refer to --> DSSB Item - FAPI 2.0 Profile Transition · Issue #47 · ConsumerDataStandardsAustralia/future-plan (github.com).

I feel there's some confusion occurring here regarding what FAPI 2.0 is. FAPI 2.0 is a family of specifications forming a Trust Framework which includes two security profiles (Baseline and Advanced) plus multiple other intended functional specifications (such as Grant Management) driven by observed requirements in a variety of open data sharing ecosystems (UK OB, CDR, Brazil OB and a number of PSD2 triggered implementations).

If FAPI 2.0 is not sufficiently finalised to implement to (although we understand it's at baseline level), we would recommend that the DSB not require any uplift to current requirements until FAPI 2.0 is ready.

For clarity, FAPI 2.0 Baseline is the profile name and it has achieved Implementers Draft status much like a large number of other specifications already in use worldwide. It is true it is not finalised however it is certainly intended to be Final in the timeframes associated with Energy sector compliance. The differences between Baseline & Advanced are focused on message integrity and non-repudiation requirements and Advanced is intended to layer on Baseline.

[da-ay]

Under “Transition Approach, Phase 1, PKCE Support”:

This is mixing support for PKCE and support for response_type=”code”

PKCE only requires that an authorization_code is being utilised and therefore can be used with response_type=”code id_token”.

Similarly, while PKCE is described as being used for OAuth2 public clients it does not forbid its use by confidential clients

It is commonly supported by OAuth2/OpenId solutions and it is likely that several data holders already advertise support for PKCE but do not support response_type=”code”; they would be in conflict with the proposed change after 1st March 2022 if they do nothing.

Support for response_type=”code” should be a separate change that is determined via discovery under “response_types_supported”, not via the support for PKCE.

[anzbankau]

ANZ supports the transition to FAPI 1.0. We propose an implementation approach where the standards become mandatory in a single phase, however could be optionally adopted by participants earlier where possible. ANZ proposes that the obligations become mandatory by 1 October 2022 to allow for minimum of 6 months lead time from when standards are published, as well boarder vendor certification to FAPI 1.0.

[cloudentity-io]

Adherence to the final versions of widely adopted open standards is important. Cloudentity, in general, welcomes the decision proposal of alignment to the final versions of PAR and FAP1.0 standards family.

Adoption of FAPI2.0 should move on in parallel with the proposed alignments.

[biza-io]

Please find attached our response to Decision Proposal 209: Transition to FAPI 1.0 Advanced Profile:
DP209 - FAPI 1.0 Transition.pdf

Biza.io supports the alignment to FAPI 1.0 Advanced as soon as possible and recommends an accelerated adoption timeline. Additionally we make a number of recommendations to enable optional support for functionality (notably JARM and signed introspection responses) permitted in FAPI 1.0 and mandated within the future FAPI 2.0 Framework.

[CDR-API-Stream]

@cloudentity-io, thank you for the feedback. Adoption of FAPI 2.0 is outlined in Decision Proposal 182 and planned for consultation under Decision Proposal 210. Adoption of FAPI 2.0 will be considered based on the functional uplift of the regime and consultation of the approach and obligation dates are yet to be consulted on.

[CDR-API-Stream]

Thank you @anzbankau. The DP considered optional, non-breaking changes, and any required changes to allow ADRs to uplift in an initial phase with transition of ADRs before a final mandatory obligation phase for Data Holders.

We note the 1 October 2022 obligation date and this will be considered with the rest of the feedback.

[CDR-API-Stream]

Hi @da-ay, thank you for the feedback.

Similarly, while PKCE is described as being used for OAuth2 public clients it does not forbid its use by confidential clients

The CDR only deals with confidential clients.

It is commonly supported by OAuth2/OpenId solutions and it is likely that several data holders already advertise support for PKCE but do not support response_type=”code”; they would be in conflict with the proposed change after 1st March 2022 if they do nothing.

Part of the transition is a simplification without the need for the ID token being sent via the front channel or being used as a detached signature as well as lower complexity in a many-to-many ecosystem. This feedback will be considered in the final decision.

Support for response_type=”code” should be a separate change that is determined via discovery under “response_types_supported”, not via the support for PKCE.

Thanks, that is a good point worth noting.

[CDR-API-Stream]

Thank you for the feedback @PratibhaOrigin.

Thank you for the opportunity to provide feedback on this paper. Please find below our responses to the questions raised in the paper.

1 (a) - Should Refresh token expiry time be pegged to consent duration?
Yes. Under no circumstances should the refresh token be misaligned to the consent duration and having this coupling between the refresh token and consent duration facilitates that. What kind of constraints are experienced with the current coupling of refresh token expiry and consent duration?

The potential advantage of decoupling these two considerations is the separation of business (consent) and security logic (tokens). This does not imply that DHs should not be checking the status of consent or the duration remaining for a consumer's consent. Because consent involves more than just a binary check of the active status of a refresh token, DHs should be performing additional checks against the status of any consumer consent associated with a refresh token.

1 (b) - Should CDR authorization input parameters be registered or otherwise moved out of the authorization request object? If so, where should they be moved to for better Identity & Access Management (IAM) software supportability?
As energy has not yet commenced development, we are ambivalent about this change. We are however, supportive of moving away from custom extensions to internationally adopted standards . As there is a plan to eventually adopt FAPI 2 (when finalized), this will be resolved. We do not see any urgent need to change the current request. Any immediate change will be temporary and the benefits of such changes may not be realized before the adoption of FAPI 2.

With the adoption of FAPI 1.0, PAR and PKCE support, the CDR will be largely uplifted to the FAPI 2.0 Baseline profile.
The purpose of the adoption of FAPI 1.0 before November 1st 2022 is to support ADRs integrating with both banking and energy DHs as well as giving energy DHs a stable target state for their initial go-live data sharing obligations with strong vendor support.

1 (c) - Should CDR token response parameters be registered or otherwise moved out of the parent token endpoint response JSON / ID token JWT? If so, where should they be moved to for better Identity & Access Management (IAM) software supportability?
As energy has not yet commenced development, we are ambivalent about this change. We are however, supportive of moving away from custom extensions to internationally adopted standards . As there is a plan to eventually adopt FAPI 2 (when finalized), this will be resolved. We do not see any urgent need to change the current request. Any immediate change will be temporary and the benefits of such changes may not be realized before the adoption of FAPI 2.

See comments above

Phase 1
2 (a) - Should the CDS explicitly define the request_uri must only be used once and cannot be replayed?
The request_uri must be used once as this is a more secure and limits the possibility of an attacker successfully reusing the redirect_uri. The possibility of an end user refreshing the page mid-flow is an edge case that must be addressed through UX/CX in a graceful manner without allowing duplicate request_uris.

Thanks for the feedback.

2 (b) - Should the CDS explicitly define the upper lifetime of the PAR request_uri? If yes, what is the acceptable lifespan (e.g., 60 minutes)?
Yes. The expires_in parameter must be set to a time that we reasonably expect the customer to be present e.g.10mins.

Is Origin proposing 10 mins or are you using this as an example? The DSB is interested in feedback regarding a consistently defined expiry time.

2 (c) - Should the Data Standards make requiring PAR mandatory for all Data Holders and Data Recipients?
Yes. This allows for more complex use cases that may require complex requests in the future.

Thanks for the feedback.

Phase 3
3 (c) - Should the CDS mandate that the same "kid" is not allowed to be used by multiple keys within a JWKS?
Yes.

Thanks for the feedback.

[CDR-API-Stream]

Hi @EnergyAustraliaBA, thank you for the feedback.

We understand that FAPI standards are not the current standard within the energy sector. We recognise the benefits/desirability of moving to FAPI standards, and generally support their adoption. However, Energy Sector Data Holders will need to undertake further detailed analysis on our existing security protocols and frameworks, to understand the complexity of uplifting to FAPI standards in the CDR timeframe.

FAPI standards are required in the energy standards. The Consumer Data Standards rely on the FAPI 1.0 profile. The data standards currently specify Draft 06 (Implementer's Draft 2) as the normative reference. With FAPI 1.0 being made final, this consultation considers the uplift to the final version.

Re: FAPI 2.0 vs. FAPI 1.0
FAPI 1.0 contains known vulnerabilities and complexity with the implementation. Our understanding is that FAPI 2.0 addresses these concerns and would therefore provide a preferred option in terms of meeting our security goals and reducing attack surface (risks).

Thanks for the feedback. If you have known vulnerabilities can you please provide explicit feedback. These can then be shared with the OpenID Foundation and considered in the transition to FAPI 1.0. Noting that the data standards will be largely uplifted to FAPI 2.0 Baseline profile through the migration of the data standards to FAPI 1.0 and adoption of the RFC version of PAR and PKCE perhaps these issues are ameliorated?

FAPI 2.0 provides a higher degree of interoperability and is easier to use while maintaining a comparable security level. FAPI 2.0 aims at on-the-wire compatibility between compliant implementations and to this end removes optional and alternative features.

This is agreed and articulated in Decision Proposal 182. The consensus of feedback recommended the DSB consider a transition path to FAPI 2.0 via FAPI 1.0 Final. This recommendation was adopted by the DSB in line with community feedback.

Delivering FAPI 1.0 does not provide an incremental path to meeting future FAPI 2.0 standards, which are not backwards compatible. We therefore believe that investing in FAPI 1.0 would represent 'regret spend' and 'technical debt', given that FAPI 2.0 will need to be delivered relatively shortly after. Refer to --> DSSB Item - FAPI 2.0 Profile Transition · Issue #47 · ConsumerDataStandardsAustralia/future-plan (github.com)

Can you please articulate how FAPI 1.0 does not provide a transition path? The remaining standards detailed in the FAPI 2.0 profile including Rich Authorization Requests, Client Initiated Backchannel Authentication etc, will provide functional enhancements to the CDR but would not introduce technical debt through the transition to FAPI 1.0. If you have feedback to the contrary, we would welcome more information.

If FAPI 2.0 is not sufficiently finalised to implement to (although we understand it's at baseline level), we would recommend that the DSB not require any uplift to current requirements until FAPI 2.0 is ready.

This will be considered through open consultation in Decision Proposal 210. FAPI 2.0 Baseline is currently in Implementer's Draft. A number of the additional specifications are in RFC however there may be some need to develop FAPI overlays (e.g. FAPI-CIBA). This will be factored into the decision making in respect to those standards and the consultation.

[AusBanking]

ABA submission - DP209.pdf
ABA views attached.

[WestpacOpenBanking]

Westpac supports the ABA’s position with the following additional note:

1a. Modifying refresh token expiry behaviour or cycling behaviour is a large change and appropriate lead times are required.

[CDR-API-Stream]

Feedback has now closed. Thank you to everyone who has provided feedback. The DSB will review the feedback and respond once it has been considered.

[CDR-API-Stream]

Hi @WestpacOpenBanking thanks for the feedback.

1a. Modifying refresh token expiry behaviour or cycling behaviour is a large change and appropriate lead times are required.

Given you are indicating an impact to your DH solution, can you be more specific in what Westpac considers appropriate lead times for your implementation?

[WestpacOpenBanking]

Westpac considers a lead time of six months from when the decision is made as appropriate.

[CDR-API-Stream]

This decision was approved by the Data Standards Chair on 16 December 2021. The decision record is attached below:
Decision 209 - Transition to FAPI 1.0 Advanced Profile.pdf

[CDR-API-Stream]

This decision was incorporated into release v1.15.0.